Asynchronous messaging - security considerations

 


Security for messaging operates as a part of global security, and is enabled only when global security is enabled.

JMS connections made to the JMS provider are authenticated, and access to JMS resources owned by the JMS provider are controlled by access authorizations. Also, all requests to create new connections to the JMS provider must provide a user ID and password for authentication. The user ID and password do not need to be provided by the application. If authentication is successful, then the JMS connection is created; if the authentication fails then the connection request is ended.

Standard J2C authentication is used for a request to create a new connection to the JMS provider. One can specify a Component-managed Authentication Alias and a Container-managed Authentication Alias for each JMS connection factory. The use of the associated J2C authentication data entries depends on the resource authentication (res-auth) setting, as follows:

User IDs longer than 12 characters cannot be used for authentication with the embedded WebSphere JMS provider. For example, the default Windows NT user ID, Administrator, is not valid for use with embedded WebSphere messaging, because it contains 13 characters.

Authorization to access JMS resources owned by the embedded WebSphere JMS provider is controlled by authorization data in

config/integral-jms-authorisations.xml


Styles of messaging in applications
WAS cloning and MQ clustering
Asynchronous messaging with WebSphere - an overview

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.