10 Replies Latest reply on Aug 15, 2007 9:07 AM by Tim Fox

    JBM and JAAS Client authentication

    Brendan Sibre Newbie

      I was under the impression that JBoss Messaging worked with the JAAS ClientLoginModule described in the JBoss AS User Guide for remote messaging clients. I understood this to mean that it would not be necessary to pass a username and password to the connectionFactory.getConnection() method.

      This seems to work for sending messages, but not for receiving messages.

      I have the DefaultSecurityConfig set to:

      <security>
       <role name="guest" read="false" write="false" create="false"/>
       <role name="admin" read="true" write="true" create="true"/>
      </security>
      


      In the destination queue, the SecurityConfig is set to:
      <security>
       <role name="admin" read="true" write="true" create="true"/>
      </security>
      


      I have a client that does the following:

      1) Perform a JAAS login using the ClientLoginModule
      2) Obtain a connection factory from JNDI
      3) Obtain a connection (without a username/password)
      4) Obtain a transacted session
      4) Send 5 messages to DEST
      5) Commit the session
      6) Set up a consumer for DEST

      This fails at step 6 whith message:

      javax.jms.JMSSecurityException: User: null is not authorized to read from destination DEST
      at org.jboss.server.container.SecurityAspect.check(SecurityAspect.java:267)
      ....
      


      If I obtain the connection with a username and password it works fine.
      Can anyone provide any insight?

      (Ultimately the intention is to use SSL and client certificates in place of a password)

        • 1. Re: JBM and JAAS Client authentication
          Tim Fox Master

          The JAAS login module is used on the server side to authenticate/authorise the user specified in the call to createConnection.

          When using the standard connection factories security credentials are not propagated from client to server.

          • 2. Re: JBM and JAAS Client authentication
            Clebert Suconic Master

             

            it would not be necessary to pass a username and password to the connectionFactory.getConnection()


            At this point you need to pass the username and password to the connectionFactory. We don't have integration with the ClientLoginModule at this point.


            But anyway.. I'm curious about how you wrote your testcase. If you could share it.. maybe using the code tags on this forum thread if the test is not too big.

            • 3. Re: JBM and JAAS Client authentication
              Brendan Sibre Newbie

              Interesting, because it does seem to work with reading messages (or it's not authenticating the user at all on write which seems unlikely).

              Note that I am using secured JNDI, so the JAAS login is working for that.

              Pardon any mistyping as I can't copy/paste:

              public static void main(String[] args) {
               try {
               System.setProperty("java.security.auth.login.config",ClassLoader.getSystemResource("jaas.config").getPath());
              LoginContext loginContext = new LoginContext("other", new StaticIdentityCallbackHandler("admin","admin");
              loginContext.login();
              
              InitialContext ctx = new InitialContext();
              ConnectionFactory f = (ConnectionFactory)ctx.lookup("ConnectionFactory");
              Destination dest = (Destination)ctx.lookup("echoService/jms/request");
              
              // This fails on the READ
              Connection conn = f.createConnection();
              conn.start();
              Session session = conn.createSession(true, Session.CLIENT_ACKNOWLEDGE);
              
              MessageProducer producer = session.createProducer(dest);
              
              for (int i = 0; i < 5; i++) {
               Message m = session.createTestMessage("Hello " + i);
               producer.send(m);
              }
              
              session.commit();
              producer.close();
              
              MessageConsumer consumer = session.createConsumer(dest);
              
              Message mess = null;
              while ((mess = consumer.receive(3000)) != null) {
               System.out.println(((TextMessage)mess).getText());
              }
              session.commit();
              
              consumer.close();
              session.close();
              conn.close();
              
              loginContext.logout();
              } catch (Exception e) {
               e.printStackTrace();
              }
              


              A few small points, the StaticIdentityCallbackHandler is a simple callback handler I wrote to just return the username and password to the callbacks.

              Both JNDI (I'm using the HTTPNamingContext) and JBM are configure to use the same JAAS domain.

              What is involved in making the connection capable of using the client login config?

              Thanks for any information.

              • 4. Re: JBM and JAAS Client authentication
                Brendan Sibre Newbie

                On a related note, when, in an EJB we're attempting to get a connection to JmsXA we're getting javax.resource.spi.SecurityException: No Password credentials found at org.jboss.resource.adapter.jms.JmsCred.getJmsCred(JmsCred.java:75).

                The resource ref is configured with container authentication and we actually _are_ passing a username and password to getConnection() (however, we would prefer if it simply used the EJB caller's information).

                • 5. Re: JBM and JAAS Client authentication
                  mskonda Apprentice

                  I am not sure if this is related or not - I was getting the same exception!

                  I have a test scenario: My MDB calls a Session EJB to do some work - The session EJB essentially uses the JmsXA CF to publish a message.

                  The MDB is authenticated properly (using the <mdb-user>, however, the security-domain is not working, which is another issue!) and calls the Session EJB. The ejb creates a connection successfully with a username and password however fails with the exact problem you have when creating a session (I am not sure why it's not failing on create connection though).

                  However, I *got* through the problem: I have changed the security domain policy for JmsXa to reflect my own application policy (the policy has been instantiated earlier during the application startup).

                  I am not sure whether it's a wrong doing or okay doing but I have a sneaky feeling that I'm breaking something.

                  Here's my JmsXa definition:

                  <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
                   <tx-connection-factory>
                   <jndi-name>JmsXA</jndi-name>
                   <xa-transaction/>
                   <rar-name>jms-ra.rar</rar-name>
                   <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
                   <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
                   <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
                   <max-pool-size>20</max-pool-size>
                   <security-domain-and-application>java:/MyPolicy</security-domain-and-application>
                   <!--security-domain-and-application>JmsXARealm</security-domain-and-application-->
                   <depends>jboss.messaging:service=ServerPeer</depends>
                   </tx-connection-factory>
                  


                  The modified MyPolicy is defined in login-config.xml as below:

                  <application-policy name="MyPolicy">
                   <authentication>
                   <login-module code="com.my.SecureLoginModule" flag="required">
                   <module-option name="username">myself</module-option>
                   <module-option name="password">Rqm8QqlcszYlZdf/eNDpx</module-option>
                   <module-option name="securePropertiesFile">secure.properties.xml</module-option>
                   <module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=MyJMSDS</module-option>
                   </login-module>
                   </authentication>
                   </application-policy>
                  


                  Bear in mind this MyPolicy is instantiated earlier during Datasource deployment!


                  One thing I've noticed is that if I change <security-domain-and-application> in the JmsXa definition to use a new JmsXARealm (I've to modify the existing one as the existing JmsXARealm policy is using ConfiguredIdentityLoginModule) exactly same as above except the name, it doesn't work! I guess this is due to the fact that this particular policy is *not* instantiated by any other components.

                  Hope this might rub the salt!

                  Thanks
                  Madhu


                  • 7. Re: JBM and JAAS Client authentication
                    Brendan Sibre Newbie

                    Tim, thanks for the attention..

                    For the other poster I had similar issues and solved them as follows:

                    1) Needed to change the JmsXARealm to use a caller identity realm
                    2) For the role to be populated either by a Session bean or MDB's run-as
                    property I needed to ensure that the caller identity in the CallerIdentityRealm actually existed in the _other_ realm that I was using AND had to set the "addRunAsRoles" module-option to true for the CallerIdentityLoginModule.

                    • 8. Re: JBM and JAAS Client authentication
                      Tim Fox Master

                      I am struggling to see what the issue is here.

                      AFAICT this is just a difficulty in configuration. Once Madhu had configured it correctly it works.

                      • 9. Re: JBM and JAAS Client authentication
                        Brendan Sibre Newbie

                        I think the only issue is that it isn't possible to propagate the client credentials from the JAAS client login to the standard ConnectionFactory. This would be a feature request.

                        However, it's still a puzzle why I was allowed to send to the destination without providing credentials, but was unable to read from it. This is the only potential 'bug'.

                        My mention of the CallerIdentityLoginModule is a separate configuration issue related to the use of the JmxXA connection factory from EJBs/MDBs. Although, for MDBs it would be nice if it was possible to use the @RunAs role without having to provide a username and password (without a username and password I get an exception). In our certificate based system, we don't use passwords anywhere. Of course this is more of a feature request than a bug.

                        Incidentally, is there a schedule for 1.4.0CR2 or GA? I'm experiencing the issue where improperly disconnected sessions eventually cause the server to hang up because the bundled version of remoting doesn't have the callback timeout.

                        • 10. Re: JBM and JAAS Client authentication
                          Tim Fox Master

                           

                          "btsibr" wrote:
                          I think the only issue is that it isn't possible to propagate the client credentials from the JAAS client login to the standard ConnectionFactory. This would be a feature request.


                          Please feel free to add a feature request in JIRA.

                          (BTW this feature is not supported by JBoss MQ either.)


                          However, it's still a puzzle why I was allowed to send to the destination without providing credentials, but was unable to read from it. This is the only potential 'bug'.


                          Can you provide a test case that demonstrates the bug?


                          My mention of the CallerIdentityLoginModule is a separate configuration issue related to the use of the JmxXA connection factory from EJBs/MDBs. Although, for MDBs it would be nice if it was possible to use the @RunAs role without having to provide a username and password (without a username and password I get an exception). In our certificate based system, we don't use passwords anywhere. Of course this is more of a feature request than a bug.


                          This is MDB/app server security, not JBM security.

                          You could try posting on their forum and ask if you can add a JIRA feature request, but we don't handle these kind of issues.


                          Incidentally, is there a schedule for 1.4.0CR2 or GA? I'm experiencing the issue where improperly disconnected sessions eventually cause the server to hang up because the bundled version of remoting doesn't have the callback timeout.


                          It will be released when we have cleared the issues.

                          You can help if you want, we are a very small team, and always in need of help.

                          I can assign you some JIRA tasks if you want?