1 2 Previous Next 24 Replies Latest reply on Nov 24, 2005 12:13 AM by Anil Saldanha

    Federated Identity

    Anil Saldanha Master

      Need some general feedback.

      Usecase: An user agent hits a Service Provider (SP)'s protected resource. The tomcat container hosting the SP, intercepts the request, redirects the user agent to an Identity Provider's (IDP) website, where the authentication process happens. The IDP redirects the user agent to the SP, with a SAML assertion in the redirection. Now the container at the SP intercepts - sets the Principal (may talk to the IDP via a backdoor to obtain additional attributes to ascertain roles) on the request, to be directed into the realm world - based on JACC.

      Possible Approach:
      a) A custom valve at the context level in the SP container checks if the request holds the Principal . If blank, the redirection to the IDP happens. When the redirection after auth happens from the IDP to the SP, this valve obtains the SAML assertion and does the necessary stuff to place the Principal on the request and also generate a set of roles applicable to the authorization decision.
      b) Authorization is based on JACC. A new permission called "SAMLPermission" needs to be created that is fed as an external permission type that is allowed in the decision making by the Delegating Policy framework on the JACC layer.

      Does this make sense? Anything that I am missing in view of our recent discussions on generalizing the JAAS/JACC layer?

        • 1. Re: Federated Identity
          Anil Saldanha Master

          The IDP's url is injected into the custom authenticator at configuration as follows:

          On the SP, WEB-INF/context.xml
          
          <Context path="/identity-sp">
           <Valve className="org.jboss.web.tomcat.security.FederatedAuthenticator"
           identityProvider="http://localhost:8080/idp-1" />
          </Context>
          


          I am sure there is a better way than handling this...

          • 2. Re: Federated Identity
            Scott Stark Master

            Today tomcat handles sso with a combination of a base authentication valve and a custom valve.

            We need to talk about the full authentication and authorization path in the context of JAAS, SSO, the web authentication mechanism, distributed web apps, and propagation of the identity to other secured components. Authentication and authorization need to remain independent, but certainly there is a correlation based on the authenticated identity. I should not need a SAMLPermission introduced into the JACC layer. What is needed is a mapping of the authenticated identity to the correct set of JACC permissions. This might be done via an attribute associated with the authenticated identity. With JSR-196, both authentication and authorization are supposed to be pluggable elements, potentially coming from different providers. How the JACC layer maps the authenticated subject to a set of permissions is what we need to understand.

            • 3. Re: Federated Identity
              Anil Saldanha Master

              Does JACC define custom permissions? AFAIK the spec defines permissions for the web and ejb resources only. The reason I am asking is because in the case of portals, I think the permissions have to defined at the individual objects in a portal page. That is what Martin has done...

              On the other hand, in the case of federation, it is not difficult to map the authenticated identity to JACC specification defined permissions.

              • 4. Re: Federated Identity
                Scott Stark Master

                No, JACC has no mechanism for extending the accepted permissions associated with a given context. This is something we added to support the portal usecase.

                What I am saying is that authentication and authorization have to remain independent or else they are not seperately pluggable. The only public representation of identity JACC knows about is the JAAS Subject. So the question is, what is the mechanism we will use to inform JACC that a Subject authenticated by some arbitrary provider maps to a valid identity and permission set for the xyz.war deployment?

                Today our JACC provider initimately associated with the JAAS authentication layer. This needs to be seperated, and a mechanism for mapping the authenticated caller to a set of permissions in a given deployment context.

                • 5. Re: Federated Identity
                  Anil Saldanha Master

                  Reread the JSR-196 specification. The initial draft is a very good step at abstracting out the authentication framework at both the client side and the server side. I like that the JAAS login modules are being abstracted into ClientAuthModules and ServerAuthModules.

                  Regarding current authentication setup in JBoss, we have both tomcat valves and JAAS login modules handling different authentication responsibilities. No one framework.

                  Section 4.8 of the JACC specification briefly mentions about the possibility of the authentication done by external providers - but still bases the authorization decisions based on caller's identity established in the JAAS subject.

                  One big issue in federated identity is the establishment of metadata about attributes supported between the Identity Provider and the Service Provider. These attributes are critical in establishing roles for authorization.

                  Now to answer the question, you posed: So the question is, what is the mechanism we will use to inform JACC that a Subject authenticated by some arbitrary provider maps to a valid identity and permission set for the xyz.war deployment?

                  I am not sure how we can do this in a clean global way. I can only visualize this as an issue the policy provider has to deal with in dealing with a protection domain (containing the calling principals). The authorization can always be rigid with a decision making setup. But I cannot think of ways by which we can push back the permissible identity metadata back to the authentication layer, without introducing a tight couple.

                  The authentication layer can be pluggable with external providers. Now whether the authorization layer can accept the caller's identity is nondeterministic in a standard way. Scott, do you have any ideas on this?

                  • 6. Re: Federated Identity
                    Scott Stark Master

                    I would handle this in the same was as authentication, callback handlers. Instead of obtaining credentials for authentication, they would allow for mapping identity. This can also be done during the authentication phase by chaining login modules, ServerAuthModules to associate the identity mapping info as well. So there is a coupling, but it can be done by a thirdparty.

                    • 7. Re: Federated Identity
                      Anil Saldanha Master

                      In the authentication phase, we can just chain the ServerAuthModules because they can internally use LoginModules.

                      You said:
                      This can also be done during the authentication phase by chaining login modules, ServerAuthModules to associate the identity mapping info as well. So there is a coupling, but it can be done by a thirdparty.

                      Ee can consolidate the authentication constructs to be ServerAuthModules.... Maybe one ServerAuthModule can provide the backwards compatibility to engulf the LoginModules configuration, people have got accustomed to...

                      I like using ServerAuthModules as the only construct for authentication ....

                      I am making sense, Scott? Or am I way off topic?

                      • 8. Re: Federated Identity
                        Anil Saldanha Master

                        Some description for observers:

                        SAML just defines a mechanism to send authentication requests to the Identity Provider and get a response back. The IDP will do the authentication and send an artifact back with the response. This artifact typically just contains limited information(An example would be it will contain an id). Now the Service Provider (SP) can query the IDP using the id, to get additional attributes about the user agent. Thats about it....
                        
                        Now that the SP has obtained additional information about the user agent, it does not require SAML anymore. All it can do is use the authorization layer to do the authorization.
                        
                        The authorization layer needs to be capable of doing JACC along with any other generalization. Now we can plug in a XACML implementation to be a jacc policy provider.
                        


                        Things we need to look at (after discussion with Scott):
                        a) Mechanism used by the service provider after authentication from the IDP, to cache the token. Are cookies used?
                        b) If a web layer makes an ejb call, the trust relationship that has been established in the web domain with external Identity Providers, may not be valid in the ejb domain. Should a trust cache be established in the ejb layer.
                        c) Unified configuration that allows to do generic pluggable authentication/authorization modules (maybe JSR-196)
                        d) Trust timeouts in the ejb layer may be out of sync with the timeouts in the web layer. If the trust timeouts in the ejb trust cache are shorter than the timeouts in the web layer, users are going to freak out.
                        e) The ejb layer may have to go to IDP once it has received an identity from the web layer.
                        f) Inability to renew expired leases (dont know a better relevant word) in the SRP domain. SRP is important to migrate username/pwd based systems to federation. It is complex to ask users to use certificates for everything.
                        g) Integration with ws-metadata exchange and other federation mechanisms - ws-trust/ws-federation/saml token profile.

                        References:
                        1. http://www.identityblog.com
                        2. http://www.dotnetcard.com/Blogs/ksachdeva/CategoryView.aspx?category=Demos
                        3. ws-metadata exchange, ws-trust, ws-federation.

                        • 9. Re: Federated Identity
                          Sohil Shah Master

                           

                          "anil.saldhana@jboss.com" wrote:

                          Usecase: An user agent hits a Service Provider (SP)'s protected resource. The tomcat container hosting the SP, intercepts the request, redirects the user agent to an Identity Provider's (IDP) website, where the authentication process happens. The IDP redirects the user agent to the SP, with a SAML assertion in the redirection. Now the container at the SP intercepts - sets the Principal (may talk to the IDP via a backdoor to obtain additional attributes to ascertain roles) on the request, to be directed into the realm world - based on JACC.


                          This approach works for federating the sites within an internal network (sites that can be modified to use centralized authentication and maybe even the same datastore).

                          However, the SSO framework should be flexible enough to provide ways to federate completely independent sites with independent data stores.

                          In this case, each site should handle their own authentication, and generate SAML assertions which is then propagated between the partner sites using the IDP. In this way, authentication logic can be made flexible for each site and at the same time allowing SSO between the participating SPs.

                          So taking that into account- the Usecase would become-
                          Usecase: An user agent hits a Service Provider (SP)'s protected resource. The SP performs the actual authentication. If the authentication works, SP produces a SAML assertion to be cached as a domain cookie. Now, when the user clicks a link to go to a partner site, the IDP of the first SP's domain redirects the SAML assetion to the IDP of the partner SP's domain. The partner SP then processes this SAML assertion and creates the necessary Principal and authorization environment for this user. .


                          Notice I did not make any assumptions about the underlying technology, but where JBoss App Server comes in is when a partner site is built in J2EE, JBoss provides a security framework with JAAS components to do SSO authenticaton and generation of SAML token. JBoss App Server also provides mechanism to process SAML assetions and generate the appropriate Principal etc.

                          • 10. Re: Federated Identity
                            Sohil Shah Master

                             

                            "anil.saldhana@jboss.com" wrote:

                            Things we need to look at (after discussion with Scott):
                            a) Mechanism used by the service provider after authentication from the IDP, to cache the token. Are cookies used?

                            Yes, you can use domain level cookies to cache the assertion. This cookie is used by the IDP to do cross domain assertions. Any access to a partner SSO site has to go through the IDP of the current domain.

                            "anil.saldhana@jboss.com" wrote:

                            b) If a web layer makes an ejb call, the trust relationship that has been established in the web domain with external Identity Providers, may not be valid in the ejb domain. Should a trust cache be established in the ejb layer.

                            Probably a clustered cache that is shared between the web layer and the ejb layer should do the trick. Is that possible?

                            "anil.saldhana@jboss.com" wrote:

                            d) Trust timeouts in the ejb layer may be out of sync with the timeouts in the web layer. If the trust timeouts in the ejb trust cache are shorter than the timeouts in the web layer, users are going to freak out.

                            e) The ejb layer may have to go to IDP once it has received an identity from the web layer.

                            Would these be an issue if both layers share the same trust cache.

                            • 11. Re: Federated Identity
                              Anil Saldanha Master

                               

                              "sohil.shah@jboss.com" wrote:


                              However, the SSO framework should be flexible enough to provide ways to federate completely independent sites with independent data stores.

                              In this case, each site should handle their own authentication, and generate SAML assertions which is then propagated between the partner sites using the IDP. In this way, authentication logic can be made flexible for each site and at the same time allowing SSO between the participating SPs.

                              So taking that into account- the Usecase would become-
                              Usecase: An user agent hits a Service Provider (SP)'s protected resource. The SP performs the actual authentication. If the authentication works, SP produces a SAML assertion to be cached as a domain cookie. Now, when the user clicks a link to go to a partner site, the IDP of the first SP's domain redirects the SAML assetion to the IDP of the partner SP's domain. The partner SP then processes this SAML assertion and creates the necessary Principal and authorization environment for this user. .


                              Notice I did not make any assumptions about the underlying technology, but where JBoss App Server comes in is when a partner site is built in J2EE, JBoss provides a security framework with JAAS components to do SSO authenticaton and generation of SAML token. JBoss App Server also provides mechanism to process SAML assetions and generate the appropriate Principal etc.


                              Thanks Sohil for the discussion.

                              Point 1: Agree that the SSO framework should be flexible. Only caveat is that we should not look at a generic framework, which instead of solving practical customer problems, will tend towards utopia. :)

                              Point 2: I am still not sold on the idea of a SP local authentication becoming a federated case. How does one distinguish between a normal local authentication and a federated authentication? Are you saying that the IDP in the local security domain as the SP, will convert the domain session cookie into a federated token? Why not just have the IDP deal with all the federated authentication for a particular security domain and if the SP needs a local authentication, then so be it - the local authentication results never get converted into a federated token.

                              Atleast the discussion that we are having on this thread has been to see how the JBoss security layer will handle federated security tokens from different security domains while delegating the plethora of identity stakeholders - SAML 2.0, WS-Federation, WS-Trust (For Web Services) to external providers.

                              • 12. Re: Federated Identity
                                Anil Saldanha Master

                                Also one area that needs to be considered is the metadata that is relevant to federation.

                                Pointers: Metadata Profiles in SAML 2.0 (Web SSO) and WS-MetaData Exchange (Web Services Federation Arena)

                                How do we solve this issue of attributes in security domain A mapping onto the attributes needed for authorization in security domain B?

                                • 13. Re: Federated Identity
                                  Sohil Shah Master

                                   

                                  "anil.saldhana@jboss.com" wrote:

                                  Point 1: Agree that the SSO framework should be flexible. Only caveat is that we should not look at a generic framework, which instead of solving practical customer problems, will tend towards utopia. :)

                                  Agreed. too much generalization does not lead to a concrete enough implementation. However, supporting local authentication is probably very useful for our customers especially when they want to federate with their ASP services like salesforce.com. In fact that is a real need for federation within our own infrastructure at JBoss.

                                  "anil.saldhana@jboss.com" wrote:

                                  I am still not sold on the idea of a SP local authentication becoming a federated case. How does one distinguish between a normal local authentication and a federated authentication? Are you saying that the IDP in the local security domain as the SP, will convert the domain session cookie into a federated token?

                                  Actually it does not really matter who does the authentication (SP or IDP) as long as a proper SAML assertion is produced as a federation token. In my opinion, the IDP's sole responsibility is to propagate the federated token to the domain where the user wants to go. Generating the SAML token would be the responsibility of the entity that performs the actual authentication (SP or IDP) depending on how you want to split the concerns.

                                  "anil.saldhana@jboss.com" wrote:

                                  Why not just have the IDP deal with all the federated authentication for a particular security domain and if the SP needs a local authentication, then so be it - the local authentication results never get converted into a federated token.

                                  local authentication results not producing a federated token would limit the use of SSO even though specs like SAML exists to support cross domain federation to some extent. Having a central IDP doing the authentication will work just fine for internal websites. However, thats just half the battle. There is definitely market value in our customers' website being able to do local authentication, producing a SAML assertion that is compatible with their partner sites like salesforce.com. Its obvious that asking SalesForce.com to hook into your company's IDP for authentication is definitely not feasible.

                                  "anil.saldhana@jboss.com" wrote:

                                  Atleast the discussion that we are having on this thread has been to see how the JBoss security layer will handle federated security tokens from different security domains while delegating the plethora of identity stakeholders - SAML 2.0, WS-Federation, WS-Trust (For Web Services) to external providers

                                  Agreed a 100%

                                  • 14. Re: Federated Identity
                                    Sohil Shah Master

                                     

                                    "anil.saldhana@jboss.com" wrote:
                                    Also one area that needs to be considered is the metadata that is relevant to federation.

                                    Pointers: Metadata Profiles in SAML 2.0 (Web SSO) and WS-MetaData Exchange (Web Services Federation Arena)

                                    How do we solve this issue of attributes in security domain A mapping onto the attributes needed for authorization in security domain B?


                                    This is a good point. The concept of authorization (permissions/roles) is pretty much specific to the requirements of each web application.

                                    If I am treated as a manager in this website does not necessarily mean I am treated as a manager in another website in the federation.

                                    But, there could also be the case where all the sites within a federation share the same roles. In this case, the Metadata Profiles would come in handy.

                                    So I guess what I am trying to say is, maybe the attributes associated with authorization should be populated and sent over in the SAML assertion (federation token), but how those attributes get processed within the partner site should be left to each web application.

                                    1 2 Previous Next