The ACEE parameter must be passed when customized security checks are written for use in multiple user address space systems such as CICS, IMS, CA Roscoe IE, and CA IDMS.
CA Top Secret maintains a security environment in every active address space. The environment is created at job/session initiation through a call to CA Top Secret. z/OS automatically invokes initiation security for BATCH, TSO, Started Task, IMS, CICS, and NCCF facilities. Any installation facility can use the same approach in creating the security environment.
The environment consists of control blocks initialized and maintained solely by CA Top Secret. The major control block is the Accessor Environment Element (ACEE) recognized by z/OS as a standard security control block. Associate individual users within the local facility with their unique ACEEs.
The information stored in the ACEE is used to validate resource access within the address space for an active user. In single user facilities, the system invokes security to build and maintain a single Master ACEE. This is also true of multi‑user facilities, so a Master ACEE will always exist.
For CA Top Secret, the Master ACEE is associated with the ACID for the BATCH job or STC that is the facility. The facility is responsible for invoking CA Top Secret (by issuing RACROUTE REQUEST=VERIFY) to build ACEEs for individual users as they sign on.
Each ACEE reflects the security‑related information for the user's ACID. When resource validation takes place in any address space, CA Top Secret uses the information associated with the Master ACEE or the user ACEE to validate access to the resource. In most cases, the security driver that invokes CA Top Secret is z/OS. However, other forms of resource checking must be initiated by the installation facility.
CA Top Secret must have an ACEE to do validation. When an ACEE is not passed to CA Top Secret on a given request, CA Top Secret attempts to locate the ACEE on its own. CA Top Secret checks the TCBSENV field of the current TCB for the address of the current ACEE:
When an address space contains multiple users (a multiple user address space), if there is no task‑per‑user relationship (each TCB anchors its own ACEE), the ACEE most often used is the Master ACEE and not the individual user's ACEE. In this case, the installation code should always provide ACEE= on all resource calls to perform security validation for each user.
When a subtask is created by z/OS through the ATTACH macro, the TCBSENV field of the mother task is not propagated to the daughter task. If it is necessary for the daughter task to retain the same ACEE (or ACID information), the mother task must fill in the daughter task's TCBSENV field.
As an example of a no task‑per‑user environment, an installation‑written facility has its own control block that reflects individual user information. In this example, the installation control block is called the USER C/B.
The USER C/B must contain the address of the ACEE for the user. This address is passed to security for all future security checks. All facilities, whether they are z/OS drivers or installation code, interface with CA Top Secret through the following standard z/OS macro instructions.
To perform signon security and build the ACEE, enter:
RACROUTE REQUEST=VERIFY,ENVIR=CREATE
To perform signoff cleanup and free the ACEE, enter:
RACROUTE REQUEST=VERIFY,ENVIR=DELETE
To perform data set, volume, terminal, abstract, and application checking, enter:
RACROUTE REQUEST=AUTH
To perform LCF checking for transactions and commands, enter:
RACROUTE REQUEST=FASTAUTH
The ACEE keyword for these macros is the key to multi‑user security validation. It passes the address of the ACEE associated with the user prior to performing the requested operation. If the ACEE is not passed, z/OS uses the Master ACEE to validate the request. This does not perform security validation for the user. Security validation must be performed prior to allowing the following operations to take place:
Important! CA will not distribute source macro listings of CA Top Secret control blocks.
The following scenario is used for the examples:
A return code of zero will normally be returned in WARN or DORMANT modes.
The following example verifies the use of the ACID, password, and terminal.
L R9,CURRENT CURRENT USER
USING USERCB,R9 ADDRESSS OF THIS USER'S C/B
LA R2,UCBTERM TERMINAL NAME
LA R3,UCBUID USER ID
LA R4,UCBPASSW PASSWORD
LA R6,UCBNEWPW NEW PASSWORD IF ANY
LA R9,UCBACEE ACEE POINTER
MVC RVFY,XRVFY TRANSFER MF=L SKELETON
RACROUTE REQUEST=VERIFY,
ENVIR=CREATE,
WORKA=SAFWORK, 512 BYTE SAF WORK AREA
USERID=(R3), VALIDATE USERID AS ACID
PASSWRD=(R4), AND PASSWORD
NEWPASS=(R6), ALLOW NEW PASSWORD
TERMID=(R2), TERMINAL CHECK
ACEE=(R9), THIS WILL HOLD ACEE PTR UPON RETURN
MF=(E,RVFY)
LTR R15,R15 SUCCESSFUL INITIATION?
BNZ INITERRI BR NO...PERFORM ERROR PROCESSING
UCBACEE now contains the address of the ACEE that was created for the user. This ACEE must be passed whenever security validation is performed for the user. This example checks for authority to open a data set:
L R9,CURRENT ACTIVE USER C/B
L R2,UCBACEE ACEE FOR THIS USER
IC R0,ACCESS REQUESTED ACCESS LEVEL
MVC RAUTH,XRAUTH TRANSFER SKELETON
RACROUTE REQUEST=AUTH,
CLASS='DATASET', DATA SET CHECK
WORKA=SAFWORK, 512 BYTE WORK AREA
ENTITY=DSNAME, WITH DATA SET NAME
VOLSER=VOLUME, AND VOLUME
DSTYPE=N, NON‑VSAM
ATTR=(R0), ACCESS MASK
LOG=NONE, IGNORE LOGGING
ACEE=(R2), FOR ACTIVE USER
MF=(E,RAUTH)
LTR R15,R15 IS USER AUTHORIZED?
BNZ DSNERR1 IF NOT AUTHORIZED, BRANCH
This example checks for authority to use an application:
L R9,CURRENT ACTIVE USER C/B
L R2,UCBACEE ACEE FOR THIS USER
MVC RAUTH,XRAUTH TRANSFER SKELETON
RACROUTE REQUEST=AUTH,
CLASS='APPL', APPLICATION CHECK
WORKA=SAFWORK, 512 BYTE WORK AREA
ENTITY=APPLICTN, FOR REQUESTED APPLICATION
ACEE=(R2), FOR ACTIVE USER
MF=(E,RAUTH)
LTR R15,R15 IS USER AUTHORIZED?
BNZ APPLERR1 IF NOT AUTHORIZED, BRANCH
This example checks for authority to execute a transaction/command:
L R9,CURRENT ACTIVE USER C/B
L R2,UCBACEE ACEE FOR THIS USER
MVC RFAUTH,XRFAUTH TRANSFER SKELETON
RACROUTE REQUEST=FASTAUTH,
CLASS=LCF, LCF CHECK
WORKA=SAFWORK, 512 BYTE WORK AREA
WKAREA=FAUTHWK, PASS 16 WORD WORK AREA
ACEE=(R2), ACTIVE USER'S ACEE
MF=(E,RFAUTH)
LTR R15,R15 DID USER PASS VALIDATION?
BNZ EXECERR1 CAN NOT EXECUTE MODULE, BRANCH
This example checks for authority to access a user resource:
RACROUTE REQUEST=FASTAUTH,
CLASS=USER5, USER5 CHECK
WORKA=SAFWORK, 512 BYTE WORK AREA
ENTITY=SPECIAL,
WKAREA=FAUTHWK,
ACEE=(R2),
MF=(E,RFAUTH)
This example processes a user's signoff:
L R9,CURRENT ACTIVE USER C/B
LA R2,UCBACEE ACEE FOR THIS USER
MVC RVFY,XRVFYD TRANSFER SKELETON
RACROUTE REQUEST=VERIFY,
ENVIR=DELETE,
ACEE=(R2)
MF=(E,RVFY)
USER5 DC CL8'USER5' Class name for FASTAUTH * special contains user resource 10000, update access level, program: SPECIAL DC CL8'10000',X'60',CL8'CUTRPGM' LCF DC CL8'XLCF' XRVFY RACROUTE REQUEST=VERIFY,ENVIR=CREATE,MF=L XRVFYD RACROUTE REQUEST=VERIFY,ENVIR=DELETE,MF=L XRAUTH RACROUTE REQUEST=AUTH,MF=L XRFAUTH RACROUTE REQUEST=FASTAUTH,MF=L USERCB DSECT USER CONTROL BLOCK MAPPING UCBUID DS XL1,CL8 USER LENGTH AND USERID UCBPASSW DS XL1,CL8 PASSWORD LENGTH AND PASSWORD UCBNEWPW DS XL1,CL8 NEW PASSWORD LENGTH AND PASSWORD UCBTERM DS CL8 TERMINAL USER IS USING UCBACEE DS A POINTER TO USER'S ACEE WORKAREA DSECT CURRENT DS A ADDRESS OF ACTIVE USER C/B FAUTHWK DS 16F WORKAREA FOR FASTAUTH SAFWORK DS XL512 SAF WORK AREA RVFY DS 0XL256 RACROUTE PARMLIST FOR EXECUTION RAUTH DS 0XL256 ““ ““ ““ ““ ““ ““ ““ ““ ““ ““ RFAUTH DS XL256 ““ ““ ““ ““ ““ ““ ““ ““ ““ ““ XACTNNAM DS CL8 NAME OF MODULE TO BE EXECUTED APPLCTN DS CL8 NAME OF APPLICATION TO BE ACCESSED DSNAME DS CL44 NAME OF DATA SET TO BE ACCESSED ACCESS DS X ACCESS LEVEL FOR DATA SET OPEN VOLUME DS CL6 VOLUME FOR DATA SET
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|