6 Replies Latest reply on May 29, 2009 3:58 PM by sidydrum.inscriptionlardi-divers.yahoo.fr

    SSO logout

    sidydrum.inscriptionlardi-divers.yahoo.fr

      Hi,
      I'm using an SSO in front of multiple seam web apps.


      The problem I'm facing is about logout of the seam apps.
      When I log in using user1 on app1, then I navigate to app2 and I logout using app2's logout link.


      Everything is fine as I can do a identity.logout in app2. But what about the login information I stored in app1 ?? I can't remove this from within app2 ....


      So If I login using user2 (and no more user1) on app 1, that app1 still has the user1's identity data and thus bypasses the seam security as the isLoggedIn returns true.
      And then, I'm logged with user2 but having user1's credentials !! arghhhh


      What I tried to do is to cache the ssoId in the app checking if this one doesn't change between two calls. But I can't find the right place to do such a check.


      It would be ideal in the isLoggedIn method. But can I override this one without breaking all the seam security ? Or is there another kind of plugin method, or ... to do this smoothly.


      Any suggestion ?


      Note: I'm struggling implementing my solution which, moreover, puts quite a big overhead on each request.


      Thanks for your replies.
      Chris.

        • 1. Re: SSO logout
          gonorrhea

          are you using OpenID?

          • 2. Re: SSO logout
            norman

            Page actions are generally a good way to get this kind of thing done, but in this case I think a plain old servlet filter is going to be the best approach.  You can perform whatever checking you need there and pass that information into seam for it to use.

            • 3. Re: SSO logout
              sidydrum.inscriptionlardi-divers.yahoo.fr

              Thanks for your reply Norman,


              That's the approach I first tried, or nearly. I used a servlet Filter. But I faced the fact that through an identity injection, @In Identity, I receive an empty Identity (new one I suppose!?) at the time the servlet Filter is processed.

              If I'm doing something wrong, please tell me. It seems (:-)) that the previously existing seam context is not yet available at the time the servlet Filter is processed.


              By the way, I managed to get the previous solution (the one I was struggling with in my previous post (using an <action execute> in the page.xml) to work. I still have to put it in the test release to certify it.


              But I also think a servlet Filter-like approach would have been a better one. If you can tell me why I don't get the seam components in the servlet Filter ....



              Many thanks for your replies.
              Chris.

              • 4. Re: SSO logout
                norman

                Did you use ContextualHttpServletRequest?

                • 5. Re: SSO logout
                  sidydrum.inscriptionlardi-divers.yahoo.fr

                  Hi Norman,


                  I'm now (after reading your post) using ContextualHttpServletRequest


                  - The good news : I can get the Identity Component using:


                  Identity identity = (Identity) Component.getInstance(
                       Identity.class, false);
                  



                  - The bad news : when trying to get one custom seam component, using this code


                  JossoAuthenticator jossoAuth = ((JossoAuthenticator) Component
                            .getInstance(JossoAuthenticator.class, false));
                  


                  I get


                  Caused by: java.lang.ClassNotFoundException: myPackage.MySSOAuthenticator
                          at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358)
                          at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
                          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
                  





                  As if my components were not in the classload path when the doFilter is called.
                  But the seam libs are at that time,
                  as I can get the org.jboss.seam.security.Identity component.
                  So why wonldn't my embedded libs be available ?


                  I don't see the difference ?
                  Did the ContextualHttpServletRequest only restore standard components ??


                  Thanks for your support,
                  Chris.

                  • 6. Re: SSO logout
                    sidydrum.inscriptionlardi-divers.yahoo.fr

                    Hi,


                    The problem is that there are two directories generated by JbossTools in eclipse when creating a new seam project. The "hot" and the "main".
                    The hot one is used for hot deployment enabled component. The other one is merely for the enity stuffs you don't want to hot deploy (because this can impact your existing data and often requires other changes to occur before).


                    So, the classes you put in the "hot" are not dealt with in the same manner as the one you put in the "main". They are deployed in a sub folder and not in the WEB-INF/lib like your entity stuffs are ("main").


                    So they are not visible to the  container's class loader. I don't understand why they are available otherwise but these are the facts.


                    ----------!!!!!!!!!!!---------- For the impatient:


                    So the solution is simply to put the servlet in the entity (main) directory and not in the "hot" deployable one and all will be just fine.
                    And to use ContextualHttpServletRequest


                    ----------!!!!!!!!!!!----------


                    As a proof of this, If you put the servlet itself in the "hot" dir, and call it in the browser address bar directly, here is the exception :


                    javax.servlet.ServletException: Wrapper cannot find servlet class be.myspeos.servlet.CheckSSOSessionIdServlet or a class it depends on
                         org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
                         org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
                         org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
                    ...
                    



                    If I switch it back to the "main" dir, it runs smoothly.


                    One last word,
                    If you don't use the ContextualHttpServletRequest as described in one previous post on this topic, you will receive this in the log :


                    java.lang.IllegalStateException: No application context active
                            at org.jboss.seam.Component.forName(Component.java:1912)
                            at org.jboss.seam.Component.getInstance(Component.java:1972)
                    ...
                    




                    Cheers,
                    Chris.