2 Replies Latest reply on Nov 10, 2006 3:36 PM by kenkyee

    federated SSO framework and http cookies

    Sohil Shah Master

      -----Original Message-----
      From: kenyee@keysolutions.com [mailto:kenyee@keysolutions.com]
      Sent: Monday, November 06, 2006 1:46 PM
      To: Sohil Shah
      Subject: federated SSO framework and http cookies


      Hi Sohil,

      You guys really need to let people comment on the JBoss blog :-)
      Quick question for you: can the federated SSO framework
      retrieve and inject http cookies as part of user validation?
      I looked at the wiki entries and the api for the LoginProvider
      class doesn't seem to let you do this.

      Two use cases I'm thinking of:
      1) a "remember me" checkbox next to the username/password field
      that lets users hit that site for a while after logging in once
      2) another web server on the same domain that puts in a
      session cookie of a logged in user (i.e., you log into that web
      server, the cookie is generated for your domain, then you go
      to the jboss federated server and autologin)

      thanks,

      ken

        • 1. Re: federated SSO framework and http cookies
          Sohil Shah Master

          Kenyee-


          >Quick question for you: can the federated SSO framework retrieve and
          >inject http cookies as part of user validation?


          Kenyee, the JBoss SSO Framework does not dictate what type of authentication method is used by the web application. Examples being JAAS based modules, completely proprietary form based approach etc. The SSO Framework kicks in once an authentication is actually performed by the web application. Once that happens, the SSO Framework generates/injects the necessary secure SAML token as a domain cookie that will be passed around within the federation of websites, so that the user will not be asked to login when going to a partner site in that session.

          At this moment, this SSO token management is closely integrated with the JAAS based authentication approach. But, based on community feedback, I think I will be adding integration with non-JAAS based/proprietary authentication methods very soon by updating the LoginProvider interface.


          >1) a "remember me" checkbox next to the username/password field that
          >lets users hit that site for a while after logging in once


          The remember me cookie can be easily used by the web application to set the cookie on the browser and authenticate using whatever authentication mechanism the web application wishes. Once the authentication is completed successfully, the SSO Framework will kick in and perform the necessary SSO token management etc. Think of it as, the SSO Framework hooks on top of your web application. But, you don't need to change the authentication usecase of your web application like remember me cookies, etc.

          Just to clarify, the LoginProvider is an abstraction to Identity Stores that should be used by your authentication mechanism to pull Identity data from the store in a Store agnostic manner (LDAP, SiteMinder, JDBC etc).

          I have gotten community feedback that besides the username, and password parameters, there needs to be provision for sending in more information as criteria to perform a successful login. This will be addressed so that the LoginProvider interface can be made more generic


          >2) another web server on the same domain that puts in a session cookie
          >of a logged in user (i.e., you log into that web server, the cookie is
          >generated for your domain, then you go to the jboss federated server
          >and autologin)


          What you are referring here it seems is a session cookie for a logged in user for that web application. This is perfectly fine and is independent of the SSO token that is generated to perform autologin via the Federation Server. The Federation Server does not process any proprietary app server specific login sessions. It uses the SAML token to perform the single sign on which is generated by the SSO framework when a user successfully authenticates on a partner web application.


          For some clarifications on some of the SSO architecture questions, also look at the following forum thread:

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


          I hope this answers your questions.


          Thanks
          Sohil

          • 2. Re: federated SSO framework and http cookies
            kenkyee Newbie

             

            "sohil.shah@jboss.com" wrote:
            I have gotten community feedback that besides the username, and password parameters, there needs to be provision for sending in more information as criteria to perform a successful login. This will be addressed so that the LoginProvider interface can be made more generic


            Thanks for the reply, Sohil.
            As part of the LoginProvider framework, if we could have some generic interface that lets us tuck away name/value bits of info, I think it'd be useful (we can then save off info like Windows Domains, securID tokens, etc.). It'd also be useful if we could get/set http cookies via that interface (e.g., "set cookie for your SSO domain").

            The use case for the latter case would be: multiple web server types in same domain. You login to one web server, which injects a cookie into your web browser. You then hit another web server in your domain, and that web server can use that cookie for validation. It's a somewhat crude way to do an SSO-like or remember-me-like login.

            If I understand correctly, the SAML token does this in a similar way, but I don't know if you can map from a SAML token to valid authentication information on each web server easily so that your web app on the second server is logged in properly (your LoginProvider seems to depend on a username/password). I guess it'd really help if there's an example that shows how SSO works in a "remember me" type of application...