HCL Workload Automation for Z subresources and RACF® resources

About this task

The AUTHDEF statement uses the HCL Workload Automation for Z subresource name to activate RACF® checking for an HCL Workload Automation for Z subresource. For example, if you want HCL Workload Automation for Z to verify authorization for application descriptions by checking the application name, you specify the value AD.ADNAME on the SUBRESOURCES keyword of the AUTHDEF statement. The resource name that RACF® then checks consists of a 3-character code identifying the subresource, followed by a name specifying the particular data to be protected. For example, to protect application descriptions whose application name is PAYROLL, you define a RACF® resource, ADA.PAYROLL, in the RACF® resource class that is specified on the AUTHDEF statement.

Here is an example that shows how you could protect the JCL and job library file (JS). This example assumes that:

The file is protected against update but can be read by any user.
The owner ID is used to protect access. Protected fixed resources and subresources shows the other names that you can select to protect the JS fixed resource.
User CASHIER has update access to data with owner PAYROLL but has only read access to other data.
OPCCLASS is the RACF® resource class used to protect HCL Workload Automation for Z resources. This name is specified on the AUTHDEF statement.
The required resources are not defined.

To implement protection:

Define the fixed resource that owns the subresource and give universal read access to it:
```
 RDEFINE (OPCCLASS) JS UACC(READ)
```
Give user CASHIER update access to the JS fixed resource:
```
 PERMIT JS ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS)
```
Define a RACF® resource, JSO.PAYROLL, to RACF® and give universal read access to JSO.PAYROLL:
```
 RDEFINE (OPCCLASS) JSO.PAYROLL UACC(READ)
```
JSO is the 3-character code that RACF® uses for JS.OWNER.

Give user CASHIER update access to JSO.PAYROLL:

 PERMIT JSO.PAYROLL ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS)

Define a subresource JSO.* to RACF® and give universal read access to this subresource:
```
 RDEFINE (OPCCLASS) JSO.* UACC(READ)
```
This rule prevents the user CASHIER from updating JCL in occurrences that do not have the PAYROLL owner ID.
Start checking for the JS.OWNER subresource by specifying JS.OWNER on the SUBRESOURCES keyword of the AUTHDEF statement.

A user's default access to HCL Workload Automation for Z subresources is determined by the user's access to HCL Workload Automation for Z fixed resources.

If you base your subresources on application names or owner IDs and these do not have consistent naming standards, you might need hundreds or even thousands of RACF® profiles. This would make your subresources difficult to maintain. It would also slow HCL Workload Automation for Z processing, particularly at startup time when all profiles are read in. You can dramatically reduce the number of profiles you need by using consistent naming standards, or RACF® generic profiles, or both.

Note:

If you define only fixed resources, a user who asks for a list of occurrences sees the names of all occurrences. If you define subresources, only the occurrences that the user has access to are listed. So two HCL Workload Automation for Z users asking for the same list on the same panel could see different lists.
If you use subresource protection, you can control the number of access violations that are logged for list requests through the LISTLOGGING keyword of AUTHDEF.
The check for a subresource authority does not depend on LISTLOGGING or the order of the subresources in the AUTHDEF statement. When more than one subresource is specified, a check for each one is issued. The check process stops at the first failure and no check is performed for the other subresources.