8 Replies Latest reply on May 21, 2013 6:05 AM by bondchan921

    SecurityAssociation: javax.security.auth.Subject dissapears

    wgiersche

      I'm working in large, international banking project in Switzerland. In an Eclipse RCP 3.4 client, some of the remote method calls fail with "Caller unauthorized". We're using ClientLoginModule and JAAS Logon. Everything used to work with JBoss AS 4.2.2.GA. Now, with the client libraries of Jboss AS 5.1, some method calls will not be accepted by the server, for the SecurityContext of the RMI seems to be incomplete.
      We could trace the problem down to the SecurityAssociation class. In a debug session we could show that immediately before a successful method call, SecurityAssociation.getSubject() would return the expected Subject. Magically, before other calls to remote methods it would return null. Interestingly, getPrincipal() and getCredential() both return the expected values, still. Method calls fail if and only if getSubject() returns null. We believe that there is a flaw in the way the SubjectThreadLocal is used. The problem is only reproducible in the full RCP application, thus we assume that the problem is that not all Threads are correctly equipped with a consistent SubjectStack. Can anybody help us out? You must have heard this before, don't you?

        • 1. Re: SecurityAssociation: javax.security.auth.Subject dissape
          thammoud

          We are having a similar problem with similar setup as yours.

          Some of the logs show:



          08:50,153 INFO [STDOUT] (MessageDispatcher [ReportFeed] pool-24-thread-2) client-login.Logging out from threadMessageDispatcher [ReportFeed] pool-24-thread-2
          10:08:50,153 INFO [STDOUT] (MessageDispatcher [ReportFeed] pool-24-thread-2) Subject after log out is:Subject:
          Principal: adminuser|64320
          Principal: Roles(members:Authenticated,Administrator)

          10:08:50,199 TRACE [messaging] (MessageDispatcher [ReportFeed] pool-24-thread-2) Begin isValid, principal:null, cache info: org.jboss.security.plugins.auth.JaasSecurityManagerBase$DomainInfo@5977cfc4[Subject(1119250452).principals=org.jboss.security.SimplePrincipal@76327959(guest)org.jboss.security.SimpleGroup@1930176751(Roles(members:john,guest,j2ee)),credential.class=null,expirationTime=1251473885241]
          10:08:50,199 TRACE [messaging] (MessageDispatcher [ReportFeed] pool-24-thread-2) Begin validateCache, info=org.jboss.security.plugins.auth.JaasSecurityManagerBase$DomainInfo@5977cfc4[Subject(1119250452).principals=org.jboss.security.SimplePrincipal@76327959(guest)org.jboss.security.SimpleGroup@1930176751(Roles(members:john,guest,j2ee)),credential.class=null,expirationTime=1251473885241];credential.class=null
          10:08:50,199 TRACE [messaging] (MessageDispatcher [ReportFeed] pool-24-thread-2) End validateCache, isValid=true
          10:08:50,199 TRACE [messaging] (MessageDispatcher [ReportFeed] pool-24-thread-2) End isValid, true
          10:08:50,200 TRACE [JBossAuthorizationManager] (MessageDispatcher [ReportFeed] pool-24-thread-2) doesUserHaveRole(Set), roles: Roles(john,guest,j2ee,)
          10:08:50,200 TRACE [JBossAuthorizationManager] (MessageDispatcher [ReportFeed] pool-24-thread-2) hasRole(guest)=true
          10:08:50,200 TRACE [JBossAuthorizationManager] (MessageDispatcher [ReportFeed] pool-24-thread-2) hasRole=true
          10:08:50,200 TRACE [SecurityAssociation] (MessageDispatcher [ReportFeed] pool-24-thread-2) popSubjectContext, sc=null
          10:08:50,200 TRACE [SecurityAssociation] (MessageDispatcher [ReportFeed] pool-24-thread-2) WARN::Deprecated usage of SecurityAssociation. Use SecurityContext
          [/Quote]


          • 2. Re: SecurityAssociation: javax.security.auth.Subject dissape
            thammoud

            We believe that found the problem area. When we come back from a JMS call, the currently authenticated user is no longer the one that was active before the call. This is all on the server.

            When we setup the server, we left the JBOSS messaging security settings as is. We are assuming that "guest" or null was used since the active user is not known to the JMS "messaging" realm. The message was sent with a null principal, which is fine for us. However, when the call comes back from the send, the principal is null. I would have assumed that it would do a runAs and pop the prior active principal but it does not seem to do so.

            One way around this is to have the messaging system use our security realm. Our realm has no concept of an unauthenticated user and we do not want to introduce such a thing.

            • 3. Re: SecurityAssociation: javax.security.auth.Subject dissape
              pcarrollnf

              I am having the exact same problem that thammoud described. I had the messaging system use my security realm but once I return from the JMS call, the getPrincipal().getName() returns the user specified by the unauthenticatedIdentity.

              Has anyone else ran into this issue and if so, were you able to resolve it? Thanks.

              • 4. Re: SecurityAssociation: javax.security.auth.Subject dissape

                Even we have faced the same problem in our application.

                The workaround is introducing a new Thread for JMS Publishing part

                For ex :

                Thread jmsPublisherThread = new Thread()
                {
                 public void run()
                 {
                 try
                 {
                 PublisherManager.getInstance().sendMessage(topicName,
                 SerializableObj, PublisherType);
                 // Publisher Type : Durable or Non Durable
                 }
                 catch(Exception e)
                 {
                 e.printStackTrace();
                 }
                 }
                };
                
                jmsPublisherThread.start();



                It will solve the problem and the caller principals will not be disturbed.

                • 5. Re: SecurityAssociation: javax.security.auth.Subject dissape
                  bondchan921

                  This workaround not work for my case.

                   

                  2013-05-15 15:44:57,152 ERROR [com.lombardrisk.f3.jms.ServerJMSSenderServiceBean] (http-0.0.0.0-8080-1:) before sendRequestMessageToDispatcherByRequired(): janan

                  2013-05-15 15:44:57,152 ERROR [com.lombardrisk.f3.jms.ServerJMSHelper] (http-0.0.0.0-8080-1:) pt Thread start()

                  2013-05-15 15:44:57,152 ERROR [com.lombardrisk.f3.jms.ServerJMSHelper] (Thread-40:) pt Thread sleep 2 seconds ...                 ///new thread used to send message

                  2013-05-15 15:44:59,184 ERROR [com.lombardrisk.f3.jms.ServerJMSHelper] (Thread-40:) before send: janan

                  2013-05-15 15:44:59,480 ERROR [com.lombardrisk.f3.jms.ServerJMSHelper] (Thread-40:) after send: null

                  2013-05-15 15:44:59,480 ERROR [com.lombardrisk.f3.jms.ServerJMSHelper] (http-0.0.0.0-8080-1:) pt Thread finished()

                  2013-05-15 15:44:59,496 ERROR [com.lombardrisk.f3.jms.ServerJMSSenderServiceBean] (http-0.0.0.0-8080-1:) after sendRequestMessageToDispatcherByRequired(): null

                   

                   

                  Anyone have other workaround ?

                  • 6. Re: SecurityAssociation: javax.security.auth.Subject dissape
                    bondchan921

                    seems this workaround only works for Topic not for Queue.

                    • 7. Re: SecurityAssociation: javax.security.auth.Subject dissape
                      bondchan921

                      Correct my last post, works sometime, not all the time for queue and topic,

                      Havn't found an pattern yet.

                      • 8. Re: SecurityAssociation: javax.security.auth.Subject dissape
                        bondchan921

                        when using this workaround:

                         

                        x = SecurityAssociation.getPrincipal()

                        sending jms ....

                        SecurityAssociation.setPrincipal(x)

                         

                        not work when sending JMS  in a new transaction.  and can add the same logic EJB interceptor to solve this issue.