CC: JMS over HTTPS Login not propagated to Queue ConnectionF

[greyfairer]

I posted this last week in the Security forum, no answer so far
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68098

"greyfairer" wrote:
Hi all,

We are setting up a secured JMS communication channel over https with CLIENT-CERT authentication. To post to the different Queue's, we also need different roles, and we want to reuse the client certificate mapping to get the required roles.

We manage to get through the HTTPIL Layer to get the ConnectionFactory, but when posting to the secured Queue, the role we got for the HTTPIL seems not to be propagated to JMS, and we get:

javax.jms.JMSSecurityException: Connection not authorized to addMessages to destination: private

Client Code:

-Djavax.net.ssl.trustStore=c:/server-truststore.jks -Djavax.net.ssl.trustStorePassword=xxx -Djavax.net.ssl.keyStore=c:/client-keystore.jks -Djavax.net.ssl.keyStorePassword=xxx

 System.setProperty( "java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory" );
 System.setProperty( "java.naming.provider.url", "https://localhost/invoker/JNDIFactory" );
 System.setProperty( "java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces;java.protocol.handler.pkgs" );
 InitialContext iniCtx = new InitialContext();
 QueueConnectionFactory qcf = (QueueConnectionFactory)iniCtx.lookup( "ConnectionFactory" );

 QueueConnection conn = qcf.createQueueConnection();
 QueueSession session = conn.createQueueSession( false, QueueSession.AUTO_ACKNOWLEDGE );
 Queue queue = (Queue)iniCtx.lookup( "queue/" + queueName );
 conn.start();
 QueueSender send = session.createSender( queue );
 TextMessage tm = session.createTextMessage( text );
 send.send( tm );send.close();
 conn.stop();session.close();conn.close();

jboss-destinations-service.xml

<mbean code="org.jboss.mq.server.jmx.Queue"
 name="jboss.mq.destination:service=Queue,name=private">
 <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
 <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
 <attribute name="SecurityConf">
 <security>
 <role name="registered" read="true" write="true"/>
 </security>
 </attribute>
 </mbean>

login-config.xml

<application-policy name = "jbossmq">
 <authentication>
 <login-module code="org.jboss.security.auth.spi.CertRolesLoginModule" flag = "required">
 <module-option name="securityDomain">java:/jaas/jbossmq</module-option>
 <module-option name="rolesProperties">props/jbossmq-roles.properties</module-option>
 <module-option name="verifier">org.jboss.security.auth.certs.AnyCertVerifier</module-option>
 </login-module>
 </authentication>
 </application-policy>

jbossmq-httpil.war web.xml

<security-constraint>
 <web-resource-collection>
 <web-resource-name>HttpInvokers</web-resource-name>
 <url-pattern>/*</url-pattern>
 <http-method>GET</http-method>
 <http-method>POST</http-method>
 </web-resource-collection>
 <auth-constraint>
 <role-name>guest</role-name>
 <role-name>registered</role-name>
 </auth-constraint>
 </security-constraint>
 <login-config>
 <auth-method>CLIENT-CERT</auth-method>
 </login-config>
 <security-role>
 <role-name>guest</role-name>
 </security-role>
 <security-role>
 <role-name>registered</role-name>
 </security-role>

jbossmq-roles.properties

registered-client=registered

jbossweb-tomcat55.sar

<Connector port="443" address="${jboss.bind.address}"
 maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
 emptySessionPath="true"
 scheme="https" secure="true" clientAuth="false" sslProtocol="TLS"
 keystoreFile="c:/server-keystore.jks" keystorePass="barcot3st"
 truststoreFile="c:/server-truststore.jks" truststorePass="barcot3st"/>
 <Engine name="jboss.web" defaultHost="localhost">
 <Realm className="org.jboss.web.tomcat.security.JBossSecurityMgrRealm"
 certificatePrincipal="org.jboss.security.auth.certs.SubjectCNMapping"/>
 <Host name="localhost" autoDeploy="false" deployOnStartup="false" deployXML="false"></Host>
 </Engine>

It works fine if we use a separate JAAS policy for the JMS Layer, using the UsersRolesLoginModule for the destination Queue, and send username and password from the client, and doing an explicit login to connect to the queue:

QueueConnection conn = qcf.createQueueConnection("registered-client","password");

Is it possible somehow to propagate the JAAS role used to login at the HTTPIL Layer to the JMS layer, so we don't need to use an extra password?
Or is it possible that the JMS Layer can use the Client Cert used to log in at the HTTPIL Layer to authenticate for the Queue?

May thanks in advance, Geert.

[benoitx]

Geert,

Sorry, I do not have the answer but... I am very very interested in it... Have you made any progress?

Also, whether you use JAAS or the createConnection with password, can the consumer of the message know who sent it? Typically do you know of any means to allow an MDB to have the security context/credential...

Login using JAAS to access our JNDI env is ok, but the MessageDrivenContext does not seem to get any credential, calling ctx.ctx.getCallerPrincipal() throws an exception.

Many thanks

Benoit

[jaikiran]

Reason why you are getting the exception is :

The security methods--getCallerPrincipal() and isCallerInRole()--also throw a RuntimeException if invoked on a MessageDrivenContext. When an MDB services a JMS message there is no "caller," so there is no security context to be obtained from the caller. Remember that JMS is asynchronous and doesn't propagate the sender's security context to the receiver--that wouldn't make sense, since senders and receivers tend to operate in different environments.

Have a look at:
Section MessageDrivenContext at:
http://www.onjava.com/pub/a/onjava/excerpt/ejb3_ch13/?page=5

[greyfairer]

Also, whether you use JAAS or the createConnection with password, can the consumer of the message know who sent it?

I guess jaikiran is right, it doesn't make sense in JMS to transport the security context outside of the message. If you want to transport it, you'd have to encode it in the message...

Anyway, my original problem isn't solved yet. I just want the sender security context of the HTTPIL to be transported to the sender security context of the Queue beneath it.