Overriding authentication aliases on JMS connection factories

Paul_Titheridge |Feb 12 2016 Updated

IBM Knowledge Center contains a topic called Authentication aliases, which provides some useful information about how to configure authentication aliases inside of WebSphere Application Server for use with applications that are connecting to WebSphere MQ. These aliases map to a username and password combination, which can then be used by:

• Activation specifications
• Listener ports
• Enterprise applications that use the Java Message Service (JMS) API

whenever a connection to MQ is established.

The following question came up on this last week:

The section Overriding the authentication alias [in the Using the connection factory via an indirect lookup subtopic] says that when using an indirect lookup, in addition to setting res-auth to container, you can override what you have set for a J2C authentication alias by using "authDataAlias".  Why would you want to? Why not just use a different J2C authentication alias?

This is a good question!

You might have a connection factory that's shared across multiple JMS applications and listener ports running inside of WebSphere Application Server. This connection factory would have an authentication alias on it, so by default all applications that use this connection factory would use the same alias.
However, you might want one application to use the same connection factory, but pass a different set of credentials to the queue manager. You could do this in one of two ways:

• Create a copy of the connection factory just for this application (giving it a new JNDI name) and then configuring that to use a different authentication alias.
• Or use the original connection factory, and configure the application to use a different authentication alias by specifying the authDataAlias attribute in the deployment descriptor

It really depends on how you want to administer your application server. A lot of customers like the idea of using different connection factories, but then if the queue manager connection details change (maybe the port for the queue manager listener changes), two connection factory definitions need to be modified instead of just one.