Postprocessing exits (ICHRFX02 and ICHRFX04)

There are two RACROUTE REQUEST=FASTAUTH postprocessing exits: ICHRFX02 and ICHRFX04. Figure 1 shows the logic that RACF® uses to determine which exit to call.

Note: For a nested ACEE, although two authorization checks might be internally driven, ICHRFX04 is only called once, after both checks have completed. It does not matter whether the nested ACEE is processed; for example, if the client is authorized or the resource is not delegated, ICHRFX04 is still called. For information about nested ACEEs, see the section on delegated resources in z/OS Security Server RACF Security Administrator's Guide.

Figure 1. Logic that determines whether ICHRFX02 or ICHRFX04 is called

if cross memory mode, or ACEEALET or ENVRIN or CRITERIA is specified, 
   or the class is UNIXPRIV or FSACCESS, 
   or a nested ACEE is provided by a supervisor state or system key caller

  then

   only call ICHRFX04

else

   if RACLISTed by RACROUTE REQ=LIST, GLOBAL=YES or RACLISTed by SETR RACLIST
      or the class is in the dynamic class descriptor table

   then

      call ICHRFX04 first and then call ICHRFX02

   else

      only call ICHRFX02

The sequence of pre- and post- processing exit invocation, FASTAUTH authorization processing, and auditing (when FASTAUTH performs auditing due to LOG=ASIS or LOG=NOFAIL), is:

Conditions	Processing sequence
Regardless of how the class is RACLISTed: Cross-memory, or The ACEEALET keyword is specified, or The ENVRIN keyword is specified, or The CRITERIA keyword is specified, or The UNIXPRIV class, or The FSACCESS class, or A nested ACEE	ICHRFX03 Auth processing ICHRFX04 Auditing
Non-cross-memory and the class is RACLISTed by RACROUTE REQUEST=LIST,GLOBAL=NO	ICHRFX01 Auth processing ICHRFX02 Auditing
Non-cross-memory, and the class is in the dynamic class descriptor table or the class is RACLISTed by RACROUTE REQUEST=LIST,GLOBAL=YES or by SETROPTS RACLIST Note that RACF performs logging based on the return and reason code set by: ICHRFX01 or ICHRFX04, if they exist If ICHRFX01 and ICHRFX04 do not exist, by one of the following: The default return code defined for the class in the class descriptor table (CDT) FASTAUTH processing done before ICHRFX02 gets control Any return and reason code set by ICHRFX02 in this case is not reflected in the auditing done by FASTAUTH, but is processed as described in ICHRFX02.	ICHRFX01 Auth processing ICHRFX04 Auditing ICHRFX02

Default return code processing occurs prior to auditing. If the profile was not found and the postprocessing exit did not change the return code, FASTAUTH uses the default return code from the class descriptor table (CDT). The default return code, if used, is reflected in the auditing done by FASTAUTH.