(zos)Secure optimized local adapters for inbound support
Use this task to set up security for the optimized local adapters connections that perform inbound calls.
Run the WAS for z/OS servers with global security and activate the Sync-to-OS Thread option if you intend to use the optimized local adapter APIs with those servers. To read about global security, see the topic, Enable security. To read more about activating the Sync-to-OS Thread option, see the topic, z/OS security options.
Local access to WebSphere Application Server 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 WebSphere Application Server 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 setup with the BBOCBRAK job. For more information about the CBIND class, read the topic, Using CBIND to control access to clusters.
All inbound requests to WebSphere Application Server run under the authority of the current user on thread. This identity is automatically propagated and is asserted in the EJB container and this identity is that which the application starts under. Inbound requests that drive into a target enterprise bean arrive in the same manner as method invocations do for local IIOP requests and the security options for RunAs work in the same way as local IIOP requests
When transaction work passes between CICS and WebSphere Application Server for z/OS, either inbound or outbound, you must take into account some special security considerations. For example, you must determine if the authentication for inbound to WebSphere Application Server work should run with the authority of the specific CICS application or the overall CICS region authority. There are similar concerns when WebSphere Application Server sends outbound work to a CICS application; you must determine if CICS should honor the originating application authority or its own CICS current security profile.
We must verify the client applications are authenticated in order for CICS to process the request.
For passing requests in to WebSphere Application Server from CICS, we can indicate to use the current CICS application identity by setting a flag for this with the Register API call.
The following steps include the tasks that you must complete to secure the optimized local adapters for an inbound call:
Configure the security settings. The security identity propagation type is specified in registration flags when the optimized local adapters connection request is made in the call to BBOA1REG. We can select either the CICS region or application security profile.
In order for this to function properly, we need to have enabled CICS application level security with the SEC=YES CICS startup option. Also, the CICS application user can only be propagated and asserted on the WAS thread when the ola_cicsuser_identity_propagate environment variable is set to 1. This gives control of this behavior to be managed by the WAS system programmer. When this option is set to 0 (the default), and the Register API calls CICS applications that select application level propagation, an error occurs. For more information about this environment variable see the topic, Optimized local adapters environment variables.
Set the environment variable to permit the CICS application-level identities to be used for authentication when the registration request is made. We can set the variable in the console as follows:
- Click Environment > WebSphere Variables.
- Under Scope, select Cell from the Show scope selection drop-down list. If the ola_cicsuser_identity_propagate environment variable displays in the resources list, we do not have to add it again. We can continue with step c. If we have not added the variable to the resource list, you must Click Add. The ola_cicsuser_identity_propagate environment variable must be added to the display list the first time you do this task. Each time after the initial addition, you are able to select ola_cicsuser_identity_propagate from the display list after set the scope.
- Click ola_cicsuser_identity_propagate A window displays the General Properties where we can configure the variable.
- Set the WAS environment variable to 1. If we set the environment variable to 0 (zero) or leave it undefined, the CICS application level security is not honored in an inbound call to WebSphere Application Server.
- Click Apply and OK.
Results
You have set up security for the optimized local adapters inbound 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 concepts
Optimized local adapters on WebSphere Application Server for z/OS Security considerations for WebSphere Application Server for z/OS Optimized local adapters for z/OS APIs Optimized local adapters environment variables
Related tasks
Security considerations using optimized local adapters with IMS z/OS security options Plan to use optimized local adapters for z/OS Secure optimized local adapters for outbound support Use optimized local adapters for inbound support 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