1 2 Previous Next 23 Replies Latest reply on Apr 12, 2006 1:30 AM by Brian Stansberry

    Clustered SSO not following the semantics of local SSO

    Jim Hazen Expert

      This problem could be related to the following post and JIRA, but I'm not sure. In either case this subject is more appropriate for this case.

      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67572

      I have an SSO cluster that seems to function differently when activity is entirely local vs distributed across the cluster.

      I have a site that uses a main login form to authenticate and then composites links to other local webapps on a page. Locally, logging into our main app logs you into every other app on the server. So following a link from our main app to any other app on the server works fine. In a cluster it seems that when you go from machine A to machine B, you will automatically be logged into the main app, but NOT all the other apps on machine B.

      So it seems that clustered SSO and local SSO behave a bit differently. Is this a known issue? Could I be doing something wrong? And yes I'm using FORM login in the main/home/login webapp.

      Thanks for any help,
      Jim

        • 1. Re: Clustered SSO not following the semantics of local SSO
          Brian Stansberry Master

          The behavior should be the same on one machine or across a cluster. If the SSO succeeds on one app on a cluster node, it should succeed on all. The SSO is driven by a cookie that applies to all apps with the same hostname.

          Couple things:

          1) If you can provide a testcase with a couple war's showing this, that would be ideal. The key thing is something that duplicates your logic for having various apps rely on a main app for authentication. I suspect the problem could be related to this.

          2) You can try adding the following attribute to the element for ClusteredSingleSignOn in server.xml

          requireReauthentication="true"

          That one's a shot in the dark; if it works let me know.

          3) How exactly does it fail:

          a) You're on node 1. You fail over to the "main" app on node 2. All is well. Then you click over to another app on node 2. SSO fails -- need to authenticate.

          OR

          b) You're on node 1. You fail over to another app on node 2 (not the main app). SSO fails -- need to authenticate.

          Best regards,

          • 2. Re: Clustered SSO not following the semantics of local SSO
            Jim Hazen Expert

            requireReauthentication="true" causes things to break even before fail over. :)

            And to answer question 3, both apply. It seems that SSO login context only gets shared across the cluster in the webapp that originated the login. However, that webapp doesn't have any trouble regardless of where you start.

            I'll try to come up with a cut down. Where do you want the wars?

            -Jim

            • 4. Re: Clustered SSO not following the semantics of local SSO
              Jim Hazen Expert

              Also, since I don't have a login form registered for the other SSO apps, I get the following error.

              HTTP Status 403 - Configuration error: Cannot perform access control without an authenticated principal

              Locally I have the 403 error page redirect to the main login page. A main log-out invalidates the local SSO. So SSO log-out seems to work like log-in except in reverse. This is nice (at least for my app). I simply don't supply the other webapps with login pages and when their auth fails I send them over to the main login.

              Locally everything works great. Clustered I automatically get logged into main, but nothing else. Since main houses my SSO login form, there's now no way to log in the other apps after a failover.

              I also have my cutdown, let me know where you'd like the files. 3 files around 350K each.

              • 7. Re: Clustered SSO not following the semantics of local SSO
                Jim Hazen Expert

                I should probably have included better steps to reproduce in my E-mail. Here they are.

                Load main, hello, hello2 in a cluster. Hit main, and log in via login form. You can then travel between all three apps via their navigation links. Find out which server you are on by looking at the server.log. Kill that server. Trying to reload either hello or hello2 will fail. Main works uneffected.

                This seems to hold true no matter the navigation after failover. Logging out of main, and then back in, unlocks hello and hello2 normally.

                If you need anything further, feel free to ask.

                -Jim

                • 8. Re: Clustered SSO not following the semantics of local SSO
                  Jim Hazen Expert

                  Any verification of this? Another person within my organization has been able to reproduce the problem. It'll be important for us to know:

                  A) That this is a bug
                  B) What the timeframe for resolution will be

                  Thanks,
                  Jim

                  • 9. Re: Clustered SSO not following the semantics of local SSO
                    Brian Stansberry Master

                    Jim,

                    Sorry for the slow response. If this is important for your organization and you need someone from JBoss to help get answers on this quickly, you should contact our support group. Please understand the forums are a form of free support and don't necessarily get the attention we would like to give them due to time constraints with dealing with support calls in addition to performing our actual development duties. :-)

                    That being said, there is a fundamental difference between SSO on a single node and over a cluster. On a single node, if the "requireReauthentication" attribute has been set to false (the default), once a user has been authenticated their Principal object is cached and for future requests is directly bound to the request object without making an authentication call to the JBossSecurityManagerRealm. However, the Principal is not replicated over the network, (because, among other reasons, Principal does not implement Serializable). So, the first time a user switches to another node, the Principal object is not cached and the ClusteredSSO valve has to authenticate the user using the login credentials (username, password) that have been cached. This should happen transparently to the user, as the required credentials are replicated.

                    In your described use case, only the main war has authentication enabled; if the first request to a new node is for one of the other wars, the ClusteredSSO valve will not be able to authenticate the user, and the request will fall through to your loginredirect.jsp.

                    I haven't had a chance yet to play with your wars, but I'm quite certain the problem you're seeing is related to the above.

                    • 10. Re: Clustered SSO not following the semantics of local SSO
                      Jim Hazen Expert

                      Thanks for the response Brian. I know you're under time pressures.

                      What you say makes sense. What it feels like JBoss is doing in SSO is that upon authentication with one app the principal gets propagated to the other webapp's context and the credentials are cached. Or there is some security context pointer back to the original login app (for single log-out). On fail over the cached credentials are used, but that initial push propagation doesn't happen.

                      At least that's what it feels like as a user. Cached credentials would explain why main functions correctly. I get the feeling that the SSO credentials aren't passed to the other webapps in SSO and that something else happens behind the scenes that allows the other apps to authenticate their principal. Not caching the credentials in all the apps and not pushing out the SSO principal again on failover would explain what I'm seeing.

                      I respect that this is free support. Pretty good free support at that. My organization is currently investigating the viability of JBoss. Once we're confident that JBoss will fit the bill we'll have no problem paying JBoss for support. Until then I know it's a bit of a catch-22. I'm willing to dedicate as much time as I need to to get you what you need. Let me know if there is anything.

                      -Jim

                      • 11. Re: Clustered SSO not following the semantics of local SSO
                        Brian Stansberry Master

                        I should be able to run through your test wars in the next day to get an exact idea of what's going on.

                        I definitely appreciate your good inputs on this. Getting a test case so quickly is not the norm with most forum questions :-) .

                        • 12. Re: Clustered SSO not following the semantics of local SSO
                          Jim Hazen Expert

                          Any luck verifying this defect? I've been away on my honeymoon these past couple weeks. Let me know if you need any anything else.

                          Thanks,
                          Jim

                          • 13. Re: Clustered SSO not following the semantics of local SSO
                            Brian Stansberry Master

                            First, congrats to you; hope you had a great honeymoon :)

                            I took another look this morning and saw the problem that eluded me before.

                            See

                            http://jira.jboss.com/jira/browse/JBAS-2314

                            • 14. Re: Clustered SSO not following the semantics of local SSO
                              Jim Hazen Expert

                              Hi Brian,

                              Finally had the chance to circle back and re-ramp on my clustered project. This problem is still there. Session information seems to be replicated fine, but not auth context.

                              I didn't exactly understand your explanation above. Is auth context not pushed along with session information out to all nodes upon login?

                              -Jim

                              1 2 Previous Next