-
1. Re: SecurityAssociation: javax.security.auth.Subject dissape
thammoud Aug 28, 2009 11:29 AM (in response to wgiersche)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 Aug 28, 2009 5:35 PM (in response to wgiersche)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 Sep 1, 2009 11:02 PM (in response to wgiersche)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
amalraj.palanichamy Oct 27, 2009 8:04 AM (in response to wgiersche)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 May 15, 2013 3:48 AM (in response to amalraj.palanichamy)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 May 20, 2013 2:11 AM (in response to amalraj.palanichamy)seems this workaround only works for Topic not for Queue.
-
7. Re: SecurityAssociation: javax.security.auth.Subject dissape
bondchan921 May 21, 2013 2:00 AM (in response to 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 May 21, 2013 6:05 AM (in response to 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.