3 Replies Latest reply on Jul 2, 2010 1:12 PM by Anil Saldanha

    SAML Http Artifact binding support

    Sergey Beryozkin Newbie

      Hi

       

      Does PicketLink SAML project support passing SAML assertions by reference ?

       

      I'm thinking of the case where a client is configured with a reference to an existing assertion only so the server would then validate it over a back channel

       

      thanks, Sergey

        • 1. Re: SAML Http Artifact binding support
          Anil Saldanha Master

          Artifact profile is our next item on the agenda. Back channel typically involves soap binding (SAML spec).

          • 2. Re: SAML Http Artifact binding support
            Sergey Beryozkin Newbie

            Hi Anil - thanks for all the answers.

             

            At the moment I'd just like to see if/how SAML can be used in the case I'm looking at and it appears to me that just passing a SAML reference over plain HTTP could work well - and it's ok that SOAP is used internally to validate it...

             

            That said, perhaps one option is to write a SOAP based OAuth-STS integration layer where the OAuth filter simply acts as an STS client and will ask the STS to validate a given reference...

             

            cheers, Sergey

            • 3. Re: SAML Http Artifact binding support
              Anil Saldanha Master

              I will brain dump based on my knowledge of oauth.

               

              So basically you can use the STS as an issuer of both the request token and access token  needed by OAuth service.  For this to happen, Sergey, you need to implement the oauth token providers for the STS. (Sergey, also I suggest you move the resteasy-oauth code into PL federation project asap). Essentially, you have made the STS an oauth provider.  Just jargon.

               

              On a side note, we have been discussing about beefing the STS to be an attribute service (to provide the attributes for the tokens) and also an access control service( to make access decisions).  We are currently leaning toward keeping the services separate (seperation of responsibilities).  Basically, one client API (WSTrustClient or STSClient) should handle all the internal details.