Authorizing access to consoles, JES input devices, APPC partner LUs, or IP addresses

When a RACF-defined user logs on to a JES or MCS console, submits a batch job from a JES input device, submits an APPC request from a partner LU, or accesses the network through an IP address, RACF® can perform authorization checking to verify that the user is permitted use of the RACF-protected console, JES input device, partner LU, or IP address. RACF performs this authorization checking during REQUEST=VERIFY processing at the same time as it performs user identification and verification. For RACF to perform this authorization checking, your installation must activate the appropriate class, as follows:

For JES or MCS consoles, activate the CONSOLE class.
For JES input devices, activate the JESINPUT class.
For APPC partner LUs, activate the APPCPORT class.
For IP addresses, activate the SERVAUTH class.

The resource must be protected by a profile in the appropriate class. If no profile exists for the resource, RACF fails the request.

Note:

If the resource is a terminal, console, partner LU, JES writer, or IP address, RACF compares the security level of the user with the security level of the resource. If the resource has a higher security level than the user, RACF denies the request. For a terminal session, the security level that RACF uses for the user is the lower of the user's SECLEVEL and the terminal's SECLEVEL. Thus, if the terminal has a SECLEVEL of 50 and the user has a SECLEVEL of 100, the user cannot access through that terminal any data that has a SECLEVEL of over 50.
RACF compares the list of security categories in the user's profile with the list of security categories in the resource's profile. If RACF finds any security category in the resource profile that is not in the user's profile, RACF denies the request. If RACF does not deny the request, RACF continues with authorization processing. If there are no categories in the resource profile, RACF continues with authorization processing.

The rest of this topic uses the term device authorization checking to refer to the authorization checking done for any of the above resources.

RACF performs device authorization checking in the following sequence:

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 the next step.
If the requesting user has at least READ access authority to the device, RACF grants the request with no further processing. If the user's access authority is NONE, RACF denies use of the device and stops device authorization checking. If the requesting user is not in the access list, device authorization checking continues with the next step.
If the requesting user's current connect group (or, if you activate list-of-groups checking, one of the user's other connect groups) has at least READ access authority to the device, RACF grants the request with no further processing. If the group's access authority is NONE, RACF denies use of the device and stops device authorization checking. If the group is not in the access list, device authorization checking continues with the next step.
If the profile has a universal access authority (UACC) of at least READ, RACF grants the request with no further processing. Otherwise, RACF denies use of the device and stops device authorization checking.
Note:
1. The TERMUACC operand of the SETROPTS command has no effect on consoles or JES input devices.
2. You cannot specify time or day-of-week restrictions for consoles or JES input devices. (You can specify user time and day-of-week restrictions with the ADDUSER and ALTUSER commands.)

Note:

The REQUEST=AUTH and REQUEST=VERIFY preprocessing and postprocessing exit routines are available during device authorization checking.
Global access checking is not available during device authorization checking performed by REQUEST=VERIFY.