Refreshing queue manager security on z/OS

IBM® MQ for z/OS® caches RACF® data to improve performance. When you change certain security classes, you must refresh this cached information. Refresh security infrequently, for performance reasons. You can also choose to refresh only TLS security information.

When a queue is opened for the first time (or for the first time since a security refresh) IBM MQ performs a RACF check to obtain the user's access rights and places this information in the cache. The cached data includes user IDs and resources on which security checking has been performed. If the queue is opened again by the same user, the presence of the cached data means that IBM MQ does not have to issue RACF checks, which improves performance. The action of a security refresh is to discard any cached security information and so force IBM MQ to make a new check against RACF. Whenever you add, change or delete a RACF resource profile that is held in the MQADMIN, MXADMIN, MQPROC, MXPROC, MQQUEUE, MXQUEUE, MQNLIST, MXNLIST, or MXTOPIC class, you must tell the queue managers that use this class to refresh the security information that they hold. To do this, issue the following commands:

The RACF SETROPTS RACLIST(classname) REFRESH command to refresh at the RACF level.
The IBM MQ REFRESH SECURITY command to refresh the security information held by the queue manager. This command needs to be issued by each queue manager that accesses the profiles that have changed. If you have a queue sharing group, you can use the command scope attribute to direct the command to all the queue managers in the group.
Note: If you have connected a new user to an existing group, you need to run the IBM MQ RVERIFY SECURITY(userid) command. The REFRESH SECURITY(*) command does not let the queue manager sign this user on again, the next time it tries to access an IBM MQ resource.

If you are using generic profiles in any of the IBM MQ classes, you must also issue normal RACF refresh commands if you change, add, or delete any generic profiles. For example, SETROPTS GENERIC(classname) REFRESH.

However, if a RACF resource profile is added, changed or deleted, and the resource to which it applies has not yet been accessed (so no information is cached), IBM MQ uses the new RACF information without a REFRESH SECURITY command being issued.

If RACF auditing is turned on, (for example, by using the RACF RALTER AUDIT(access-attempt (audit_access_level)) command), no caching takes place, and therefore IBM MQ refers directly to the RACF dataspace for every check. Changes are therefore picked up immediately and REFRESH SECURITY is not necessary to access the changes. You can confirm whether RACF auditing is on by using the RACF RLIST command. For example, you could issue the command

RLIST MQQUEUE (qmgr.SYSTEM.COMMAND.INPUT) GEN

and receive the results

CLASS      NAME                                
-----      ----                                
MQQUEUE    QP*.SYSTEM.COMMAND.*.** (G)         
    AUDITING                
    --------                
    FAILURES(READ)

This indicates that auditing is set on. For more information, see the z/OS Security Server RACF Auditor's Guide and the z/OS Security Server RACF Command Language Reference.

Figure 1 summarizes the situations in which security information is cached and in which cached information is used.

IBM MQ checks whether object and userid information is currently in the cache. If so, and it is specified that cached information is to be used, the security decision is based on the cached information. If object and userid information is not currently in the cache, IBM MQ interrogates RACF. If RACF warning mode is active, data is not cached. If warning mode is not active, it checks whether access is permitted. If not, data is not cached. If access is permitted but Audit(Success) is set on, data is not cached. Otherwise (which means that either auditing is turned off, or Audit(Failure) is on) data is cached. — Figure 1. Logic flow for IBM MQ security caching

If you change your security settings by adding or deleting switch profiles in the MQADMIN or MXADMIN classes, use one of these commands to pick up these changes dynamically:

REFRESH SECURITY(*)
REFRESH SECURITY(MQADMIN)
REFRESH SECURITY(MXADMIN)

This means you can activate new security types, or deactivate them without having to restart the queue manager.

For performance reasons, these are the only classes affected by the REFRESH SECURITY command. You do not need to use REFRESH SECURITY if you change a profile in either the MQCONN or MQCMDS classes.

Note: A refresh of the MQADMIN or MXADMIN class is not required if you change a RESLEVEL security profile.

For performance reasons, use REFRESH SECURITY as infrequently as possible, ideally at off-peak times. You can minimize the number of security refreshes by connecting users to RACF groups that are already in the access list for IBM MQ profiles, rather than putting individual users in the access lists. In this way, you change the user rather than the resource profile. You can also RVERIFY SECURITY the appropriate user instead of refreshing security.

As an example of REFRESH SECURITY, suppose you define the new profiles to protect access to queues starting with INSURANCE.LIFE on queue manager PRMQ. You use these RACF commands:

RDEFINE MQQUEUE PRMQ.INSURANCE.LIFE.** UACC(NONE)
PERMIT PRMQ.INSURANCE.LIFE.** ID(LIFEGRP) ACCESS(UPDATE)

You must issue the following command to tell RACF to refresh the security information that it holds, for example:

SETROPTS RACLIST(MQQUEUE) REFRESH

Because these profiles are generic, you must tell RACF to refresh the generic profiles for MQQUEUE. For example:

SETROPTS GENERIC(MQQUEUE) REFRESH

Then you must use this command to tell queue manager PRMQ that the queue profiles have changed:

REFRESH SECURITY(MQQUEUE)

Refreshing SSL/TLS security

To refresh the cached view of the TLS Key Repository, issue the REFRESH SECURITY command with the option TYPE(SSL). This enables you to update some of your TLS settings without having to restart your channel initiator.