Refreshing queue manager security on z/OS

IBM MQ for z/OS caches RACF data to improve performance. When we change certain security classes, we must refresh this cached information. Refresh security infrequently, for performance reasons. We 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, we 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 we have a queue sharing group, we can use the command scope attribute to direct the command to all the queue managers in the group.

If we are using generic profiles in any of the IBM MQ classes, we must also issue normal RACF refresh commands if we 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. We 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, refer to 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.
Figure 1. Logic flow for IBM MQ security caching
If we 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:

This means we 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 we change a profile in either the MQCONN or MQCMDS classes.

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

For performance reasons, use REFRESH SECURITY as infrequently as possible, ideally at off-peak times. We 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, we change the user rather than the resource profile. We 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)
We 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, we must tell RACF to refresh the generic profiles for MQQUEUE. For example: 
SETROPTS GENERIC(MQQUEUE) REFRESH
Then we 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. Parent topic: IBM MQ for z/OS security management