IBM Websphere MQ : Changing away from applications running as mqm - Middleware News

  To move from running as an mqm user to a user that only has the authorities it needs and nothing more should probably done in a piece meal, step-by-step way. It should be noted that although these steps are designed to exhibit no change to the applications, the process should be run through on a test infrastructure before proceeding to production systems.

Step 1: Create some non-mqm users with all authorities.

In order to have applications running with only the authorities they need and nothing superfluous, you first need to be able to tell the applications apart. So our first step is to create some new user IDs that each application will use instead of using the mqm user ID. Initially we will create these users with privileges to everything so no change will be seen by the applications. These user IDs need to be created on the machine where the queue manager is running so that the component in the queue manager that checks authorities (the OAM on distributed platforms, or SAF-compliant External Security Managers such as RACF on z/OS) is able to use them.

Consider the naming scheme you will use to make it clear which user ID will be used by which application - this will pay dividends in the long run making it much more obvious when a user is trying to request access to resources that it shouldn't require.

Each new user that is created should be granted all authorities to all objects - this is a temporary state of affairs, and is only step one for moving off mqm users - in a later step you will then reduce the authorities each of these users has. You will need to decide whether you plan to set authorities on individual users or groups. On Unix, from V8, you have the choice of running the OAM in user mode or (the default) group mode. Prior to V8 you only had group mode on Unix. In group mode on Unix, any authority you set on a specified user was actually set on that's user's primary group and this means that unique primary groups for each new user would be the recommended configuration to aim for.

For now though, it may be helpful to use the wizard in the MQ Explorer GUI (see Blog Post: A non-privileged MQ administrator for more details) that can grant all administrative privileges in one click. This wizard shows a list of all the setmqaut commands to issue. Copying these from the Command preview window and editing them to change +alladm into +all will give you a set of commands to achieve this step.

Step 2: Convert the applications over to use these newly created user IDs

For client applications, you can set the appropriate user ID to be used for each SVRCONN when it runs against the queue manager. This can easily be done using CHLAUTH rules - which assumes you are on a minimum level of MQ V7.1 (if you're not a Security Exit can do the same job). There is some variety on how you might decide to do this which won't be covered in this post. For example, if you're already using SSL/TLS certificates on your client connections, you can use the Distinguished Name (DN) of the client certificate to allow you to uniquely identify the client and this the user ID that is should run with; alternatively, if you're not yet there, you might consider some IP address filtering to be better than nothing. Whatever you use to identify your client and thus map the user ID that the SVRCONN will run with, make sure you also block off anything that doesn't match by having a back-stop rule as described in Blog Post: CHLAUTH - the back-stop rule.

For locally bound applications, you should ensure that their environment is changed to be run under the new user ID instead of the mqm user. Since you have defined these users on the local machine alreadu this should be possible now.

Having made these changes, your applications should not be aware of any difference. They were previously running with a privileged user ID that automatically had access to everything, and now they are running with a non-privileged user ID that has been granted access to everything. Of course, as with any change, it may be worth now leaving it for a few days to bed in, in case you have some applications that were doing unusual things like requiring their messages to come from a specific user ID (which will of course now have changed). While you let this step settle in, you can be reviewing what is needed for the next step.

Step 3: Review which resources your applications need

The next two steps require you to get to know your applications. This may be really easy for you because your applications are provided with documentation which detail the resources, e.g. queues, topics, channels etc, that the application makes use of. However, for some people this may be harder because such information is not available and inspection of the application's behaviour is the only way to discover it. Of the next two steps, this step is probably slightly easier, locating the resources in use is easier by inspection than perhaps determining the exact operations utilised by the applications on those resources.

If your company uses a naming convention for its resources, then this may also be easier as that naming convention indicates the resources belonging to each application (or application suite). There are several methods you can utilise to determine which resources your applications make use of:-

• Interview the application team
  They may well know exactly what the application uses, and between you a list of the resources can be drawn up. You can then use the remaining method in this list to validate the list you have produced. Even if they don't know the details, the owners of the application should be able to give you enough detail to know whether the application is, for example, issuing administrative commands to the command server, or just doing normal application MQPUTs and MQGETs to application queues; and whether it makes use of topics.
• Manually monitor the application usage
  Commands such as DISPLAY CONN, DISPLAY QSTATUS and DISPLAY TPSTATUS will show you the resources in use by an application at the time of the command. This is of course not an exhaustive list as the application may use some resources for a very short period of time and you may not catch it with a display command
• Use Activity Trace to monitor the application more closely
  Activity Trace can be configured to only apply to a single, or very small subset of applications at a time, thus reducing its impact on the overall system. This will give you a complete view of all the resources used by the application (and also the actions it takes, so save the output for Step 4).

Now armed with all this information you can look to reduce the resources each user ID is allowed to access. There are immediately some low hanging fruit here. With a privileged user ID, the application had access to all the administrative commands as well as all the application operations. It is highly unlikely that most of your business applcations would have any need for these authorities, and your interview with the application team should at least have informed you of this much. Here is a table of the reources that initially you should be able to remove all authorities for from your user IDs.

Resource Type ‑t on the setmqaut command	Notes
authinfo	Authentication Information objects, Channel objects (including client connection channels), Communication Information objects, Listener and Service objects cannot be MQOPENed, so the only time an application would need access to these resources would be if it was issuing administrative commands to the command server
channel
clntconn
comminfo
listener
service
namelist	Namelists and Processes can be MQOPENed and MQINQuired by applications, but as a less common application usage, this may be something you can rule out too. Additionally, if you don't have any namelists or processes defined other than the SYSTEM.DEFAULT ones, then that may also offer a clue.
process
rqmname	This specific resource type is only applicable for cluster queues and only if you have the qm.ini setting ClusterQueueAccessControl=RQMName. If you are not making use of clusters or don't have this qm.ini setting, then it is an easy one to rule out. If you are making use of cluster queues and are running the OAM in the above mode, then you need to look for applications making MQOPEN calls to fully qualified queues, such as a ReplyToQ with ReplyToQMgr.
topic	If you're not making any use of Publish/Subscribe, then this object can also be ruled out. If you are, you will need to know what applications are using, just as you need to know for queues.

Any of these resource types that you can rule out immediately, then you can issue one of the following commands to remove their authorities from all your user IDs (or their groups depending on which mode you are using).

setmqaut -m qmgr-name -t type-from-left-column -n "**" -p user -all

setmqaut -m qmgr-name -t type-from-left-column -n "**" -g group -all

For the remaining resources types that can't be obviously removed, queue, qmgr and perhaps some topic, namelist and process objects, we need to know the names of the objects that are in use. You should have gleaned this information by the methods listed above. With that information your aim is to be able to put in place commands such as these (again one example using a user and one using a group).

setmqaut -m qmgr-name -t type -n "SALESAPP.**" -p user +allapi +dsp

setmqaut -m qmgr-name -t type -n "SALESAPP.**" -g group +allapi +dsp

In the above command SALESAPP, is an example of a prefix to the object name that might be used for several related objects. If this naming convention is used in your objects, you will be able to make generic profiles instead of lots of individual profiles. We set the authority +allapi rather than +all because we have ruled out the need for administrative access to the objects. We include +dsp as it is used for some API calls such as temporary queue creation.

After adding the various specific object profiles needed, the overall '**' profile can be removed with the same command that you used for the types that were considered low hanging fruit.

Step 4: Review which actions your applications take on the resources

By this point we have seriously reduced the authorities each application has been granted. Where before they were running under a privileged user ID that automatically had access to all resources, now they are running under a non-privileged user ID that has full API access to only a few resources. These resources belong to that application, so you could argue that even if they decide to do things that they aren't supposed to do, like setting the context of messages, or issuing MQSET on the queue, they are only harming themselves. While you may consider that to be an appropriate stance to take for you own queue managers, after all you've come a long way already, we are going to look at those more dangerous authorities and look to reduce those on your application user IDs as well.

Here is a table that lists all of the authorities that you should look seriously at whether the application user IDs need them at all. Some will be easy to remove whereas others will require you to get details from the applcation team and/or review the Activity Trace output for their usage.

Authorization	Notes
altusr	For a normal business application, altusr authority should not be necessary. It allows the authority checks to be made under a different user ID. If everything were previously running under a privileged user ID, it would seem very unlikely that this would be in use.
pub	If you're not using Publish/Subscribe, then this can of course be ruled out, but then you already ruled out the topic objects above anyway in that case, since it is only applicable on those objects. If you are making use of topics and subscriptions then these are appropriate and can be considered to be in the lower table.
sub
resume
set	There aren't many things that can be MQSET on a queue, the main example would be turning triggering back on again when utilising trigger depth. This is likely to be fairly unusual behaviour in general but can be spotted by displaying all your queues and looking at the trigger settinsg. and it will also show up in your activity trace so you'll know if the applcation requires it.
passall	The use of context passing is fairly specialist, an application that distributes work sitting in between input application queues and the backend working process might use this. Normal business applications are unlikely to need these.
passid
setall	The use of context setting is even more specialist, and allows that application to masquerade as any other entity. Close review of any need for this authority should be made.
setid
chg	If we have already ruled out the need for administrative commands then none of these Administrative authorities should be required by your business applications. We don't include dsp in this as noted below.
clr
crt
dlt
ctrl
ctrlx

This table lists the authorizations that would be expected to be in use by a business application, and if you get down to just this list, you are in a very good place. Of course there will always be exceptions which is exactly why the above authorities exist at all, but if there is good justification for the application needing additional ones, then that is fine.

Authorization	Notes
browse	Only on queues of course
connect	Every application will need this on the qmgr object.
get	Only on queues of course
inq	This may well be rarer than some of the others, but still in the realms of good practice, for example for obtaining the back-out queue name for an application that processes request messages and wants to avoid the poison message looop.
put	Only on queues or remote queues and thus the rqmname resource type.
dsp	Needed for operations such as using temporary queues created from a model queue.

The aim of your review in this step is to be able to put in place commands such as these which only use a few of the authorities instead of the wider set we previously had. Again we illustrate one of each for user or for group - use the appropriate one depending on what mode you have chosen to run with. Note that the command removes everything we had previously granted and then adds only what we need.

setmqaut -m qmgr-name -t queue -n "SALESAPP.**" -p user -all +put +get

setmqaut -m qmgr-name -t queue -n "SALESAPP.**" -g group -all +put +get

Step 5: Review what you have ended up with

One way to review all the authorities you now have is to use the MQ Explorer GUI to view them. Explorer can also show you accumulated view of what each user has so if you've mixed up your users and groups and not stuck to a single regime, this will show up here.

To review the authorities set for, say queues, right-click on the Queues folder, choose Object Authorities → Manage Authority Records... and this will bring up a dialog like the one shown below. You can see the authorities each user has on each queue profile by means of the tick marks.

You can of course review the output on the command line if you prefer by using the dspmqaut command.

At the end of this process, however detailed you decided to make it, you will have a greatly reduced access to your resources by the user IDs being used by your applications. Combine this with some authentication features for your client applications especially (such as SSL/TLS digital certificates, or the new MQ V8 user ID and password checking) and CHLAUTH to map that authenticated connection onto the correct MCAUSER ID, and only allowed application can get in, and once in, they can only do what they are supposed to do.

This is not a trivial exercise to do, and should be practiced in a test environment first, but this step-by-step process should make it possible to change over without a huge upheaval to the applications.