Security

Introduction

UPSTREAM interacts with your mainframe security system to provide various levels of security checking. These security checks are implemented by issuing RACROUTE macros that call the z/OS Security Access Facility (SAF) Router. SAF will route the security check to your security system.

UPSTREAM supports any security system that supports SAF. This includes CA ACF2, IBM RACF, CA Top Secret, and others. Specific notes about these security systems appear later in this chapter.

UPSTREAM security checking falls into two distinct categories:

• Internal Security
  
• External Security
  

Internal Security

(Optional). For operations such as backups, restores and file transfers. This ensures that users or jobs can only initiate UPSTREAM operations for which they have the appropriate authority. The following sections describe the implementation of UPSTREAM internal security.

External Security

(Mandatory). Regardless of the internal security settings that have been chosen, UPSTREAM (like any other application running under z/OS) also requires the appropriate level of security for the z/OS data sets that it will create and access, such as its backup files. z/OS Data Set Securitydescribes the implementation of UPSTREAM external security.

If you are using the UPSTREAM encryption feature (UPSTREAM Data Encryption), you should also look at using your security system to restrict access to the data encryption “key file” and to optionally set up a security profile for the encryption Master Key. Both of these processes are described in UPSTREAM Data Encryption.

UPSTREAM Security Parameters

UPSTREAM security is controlled by the SUBSYS, SECLVL, and RACFUPD main configuration parameters.

The SUBSYS Parameter

The SUBSYS parameter specifies a value that will be used on security calls (if SECLVL=1, 2, or 3 is used) to identify the “subsystem” and “requester” of the security request.

SUBSYS is optional. If it is not specified, the value of “UPSTREAM” will be used instead.

For some security systems, as described later in this chapter, this name may need to be defined to the system to permit these security requests.

The SECLVL Parameter

The SECLVL parameter specifies the level of security UPSTREAM is to employ on requests from a UPSTREAM Client.

SECLVL=0

This is the DEFAULT value. This level causes UPSTREAM to perform no security checking.

The GLOBAL profile (see The GLOBAL Profile) is used for any profile name that does not exist in the configuration, effectively allowing any profile name to be used by any Client. For this reason, we generally recommend that you disable the backup operations for the GLOBAL profile by setting DASD=NO and TAPE=NO.

SECLVL=1

UPSTREAM issues a security call to verify that the entered userid is defined to your z/OS security system and that the entered password is correct for that userid. The userids used with UPSTREAM may be those already existing in your security system, or special userids established just for the purposes of UPSTREAM, or a combination of both.

As with SECLVL=0, the profile name and operation type are also verified against the UPSTREAM configuration. No security authorization check are made against the profile name itself. This means a user with a valid userid and password is permitted to backup or restore data using any valid profile name.

SECLVL=2

This is the most restrictive level available. In addition to the checks done for SECLVL=0 and 1, a security call is also issued to verify that the userid is authorized to use the profile name entered.

Employing SECLVL=2 prevents a user with a valid userid and password from backing up or restoring data under an unauthorized profile name. Users may be granted full backup and restore authority, or they may be authorized to perform only backups or only restores. For restores, another security call is done to determine the USERID’s authority to request restore from tape (see “Tape Mount Authority”).

Users can also be granted the authority to modify the definition of certain profiles, using the configuration modification facility under UPSTREAM at the Client. Special security rules must be established to define authority to the profile names (see Implementing UPSTREAM Security).

SECLVL=3

This is the same as SECLVL=2 with one difference. If the profile name entered at the Client is the same as the userid, UPSTREAM assumes that the userid is authorized to do backups and restores under that profile name without further checking. This reduces overhead and also simplifies the security rule definition. If you create a security userid with the same name as every profile name, you do not need to explicitly authorize the userid to the profile.

The RACFUPD Parameter

Valid only if SECLVL=2 or 3 has been specified and if a userid has been granted UPDATE or READ access to a Client profile name. RACFUPD then specifies what operation the user is authorized to perform.

RACFUPD=BACKUP allows users with UPDATE authority to do backups or restores, while users with only READ access can do only restores.

RACFUPD=RESTORE allows users with UPDATE authority to do backups or restores, while users with only READ access can do only backups.

Implementing UPSTREAM Security

Modifications to Your z/OS Security System

SECLVL=0

Implementing SECLVL=0 security within UPSTREAM requires no modifications to your z/OS security system. UPSTREAM will not perform calls to the z/OS SAF Router.

SECLVL=1

Implementing SECLVL=1 security within UPSTREAM requires only minor modifications to your z/OS security system. SECLVL=1 issues RACROUTE TYPE=VERIFY to verify the userid and password, so to implement SECLVL=1 security, you will need to:

• 
  
  • 
    
    • Verify that the SAF interface is enabled for your z/OS security system (IBM RACF and CA Top Secret always support SAF).
    • Modify security tables to allow security calls from the subsystem named by the SUBSYS parameter. This may not be necessary for some security systems, as described later in this chapter.

SECLVL=2 and 3

SECLVL=2 and 3 allow you to define security rules so that only certain USERIDs can use certain profile names. They also allow you to grant certain USERIDs the authority to do only backups or only restores.

In addition to the authorization checks described previously for SECLVL=1, SECLVL=2 or 3 issues a RACROUTE to verify that the userid is authorized to use the profile name sent from the UPSTREAM Client:

       TYPE=AUTH,CLASS='$UPSTRM',ENTITY='profilename',ATTR=typeFor compatibility with earlier releases, if class $UPSTRM is not found, an additional check is done with class WSIDENT. If the userid is not authorized to the profile name, but the profile definition was provided in the UPSTREAM configuration by a PREFIX= entry instead of an explicit PROFILE=entry (see UPSTREAM Configurator), a second check is done to see if the userid is authorized for the prefix name. This allows one userid to be authorized for all profile names that begin with the specified prefix.

However, if SECLVL=3 is in effect, and the userid specified at the Client matches the profile name entered, or the name of the PREFIX= profile entry in the UPSTREAM configuration matches the profile name, the userid is automatically considered to be authorized for UPDATE to that profile name. In this case, the RACROUTE for the profile name will not be done. This can greatly simplify the setup of the security rules, since the profile names do not have to be defined, only the userids.

In the RACROUTE request shown previously, the “ATTR=type” is the type of authority requested.

• 
  
  • 
    
    • You must give the userid UPDATE authority if it is permitted to do backups and restores.
      
    • Give the userid ALTER authority if, in addition to backup and restore operations, it is also authorized to modify the profile definition from the Client.
      
    • You may also give users the authority to perform only one type of operation by granting them only READ access.
      

The type of access granted is then defined by the RACFUPD configuration parameter:

• • 
    
    • RACFUPD=BACKUP means that users with READ access can only do restores. It should be used when you want to protect against unauthorized backup while allowing some users to do restores at will.
      
    • RACFUPD=RESTORE (the default) grants READ users the authority to do backups only and protects against unauthorized or ill-considered restores.

  Important

  UPSTREAM profile names that are not protected in your security system can be used by any userid.

  To implement SECLVL=2 or 3 security, you need to perform the following steps, in addition to those already outlined for SECLVL=1:

  Important

  These notes and sample procedures should be verified in the appropriate manuals for your level of IBM RACF.

• Define a resource class of $UPSTRM. A class of WSIDENT is also acceptable if already in use with an earlier release, but we recommend that you convert to $UPSTRM for compliance with IBM recommendations for user-defined resource classes. For example:
  

  • Create the RACF Resource Class.

    RDEFINE CDT $UPSTRM CDTINFO(POSIT(23) MAXLENGTH(9) FIRST(ALPHA,NATIONAL,NUMERIC)
    OTHER(ALPHA,NATIONAL,NUMERIC) DEFAULTUACC(NONE) OPER(NO))
  • Activate CDT RACF Class.
      SETROPTS CLASSACT(CDT) RACLIST(CDT)

• Define resource names under that class corresponding to the profile names that will be used with UPSTREAM. Generic resource names are acceptable. If you have defined PREFIX= profiles in the UPSTREAM configuration, you can either define resource names equal to the prefix names (to give a userid authority to all of the profiles under that prefix), or you may define the actual profile names to be used, or both. If SECLVL=3 is enabled, you do not need to define the profile names (or prefixes) if the userids themselves match the profile names or prefixes. Be sure to specify that the universal (default) access is NONE (e.g., for IBM RACF; UACC(NONE)). For example:
  
  • Create a backup profile entry for profile TEST001, in Class $UPSTRM.
    RDEFINE $UPSTRM TEST001 UACC(NONE)
  • If using the Web Portal, add the $APS profile to the $UPSTRM Resource Class.
    RDEFINE $UPSTRM $APS UACC(NONE)

• Authorize appropriate userids to have READ, UPDATE, or ALTER access to those profile names they are permitted to use.
  
  • Allow User “user_id” to Access UPSTREAM Profile TEST001.
    PERMIT TEST001 ID(user_id) CLASS($UPSTRM) ACC(ALTER)
  • If using the Web Portal, allow user “user_id” to access UPSTREAM profile $APS.
    PERMIT $APS CLASS($UPSTRM) ID(user_id) ACC(READ)

• If you wish to restrict restores from tape for certain userids (as described below), define a resource of TAPEMOUNT under the $UPSTRM (or WSIDENT) class to grant global tape restore authority. Alternatively, define resources of “Rprofilename” (profile name preceded by the letter “R”) to grant tape restore authority for specific profiles. You must then authorize appropriate userids to those profiles with UPDATE authority.
  
• Finally, define any userids for use with UPSTREAM that are not already defined to your security system.
  

Tape Mount Authority

By default, any authorized user can do restores from either tape or disk backups. But if you want to limit tape mounts by allowing only certain users to restore from tape backups, you can do so under SECLVL=2 and 3. For a restore request, a RACROUTE will be issued:

RACROUTE TYPE=AUTH,CLASS='$UPSTRM',ENTITY='TAPEMOUNT',ATTR=UPDATEIf the userid is authorized to this name, then the UPSTREAM Client is permitted to request restores that require tape mounts. If not, only disk restores are permitted. TAPEMOUNT allows you to give global tape restore authority to selected users. However, if TAPEMOUNT has not been defined as a resource to your security system (resource not found), UPSTREAM expects the check using an entity name of “Rprofilename” (profile name preceded by the letter R). This allows you to give a userid the authority to do tape restores for certain profiles, but not for others.

If neither resource (TAPEMOUNT nor Rprofilename) is defined to your security system, all tape restores will be allowed. You can use either the TAPEMOUNT or Rprofilename resource names to control tape mounts, but not both. TAPEMOUNT is much simpler (and is recommended) because you simply define that one resource and give the appropriate userids UPDATE access to it.

The USTRGSTR Profile

The Registered Name Service is described in Registered Name Service. Although there are no special security requirements for a Client to register its own name, the special profile name of “USTRGSTR” must be security authorized for UPDATE for any userid to display or update the registered name table from ISPF, or from the equivalent Client interface. This applies only for SECLVL=2 or 3. A profile for USTRGSTR does not need to be defined in the UPSTREAM configuration.

USTBATCH Security Checking

There is a special security check done for UPSTREAM functions requested via USTBATCH (see USTBATCH Security).

When a security system is active, a security userid must be associated with every batch job. This userid can be specified by the USER= parameter on the JOB statement, or can be the userid of the TSO user or other job that submitted the batch job. Since this userid and its password have already been validated, if the same userid is being used for the UPSTREAM operation, there is no need to re-validate it or re-specify the password.

When USTBATCH initiates its conversation with the UPSTREAM started task, the started task will extract the userid of the USTBATCH job. Several validation techniques are used to ensure that the calling program is actually a USTBATCH job. This is done only if CONV=KEEP or WAIT was specified to USTBATCH and only if USTBATCH is executing as an APF authorized program (under TSO, USTBATCH must be defined as an authorized program, (Define the UPSTREAM Started Task PROC).

Later, when the function request has been sent to the Client and is being initiated by the Client, UPSTREAM compares the security userid associated with the request with the userid extracted from the USTBATCH job.

• If they match, UPSTREAM does not require or validate a password; it assumes that the password of the userid has already passed validation and it will use the userid for security checking as though a valid password had been provided. If SECLVL=2 or 3 is in use, the userid must still be authorized to the profile associated with the request, as described earlier. For installations that change passwords regularly, this means that the password need be changed only in the TSO logon or USTBATCH JCL and does not need to be changed (or even specified) in the USTBATCH parameters or Client parameters.
  
• If the userids do not match, then normal validation will be done on the userid associated with the UPSTREAM request and a password will be required. This is also true if the userid cannot be extracted from the job, or the USTBATCH job does not pass the UPSTREAM validation checks.
  

To simplify use of this feature, USTBATCH accepts a statement (USERID &JOB) that automatically copies the userid associated with the USTBATCH job and makes it the userid associated with the USTBATCH-initiated request.

When USTBATCH is used to submit UPSTREAM console commands, there are two classes of commands for security purposes:

• All console commands check for READ authority to a dummy profile name of USTCMD. This profile does not need to exist in the UPSTREAM configuration, but you can define a security rule for that profile to control the ability to execute UPSTREAM console commands through USTBATCH.
  
• Utility commands that execute in a sub-task and have an associated profile name (e.g., USTVAULT) do normal security checking against that profile name. For example, a command of VAULT03 requires authority to the profile USTVLT03. This allows you to restrict certain sub-task-type commands to certain userids.
  

CA Top Secret Considerations#

Listed below are considerations for implementing UPSTREAM security under CA Top Secret. These notes and procedures should be verified in the appropriate manuals for your level of CA Top Secret.

Facility Definition

In order that UPSTREAM be able to verify userids and passwords, it must be defined as a “facility” to CA Top Secret. The following is a sample of the input required to do this definition. It replaces “USER10”, one of the user-defined facility names provided by CA Top Secret. If this name has already been used, choose another available name. You should verify in CA Top Secret documentation that the options shown are correct for your installation.

Resource Class Definitions

If you are using SECLVL=2, the resource class $UPSTRM must be defined to CA Top Secret. Shown below is a sample resource class definition (RDT) for the “$UPSTRM” resource class used by UPSTREAM:

• The RESCODE is any value from “01” to “3F” that is not already in use. You can use the TSS LIST(RDT) command to display the codes currently in use.
  
• The DEFPROT attribute is optional. If specified, all UPSTREAM profiles will be protected by default, even if no specific rule has been defined for them.
  

Now you can begin defining profile names under the $UPSTRM class, and granting the appropriate access to them by specified userids.

CA ACF2 Considerations#

Listed below are considerations for implementing UPSTREAM security under CA ACF2. These notes and procedures should be verified in the appropriate manuals for your level of CA ACF2.

SAF Interface

The security checks done by UPSTREAM can only be processed by CA ACF2 if the CA ACF2 SAF interface is enabled. Consult the appropriate CA ACF2 manuals for details on enabling this interface if you do not already use it.

Depending on your level of CA ACF2, you may need to define a rule for the SAF interface in order to process SECLVL=2 security calls. This rule is not required in CA ACF2 V6 or higher.

An example of such a rule is:

   SAFPROT.UST SUBSYS(UPSTREAM) CNTLPT(UPSTREAM) CLASS($UPSTRM,VERIFY)If you have specified a SUBSYS parameter in the UPSTREAM configuration with a value other than “UPSTREAM”, change the SUBSYS= and CNTLPT= values to match.

CA ACF2 Command Limiting Facility

If you are using the CA ACF2 Command Limiting Facility to limit the use of TSO command processors, you must add USTATUS, USTISPF, USTCONFG, USTMONA, and USTSCHKW to the list of authorized commands for any user who will use the UPSTREAM TSO/ISPF dialogs.

Other Considerations for CA ACF2

UPSTREAM must be defined to CA ACF2 as a “MUSASS” (multi-user) application subsystem. Consult CA ACF2 documentation for details on defining the UPSTREAM application, and for defining the $UPSTRM class and profile names, and authorizing userids to use them.

z/OS Data Set Security

Just like any other z/OS job or started task, UPSTREAM is itself also subject to security rules for the z/OS data sets it creates or accesses, as follows.

The UPSTREAM Started Task

The UPSTREAM started task authority is controlled by the userid that you have assigned to that started task. Consult the documentation of your z/OS security system for details on assigning security IDs to started tasks. It should be given CREATE and UPDATE authority to the UPSTREAM repository data sets, as well as to any sequential disk and tape backups that will be created.

UPSTREAM Batch Jobs

UPSTREAM batch jobs are subject to the authority of the userid assigned to that batch job. This can be the propagated userid of the user/task that submits the USTBATCH job (e.g., a TSO user, the Job Scheduling System), or optionally the USER= operand on the submitted requesters JCL JOB statement.

File Transfer

If the file transfer feature is used (see File Transfer), the output data sets created by a client-to-z/OS file transfer are subject to the security of the userid under which the transfer is run. In other words, that userid must be authorized to create the z/OS output data sets used by the file transfer.

UPSTREAM Data Encryption

As described in UPSTREAM Data Encryption, UPSTREAM includes a data encryption feature. With this feature licensed and enabled, you can use USTVAULT to create additional encrypted copies of some/all of your primary “copy 1" backups, which may be intended for off-site transportation and storage.

Securing The “Key File”

Since numerous encryption algorithms and accompanying encryption keys can be used by USTVAULT, it is not practical to manually enter the required key for each restore from an encrypted copy of a backup. For that reason, UPSTREAM stores the encryption keys in a special “key file”, which is named either in the KEYFILE keyword in the USTCRYPT DD statement in the UPSTREAM startup PROC (Installation and Configuration), or via the USTCRYPTV option set though the TSO/ISPF dialog or USTZAPOP program (UPSTREAM Data Encryption). The key file is automatically read by UPSTREAM when restoring from an encrypted copy of a backup.

In your security system, only those users that have a need to create (ALTER), backup (READ), or restore (UPDATE) the key file should be given the required access. All other users should be prevented from accessing the key file.

• Under IBM RACF, UPSTREAM itself does not require security access to the key file as it is always able to read and write to it. Any user who can create or restore from an encrypted copy of a backup can access the key file, but only via UPSTREAM. They will not be able to browse, update or copy the key file externally.
  
• Under non-RACF security systems, UPSTREAM users may need to be given UPDATE authority to the key file to create encrypted copies of backups, and READ authority to restore (decrypt) an encrypted copy of a backup.
  

Securing Master Keys

The UPSTREAM data encryption feature also supports an optional master key, which is used to create an encrypted copy of the actual key used to encrypt the data. This encrypted key is then saved on the backup data set. The master key can be used to decrypt any copy of a backup that has been encrypted by USTVAULT, in the event that the key file is either not available, or the actual keys cannot be provided manually.

The most secure way to specify a master key is to store it in a FACILITY class profile in IBM RACF (or the equivalent in a non-RACF security system). The profile must be created with:

• Class FACILITY.
  
• Profile name “USTCRYPT.keyname” (“keyname” is a 1-8 character name of your choice). Multiple profiles can be created if multiple master keys are needed.
  
• Set Universal Access should to NONE so that no one can display the master key.
  
• Only those individuals who need to know or update the master keys should have authority to these profiles.
  

In IBM RACF, you can define this profile with the RACF ISPF dialog, or you can issue a RACF command such as the following, where “keyvalue” must be a valid 16-byte AES128 master key, consisting of exactly 32 hexadecimal digits (0-9, A-F):

   RDEFINE FACILITY USTCRYPT.keyname UACC(NONE) APPLDATA('MASTERKEY=keyvalue')For CA ACF2 and CA Top Secret, the procedure for defining the security profile is different and you may need assistance or a usermod. Contact CA Technologies for information.

Using Master Keys

When encrypting a copy of a backup with USTVAULT, UPSTREAM extracts the master key that was specified via “MASTERKEY” in the above security profile. Under IBM RACF, UPSTREAM users do not need to be authorized to the profile in order to use master keys, but in other security systems they may need READ authority to the profile name.

For restores, or when running USTREGEN (Updating the Repository) against an encrypted copy of a backup, if the master key is to be used, MASTERKEY must be manually specified on a DECRYPT statement (MASTERKEYID is not supported for restores or USTREGENs).

For obvious reasons, master keys must be kept extremely secure and secret:

• Easily remembered keys should be avoided, as should repetitive strings and duplicated characters (this is also true for other user-specified encryption keys).
  
• Access to the master keys, either in printed form or from the FACILITY profile, should be limited to a small number of trusted individuals.
  
• The printed copies of master keys should be stored securely, such as in a bank safe-deposit box
  

To enhance security, you may wish to periodically change master keys, e.g., once a month or once a quarter. However, if you change your master key, remember that encrypted copies of backups that were created before the change in master key will require the previous master key if you plan to restore using a master key. Therefore, if you periodically change master keys, the dates of those changes and the actual master keys used should be retained in a secure location.

z/OS Initiated RUN JOB Functions with SECLVL=2

Goals

• Mainframe (z/OS) or client initiated UPSTREAM RUNJOB function.
  
• Allow for the specification or propagation of the submitters z/OS security system userid.
  
• Allow for impersonation of a selected client system userid.
  
• No z/OS or client system passwords are to be transmitted or stored.
  
• This facility should operate in a similar manner to existing UPSTREAM z/OS initiated functions.
  
• The solution should work with all supported SAF interface security systems (CA ACF2, IBM RACF, CA Top Secret, etc.).
  

Narrative

1. The initiating process (TSO user, UPSTREAM internal scheduler, OPCA, etc.) submits the USTBATCH JOB. This provides the initial userid to be associated with the UPSTREAM request (USER=SCHED in this example).
   
2. The USTBATCH JOB has the userid of the submitting process (USER=SCHED) and it contains two important parameters instream, ACTION=5 (run a client script) and LOCALUSER=ORACLE (in this example) that provides the userid that will ultimately be “impersonated” on the client system. The USTBATCH JOB connects to the UPSTREAM z/OS Started Task and passes the request. An implementation restriction will allow the specification of only 8 national characters for the LOCALUSER (client system userid specification) parameter for an ACTION=5 type request. If the LOCALUSER parameter is NOT coded, the IBM RACF userid of the submitting USTBATCH JOB will be used on the client system.
   
3. The UPSTREAM z/OS Started Task receives the request from the USTBATCH JOB and connects to the remote client system as normal and passes the request via an x'A1' structure and subsequent x'A2' structures containing all the other control cards.
   
4. The Client software receives the request from the z/OS Started Task and reformulates the request as necessary. It then performs an UPSTREAM LOGIN function to the UPSTREAM z/OS Started Task for security validation purposes via the x'80' structure. The IBM RACF userid for this example request continues to be SCHED and now the LOCALUSER value is ORACLE because it was supplied in the x'A2' UPSTREAM control cards.
   
5. The UPSTREAM z/OS Started Task receives the security LOGIN validation request from the client system and calls the z/OS SAF security interface to process it. The IBM RACF SAF call is
     USER=SCHED,ENTITY=ORACLE,CLASS=$UPSTRM
   and optionally if the password is NOT being propagated along via the AVI indicator PASSWORD=password or PassTicket.
6. For requests in which there was a IBM RACF userid and password specified, we need to validate the userid and password combination. This is to maintain compatibility with customers who want to continue doing this.
   
7. IBM RACF responds either positively or negatively to the request to validate the IBM RACF userid and password combination outlined in item # 6.
   
8. This SAF return code is returned to the IBM RACF z/OS Started Task.
   
9. If the prior two steps completed successfully or where not necessary (propagated/already verified IBM RACF userid), a IBM RACF request is made by the UPSTREAM z/OS Started Task to validate the userid (USER=SCHED in our example) against the previously created and configured IBM RACF Resource Class $UPSTRM. Within that resource class are entities for each client system userid that is going to be impersonated. Each entity is also permitted access of at least read by the user of the initiating process (USER=SCHED in our example). The IBM RACF commands to define these classes and entities are:
   
   • Add an Entity of “ORACLE” to IBM RACF Resource Class $UPSTRM:
     RDEFINE $UPSTRM ORACLE UACC(NONE)
   • Permit RACF Userid “SCHED” to be Impersonated by Client System Userid “ORACLE”:
     PERMIT ORACLE CLASS($UPSTRM) ACC(READ) ID(SCHED)
10. IBM RACF examines the IBM RACF database for previously defined entity access definitions, in this example: Does IBM RACF user SCHED have at least READ level access to $UPSTRM resource class entity (client system userid) ORACLE?
    
11. The request is responded to positively or negatively depending on the previously made definitions. Special cases are:
    
    • If a LOCALUSER value is specified and the matching IBM RACF entity value is NOT defined, the request fails.
      
    • If a LOCALUSER value is specified and the $UPSTRM IBM RACF resource class is NOT defined, the operation will be a success.
      
12. The SAF return code is provided to the UPSTREAM z/OS Started Task.
    
13. The UPSTREAM z/OS Started Task communicates the success (or failure) of the authorization request back to the requesting Client system.
    
14. The Client system (running as “root” user authority) spawns a new Client process that then “impersonates” the user (ORACLE in this example) previously validated with IBM RACF and begins execution of the requested script.
    
15. The requested client script is executed and it returns its messages and return code to the client upstream.log file.
    
16. The Client software forwards (if so requested) the script generated messages and return code to the z/OS Started Task.
    
17. The UPSTREAM z/OS Started task passes the client messages (if requested) and return code to the requesting USTBATCH JOB.
    
18. All the requested output is placed on the USTBATCH USTLOG DD statement output data set or SYSOUT.
    

Figure 4.1: SECLVL-2 RUNJOB Logical Flow

4.10 Implementing RACF PassTickets with UPSTREAM

PassTicket support requires UPSTREAM for z/OS Release 03.09.03 or later.

The following are the RACF steps to implement PassTickets with UPSTREAM

1. Define the UPSTREAM application to RACF.

   RDEFINE APPL UMPASETR UACC(NONE)
   SETROPTS CLASSACT(APPL)
   SETROPTS GENERIC(PTKTDATA)
2. Activate the RACF PassTicket class.
   SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)

3. Define a RACF PassTicket profile that associates a session key with your application definition.

   RDEFINE PTKTDATA UMPASETR SSIGNON(KEYMASKED(xxxxxxxxxxxxxxxx)) APPLDATA(‘NO REPLAY PROTECTION’)

   Where xxxxxxxxxxxxxxxx is a 16 hexadecimal digit (creating an 8-byte or 64-bit) session key. Use a site specific key value. Keep the value secret.

   0123456789ABCDEF

4. Define the UPSTREAM application name to the RACF PassTickets PTKTDATA Resource Class and then Permit access to the UPSTREAM Started task userid so it can generate Passtickets.

   RDEFINE PTKTDATA IRRPTAUTH UMPASETR.* UACC(NONE)
   PERMIT IRRPTAUTH UMPASETR.* ID(upstream_stc_user_id) CLASS(PTKTDATA) ACCESS(UPDATE)

5. Permit access to the UMPASETR application for each user that is permitted to run UPSTREAM function requests. Also allow the UPSTREAM started task read access.

   PERMIT UMPASETR CLASS(APPL) ID(upstream_stc_user_id) ACCESS(READ)
   PERMIT UMPASETR CLASS(APPL) ID(userid)

6. Refresh the APPL and PTKTDATA classes with the following commands:

   SETROPTS RACLIST(APPL) REFRESH
   SETROPTS RACLIST(PTKTDATA REFRESH

The following are the changes necessary to perform to each UPSTREAM client

• In each UPSTREAM client configuration file, you must specify:
  PTKSUPPORT=Y

• For ORACLE backups: When PTKSUPPORT=Y is specified, add the following password in the UPSTREAM parameter file.

  PASSTICK
• For DB2 and file system backups: When PTKSUPPORT=Y is specified, the supplied password in the UPSTREAM parameter file must be blank (no characters specified).