IMS Security Enhancements Focus on Distributed Information
Recent IMS enhancements enable propagation of distributed user identity into IMS for logging and auditing purposes.
By Rita Shih
Every IT team today is looking for ways to improve security and strengthen data protection. In today’s heterogeneous, distributed computing environment, the ability to preserve a user identify from one security realm to another can significantly enhance accountability and reduce vulnera-bilities.
Some recent IMS enhancements enable propagation of distributed user identity into IMS for log-ging and auditing purposes. As more transactions come in driving more workloads, Open Transac-tion Manager Access (OTMA) is also enhanced to provide better flood control of RACF Accessor Environment Element (ACEE).
Network Security Credential Propagation
A transaction that originates from a remote system enters IMS with a distributed identity, which represents user identity information (e.g., an X.500 distinguished name and its associated light-weight directory access protocol (LDAP) realm that originates from a remote system). This dis-tributed identity might be lost if it is mapped to a different z/OS System Authorization Facility (SAF) user ID for authentication and authorization (see Figure 1).
Starting with IMS V15, you can propagate up to 500 bytes of the distributed identity, also known as network security credential, for auditing and logging purposes. This new function allows a distributed user identity to flow into IMS and be added to the IMS log records with the SAF user ID. Note that IMS does not use this distributed user identity for authentication or authorization, and this IMS function is not using z/OS RACF identity propagation. See Figure 2.
IMS Transaction Manager Resource Adapter (TMRA) in IMS 15 supports this function by providing an extendable custom Java Authentication and Authorization (JAAS) login module. This module needs to be installed in WebSphere Application Server and linked to the applica-tion. Once a user credential is authenticated, TMRA will pass the distributed user ID and registry name to IMS through IMS Connect. Prior to setting up the login module, the application needs to have container-managed security enabled. To do so requires modifying the application’s web.xml file. In addition, a user account registry that contains authorized users (e.g., an LDAP server) must also be accessible by WebSphere Application Server.
IMS Connect user-written applications can pass in the network security credentials. IMS Con-nect 15 adds two new IMS request message extension specifications with an ID of *NETUID* for up to 246 bytes of distributed user ID, and an ID of *NETSID* for up to 254 bytes of registry name. The enhanced IMS Connect message exit (HWSSMPL0 or HWSSMPL1) is required. However, note that applications using the IMS Connect API in IMS Enterprise Suite can’t use this function.
The OTMA Callable Interface in IMS 15 also adds two new APIs, otma_send_receivey and ot-ma_send_asyncx, to send up to 200 bytes of network security credentials to IMS. OTMA clients, as they support OTMA protocol, can explore this new function by expanding their OTMA secu-rity prefix with network security credentials.
Once IMS accepts the input transaction with the network security credential, IMS application running in a dependent region can issue the enhanced DL/I INQY call with sub-function MSGINFO to query the data. The returned distributed credentials are placed at the end of the I/O area. Two new pointers inside the INQMSGIN DSECT can be used to point to the distributed user ID and the registry name. See Figure 3 for a COBOL example.
z/OS Connect Enterprise Edition Passing Distributed Identities to IMS
z/OS Connect Enterprise Edition (EE) versions 3.0 and 2.0.10 or later support this network secu-rity credential propagation to IMS. When the z/OS Connect EE server detected that it’s connect-ing to IMS Connect V15, by default, it passes the distributed network security credentials to IMS Connect. The distributed network security credentials can include a network user ID and a net-work session ID.
Figure 4 from the z/OS Connect EE server.xml file (under the server/ subdirectory of your server instance) shows a sample basic authentication registry definition that is configured for a z/OS Connect EE server. In this example, the specified user name (network user ID) and realm (network session ID) are passed to IMS Connect, as highlighted in the z/OS Connect EE log in Figure 5. Figure 5 shows a sample buffer sent to IMS Connect from the z/OS Connect EE log (the imsmobile.log file under the logs/ subdirectory of installed server) with the dis-tributed identity.
IMS Connect then passes the distributed user identity to IMS to propagate to the IMS log records for IMS 15. Figure 6 shows a sample Fast Path X’5911’ log record of the front-end IMS in a shared-queues environment.
z/OS Connect EE won’t pass the network security credentials to IMS Connect when IMS Con-nect is at 14 or lower. If IMS Connect 15 is running with an older versions of IMS (IMS 14 or lower versions), IMS would tolerate the network security credentials that are passed for Full Function transactions and store them in IMS log records. You can modify the user exit HWSJA-VA0 to strip off the network security information if IMS isn’t at V15.
Table 1 shows the IMS behavior depending on the version of IMS Connect by using the z/OS Connect EE usage scenario as an example.
Flood Control for Security ACEE
An enhancement to the OTMA security module is made available via V14 APAR PI68466 and V15 APAR PI81171 to control the number of RACF ACEE that’s cached in IMS.
Each ACEE control block for a RACF user ID (userid) represents the current user’s security en-vironment. IMS OTMA calls RACF to obtain the user’s ACEE for authorization and caches the ACEE for reuse for performance reason. However, when many ACEEs are cached for RACF user IDs, virtual storage in the IMS control region could run out. A new ACEE flood control pa-rameter, TOACEE=, has been added to the DFSOTMA descriptor in the DFSYDTx member of the IMS PROCLIB data set. When TOACEE=YES is specified, IMS will monitor the number of cached ACEEs for OTMA with the default limit of 30,000 RACF user IDs. The cached ACEEs will be chained using the least recently used (LRU) concept so that the LRU user ID with its ACEE will be pushed to the end of the chain for fast cleanup.
If you want to have a higher limit of ACEEs cached in the system, the parameter ACEEUSR= in DFSOTMA descriptor in DFSYDTx member of IMS PROCLIB data set can be used to set a dif-ferent limit for RACF userid, which can be up to 60,000. Since the age of each cached ACEE in the system is depending on the aging value specified by its OTMA client, specifying a lower ag-ing value will expedite the ACEE cleanup process. If needed, issue the following IMS command to specify an aging value override for a faster ACEE cleanup:
/SECURE OTMA ACEEAGE aging_value_in_seconds [TMEBER member-name]
The network security credential propagation enhancement in IMS 15 provides a mechanism to allow a user identity from an external security realm to be preserved, regardless of where the identity information was created, strengthening accountability across distributed environments. Enhanced OTMA flood control for RACF ACEEs in IMS 14 (APAR PI68466) and IMS 15 (APAR PI81171) improves the overall reliability of security support in OTMA.
Rita Shih is an IMS quality analyst with IBM. She can be reached at firstname.lastname@example.org
Jack Yuan is a senior software engineer for IMS development at IBM. He can be contacted at email@example.com.
Yee-Rong Lai is an IBM information developer, focusing on IMS integration solutions and tools.
Sponsored ContentAchieve Compliance Without Impacting Productivity
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus