[ http://jira.jboss.com/jira/browse/JBAS-1612?page=history ]
Ovidiu Feodorov moved JBMESSAGING-23 to JBAS-1612:
--------------------------------------------------
Project: JBoss Application Server (was: JBoss Messaging)
Key: JBAS-1612 (was: JBMESSAGING-23)
Component: (was: JMS Security)
Security Level: Public
> Sending message re-authenticates user and clears security association
> ---------------------------------------------------------------------
>
> Key: JBAS-1612
> URL: http://jira.jboss.com/jira/browse/JBAS-1612
> Project: JBoss Application Server
> Type: Bug
> Environment: JBoss AS 3.2.7
> JDK 1.4.2
> Reporter: eugene75
>
>
> public void testJmsMethod()
> {
> // TRANSACTION BEGINS; org.jboss.security.SecurityAssociation.getSubject()
> returns current Subject
> ApplicationUser appUser... // user object retrieved from current Subject
>
> Context jndiContext = new InitialContext();
> QueueConnectionFactory factory = (QueueConnectionFactory)
> jndiContext.lookup("java:/JmsXA");
> QueueConnection conn = factory.createQueueConnection(appUser.getUserId(),
> appUser.getPassword());
> Queue queue = (javax.jms.Queue) jndiContext.lookup("queue/nameOfQueue");
> QueueSession session = connection.createQueueSession(true,
> Session.AUTO_ACKNOWLEDGE);
> // #1 USER HAS BEEN RE-AUTHENTICATED (new JAAS subject)
> QueueSender sender = session.createSender(queue);
> MapMessage message = session.createMapMessage();
> sender.send(message);
> conn.close();
> }
> // #2 TRANSACTION COMPLETES;
> org.jboss.security.SecurityAssociation.getSubject() returns null
> #1. User is re-authenticated -- even though the username and credential are
> for the current user -- ecause the JaasSecurity.validateCache method returns
> false. The method does so because the web layer stores the user credential
> as a String, so the cached DomainInfo.credential is a string; but the
> SpyXAConnection calls JaasSecurityManager.isValid using a char[] as the
> credential. Cache validation will never consider char[] and String to be
> equivalent even if the underlying character sequence is identical.
> #2. Security association for the thread has been cleared. This appears to
> happen when the transaction completes, indicating it is done by a
> Synchronization listener. Normally, the security association is cleared by
> the SecurityAssociation valve in Tomcat.
> Workarounds are possible by ensuring that any JMS message sending is the
> absolute last thing that occurs during a request, but this is not optimal.
> The re-authentication also discards information stored in the Subject that
> was added after the login process.
> It would be helpful is JBoss would choose a standard format for user
> credentials so as to prevent this problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
