1 2 3 Previous Next 32 Replies Latest reply: Nov 19, 2008 9:48 AM by Micah Cleveland Go to original post RSS
  • 15. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    Currently, as it stands the SessionListener will flush the principal from the auth cache when the session expires.

    Previously, whether a flush should happen on session invalidation or not, was a user specified attribute of the security-domain element, in the jboss-web.xml

    So, Scott, do you see any issues with flushing the principal from the cache every time the session expires/destroyed?

    Just checking with you, before I checkin the session listener.

  • 16. Re: Flush security domain cache on sessionInvalidation
    chris griffith Expert

    Dear Gang,

    I recently solved this issue in my environment, so I though I would add my input. I belive the solution should be handled entirely by Tomcat modifications. Here is my reasoning.

    From what I read, the servlet spec only requires a servlet container to destroy the session as a means of logging a user out. However, consider the Tomcat Realm that uses JAAS based AA (which includes the JBossSecurityMgrRealm). In this case, just destroying the session is not enough. I would think a logout() must be called on LoginContext that authenticated session user at session destruction time.

    What I would suggest (since this is what I did to handle this)...
    1.) modify the Authenticator interface
    a.) to be a SessionListener.
    b.) modify the authenticate method of any classes that implement Authenticator such that if user is authenticated by realm, add it self to the Session's listener list.
    c.) modify any classes that implement Authenticator with the sessionEvent(SessionEvent) method that will call realm.logout(Principal) if a Session.SESSION_DESTROYED_EVENT occurs.

    2.) modify the Realm interface...
    a.) with a logout(Principal) method that can log Principal out of realm

    Thus any realm that would care to log user out (Such as our case) can call the LoginContext's logout() method.

    If I did not make myself clear, please let me know. Also, if I am way off base, tell me where to go.

    later, cgriffith

    b.) In my

  • 17. Re: Flush security domain cache on sessionInvalidation
    Scott Stark Master

    That is probably too radical a change to make it back into the tomcat codebase. Instead, it would be better to propse a new Authenticator extension:

    public interface SessionAwareAuthenticator extends Authenticator, SessionListener {
    
    }
    


    1b. I would also want the registration of SessionAwareAuthenticator SessionListener events pushed to the AuthenticatorBase. What impact this has on the SSO valves/existing authenticator SSO code needs to be considered as well.

    1c. should also be pushed to the AuthenticatorBase as a default behavior.

    The Realm interface should also be introduced as an extended interface to avoid breaking existing implementations. We have other extensions in mind such as a general authenticate(String type, HashMap authInfo) method to allow new authentication schemes to be delegated to a Realm without tomcat getting in the way.

    I would not mind prototyping these changes in the jboss codebase to get something to submit back to tomcat.


  • 18. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    I am not clear why the last two posts are relevant to the discussion we are having.

    We basically just discussed the removal of the cache information for a principal during session logout.

  • 19. Re: Flush security domain cache on sessionInvalidation
    Scott Stark Master

    The last two posts are a way to implement that.

  • 20. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    http://jira.jboss.com/jira/browse/EJBTHREE-450

    There is a problem with the current implementation.

  • 21. Re: Flush security domain cache on sessionInvalidation
    chris griffith Expert

    I was hoping to implement what Scott and I were talking about as a fix for this problem. Do you have any input on our proposed change?

    later, cgriffith

  • 22. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    I agree that the solution that has been proposed by you and seconded by Scott will ensure that the logout is called on the LoginContext, to give the login modules an opportunity to clean up. But this is just the JBoss way of implementing authentication via the JAAS framework in the realm implementation.

    I do not however think that the proposed realm interface changes are relevant to the entire tomcat community. I just confirmed this with Remy (Apache Tomcat Lead).

    Also I think the Tomcat SessionListener interface has been deprecated in favor of the standard HttpSessionListener interface.

    So given this, we can make the changes to JBossSecurityMgrRealm to extend the SessionListener interface (suitably HttpSessionListener interface) and that does lc.logout on session end. But a test has to be made whether the TC layer really dispatches to the realms on session invalidation (my guess is it does).

  • 23. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

     

    "anil.saldhana@jboss.com" wrote:
    But a test has to be made whether the TC layer really dispatches to the realms on session invalidation (my guess is it does).


    My last statement should mean that if we extend the JBossSecurityMgrRealm with the sessionlistener interface, we have to test that the TC will dispatch to it on session end.

    The realm is at the context level. So if the dispatch happens to JBossSecurityMgrRealm, it should be fine for us. :)

  • 24. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    Sorry, did not read the proposal property before making the post. The extension of the interface for session listening should be on the authenticator and not on the realms. My apologies.

  • 25. Re: Flush security domain cache on sessionInvalidation
    chris griffith Expert

    Anil,

    I would first like to review the issue about relevancy to puprosed changes in the tomcat community. If Tomcat never considered using JAAS, then their interfaces (i.e. Realm and Authenticator) for the security layer are adequate. However, I believe they are lacking with respect to the use of JAAS. As an aside, I think Tomcat could have only implemented the JAASRealm and all the other realms could have been accomplished using JAAS login modules. Which would support a Realm having a logout type mechanism. Anyway, the JAASRealm (and in a simalar fashion the JBossSecurityMgrRealm) in the least should have a mechanism to log user out of LoginContext when the user is considered by the container to be logged out (i.e. at session invalidation time.) To not have this presents a problem to LoginModule developers (like me) that want things to happen when the user logs out. When I first considered how to solve this problem, I too looked at making the JBossSecurityMgrRealm a sessionListener. But the Realm is abstracted from the concept of the Session and rightly so.
    The Authenticator on the otherhand is the inteface between the Session based servlet container and the realm. So I feel such a change to the Tomcat environment is needed to handle the JAASRealm (as well as JBoss's JBossSecurityMgrRealm.)


    If TC does 'dispatch' session invalidations to the realm, then modifing the JBossSecurityMrgRealm (as you suggest) would be a great alternative. However, I do not think that happens. Let me know if you find out either way. I may try to test that as well.

    thanks for your input and help, cgriffith

  • 26. Re: Flush security domain cache on sessionInvalidation
    Scott Stark Master

    The realm is purely the authentication mechanism plugin right now. It really should be rethought in terms of a more generic api such as the JSR-196 APIs. It does not have an explicit logout, but does have a disposeSubject(Subject subject, Map sharedState) that does map to a JAAS login module logout.

    At some point we need to propose a realm replacement based on this. Whether or not this issue should force that investigation is an open question.

  • 27. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

     

    "j2ee_junkie" wrote:

    If TC does 'dispatch' session invalidations to the realm, then modifing the JBossSecurityMrgRealm (as you suggest) would be a great alternative. However, I do not think that happens. Let me know if you find out either way. I may try to test that as well.

    thanks for your input and help, cgriffith


    Doing anything in the JBossSecurityMgrRealm would be similar to the SecurityFlushListener because in both the reference to the JaasSecurityManager is obtained through JNDI using the private namespace: "java:comp/env/security/securityMgr".

    http://jira.jboss.com/jira/browse/EJBTHREE-450 is indicating that the JNDI based approach somehow fails either in an ejb3 environment or clustering env.

  • 28. Re: Flush security domain cache on sessionInvalidation
    Anil Saldhana Master

    It looks like we will need to add a "logout" method to either our AuthenticationManager interface (does not seem appropriate) or to our JaasSecurityManager implementation(is ok).

    But as Scott said, JASPI (JSR196) is probably the way to go to solve this issue in a correct way.

    Chris, can you send me an email, please. I want to touchbase with u.

  • 29. Re: Flush security domain cache on sessionInvalidation
    chris griffith Expert

    Dear gang,

    Just to clearify and refresh our memory, we are looking at a solution to allow Tomcat's security layer to call for a flush of an authentication cache for a specific principal when the principal's session has been invalidated. Here is a list of important issues when considering an implementation, along with thoughts I have made while trying to consider this implementation.


    1: Obviously, our implementation would need to be a listener in order to be notified of when the session was invalidated.

    a: My orginal post suggested creating a org.apache.catalina.SessionListener. My reasoning is that a org.apache.catalina.SessionEvent provides direct access to the session's principal.
    b: Anil points out that this interface is soon to be deprecated. His implementation uses an HttpSessionListener.

    If Anil is correct, then I agree with staying with using an HttpSessionListener. This does make our job harder when it comes time to acquire the principal. But then again, Anil already implemented that. I was just looking for something cleaner.

    2.) Should we modify Tomcat's security layer to better support a session invaliation logout-type call to realm.

    a.) My orginal post along with Scott's suggestions recommended an extension of Tomcat's Authenticator and Realm interfaces to support a logout-type facility. The Authenticator receives the session invalidation and asks the Realm to do the logout.
    b.) Anil already implemented this as a HttpSessionListener(the SecurityFlushSessionListener)

    When I originally posted, I did not know that Anil already implemented a solution. I was just adding some comments to say, "hey, this is how I did it." I still like 2a better than 2b only because I think it is relavent in Tomcat's environment since their own JAASRealm does not
    allow for a logout-type facility.

    3.) How does the Realm actually handle flushing the authentication cache.

    a.) My orginal plan was to use the security context to look up the SubjectSecurityManager (as it does during the authenticate() method) and ask it to log principal out. This would of course require us to add a logout-type facility to the security manager.
    b.) Anil implemented this by looking up the security manager MBean and calling a flush of the authentication cache for principal. Note that Anil's implementation uses the security context to look up the security manager in order to get the subject. Also note, that this is where a JIRA issue has been found.

    After looking more closely at the main JBoss SX code, I see that the security manager service has been put in charge of the authentication cache. This would make 3a kinda go against the standard. Would you agree?

    4.) The only documented problem with SecurityFlushSessionListener http://jira.jboss.com/jira/browse/EJBTHREE-450

    Since the problem is not reproducible, I can not find a way to trouble shoot. My instincts say that there is a race issue between releasing the old security context and issue a new security context. However, I have not been able to isolate where that happens, at this time, in the code. So I thought that maybe we need to also implement our cache flush on Context destruction in addition to session invalidation. But there is no way to test this, if the problem is not reproducible.


    To sum up my current position on this issue. I think Anil's implementation is just as good as what Scott and I suggested for the time being. However, I would really like to switch gears and start considering how to redisgn JBoss' SX system to handle this issue as well as JSR-192. If you Scott, still want me to move forward with implementing your and my suggested session invalidate cache flush changes, I would be delighted. I am sorry this is such a long post. I just wanted you to know I have been working on this (to a small degree.), and I am looking for some feedback.