[esb-issues] [JBoss JIRA] Updated: (JBESB-1404) Support for JMS authentication

[Mark Little (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBESB-1404?page=all ]

Mark Little updated JBESB-1404:
-------------------------------

    Fix Version/s: 4.2.1 CP1

> Support for JMS authentication
> ------------------------------
>
>                 Key: JBESB-1404
>                 URL: http://jira.jboss.com/jira/browse/JBESB-1404
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Rosetta
>    Affects Versions: 4.2.1
>            Reporter: mwax
>             Fix For: 4.2.1 CP1
>
>
> ESB currently does not provide explicit support for JMS authentication.  In real production systems, authentication is typically manadatory.
> Potential solutions:
> In cases where JNDI authentication only is required, adding JNDI properties to the jms-provider definition will work, as in the following example for TIBCO:
> <jms-provider name="TIBCOJMSProvider"
> 	connection-factory="QueueConnectionFactory"
> 	jndi-context-factory="com.tibco.tibjms.naming.TibjmsInitialContextFactory"
> 	jndi-pkg-prefix="com.tibco.tibjms.naming"
> 	jndi-URL="tcp://myhost:7222">
> 		<property name="java.naming.security.principal" value="username"/>
> 		<property name="java.naming.security.credentials" value="password"/>
> ...
> However, for consistency it might be better to either create new attributes for the jms-provider element, e.g., jndi-security-principal, or to deprecate the jndi attributes and replace them with properties, such as:
> <jms-provider name="TIBCOJMSProvider"
> 	connection-factory="QueueConnectionFactory">
> 		<property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
> 		<property name="java.naming.provider.url" value="tcp://myhost:7222"/>
> 		<property name="java.naming.security.principal" value="username"/>
> 		<property name="java.naming.security.credentials" value="password"/>
> This latter alternative would simplify the code, which currently needs to translate from, e.g., jndi-URL to java.naming.provider.url.
> In cases where authentication is required to after the JNDI lookup, changes to the code are needed.  The following change to the JmsConnectionPool addAnotherSession method works when the JMS username and password are the same as the JNDI principal and credentials:
>             String username = poolKey.get(Context.SECURITY_PRINCIPAL);
>             String password = poolKey.get(Context.SECURITY_CREDENTIALS);
>             if (JMSEpr.QUEUE_TYPE.equals(destinationType)) {
>                 QueueConnectionFactory factory = (QueueConnectionFactory) factoryConnection;
>                 if (username != null || password != null) {
>                 	jmsConnection = factory.createQueueConnection(username, password);
>                 } else {
>                 	jmsConnection = factory.createQueueConnection();
>                 }
>             } else {
>                 TopicConnectionFactory factory = (TopicConnectionFactory) factoryConnection;
>                 if (username != null || password != null) {
>                 	jmsConnection = factory.createTopicConnection(username, password);
>                 } else {
>                 	jmsConnection = factory.createTopicConnection();
>                 }
>             }
> This does not work if the JMS username and password are distinct from the JNDI values.  I tried simply creating new keys to store the username and password, but this requires additional code changes, as methods such as JmsConnectionPool.getPool only have access to the java.naming.xxx properties of the EPR.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira