RACF security levels for OTMA
OTMA uses four levels of RACF® security: CHECK, FULL, JOIN, NONE, PROFILE.
Only one RACF security level can be in effect at one time for OTMA globally; however, using the /SECURE OTMA TMEMBER command, you can specify different security levels for individual OTMA clients.
- NONE
- A system-wide security
level. RACF is not called for
messages received through OTMA. Specifically:
RACF is not called when IMS receives the connection request (client-bid) from IBM® MQ or IMS Connect.
RACF is not called to verify that the user ID in the incoming message is a valid user ID (one that has been defined to RACF ).
RACF is not called to verify that the user ID in the incoming message is authorized to the IMS command or IMS transaction requested in the message.
The user ID caching scheme is not used.
- PROFILE
- A message-by-message
security level. In other words, each incoming message entered through
OTMA is checked to determine whether or not RACF will be called. IMS checks each incoming message independently
to see if the security value is set to NONE, CHECK, or FULL. Specifically:
Messages entered from IMS Connect will contain a 1-byte security flag field. The value in this field determines whether or not RACF is called.
Messages entered from the IBM MQ-IMS Bridge application will contain a SecurityScope field in the MQIIH structure. The value in this field will determine whether or not RACF is called.
Tip: Consider using the PROFILE security level for situations when application developers set the RACF security level as N (NONE), C (CHECK), or F (FULL) in each incoming message. In this case, the security level set in each message determines whether IMS calls RACF for security checking related to that message. You might not want application programmers deciding on the security for IMS commands and IMS transactions. RACF is called when IMS receives the connection request (client-bid) from IBM MQ or IMS Connect.
- JOIN
- A system-wide security level, which means that RACF is called only to authorize the user ID on the initial client bid request from an OTMA client, such as IMS Connect or MQ series.
After the connection is authorized, no additional transaction or command security checking is performed on messages that are received on the connection.
- CHECK
- A system-wide security
level, which means that RACF is
called for messages received through OTMA. Specifically, RACF is called:
- For client-bid connection requests. A cache, or hash table, is
built for each OTMA client if the client-bid is successful.
A user ID caching scheme is used in IMS/OTMA environments. The caching scheme also improves authorization checking performance.
A cache, or hash table, is used to store previously verified user IDs. Each OTMA client (IMS Connect, IBM MQ for z/OS®, or others) has a hash table created in the IMS control region after a successful client bid. Use of the hash table minimizes the number of calls to RACF to VERIFY user IDs. This way, if the same user ID enters multiple messages destined for IMS/OTMA, IMS can check the hash table for a valid entry for the user ID and might be able to avoid the VERIFY call to RACF. The entry for the user ID in the hash table contains a pointer to the accessor environment element (ACEE) for the user ID. The ACEE that is pointed to can be used for resource (command and transaction) FASTAUTH calls to RACF.
- To VERIFY that the user ID in the incoming message is a valid
user ID (one that has been defined to RACF).
If the OTMA client (IMS Connect or IBM MQ for z/OS) supplied a UTOKEN in the incoming message, IMS supplies the address of the UTOKEN on the VERIFY call to RACF. Use of the UTOKEN in VERIFY processing improves performance. RACF returns an ACEE security control block to IMS for verified user IDs.
- To verify that the user ID in the incoming message is authorized to the IMS command or IMS transaction requested in the message. The address of the ACEE, previously built by RACF during verify authorization processing, is supplied by IMS on the FASTAUTH call to RACF.
- To verify that the user ID in the incoming message is authorized to the IMS transaction code set as the destination on a DL/I CHNG or AUTH call. A cached ACEE is used for these calls, which eliminates performance concerns for application programs that issue many CHNG or AUTH calls.
- For client-bid connection requests. A cache, or hash table, is
built for each OTMA client if the client-bid is successful.
- FULL
- A system-wide security level, which means
that RACF will be called for
messages received through OTMA. FULL has the same characteristics as CHECK, with the following exceptions:
- During the verify processing, RACF is called a second time to build an additional ACEE security control block in the dependent region.
- The dependent region runs under the requestor's user ID. Any resources, such as files, that are accessed from the dependent region must be authorized to that user ID.