8 Replies Latest reply on Jul 16, 2008 6:56 PM by alllle

    How is JBoss SSO SAML token been validated?

    alllle

      I want to understand how the JBoss SSO SAML token is validated
      1. between JBoss federation servers?
      2. with a 3rd party federation server?


      With some testing, I think how it works between JBoss federation servers, when authenticated at sso site1 and try to access sso site2, is:
      1. With the help of the HTTP "Referer" header, when sso site2 is accessed, the sso tomcat valve at site2 posts back to the "/federate/" servlet at site1, including the "target" URL the user attempts to access.
      2. The "/federate/" servlet have access to the SAML token at site1 because the browser sends it to the site1 in cookie. It then posts this SAML token to the "/federate/" servlet at site2, together with the "target" URL the users attempts to access.
      3. The federation server at site2 validates the SAML token and setups the authentication status at site2 using the username presented in the SAML token.
      4. It also returns the "Set-Cookie" header to the browser so the token is sent to the site2 from now on.

      Is this observation correct?


      And how is the token validated when a 3rd party federation server is involved?

      Thanks,

        • 1. Re: How is JBoss SSO SAML token been validated?
          soshah

          Yes this flow of events is correct

          Just to elaborate:


          3. The federation server at site2 validates the SAML token and setups the authentication status at site2 using the username presented in the SAML token.


          the SAML token validation between site2 and site1 involves a Trust callback between the federation servers of site1 and site2.


          And how is the token validated when a 3rd party federation server is involved?


          The protocol/communication mechanism for the Trust callback is pluggable using a component called TrustPlugin, with the JBossSSOTrustPlugin shipping out-of-the-box

          To support thirdparty Federation servers, you just need to create a TrustPlugin for that and plug it in.

          btw- this functionality is not included in the CR1 release. Its currently implemented on the trunk, and will be part of the next release

          Thanks



          • 2. Re: How is JBoss SSO SAML token been validated?
            alllle

             

            "sohil.shah@jboss.com" wrote:

            the SAML token validation between site2 and site1 involves a Trust callback between the federation servers of site1 and site2.


            And this trust callback happens directly between the federate server in the backend on the server side, no browser redirection involved?

            Where does the site2 gets the URL of the issuing site? The SAML token doesn't seem to have that information.

            Thank you!

            • 3. Re: How is JBoss SSO SAML token been validated?
              soshah

               


              And this trust callback happens directly between the federate server in the backend on the server side, no browser redirection involved?


              Yes this is a backend server side communication. There is no browser involvement here. Browser is only used to store/propagate the token. At some point I would also like a complete cookie-less approach for token storage/propagation, but its something I have only thought about for now.


              Where does the site2 gets the URL of the issuing site? The SAML token doesn't seem to have that information.


              Correct. For security reasons, the SAML token does not need to carry this information.
              This information is contained as part of the federation server configuration where information about the partners it needs to support/trust within the federation is provided.

              Here is a sample configuration file for a federation server. Note: this is new functinality added on the trunk, so it different than the CR1 release. This will be included in the next release

              Here is the conf/server.cfg.xml file
              <?xml version='1.0' encoding='ISO-8859-1'?>
              
              
              
              <jboss-sso>
              
              
              
               <!--
              
               partners configuration of the federation server...
              
               partners are the collection of sites which are part of the Single Sign On Federation
              
               it lists the web domains and their corresponding federation servers in this domain
              
               -->
              
               <federation-server>
              
               <partners>
              
               <partner domain="jboss.com" server="https://node1.jboss.com:8443/federate">
              
               <host>
              
               <id>node1.jboss.com</id>
              
               <secret>node1.jboss.com/somesecret</secret>
              
               </host>
              
               <host>
              
               <id>node2.jboss.com</id>
              
               <secret>node2.jboss.com/somesecret</secret>
              
               </host>
              
               <!--
              
               Used to configure the TrustPlugin which is responsible for validation of an incoming assertion/token
              
               Basically this verifies the token against the partner sending the assertion and makes sure with
              
               the partner that this assertion/token is valid so the user can be granted access without
              
               challenging them for credentials
              
               -->
              
               <trust>
              
               <url>https://node1.jboss.com:8443/federate/trust/validateSecret</url>
              
               <plugin class="org.jboss.security.federation.trust.JBossSSOTrustPlugin">
              
               <property name="allowSelfSignedSSLCert">true</property>
              
               </plugin>
              
               </trust>
              
               </partner>
              
               <partner domain="jboss.org" server="https://node1.jboss.org:8443/federate">
              
               <host>
              
               <id>node1.jboss.org</id>
              
               <secret>node1.jboss.org/somesecret</secret>
              
               </host>
              
               <trust>
              
               <url>https://node1.jboss.org:8443/federate/trust/validateSecret</url>
              
               <plugin class="org.jboss.security.federation.trust.JBossSSOTrustPlugin">
              
               <property name="allowSelfSignedSSLCert">true</property>
              
               </plugin>
              
               </trust>
              
               </partner>
              
               </partners>
              
               </federation-server>
              
              
              
              </jboss-sso>
              


              The trust server url is what is used based on the partner in question

              Thanks

              • 4. Re: How is JBoss SSO SAML token been validated?
                alllle

                Thank you for the detailed explanation.

                There is one thing that is still not clear to me: when validating a token, how does it know which partner issued the token? There is a "issuer" element in the SAML xml (in my demo, the token shows Issuer="ssodemo:site1"). But this issuer value is what I specified in the context.xml file:

                <Valve className="org.jboss.security.valve.SSOTokenManager" assertingParty="ssodemo:site1" />
                

                And this value would not be visible to the federate server...

                • 5. Re: How is JBoss SSO SAML token been validated?
                  alllle

                  Just want to bump this thread as it is still not clear to me that when a federate server receives a SAML token, how does it know the URL to contact to in order to validate the token? The token itself only has the "issuer" ID, which is set in the context.xml file. The federate server wouldn't be able to know which URL it needs to contact based on that info...

                  • 6. Re: How is JBoss SSO SAML token been validated?
                    soshah

                    allie-

                    The receiving federation server knows the partner that is propagating/issued the SAML token by looking at the Referer header of the request that is received by the receiving federation server

                    Here is the small code snippet to clariy

                    // Validate the incoming token with the partner that issued
                    // this token
                    // Basically perform a Trust Handshake with the partner to
                    // make sure
                    // The partner in fact successfully authenticated this user
                    String referer = request.getHeader("Referer");
                    Partner partner = this.findPartner(referer);
                    boolean isTokenValid = partner.getTrustPlugin().validateTrust(token, partner);
                    


                    Thanks

                    • 7. Re: How is JBoss SSO SAML token been validated?
                      alllle


                      I see. Thank you for the explanation. Now I see how everything is connected.

                      • 8. Re: How is JBoss SSO SAML token been validated?
                        alllle

                        When thinking about it, it occurs to me that the "referer" does not seem to be a reliable way of determine the issuing site.

                        1. The "Referer" site might not be the original issuer of the token, when more than 2 sites are participating in the SSO.

                        2. If integrate with 3rd party application / platform, it may not look at the "Referer" header at all.

                        3. It will be difficult to support SSO for programmatic access of remote services like SOAP or REST.

                        It seems to me that including the issuer URL in the token does not impose security risks, as the validation of the token is still done by the original issuer. And doing so makes the SAML token contains sufficient to perform validation instead of relying on additional "meta" data like referer header.