WebSphere: Connect an application to the default messaging provider using the Run-as identity

Authenticating the messaging provider

Typically, a JMS application authenticates using a statically configured mapping identity. This identity can be configured using an authentication alias on the connection factory or an authentication alias on a resource reference. These are off-the-shelf mechanisms provided by ibm®websphere®application Server.

People often ask me how to authenticate the JMS connection to the service integration bus using the application identity. People who ask me this question usually do this for two reasons:

They think this is how the bus should be authenticated.

They need this functionality.

People who ask such questions for the first reason may think the most obvious is the simplest, regardless of their security implications. The person who raised the issue for the second reason may have analyzed the application requirements, often taking into account the security implications of using the application identity.

The answers I give are different, depending on the reasons, but the answers are often the same-but only because it is often difficult to tell the reason for the problem. If you are for the first reason, you should use the application identity, which is simple and straightforward. But there are drawbacks, and it is only after understanding the risks involved that this approach should be considered comprehensively. Of course, after this step, it is classified into the second category.

This article explains the security risks involved in using the application identity to help you determine whether you need this feature or if you really should deploy it. For the scenarios that you want to continue, the remainder of this article explains how to implement this functionality for the service integration bus.

What is an application identity?

When security is enabled for a Java EE application, the application uses the identity for execution. Secure WEB applications are typically executed using the identity of the user who is authenticated by the application. Enterprise Bean (or Web Service) applications, on the other hand, can be executed using the identity of the caller (similar to how the Web application is run) or a specific identity (called a Run-as identity). The latter is implemented by setting the Run-as role for Enterprise JavaBean; the identity of the running thread is called the application identity.

Considerations before starting the implementation

Typically, you should limit the number of identities used to send or receive messages. Of course, you should not provide this permission to users who are authenticated by the application, or they will be able to put messages directly into the queue to circumvent the application's business logic.

In order to have the appropriate context, suppose we have an Internet-based online store. When someone buys something, the WEB application sends two messages, one for payment and the other for the warehouse to distribute the items. (This sample is simplified for this article.) If a user of the WEB application is able to send a message to the warehouse queue, the user can distribute the warehouse goods directly by sending a new message, without paying. Alternatively, if the user is able to receive messages from the payment queue, the user can delete the message that caused the payment to be processed.

Therefore, these techniques should not be used to project the end user identity directly into the queue. Instead, you can use it to project other identities that reflect the system's identity, rather than projecting the identity of the human end user. Therefore, if your application is intended only for other system calls, the Java EE identity of the caller may be projected in a very correct manner, and it may not be good to use this technique to send the identity of the Web user to the queue.

About the solution

The solution relies on several different features of the application server:

Java Connector Architecture (JCA): The default messaging provider inserts an application server runtime by using the JCA resource adapter. JCA defines a mechanism for the container to provide credentials to the resource adapter that will be used on the connection.

Resource reference: You should always use resource references to find JMS connection factories. The application for this work contains a query string that begins with "java:comp/env/." A resource reference has multiple properties, one of which is about whether the container or application should provide credentials. In this case, the container must provide credentials.

Java Authentication and Authorization Service (JAAS): WebSphere application Server uses the JAAS application logon configuration to prepare credentials to be passed to the resource adapter when a connection is created.

Lightweight third-party authentication (lightweight thirdparty AUTHENTICATION,LTPA): In WebSphere application Server V6.1, the default message provider supports authentication using the LTPA token format. This allows the authentication session to be securely transmitted between remote processes.