David Currie

I had a couple of questions last week relating to authentication aliases. When using WebSphere Application Server resources built on the JCA support, including JDBC data sources and JMS connection factories, there are a number of different mechanisms for specifying security credentials.

The simplest mechanism is to specify a username and password programmatically when creating a connection. Generally this is a bad idea as it involves hardcoding these credentials in to the application. The next option is to specify the username and password directly on the connection factory or data source when defining it administratively. This removes them from the application but means that any application with access to the JNDI namespace, whether it is running in the server or not, can retrieve the resource and create an authenticated connection.

Another option is to use a component-managed authentication alias. This involves creating a mapping from an alias name to the username and password. This alias name is then specified administratively on the connection factory or data source. As the alias can only be resolved in the application server, this restricts authenticated access to applications running in the application server.

One step better still is to use a container-managed authentication alias. This works in much the same way as the component-managed alias but the connection factory or data source needs to be looked up via a resource-reference that specifies a res-auth of Container. As a consequence, for an application to retrieve the authenticated resource, the administrator must have explicitly bound the resource-reference to the resource on deployment of the application.

The final option, which only became available in WebSphere Application Server Version 6, is to use a container-managed authentication alias but, rather than specify the alias on the connection factory or data source, the alias can be defined on the resource-reference itself. This means that only that application can retrieve the resource and create a connection with those associated credentials. There is one gotcha with this approach which was the source of the two questions I recieved: if you create an alias via the administrative console, it is prefixed with the name of the node via which the alias was created. Consequently, if you want to specify this alias name in your application you end up with a dependency on the deployment environment.

The thinking was that, if you created an alias on a standalone server and then federated it in to a cell, this approach would avoid naming collisions. Now, IMHO, it would have been preferable just to omit warnings on the federation or some such approach. Anyway, to avoid this issue, create the aliases via wsadmin as the prefix is then not added. The InfoCenter covers how to achieve this in Jacl or Jython.

This entry was posted on Wednesday, November 8th, 2006 at 5:57 pm and is filed under WebSphere Application Server. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.