|
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.
- 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.
- 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.
- If RACF is not active, RACF returns the "not protected"
return code.
- For general resource classes, if the class of the resource is
not active, RACF returns the
"not protected" return code.
- 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.
- If the user requesting access is "trusted" or "privileged", RACF grants the request. See the
following:
- 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.
- The REQUEST=AUTH preprocessing exit (ICHRCX01) can grant or deny
the request.
- If the requesting user has a default user token (created by SAF), RACF denies
the request.
- 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.
- 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.
- 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.
- 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: - Issue SETROPTS NOGENERIC(classname).
- Issue SETROPTS NOGENCMD(classname).
- 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.
- Issue SETROPTS GENERIC(classname).
- Define the profiles again.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- If SETROPTS CATDSNS(FAILURES) is in effect, RACF denies the request unless at
least one of the following is true:
- The postprocessing exit (ICHRCX02) can grant or deny the request.
- 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.
|