General OTMA security considerations

A number of general security considerations exist for OTMA that you should be aware of.

• If you use RACF® (or an equivalent product) for security, define the IMSXCF.group.client_member_name in the FACILITY class.

  If you define the IMSXCF.group.client_member_name in the FACILITY class, and if IMS™ security is not set to NONE, the user token for the client-bid request must be valid and the user must have READ access to the FACILITY class.

  If the user token for a client-bid request fails RACF verification, the client receives a NAK message from the server.

• Authorize the z/OS® cross-system coupling facility client for z/OS.
• If you define your OTMA applications with full security, the security environment is kept until the application ends.
• After IMS receives messages from OTMA, when OTMA security is activated, IMS calls RACF to verify that the user ID in the incoming message is a valid RACF user ID. IMS is not passed a password for the user ID, so the call to RACF is to verify the user ID only. If a password must be validated, it must be validated before sending the message to IMS.
• IMS uses the UTOKEN in the input message in the call to RACF not only to verify the user ID, but also to create a security control block in the IMS control region to represent each verified user ID. The security control blocks built in the IMS control region, representing verified RACF user IDs, are called accessor environment elements or ACEEs.
• The DL/I ICAL call has special security requirements related to the OTMA security configuration. The DFSYICAL tmember that is used for synchronous program switch request processing uses OTMA security configuration settings even if OTMA is not enabled.