[jboss-jira] [JBoss JIRA] Commented: (JBAS-5995) Jaas multiple login failure (ClientLoginModule)

[Koen VT (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12434150#action_12434150 ] 

Koen VT commented on JBAS-5995:
-------------------------------

If I understand correctly, this problem is that when the SECOND user logs in (with sufficient privileges for the method) and he invokes a business method on a stateless session bean, the getCallerPrincipal() of the injected SessionContext returns the Principal of the FIRST authenticated user.

If so, this is exactly the same issue I spotted. I'm also trying to invoke an EJB 3 stateless session bean in JBoss 5 with a standalone client. I also use the ClientLoginModule to authenticate the client to the server. It seems that security works well (you cannot invoke the business method with a user without the required role or an unauthenticated user, only with correctly authenticated users).

The problem is when the second user calls a method on the same type of bean, that jboss invokes it in almost all the cases (not always!) on the same instance of the session bean that was used for the FIRST user (which survived in the method-ready state pool). This is not a problem, but the injected session context provides us with the same Principal as before (for the FIRST user). Shouldn't getCallerPrincipal() return the principal of the CURRENT user that is invoking the method? I would say yes? (read paragraph '17.2.5.1 - Use of getCallerPrincipal' of the core ejb specs). So JBoss should update the security parameters in the EJBContext , but it doesn't...

If this is indeed the bug, the description of this bug should be altered.

By the way, as I expected, stateful beans don't have this problem, since they are always instantiated and a new SessionContext is injected right after instantiation.


> Jaas multiple login failure (ClientLoginModule)
> -----------------------------------------------
>
>                 Key: JBAS-5995
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5995
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Thomas Gueze
>            Assignee: Anil Saldhana
>
> As explained in the forum :
> I have an ear deployed on Jboss 5 CR2.
> J perform Jaas authentification with a Jaas login module on client side and use the ClientLoginModule to propagate the user on the server side (so specified in the jaas config file).
> On the bean, I retrieve the caller principal name with a lookup on the EJBContext :
> final Object o = new InitialContext().lookup("java:comp/EJBContext");
> final Class< ? > ejbContextClass = Class.forName("javax.ejb.EJBContext");
> final Method getCallerPrincipalMethod = ejbContextClass.getMethod("getCallerPrincipal");
> final Principal principal = (Principal) getCallerPrincipalMethod.invoke(o);
> final String callerId = principal.getName();
> The case is :
> A user log in, perform some operations on the bean (He's also the first bean caller), the callerId corresponding.
> Then this user log out and another user log in successfully (the login modules committed).
> He perform operations on the bean, and the callerId correspond to the precedent user.
> I've tried to set the DefaultCacheTimeout to 0 and set the different jaas ClientLoginModule options (especially multi-threaded to true), but It didn't solve the problem.
> Use the SecurityAssociation API is a work around possible (work in my case, but cannot use it), but it's an internal API (can change), right?
> Apparently, there is also an issue with JndiLoginInitialContextFactory (explain in the forum), but I don't know if it's related.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira