13 Replies Latest reply: Mar 8, 2012 3:23 PM by Justin Bertram RSS

JBoss 7.1:  security on queues (Unable to validate user)

Ed Keen Newbie

I have added the following security domain to the security subsystem:

 

<security-domain name="messaging" cache-type="default">

  <authentication>

    <login-module code="UsersRoles" flag="required">

      <module-option name="usersProperties" value="${jboss.server.config.dir}/messaging-users.properties"/>

      <module-option name="rolesProperties" value="${jboss.server.config.dir}/messaging-roles.properties"/>

    </login-module>

  </authentication>

</security-domain>

 

My messaging-users.properties file just has a user=password format:

 

    user1=password

 

My messaging-roles.properties file has a user=role format:

 

    user1=cbsuser

 

I also added the following security section in my messaging subsystem:

 

<security-settings>

  <security-setting match="jms.queue.cbs.#">

    <permission type="send" roles="cbsuser"/>

    <permission type="consume" roles="cbsuser"/>

    <permission type="createNonDurableQueue" roles="cbsuser"/>

    <permission type="deleteNonDurableQueue" roles="cbsuser"/>

  </security-setting>

</security-settings>

 

When I create my JMS connection, I pass a username & password, like this:

 

Connection conn = factory.createConnection("user1", "password");

 

However, I am getting the following error:

 

javax.jms.JMSSecurityException: Unable to validate user: user1

          at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:286)

          at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:695)

          at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:264)

          at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:589)

          at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:694)

          at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:121)

          at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)

 

 

Is there a step that I am missing in the process? I know that for the application-users and mgmt-users, you have to call the add-user.bat file in order to add the user. Do we have to do that here as well?

 

Thanks,

Ed

 




  • 1. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    Those are the correct steps.  In fact, that is essentially exactly what the AS7 test-suite does.

     

    At this point you don't need to do anything with add-user.bat as that only applies to management. 

     

    Are there any additional exceptions in your server.log (perhaps from the security subsystem)?

     

    Also, what version of AS7 are you using?  I assume you are building from source.  If so, when did you pull?

  • 2. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Ed Keen Newbie

    I don't see any other exceptions in server.log.  No, I did not build from source... I just got the latest version as of today (2/10/2012) from the nightly builds.  Have your changes made their way to the nightly build yet?  If not, is this going to be incorporated into the 7.1 final release?

  • 3. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Ed Keen Newbie

    Actually, I ran the test again and did see the following exception in the server.log file.  I apologize for overlooking it.  It appears that it thinks I used an invalid password, but I have double-checked that the password is "password" and I am sending it that way in my code:

     

    10:57:04,655 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required

            at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:269) [picketbox-4.0.6.final.jar:4.0.6.final]

            at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:155) [picketbox-4.0.6.final.jar:4.0.6.final]

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_30]

            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_30]

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_30]

            at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_30]

            at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) [rt.jar:1.6.0_30]

            at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [rt.jar:1.6.0_30]

            at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [rt.jar:1.6.0_30]

            at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_30]

            at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [rt.jar:1.6.0_30]

            at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [rt.jar:1.6.0_30]

            at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.6.final.jar:4.0.6.final]

            at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.6.final.jar:4.0.6.final]

            at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.6.final.jar:4.0.6.final]

            at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.6.final.jar:4.0.6.final]

            at org.jboss.as.messaging.HornetQSecurityManagerAS7.validateUser(HornetQSecurityManagerAS7.java:39) [jboss-as-messaging-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]

            at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:134) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:807) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:187) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:85) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:508) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:556) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:517) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:533) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:73) [hornetq-core-2.2.11.Final.jar:]

            at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.StaticChannelPipeline$StaticChannelHandlerContext.sendUpstream(StaticChannelPipeline.java:534) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:287) [netty-3.2.6.Final.jar:]

            at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-2.2.11.Final.jar:]

            at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-2.2.11.Final.jar:]

            at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:367) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:100) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44) [netty-3.2.6.Final.jar:]

            at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:181) [netty-3.2.6.Final.jar:]

            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]

            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]

            at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

  • 4. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    I took a look at the code and I see some changes have been made since my stuff was committed.  I was under the impression these changes were going into 7.1.1, but looks like they are already in.  Let me play with this for a bit and I'll get back to you.

  • 5. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    So it looks like now HornetQ will use the "other" security domain which uses the same kind of mechanism as the management stuff except it will use application-users.properties and application-roles.properties.  See those files for instructions on their use.  The realm will be "ApplicationRealm".

     

    The usability of this approach is better (e.g. add users while the server is running) and you get password masking thrown in as well.

  • 6. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Ed Keen Newbie

    OK, so here is my "other" security domain:

     

     

    
    
    
    
    
    
    
    <security-domain name="other" cache-type="default">
    
    
    
    
    
    
    
    
    
    
    <authentication>
    
    
    
    
    
    
    
    
    
    
    
    
    <login-module code="Remoting" flag="optional">
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <module-option name="password-stacking" value="useFirstPass"/>
    
    
    
    
    
    
    
    
    
    
    
    
    </login-module>
    
    
    
    
    
    
    
    
    
    
    
    
    <login-module code="RealmUsersRoles" flag="required">
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <module-option name="realm" value="ApplicationRealm"/>
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    <module-option name="password-stacking" value="useFirstPass"/>
    
    
    
    
    
    
    
    
    
    
    
    
    </login-module>
    
    
    
    
    
    
    
    
    
    
    
    
    
    </authentication>
    
    
    
    
    
    
    
    
    </security-domain>
    
    
    
    

     

     

    Also, I have the following defined for "ApplicationRealm":

     




    <security-realm name="ApplicationRealm">




    <authentication>





    <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>




    </authentication>



    </security-realm>

     

     

    Then, I called add-user.bat to have my user added to application-users.properties.  Is that all I need to do?  These are the steps I followed, but I am still getting the same error.  I will go over it all again, but I just wanted to validate with you that these are the correct configuration settings.

  • 7. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Prasad Deshpande Expert

    Just a quick one Justin, If I don't specify username/password, while creating factory (RemoteConnectionFactory in remote client), it complains that null user could not be validated.. Where do I specify mapping saying if no user specified use default user which is say guest.. (the stuff you'd normally specify in hornetq-users.xml)?

     

    Currently I had to disable security... to get my other development stuff going..

  • 8. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Ed Keen Newbie

    @Jason, nevermind, I figured it out.  I had misspelled my username.  I changed everything over to use the "other" security domain as you said, and everything works fine now.  Thank you for your help!

     

    Ed

  • 9. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    To allow unauthenticated users to access JMS remotely then add this to the "RealmUsersRoles" login-module in the "other" <security-domain>:

     

      <module-option name="unauthenticatedIdentity" value="guest"/>

     

    You'll also need to add the "guest" role/user to application-roles.properties, e.g.:

     

      guest=guest

  • 10. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    BTW, inVM stuff (e.g. MDBs) should just work.  It's only remote connectivity which is secured by default.

  • 11. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    To be clear, the use of "other" for HornetQ is set up by default in the latest nightly.  The only thing you should need to do out-of-the-box is run add-user.bat/sh.

  • 12. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Ed Roberts Newbie

    With the setup that you guys have mentioned; i.e. Security Domain "other" (should that be specified in the schema as the default value ?)

    and authentication happening via the RealmUsersRoles login method.

     

    I can connect if I have a clear text password for the remote jms client code. What would be required to mask that client side ? I get

    the same exception as was detailed above if I (for instance) try to use the same hashed value as found in the application-users.properties.

     

    2012-03-08 19:12:12,229 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager](Old I/O server worker (parentId: 5105880, [id: 0x004de8d8, YANGTZE.saa-cons.co.uk/10.1.11.103:5445])) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
    at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:269)
    at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:155)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
    at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
    at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
    at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
    at org.jboss.as.messaging.HornetQSecurityManagerAS7.validateUser(HornetQSecurityManagerAS7.java:39)
    at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:134)
    at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:807)
    at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:187)
    at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:85)
    at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:508)
    at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:556)
    at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:517)
    at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:533)
    at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:73)
    at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100)
    at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372)
    at org.jboss.netty.channel.StaticChannelPipeline$StaticChannelHandlerContext.sendUpstream(StaticChannelPipeline.java:534)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:287)
    at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169)
    at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
    at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372)
    at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:367)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
    at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:100)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44)
    at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:181)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

     

  • 13. Re: JBoss 7.1:  security on queues (Unable to validate user)
    Justin Bertram Master

    should that be specified in the schema as the default value ?

    It is specified as the default (in the code).  See here.  You can change this by setting the <security-domain> in <hornetq-server> if you like.

     

    As far as masking the password on the client side, at this point you are on your own to mask it and then unmask it when you pass it to javax.jms.ConnectionFactory.createConnection(String, String).  We've never had any libraries to facilitate this for JMS.