5 Replies Latest reply on Jan 16, 2012 2:30 PM by owulffjboss

    WS-Federation/STS across domains discussion

    anil.saldhana

      This thread will discuss the requirements, design etc for the functionality of WS-Federation/STS across domains.

       

      What is the major use case?

      We have solved the requirement of having a STS within a single security domain.  The domain can be a single JBoss cluster or a single machine or within a subnet.  Now if the security propagation has to happen across multiple domains, then we need to bring in WS-Fed.

       

      What is needed to implement WS-Fed?

       

      In my view, the following is the path to getting the use case implemented.

       

      1. Get sample ws-fed payload data.
      2. Enhance the PL parsers to include WS-Fed payload.
      3. Enhance the PL STS configuration to handle WS-Fed.
      4. Create a working demo that people can download and test.

       

      What is the end date for this implementation?

      July 25th, 2011.

        • 1. Re: WS-Federation/STS across domains discussion
          sguilhen

          After taking a good look at the spec, I agree with the main points you outlined. I also think we will need a web front-end for the STS to enable the retrieval of federation metadata via HTTPS. We also have to think how to configure the metadata the STS will expose.

           

          While we are talking about HTTP, some scenarios use redirection to point the user to the STS in order to obtain a token. This probably means we will also need a web login form for the STS for redirected users to login and get their tokens using the web browser.

           

          Also, many scenarios involves the claims needed to authorize access to a resource. That is, standard federation XML can include claims statements that must be verified and included in the assertions, such as groups, roles, e-mail, etc. While WS-Trust doesn't define a claim dialect, we have one for WS-Federation, the WS-Federation Passive Requestor Interoperability Profile (PRIP) which defines common types of claims that should be handled by federated STSs. I think we must support this too, which means the STS must act as some sort of identity provider or at least access the identity provider that can verify the claims.

          • 2. Re: WS-Federation/STS across domains discussion
            anil.saldhana

            I have determined that our configuration framework common to the sts and idp needs to be a little more smart and extendable, with the use of DB, ldap, metadata etc as identified here: http://community.jboss.org/thread/168336?tstart=0

             

            At this time, I am very interested in seeing sts across domains/clusters.

            • 3. Re: WS-Federation/STS across domains discussion
              thrash

              Has there been any further work on this topic?  I have a need for this on my current project and would like to know if this work has continued or not.

               

              Thanks

               

              --thrash

              • 4. Re: WS-Federation/STS across domains discussion
                anil.saldhana

                Brian,  we have not made progress here.

                • 5. Re: WS-Federation/STS across domains discussion
                  owulffjboss

                  Hi there

                   

                  I've recently contributed a federation plugin for Tomcat here:

                  http://svn.apache.org/viewvc/cxf/sandbox/fediz/

                   

                  whereas 80% is Tomcat agnostic (fediz-core) and 20% tomcat specific (custom Authenticator). I think this could be easily re-used within JBoss as it uses Tomcat also.

                   

                  I've also contributed a mock idp/sts which is able to issue SAML tokens which contain claims (which is also standardized by OASIS) and such.

                   

                  The IDP component is a very thin facade as most of the token issuance functionality is encasulated within the STS. Therefore, the STS can be re-used to secure the Web-Services communication also. In this case, the web application must request a new token (based on WS-SecurityPolicy) on behalf of the token issued during the web login.

                   

                  More information are available here:

                  http://owulff.blogspot.com