Activating the Role-based Resource Manager

The Role-based Resource Manager is activated by a parameter to the Remote Build server. The server option is specified in the server startup JCL RCCRUNM.

About this task

When the role-base Resource Manager is active, the administrator for the Remote Build server can specify the role of the Remote Build user. The administrator specifies the user ID and password (of the rccbuild invoker) in the rccbuild command.

The administrator can define as many roles as needed. A typical set of roles are: Developer, Builder, and Tester. Each role has an associated ID and each role ID has control of a set of resources (files, application, etc.).

Valid values of the –rl roleID argument are identifiers for these roles. This argument also enables users (rccbuild invokers) to identify a set of resources to be accessed by entering the user's role. The Remote Build user specifies the user ID and password either in the command or in the secure password protection file. This argument is ignored if the -a S option is not specified for the Remote Build server.

The administrator for the Remote Server creates these values and associates them with a Remote Build server. Each role ID controls a set of resources (files, application, etc.). For example, identifiers for the typical set of roles could be: RBDEVP, RBBULD, and RBTEST.

There are many effective ways to set up and activate the Role-based Resource Manager. The following example shows one way to accomplish this goal. This example makes the following assumptions:

The Remote Build Server was started by a user whose role ID is RBADMN.
This is the name of the role for the Remote Build Server Administrator.
The Remote Build server is running with option -a S.
The following roles are indicated and the applicable role IDs are specified:
- Administrator = RBADMN
- Developer = RBDEVP
- Tester = RBTEST
- Three Remote Build users = RBUSER1, RBUSER2 and RBUSER3

Procedure

To set up and activate the Role-based Resource Manager according to these assumptions, do these steps:

Create the following role IDs.
- RBADMN
- RBDEVP
- RBTEST
- RBUSER1
- RBUSER2
- RBUSER3
Create FACILITY Classes and enable role IDs and user IDs to access the resources.

Note: You might need to have your Security Administrator set these up for you.
1. Create three FACILITY classes:
  - BCC.REMOTE.BUILD.RBDEVP
  - BCC.REMOTE.BUILD.RBTEST
  - BCC.REMOTE.BUILD.*
2. Enable the role IDs as follows:
  - RBADMN and RBUSER1 to access BCC.REMOTE.BUILD.*
  - RBDEVP and RBUSER2 to access BCC.REMOTE.BUILD.RBDEVP
  - RBTEST and RBUSER3 to access BCC.REMOTE.BUILD.RBTEST
After the FACILITY class is activated and the resource names are defined, the Security Administrator can issue a RACF® command (or other compatible security product command) such as the following one, which enables the role RBUSER to submit rccbuild requests:
```
RDEFINE FACILITY BCC.REMOTE.BUILD.RBDEVP 
PERMIT BCC.REMOTE.BUILD.RBDEVP 
CLASS(FACILITY)ID(RBUSER) 
ACCESS(READ)
```
This example enables the user whose role is developer to access the Remote Build server.
```
rccbuild -h servermachine@portno -rl RBDEVP
```
Grant RACF (or other compatible security product) Access.
RBADMN is the user whose role ID provides for starting the Remote Build server. Only the RBADMN role ID can submit a job on behalf on RBADMN, RBDEVP and RBTEST, and these three execution IDs need to access Remote Build server; therefore, RBADMN grants the appropriate access (read or write) for the Remote Build server to these three IDs.
RBADMN then starts the Remote Build server by performing the following steps:
1. In the RCCRUNM JCL, either specify -a S in the PARM clause within the EXEC statement or add the AUTHNO security option within the PROC statement as shown below.
```
//RSERVER PROC HLH='RBADMN',
//             PORTNO=…,
//             AUTHNO=S,
//             MAXBUILD=..   
```
2. Modify the worker RCCMVS JCL by adding the USER and NOTIFY options in the job card:
```
//&USERID  JOB ,
//     MSGCLASS=H,REGION=7M,TIME=2,
//     USER=&SYSUID,NOTIFY=&SYSUID  
```
  Note: USER=&SYSUID,NOTIFY=&SYSUID must be the last line in the job card.
After the Security Administrator has activated the FACILITY class and defined the resource names, users can issue a RACF command (or other compatible security product command) such as the following one, which enables the role RBUSER to submit rccbuild requests:
This example enables the user whose role is developer to access the Remote Build server.
```
rccbuild -h servermachine@portno -rl RBDEVP
```
Note: If the server rejects the job and if the role-based Resource Manager is activated, determine if one or more of the following conditions could be the cause:
- The user ID was omitted.
- The role ID was omitted.
- The user ID is not authorized for the specified Remote Build server.
- The role ID is not authorized for the specified Remote Build server.

Example

Assume the following associations for this example:

Associations:

Facility class
- BCC.REMOTE.BUILD.*
- BCC.REMOTE.BUILD.RBDEVP
- BCC.REMOTE.BUILD.RBTEST
Role ID
- User ID Jane is associated with role ID RBADMN
- User ID John is associated with role ID RBADMN
- User ID George is associated with role ID RBDEVE
- User ID Jason is associated with role ID RBTEST

User IDs and passwords that are passed by the client command, rccbuild, are verified.
Authorization is confirmed for using the z/OS® MVS™ libraries and z/OS UNIX® System Services directories that are accessed during a build request.
- If argument -rl roleID is not specified, this user ID is validated for the role as a Remote Build administrator. The Remote Build administrator starts the Remote Build task, using the user ID (RBADMN) that is authorized to access the set of z/OS resources as defined by the Security Administrator. If this user ID is confirmed, this ID is authorized to start the Remote Build task. For example, only Jane, role ID (RBADMN, can start the Remote Build feature.
- If argument -rl roleID is specified, the user ID is validated for that special role; and if the user ID is validated for this special role, the Remote Build administrator has the surrogate authority to initiate MVS processes on behalf of role IDs.
  Possible scenarios:
  
  Example 1: If –rl RBDEVP is specified by user John and if John is verified as a role RBDEVP, the Remote Build server will start a remote build process under the role ID RBDEVP and execute the script requested from user John. Because John's script is executed under the role ID RBDEVP, John can access all the resources under BCC.REMOTE.BUILD.RBDEVP.
  
  RBUSER2 to access
  
  Example 2: If George specifies –rl RBTEST and if George is verified as role RBTEST, which is authorized only to access testing data, the Remote Build server will start a remote build process under the role ID RBTEST and execute the script requested from user George. Because George's script is executed under the role ID RBTEST , George can access only testing data. If he tries to access development data, the validation will fail for George and he will be rejected for submitting job to Remote Build server.