For z/OS platforms

Securing optimized local adapters for outbound support on Liberty for z/OS

Secure your WebSphere® optimized local adapters (WOLA) connections that make outbound calls from the Liberty server.

Procedure

  1. Optional: Set up server-side security.
    1. Run the Liberty servers on z/OS® with server security. For more information, see Configuring authorization for applications in Liberty and Enabling z/OS authorized services on Liberty for z/OS.
    2. If you are calling from a Liberty server to Customer Information Control System (CICS®) and security is enabled on the CICS link server, choose a user ID to run the target CICS program.

      By default, the invocation subject obtains the MVS user ID that runs the target CICS program. The invocation subject is the subject that runs the application component that makes the optimized local adapters request. In many cases, this subject is the run-as identity that is configured in the application deployment descriptor.

      You can define an alternative subject to the invocation subject in three ways:
      • In the connection factory configuration, specify a user ID and password in an authData element, and reference the element in the connectionFactory element. In the following example, the optimized local adapter connection factory references the auth2 authData element, which specifies a user ID of user2 and an associated password.
        <connectionFactory jndiName="eis/ola" containerAuthDataRef="auth2">
         <properties.ola RegisterName="OLASERVER"/>
        </connectionFactory>
        <authData id="auth2" user="user2" password="{xor}Lz4sLCgwLTtt"/>

        For more information about configuring connection factories, see Configuring JCA connection factories.

      • The system administrator can provide a user ID and password on the optimized local adapters connection factory. For more information, see Connection factory properties for optimized local adapters on Liberty.
      • The application developer can provide a user ID and password on the ConnectionSpec object that obtains a connection from the optimized local adapters connection factory.

      The security service attempts to authenticate with the provided user ID and password. If authentication is successful, the new subject obtains the MVS user ID that runs the target CICS program.

    3. If you are calling from a Liberty server to IBM Information Management System (IMS) by using OTMA, the Liberty server can propagate the current user ID to the IMS region if the Liberty server and the application are both configured to use sync-to-OS-thread. The IMS region must also be running with the option OTMASE=FULL in the IMSPBxxx PROCLIB member.
  2. Set up client-side security.
    1. If you have CBIND enabled in System Authorization Facility (SAF), grant access to the clients that will use optimized local adapters.
      1. Define a profile for the Liberty server in the CBIND class. The profile name is BBG.WOLA.<WOLA1>.<WOLA2>.<WOLA3>, where WOLA1,WOLA2, and WOLA3 are the three parts of the optimized adapter group name that are specified in the <zosLocalAdapters> element in the server.xml file. You can define a profile by using the SAF RDEFINE TSO command. For example, the following command creates a profile in the CBIND class for a WOLA group that is named LIB1.LIB2.LIB3:
        rdef cbind bbg.wola.lib1.lib2.lib3 uacc(none)
      2. Permit READ access to the profile. For example, the following command permits read access for the username user name on the bbg.wola.lib1.lib2.lib3 profile:
        permit bbg.wola.lib1.lib2.lib3 class(cbind) access(read) id(username)
        You can use asterisks to permit a user access to multiple profiles. The following example permits READ access to the username user for all profiles that start with bbg.wola in the CBIND class:
        rdef cbind bbg.wola.* uacc(none)
        permit bbg.wola.* class(cbind) access(read) id(username)

      For more information about SAF commands and syntax, see the documentation for your version of z/OS.

    2. If you are running a CICS link server with security enabled, configure CICS to enable user identity assertion.
      1. Ensure that the CICS region is running with security enabled and EXEC CICS START checking enabled.
        • Enable security at CICS startup by specifying the parameter SEC=YES.
        • Enable EXEC CICS START checking at startup by specifying the parameter XUSER=YES.

        For more information about CICS system initialization parameters, see the documentation for your version of CICS.

      2. Create a System Authorization Facility (SAF) SURROGAT class definition that permits the user ID of the link server to issue the EXEC CICS START TRAN('BBO#') USERID(<propagated_id>) command.
        The following example shows a SURROGAT class that is defined for the USER1 user ID. The class enables user ID OLASERVE to run the EXEC CICS START TRANS(BBO#) USERID(USER1) command 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 

        For more information about defining a SURROGAT class, see the documentation for your version of CICS.


Icon that indicates the type of topic Task topic

File name: twlp_dat_security_out.html