Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
RACROUTE REQUEST=FASTAUTH: Verify access to resources z/OS Security Server RACROUTE Macro Reference SA23-2294-00 |
|
NOT programming interface information Use of CLASS='PROGRAM' with RACROUTE REQUEST=FASTAUTH is not part of the intended programming interface. It is intended for use only by z/OS® itself, and follows different rules and has different restrictions than uses of RACROUTE REQUEST=FASTAUTH with other class names. For more information, including effects on SAF exits, see System authorization facility (SAF) and SAF exits and SAF interface to an external security product. End of NOT programming interface information The RACROUTE REQUEST=FASTAUTH macro is used to check a user's authorization for access to a resource. RACROUTE REQUEST=FASTAUTH verifies access to those resources whose RACF® profiles have been brought into main storage by the RACROUTE REQUEST=LIST service or by SETROPTS RACLIST. If the profiles were not RACLISTed by RACROUTE REQUEST=LIST but were processed using SETROPTS RACLIST, and the caller is in supervisor state or system key (0–7), FASTAUTH uses the SETROPTS profiles RACLISTed for the authorization check. Using SETROPTS RACLIST instead of RACROUTE REQUEST=LIST to bring profiles into storage can simplify application design. However, to get optimum performance from calls to RACROUTE REQUEST=FASTAUTH, the class should be RACLISTed using RACROUTE REQUEST=LIST. RACROUTE REQUEST=FASTAUTH does limited parameter validation, and does not gather statistics or issue SVCs. Therefore, use of RACROUTE REQUEST=FASTAUTH is recommended only for applications that have stringent performance requirements. The RACROUTE REQUEST=FASTAUTH caller must be authorized (supervisor
state or system key 0–7) for certain keywords. See the keyword descriptions
for authorization requirements.
Note: The caller must not hold any
locks when issuing RACROUTE REQUEST=FASTAUTH. Programs that issue
RACROUTE REQUEST=FASTAUTH while holding a lock might experience unpredictable
results.
When a nested ACEE (or ENVR object for an ACEE created with the NESTED option of RACROUTE REQUEST=VERIFY) is passed to RACROUTE REQUEST=FASTAUTH by a supervisor-state or system-key caller and the access request is for a delegated resource (a resource defined with the RACF-DELEGATED string in the APPLDATA field), FASTAUTH processing retries the access request using the nested identity (usually, a daemon) when the primary identity has insufficient access authority. You can use the installation exits associated with RACROUTE REQUEST=FASTAUTH to make additional security checks or to instruct RACROUTE REQUEST=FASTAUTH to either accept or fail the request. You can write an application that uses RACROUTE REQUEST=LIST and RACROUTE REQUEST=FASTAUTH for authorization checking on a resource class and associated resource group that your installation defines. RACROUTE REQUEST=FASTAUTH is SRB-compatible. When issuing RACROUTE REQUEST=FASTAUTH in SRB mode for RACLISTed classes, you must ensure that the jobstep task pointed to by the ASCBXTCB field in the target address space is active when you schedule the SRB, and remains active until the SRB completes. Rule: In order to ensure that the SRB does not run after
the ASCBXTCB task completes, it is necessary to enable purgeDQ to
deal with that SRB. In particular:
RACROUTE REQUEST=FASTAUTH can also be invoked from a cross memory environment, when in task or SRB mode. The ACEE used for authority checking must reside in the HOME address space (unless ACEEALET specifies a different address space), but that ACEE is not used to locate the profiles RACLISTed. The main ACEE in the PRIMARY address space is used to locate the profiles. Restriction: When RACROUTE REQUEST=FASTAUTH is invoked in SRB mode, WHEN (PROGRAM) conditional access checking for profiles in the SERVAUTH class is bypassed. RACROUTE REQUEST=FASTAUTH provides support for auditing. FASTAUTH
determines that auditing is necessary if at least one of the following
conditions is met:
Restrictions:
|
Copyright IBM Corporation 1990, 2014
|