Bitesize Blogging: MQ 9.0.1 - IBM MQ Console Authentication
63SV_Jonathan_Rumsey 11000063SV Comment (1) Visits (3273)
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 post will look at the user authentication options available in V9.0.1 and how to configure these.
The IBM MQ Console uses IBM WebSphere Liberty application server, which supports a wide range of security features to protect web based applications. I've already covered how MQ leverages role based access control for MQ in my blog
To be able to map a user or group to a role, we need the IBM MQ Console to know about the users who will be allowed to connect. The configuration of users and groups for the IBM MQ Console is achieved through using user registries, as with role mappings, these settings are managed through the mqwebuser.xml configuration file.
Two sample XML files are shipped identifying the two main choices for user registry, basic or LDAP.
Let us first look at the basic registry sample in "C:\Program File
<!-- Sample Basic Registry --> <basicRegistry id="basic" real
The sample provides a simple list of users and groups, the XML for the users defines the username and password, whilst the XML for groups defines the group names and user membership. We saw in the role based access control blog that users and/or groups can be assigned roles that allow the users to issue various commands/operations under varying security contexts. In this example (for clarity) the passwords are provided in cleartext, this represents a security risk as any user with authority to read the mqwebuser.xml will know the password for every user.
IBM WebSphere Liberty provides a tool which can be used to encode/encrypt these passwords called securityUtility;
The encoded password can be generated and pasted in the mqwebuser.xml in place of the cleartext password. For more details on the securityUtility tool see; http
A basic registry starts getting a little unwieldy with more than a handful of users or groups, for a larger number of users a better choice would be to use LDAP. With an LDAP registry the usernames, passwords and group membership information is held on a central server. The "ldap_registry.xml" sample gives an example of how this might be configured.
Within IBM, our team have used this approach to use our intranet credentials to effectively log into MQ. The same LDAP servers can also be used for both IBM MQ Console authentication and distributed queue manager OAM authorization checks, this might be particularly useful when configuring users to have "MQWebUser" roles.
There are two authentication methods for users of the IBM MQ Console in 9.0.1, either username and password submission via a HTML form or via client certificate authentication. Whilst username and password configuration is quick and simple to configure, the client certificate authentication needs a little more configuration, but allows users to sign into the IBM MQ Console without a password - with a certificate stored in their web browser. The steps needed to add a certificate to a browser varies by vendor, however the same steps are needed at the server end.
Firstly the IBM MQ Console must trust the certificates that it receives, to enable this, any intermediate and root CA certificates needed to validate a certificate need to be added to the consoles JKS trust store (if you don't have a trust store you'll need to create one);
Certificate to User mapping
The client certificate distinguished name maps to users in different ways dependent on the configured user registry. For an LDAP registry, the default mapping is to use the whole distinguished name to locate the LDAP user (i.e. "CN=jblogger, O=IBM, C=GB"), the mapping can be changed using further configuration options. If using a basic registry, the mapping takes the value of the common name ("CN=") attribute from the certificate to identify the user, so in this example the certificate DN would map to a user named 'jblogger'.
HTTP or HTTPS ?
The IBM MQ Console supports HTTPS at first startup in V9.0.1, to enable this protocol, a default self-signed certificate is generated for convenience. Whilst this is fine for testing purposes, things in life that are convenient are not normally as secure as they could be - it is strongly recommended that the self-signed certificate is exchanged for a certificate properly named and signed by a trusted CA before used in anger/production.
How about IBM MQ Console supporting HTTP ? Whilst it is possible to enable HTTP using the following XML;
<variable name="httpPort" value="9080"/>
...this is not recommended as the authentication credentials and security tokens are sent over a network in cleartext using HTTP protocol.
Anything else I should know ?
By default, the IBM MQ Console will open a port on 9443 on a local interface (127.0.0.1) listening for HTTPS requests. It is likely that you'll want at some point to allow browser access across a physical network, this can be achieved for by setting the following in mqwebuser.xml to listener on all network interfaces;
<variable name="httpHost" value="*"/>