There are four predefined resource classes to support the CA Top Secret UADS replacement:
(account numbers)
(JCL procedure names)
(performance group numbers)
(TSO authorities/privileges)
A list of the TSS keywords for the TSO‑related resources and a brief description appear next. The TSS ADD/REMOVE and PERMIT/REVOKE command functions are used to implement these resources within the CA Top Secret environment.
All one‑ to 40‑character account numbers must be owned and permitted to users wishing to use a specific number. TSO issues a security request on the account number specified at logon; if this check fails, TSO prompts the user for a new account number. Logon does not complete unless the user is authorized to an account number. Ownership and permission are required. The TSS ADD and PERMIT commands can be used to assign ownership and authorization, respectively, to TSOACCT resources.
All one‑ to eight‑character procedure names must be owned and permitted to users wishing to use them. TSO issues a security request on the procedure name specified at logon; if this check fails, TSO will prompt the user for a new name. Logon will not complete unless the user is authorized to a procedure name. The user must also be permitted to all data sets in the specified procedure with the TSS commands. Authorization to a procedure name does not convey authorization to the data sets in the procedure.
All one‑ to three‑character performance group numbers must be owned and permitted to those wishing to use them. TSO will issue a security request on the group number specified at logon; if this check fails, TSO will prompt the user for a new number. The user can complete logon by specifying a new number or blanking out the performance group number field on the logon screen.
In the UADS environment, these authorities are known as attributes. They specify whether or not a given user has the authorities or privileges that are implied by their assignment. Attributes are as follows:
TSO issues a security request on these authorities at logon and saves the results in an internal table. When the need arises, TSO refers to the internal table rather than doing another security request. For example, if the user tries to submit a job, TSO checks to see if the security request for TSOAUTH(JCL) was successful at logon. If not, the user is denied the job submission. The user may subsequently be permitted to TSOAUTH(JCL), but he then must log off and log back on to have TSO become aware of it.
These seven TSOAUTH resources must be owned and authorized to those users that require them. Again, ownership is required; if one or more is not owned, the security call will set a return code of 4 to TSO which interprets this as a denial of access. For example, if TSOAUTH(JCL) is not owned, no user (except those whose IDs are obtained from UADS) is able to submit jobs. The spelling of these resources is critical for the same reason. TSOAUTH(ACCT) is correct, while TSOAUTH(ACCOUNT) is not an acceptable substitute.
Again, it should be stated that TSO must find at least one of the fields described in 4.1, “Default TSO Data” from the Security File or else it will interrogate UADS for all data. This means that TSO will determine authorization to ACCOUNT, SUBMIT, and so on, from the UADS attribute settings, rather than from security requests. However, if TSO does find at least one field on the Security File, it ignores UADS for the duration of the session.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|