Bitesize Blogging: MQ 9.0.1 - IBM MQ Console Role Based Access Control
63SV_Jonathan_Rumsey 11000063SV Comments (5) Visits (3019)
Another in the series of bitesize blog posts about new features in MQ. Check out the whole series here.
The IBM MQ Console is a browser-based MQ administration and monitoring tool. A browser based tool offers a number of advantages over other administration tools such as MQ Explorer or client runmqsc, including avoiding the overhead of installing and maintaining software packages locally, and also being available across a much wider variety of platforms and devices. The IBM MQ Console was first seen on the IBM MQ M2000 appliance, however with the recent release of MQ V9.0.1 it is now possible to deploy the console on additional platforms.
In addition to the wider platform support, MQ V9.0.1 offers a range of new capabilities in the IBM MQ Console to configure security for administration. This blog will take a look at one facet of that, namely role based access control.
What is Role Based Access Control ?
Role based access control can be described as an access control mechanism that maps security context/permissions to a set of roles, these roles can be granted to a user's account. Let me put try putting that into a generic example, lets take a user - "Joe Blogger". Joe can be granted one or more predefined roles ("Admin", "Reader" or "User") which allows him to perform different administration tasks. The roles define which operations can be attempted (i.e. create resource, inquire resource, etc) and which security context is used for access control checks (i.e. which userid is used for authority checks). Let us see how this model is used by the IBM MQ Console...
MQWebAdmin, MQWebAdminRO and MQWebUser
There are three roles which can be granted to users of the IBM MQ console, which define the MQ operations which can be attempted and also the security context that will be used for the MQ access control checks involved in those operations.
The most powerful role is "MQWebAdmin", which allows any user with that role to use all commands/operations (including create, start, stop and delete queue managers on non-z/OS platforms) and these operations will use the security context of the IBM MQ console itself when accessing MQ resources. Perhaps one way to think of this role is the equivalent of adding a user into the "mqm" group on a UNIX platform and granting them shell access.
The next role is "MQWebAdminRO", this allows any user granted the role to use immutable commands/operations against queue managers, for example inquiry and browse. As with the "MQWebAdmin" role, all of these operations will use the security context of the IBM MQ console when accessing MQ resources. One way to think of this role is granting read-only permissions on a distributed platform (i.e. OAM +dsp, +inq and +browse) to all queue managers and objects.
The last role is "MQWebUser", this allows any user granted the role to attempt commands/operations against queue manager, however unlike the other two roles the operation uses the security context of the authenticated user for access control checks against each queue manager. So in the example that user "joeblogger" had authenticated and had been given the "MQWebUser" role, if he tries to alter a queue attribute, the queue manager would check that "joeblogger" has +chg authority to that queue. This role gives the most granular control over access to queue manager resources and is more tightly coupled to MQ's existing access control.
A user may be assigned multiple roles, where these roles overlap there is a precedence order that is used to determine which role is used to determine which operations are permitted and also which security context is used. The "MQWebAdmin" role overrides all other roles and so if a user is assigned this role, it will always be used for all operations - it is also the only role that is allowed to crea
Overlapping roles is a convenient way in which you could mix the granularity of control with "MQWebUser" with the convenience of "MQWebAdminRO".
A users role(s) can be checked using the "About" menu option from the IBM MQ Console, this might help in understanding why certain options are 'greyed out';
Roles are assigned to users or groups through an XML configuration file called 'mqwebuser.xml', IBM MQ 9.0.1 ships a couple of samples to get you going based on the type of user registry and authentication that you want to use for the users of the IBM MQ Console (LDAP or Basic Registry). I'll cover the options you have for user registries in another article, but for now let's look at just the security-roles section in the basic registry example;
There are 3 types of role assignment here, the first is indicating that any authenticated user that is a member of the "MQWebUI" group is given the "MQWebAdmin" role. The second is indicating an authenticated user "reader" is given the "MQWebAdminRO" role. Finally, there is a special subject that states that all authenticated users are given the "MQWebUser" role. Let us consider "joeblogger" again, once he has authenticated he will be granted "MQWebUser" role and every operation (inquire queue manager, alter channel, etc) will check his user id for access control.
If "joeblogger" is added to the "MQWebUI" group he will also be granted "MQWebAdmin" role which takes precedence over all other roles, in this instance the IBM MQ Console will use its own security context to execute the commands on behalf of Joe. If a user authenticates as "reader" the security context used will vary based on the command/operation as the user has both "MQWebAdminRO" and "MQWebUser" roles, for example an inquire queue would use the security context of the IBM MQ Console, whilst start channel would need the "reader" user to have been granted +ctrl authority on the queue manager for this to be successful.