By Kevin Stewart, Sanjay Kaliyur, and Jack Yuan
For most IMS customers, corporate audit standards require the use of an external security manager like RACF for all Z systems security. Using the same security interface across products simplifies administration and allows separation of security function from product support. Essentially, security administrators would benefit greatly if multiple products retain the same or similar security characteristics.
Db2 provides both external security (i.e RACF or equivalent) or Db2 specific, internal security, based on userids and authorities defined in the Db2 Catalog. To use external security, an agent thread (IMS dependent region, for example) needs to have established an external security user identifier (a RACF ACEE) at the z/OS thread (TCB) level. Specifically, TCBSENV of the agent thread must point to an ACEE. Otherwise, DB2 internal security is used. Alternatively, for the IMS External Subsystem Interface (ESS), Db2 will accept an ACEE passed in with the Sign On exit parameter list (e.g. IMS ESAF_SIGNON_ACEE is passed to Db2 via Sign On exit for a JVM dependent region).
IMS would be able to create an ACEE in the dependent region TCB TCBSENV under some conditions. For APPC or OTMA with FULL security option, IMS will create a new ACEE each time a new transaction message is scheduled into a message region and delete it at end of the transaction. For non-OTMA, non-APPC messages, a user exit (DFSBSEX0) is called which can request ACEE build. This ACEE is not used by IMS security processing but enables the z/OS thread level (TCBSENV) security to be established for any non-IMS security processing the application may invoke (such as Db2). In most cases, besides the persistent JVM dependent region environment, IMS does not pass an ACEE in the ESS Sign On parameter list.
However, it is very performance intensive to create and delete ACEEs. Because of a significant CPU cost, most z/OS subsystems cache ACEEs. Once created, an ACEE is retained for future for future transaction entry security checking. OTMA and APPC cache ACEEs for use when a new message arrives to perform point-of-entry validation, such as a transaction code checking. Legacy SNA processing saves the ACEE from Sign On in a terminal control block and will reuse it for point-of-entry validation. For this reason, most OTMA users specify the CHECK rather than the FULL option for OTMA security. This option performs point-of-entry validation using cached ACEEs (transaction code authority checking) but does not create an ACEE once per message in the dependent region that process the message. For the same reasons, most users do not code a DFSBSEX0 user exit to request an ACEE be created for legacy SNA messages. Note that DFSBSEX0 is not called for OTMA or APPC messages, so the only way to have a thread level ACEE built for OTMA and APPC messages is to specify OTMA or APPC Security FULL, which is performance intensive.
How it works
Every IMS dependent region address space has an address space level security environment (an ACEE pointed to by ASXBSENV). This ACEE is built by z/OS when address space is initialized, based on the source of the address space. IMS could optionally pass this address space level ACEE to Db2 at ESS Sign On if no thread-level ACEE is present in TCBSENV and no ESAF_SIGNON_ACEE is specified. This would allow Db2 to use external security processing, rather than defaulting to internal security processing. Because there is a one-to-one relationship between IMS transaction code, IMS PSB name, and Db2 package names, and IMS checks transaction code rather than the actual end user userid at the transaction point of entry, it is often acceptable to use the dependent region address space userid and not the actual end user userid, to perform Db2 external security processing. The address space userid can be controlled by the user to match the IMS/Db2 workloads running in the dependent region. Different dependent regions can have different userids. The address space level ACEE is always present, and IMS does not need to manage, create, or delete it. The only action needed from IMS is to pass the ACEE in the ESS Sign On parameter list. This eliminates the overhead of creating and deleting an ACEE once per transaction.
This enhancement has been delivered in IMS version 15.1 APAR PH33024. Here are some changes found in this APAR:
- Region Level ACEE (RLA=) keyword is added to the subsystem member (SSM) of the IMS PROCLIB data set for a Db2 subsystem. When RLA= is specified for a non-Db2 subsystem, it will be rejected. When RLA=Y is specified for a Db2 subsystem, IMS passes the dependent region address space level ACEE to Db2 if ESAF_SIGNON_ACEE and TCB level ACEE are not present. This RLA= is a keyword-only parameter for SSM PROCLIB member. It cannot be specified as a positional parameter.
- /DISPLAY SUBSYS command is enhanced to display the RLA= value based on the SSM PROCLIB member for IMS control region. Once the RLA= value is determined to be Y during the dependent region initialization, an IMS message “DFS7432I xxxx ADDRESS SPACE LEVEL RACF DB2 SECURITY REQUESTED FOR JOBNAME = zzzzzzzz” will be displayed on the system console and IMS MTO. This informational message can be used to determine if this new function is activated for an IMS dependent region.
- If the control region SSM entry is coded and not on a dependent region, IMS will take whatever is specified on the control region SSM entry for the dependent region.
- If both the control region SSM entry and dependent region SSM entry are coded, IMS will take the dependent region SSM settings, including the RLA= specification, for the dependent region.
- If only the dependent region SSM entry is coded and there isn't a control region SSM entry coded for a Db2 subsystem, the dependent region settings for the SSM will not be accepted.
- To improve serviceability, the external subsystem table trace entry for the External SubSys SIGNON exit record will show the RLA= parameter value at the byte 0 of word 6.
With this enhancement, customers can fully implement Db2 external security, with attendant audit, cost, and management benefits, while reducing the performance overhead and reliability, availability and scalablilty risk (e.g. if RACF DB is locked by another process) of creating and deleting an ACEE once per transaction. Customers will still have the option of using end user and message-based processing with OTMA/APPC FULL security or legacy processing with DFSBSEX0 since the dependent region address space level ACEE will only be passed if the TCB level ACEE and ESAF_SIGNON_ACEE are not present. This enhancement will also be disabled by default and can be enabled by a dependent region startup parameter in the SSM PROCLIB member that defines the dependent region ESS connections.
Some customers will be able to eliminate DFSBSEX0 user exits, which may have been implemented in order to use Db2 RACF security for legacy SNA transactions. Certain customers will be able to switch from OTMA or APPC Security FULL with its attendant overhead and RAS risk for transaction processing.
Don’t forget to check out our newsletter for the latest updates from the IBM Z Application Platform!