To perform authorization checking for RACF-protected resources, RACF® makes the following checks. RACF stops processing when the request is granted or denied.

For a pictorial view of the following steps, see Figure 2 through Figure 4.

1. The SAF router exits can grant or deny access before RACF authorization processing occurs.
   Note: Before master scheduler initialization (MSI), this is the ICHRTX01 exit routine. After master scheduler initialization (MSI), this is the ICHRTX00 exit routine.
2. If the entry for the class in the RACF router table has NONE specified, RACF returns the "not protected" return code. This also occurs if the caller specified the REQSTOR and SUBSYS operands on the RACROUTE macro, did not also specify DECOUPL=YES or give the REQSTOR and SUBSYS information in the RACF router table entry.
3. If RACF is not active, RACF returns the "not protected" return code.
4. For general resource classes, if the class of the resource is not active, RACF returns the "not protected" return code.
5. If the RACF class must be RACLISTed, as specified in the class descriptor table (CDT), but is not currently RACLISTed, RACF returns the "not protected" return code.
6. If the user requesting access is "trusted" or "privileged", RACF grants the request. See the following:
   • If the user has the trusted attribute, RACF grants the request (unless the CSA or PRIVATE operand was specified on the authorization request).

     Such requests can be audited only by using the LOGOPTIONS operand on the SETROPTS command (which audits access requests issued by all users) or the UAUDIT operand on the ALTUSER command (which audits all access requests by a particular user).

   • If the user has the privileged attribute, RACF grants the request (unless the CSA or PRIVATE operand was specified on the authorization request). Such requests cannot be audited.
7. RACF invokes the naming convention table if:
   • The naming convention routine exists
   • The resource being checked is a CLASS data set

   The naming convention table can continue REQUEST=AUTH processing or deny the request.

8. The REQUEST=AUTH preprocessing exit (ICHRCX01) can grant or deny the request.
9. If the requesting user has a default user token (created by SAF), RACF denies the request.
10. If SETROPTS MLQUIET is in effect (see Quiescing RACF activity (MLQUIET option)), RACF denies the request unless the user has the SPECIAL attribute, has the privileged or trusted attribute, or is logged on at a system console.
11. If the user ID in the RTOKEN for the resource matches the user ID in the UTOKEN for the user making a request, RACF grants the request. This allows a user to cancel one of the user's own jobs using the TSO CANCEL command without being affected by the user's current security label.

    RTOKEN processing typically applies to resources in the JESSPOOL class, but it might not apply to all JESSPOOL resources based on processing by the application or resource manager.

12. If global access checking is active for the class, RACF searches the global access table (unless the CSA or PRIVATE operand was specified on the authorization request). If RACF finds a matching entry that allows access to the resource, RACF grants the request for all users, except those with the RESTRICTED attribute.
13. RACF looks for a profile in storage or in the RACF database. If no profile is found that protects the resource, RACF returns the default return code of the class. See the entry for the class in the class descriptor table (CDT) described in z/OS Security Server RACF Macros and Interfaces.) Specifically, no profile is found in the following cases:
    • Profiles for the class exist in the user's storage or in a data space, but no profile matches the resource name.
    • Profiles for the class do not exist in the user's storage, in a data space, or in the RACF database.
    Note: If you expect generic profiles to be used by RACF authorization checking, list their profile names using the SEARCH command. If the profile names listed by the SEARCH command are not followed by (G), RACF does not treat them as generic profiles. To recover, perform the following steps:

    1. Issue SETROPTS NOGENERIC(classname).
    2. Issue SETROPTS NOGENCMD(classname).
    3. Delete the profiles. (If the profiles have complicated specifications, such as long access lists, you might want to define "dummy" profiles modeled on them before deleting them. Specify the FROM operand on the RDEFINE command.
    4. Issue SETROPTS GENERIC(classname).
    5. Define the profiles again.
14. If your installation has activated the SECLABEL class, RACF performs security label authorization checking. For a complete description, see Security label authorization checking. If security label authorization checking succeeds, RACF authorization checking continues with Step 16.
15. If the SECLABEL class is not active, the SECDATA class is active, and the requested resource has a security level or security category specified, RACF makes two checks in the sequence described below.
    1. RACF compares the security level (SECLEVEL) in the user profile with the security level in the resource profile. If the resource has a higher security level than the user, or if the user has no security level, RACF denies the request.

       For a terminal session, RACF uses the lower of the user's SECLEVEL and the terminal's SECLEVEL when authorizing access to a resource. For example, if the user has a SECLEVEL of 100 and the terminal has a SECLEVEL of 50, RACF uses the terminal's SECLEVEL during authorization checking. Thus, in this case, the user cannot access, through the terminal, any resource with a SECLEVEL greater than 50. (If the terminal is not defined to RACF or is defined without a SECLEVEL, RACF uses the user's SECLEVEL to determine the resources that can be accessed.)

       If the security level check passes, authorization checking continues with the following check.

    2. RACF compares the list of security categories in the user profile with the list of security categories in the resource profile. If the resource profile contains a security category that is not in the user's profile, RACF denies the request.

       Unlike the security level check, RACF uses only the user's security category list for a terminal session.

    If both checks succeed, RACF continues authorization checking with Step 16.

16. If users attempt to access their own resources, RACF grants the request. For example:
    • For tape and DASD data sets, if the user ID of the requesting user is the high-level qualifier of the data set name, RACF grants the request.
    • For spool data sets, if the JESSPOOL class is active, RACF compares the user ID and node of the requester with the user ID and node of the creator of the spool data set (using the security token). If the user IDs match, RACF grants the request.
17. RACF checks the user's access authority in the standard access list. If the user is in the list and if the specified access authority is sufficient to allow access, RACF grants the request. If the user is in the list and if the specified access authority is less than the requested access, RACF continues processing at Step 22 (conditional access list checking). This prevents access based on ID(*), UACC, or the OPERATIONS attribute.

    This could happen if, for example, user JOE requests UPDATE access, and the standard access list includes ID(JOE) ACCESS(READ).

18. RACF determines whether the user has access to the resource because the user is a member of a group and the group is on the standard access list. Which group is used depends on whether list-of-groups processing is in effect. (List-of-groups processing is in effect if the SETROPTS command has been issued with the GRPLIST operand.) RACF determines which group to use according to the following rules:
    • If list-of-groups processing is not in effect, RACF uses only the user's current connect group.
    • If list-of-groups processing is in effect, RACF finds all of the groups to which the user is connected that are also in the access list. Of these groups, RACF uses the group that has the highest access authority to the resource. (For example, assume that a user is a member of groups A, B, and C. If group A has NONE access authority, group B has READ access authority, and group C has UPDATE access authority, RACF uses group C to determine the user's access.)

      If the highest access authority is sufficient to allow the requested access, RACF grants the request. If the highest group that was found in the list does not have the requested authority, RACF continues processing at Step 22 (conditional access list checking). This prevents access based on ID(*), UACC, or the OPERATIONS attribute.

19. If a user ID of * is found on the standard access list, the current user is defined to RACF without the RESTRICTED attribute, and the access authority granted to * is:
    • Sufficient to allow the requested access, RACF grants the request.
    • Not sufficient to allow the requested access, RACF continues processing at Step 21 (OPERATIONS attribute checking).
20. If the universal access authority (UACC) for the resource provides sufficient access authority and the requesting user is not defined with the RESTRICTED attribute, RACF grants the request.
21. If the requesting user has the OPERATIONS attribute (or group-OPERATIONS if the resource is within the scope of that group) and OPERATIONS access is allowed for the class, RACF grants the request.
22. RACF checks the user's access authority in the conditional access list specified with WHEN(TERMINAL), WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH). If the user is in the list, if the user meets the specified condition (such as logged on at the specified terminal), and if the specified access authority is sufficient to allow access, RACF grants the request. If the user is in the list with insufficient access authority, RACF authorization processing continues at Step 25.
23. RACF determines whether the user has access to the resource because the user is a member of a group that meets a condition specified on the conditional access list specified with WHEN(TERMINAL), WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH). Which group is used depends on whether list-of-groups processing is in effect. (List-of-groups processing is in effect if the SETROPTS command has been issued with the GRPLIST operand). RACF determines which group to use according to the following rules:
    • If list-of-groups processing is not in effect, RACF uses only the user's current connect group.
    • If list-of-groups processing is in effect, RACF finds all of the groups to which the user is connected that are also in the access list. Of these groups, RACF uses the group that has the highest access authority to the resource. (For example, assume that a user is a member of groups A and B. If A has READ access authority and B has UPDATE access authority, RACF uses group B to determine the user's access.)

    If the group to be used according to the preceding rules has sufficient access authority to allow the requested access, RACF authorization processing continues at Step 25. If none of the user's groups has sufficient authority, RACF does not grant the request, and continues with the next step.

24. If a user ID of * is found on the conditional access list specified with WHEN(TERMINAL), WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH), and if the current user is defined to RACF without the RESTRICTED attribute, and if the current user meets the specified condition (such as logged on at the specified terminal), and the access authority granted to * is sufficient to allow the requested access, RACF grants the request.
25. RACF checks the user's access authority in the conditional access list specified with WHEN(PROGRAM). If the user is in the list, if the user meets the specified condition (such as running the specified program), and if the specified access authority is sufficient to allow access, RACF grants the request.
    Note: For DASD data sets, if program control is active and a controlled program is executing, RACF performs authorization checking for program access to data sets. If the user/program combination is in the conditional access list with sufficient authority to allow access to the data sets, RACF grants the request. If the user/program combination is in the conditional access list with insufficient authority, RACF denies the request. For more information, see Authorization checking for access control to data sets.
26. RACF determines whether the user has access to the resource because the user is a member of a group that meets a condition specified on the conditional access list (such as running a specified program). Which group is used depends on whether list-of-groups processing is in effect. (List-of-groups processing is in effect if the SETROPTS command has been issued with the GRPLIST operand.) RACF determines which group to use according to the following rules:
    • If list-of-groups processing is not in effect, RACF uses only the user's current connect group.
    • If list-of-groups processing is in effect, RACF finds all of the groups to which the user is connected that are also in the access list. Of these groups, RACF uses the group that has the highest access authority to the resource. (For example, assume that a user is a member of groups A and B. If A has READ access authority and B has UPDATE access authority, RACF uses group B to determine the user's access.)

    If the group to be used according to the preceding rules has sufficient access authority to allow the requested access, RACF grants the request. If the group is specified in the list with insufficient access authority, RACF denies the request.

27. If a user ID of * is found on the conditional access list specified with WHEN(PROGRAM), and if the current user is defined to RACF without the RESTRICTED attribute, and if the current user meets the specified condition (such as logged on at the specified terminal or running the specified program), and the access authority granted to * is sufficient to allow the requested access, RACF grants the request.
28. If the WARNING flag is ON in the profile (set using the WARNING operand on the ADDSD, ALTDSD, RDEFINE, or RALTER command), RACF grants the request.
29. If SETROPTS CATDSNS(FAILURES) is in effect, RACF denies the request unless at least one of the following is true:
    • The data set is newly created in this job, or is a system temporary data set.
    • The data set is on tape, and the request is for UPDATE access.
    • The data set is protected by a discrete profile.
    • The data set is cataloged in the master catalog.
    • The user has access to FACILITY resource ICHUNCAT.data-set-name (truncated to 39 characters, if necessary).
    • The user has the SPECIAL attribute.
      Note: If the user gains access through having the SPECIAL attribute and none of the prior conditions were true, RACF issues a warning message and creates an SMF record as though CATDSNS(WARNING) were in effect.
30. The postprocessing exit (ICHRCX02) can grant or deny the request.
31. For the DATASET class, if no profile is found and the SETROPTS PROTECTALL(FAILURES) option is in effect, RACF denies the request. If no profile is found and the SETROPTS PROTECTALL(WARNING) option is in effect, RACF grants the request.