(ZOS) Secure optimized local adapters for outbound support
Use this task when to set up security for our optimized local adapters that perform outbound calls.
Run the WebSphere Application Server for z/OS servers with global security and activate the Sync-to-OS Thread option if we intend to use the optimized local adapter APIs with those servers. To read about global security, see the topic, Enabling security. To read more about activating the Sync-to-OS Thread option, see the topic, z/OS security options.
Alternatively, the system administrator can provide a username and password on the optimized local adapters connection factory, or the application developer can provide a username and password on the ConnectionSpec object, which is used to obtain a connection from the optimized local adapters connection factory. A login is performed using this username and password combination, and the MVS™ user ID associated with the username is used when making optimized local adapters requests from this connection. If there is no MVS user ID associated with this username, then an MVS user ID is not used when making optimized local adapters requests from this connection.
Local access to WAS for z/OS servers is protected by the System Authorization Facility (SAF) CBIND class. This class is defined during profile creation and is used to protect WAS for z/OS servers when Internet Inter-ORB Protocol (IIOP) local client connection requests are made, and optimized local adapters requests. Before running any application that uses the Register API, be sure to grant READ access for the user ID for the job, UNIX System Services (USS) process, or Customer Information Control System (CICS ) region to the CBIND class for the target server. this is set up with the BBOCBRAK job. For more information about the CBIND class, read the topic, Using CBIND to control access to clusters.
For calling from WAS to an application using either the optimized local adapters Host Service and Receive Request APIs, the identity on the thread that the API was called on is used. For environments other than CICS, there is no attempt by the optimized local adapters to assert the WAS application identity. This includes Information Management System (IMS) dependent regions. For these, transactions start under the ID of the user that started the transaction. This includes IMS dependent regions. For these regions, transactions start under the user ID that started the transaction.
When transaction work passes between CICS and WAS for z/OS, either inbound or outbound, we must take into account some special security considerations. For example, we need determine if the authentication for inbound to WAS work should run with the authority of the specific CICS application or the overall CICS region authority. There are similar concerns when WAS sends outbound work to a CICS application; we need to determine if CICS should honor the originating application authority or its own CICS current security profile.
Ensure that the client applications are authenticated in order for CICS to process the request.
For receiving requests in CICS and processing them with the optimized local adapter CICS Link server (BBO$ task), we can indicate when we start the Link server to have Link server assert the propagated WAS thread-level identity to the CICS thread where the target program starts. This is done with a parameter on the optimized local adapters BBOC CICS transaction.
The following steps include the tasks that we must complete to secure the optimized local adapters for an outbound call:
Tasks
Configure the security settings. When using the optimized local adapters Host Service or Receive Request APIs in an application running under CICS, the authority of the CICS application that called these APIs is used. When using the optimized local adapters CICS Link server, we can indicate that we want the Link server task, BBO$, to assert the WAS identity before calling the target program as follows:
- On the optimized local adapters BBOC CICS transaction that we are using to start the Link server (with BBOC START_SRVR), pass the SEC=Y parameter. When this is specified, the optimized local adapters Link server task, BBO$, starts the link task, BBO#, with the identity that was propagated from calling the WAS thread.
- Ensure that the CICS region is running with security enabled and EXEC CICS START checking enabled. Security is enabled at start up with the parameter SEC=YES. The EXEC CICS START checking is enabled at start up with the parameter XUSER=YES.
- Create a SAF surrogate class that grants the identity that the optimized local adapters Link server is running with the authority to issue EXEC CICS START TRANSACTION API and pass the USERID that was propagated to CICS from WAS. The following is a sample that shows a surrogate class defined for user ID USER1 that allows user ID OLASERVE to issue EXEC CICS START TRANS(BBO#) USERID(USER1) and process optimized local adapters CICS Link transactions that run with the identity of USER1.
RDEFINE SURROGAT USER1.DFHSTART UACC(NONE) OWNER(USER1) PERMIT USER1.DFHSTART CLASS(SURROGAT) ID(USER1) PERMIT USER1.DFHSTART CLASS(SURROGAT) ID(OLASERVE) SETROPTS RACLIST(SURROGAT) REFRESH
We have set up security for the optimized local adapters connections.
What to do next
For more information about using security with IMS, see the topic, Security considerations when using optimized local adapters with IMS.
Related:
Optimized local adapters on WAS for z/OS Security considerations for WAS for z/OS Optimized local adapters for z/OS APIs Optimized local adapters environment variables z/OS security options Planning to use optimized local adapters for z/OS Secure optimized local adapters for inbound support z/OS: Use optimized local adapters for inbound support z/OS: Use optimized local adapters for outbound support Use CBIND to control access to clusters Enable security z/OS System Authorization Facility authorization Summary of controls Optimized local adapters for z/OS usage scenarios Security considerations using optimized local adapters with IMS