1 Reply Latest reply on Mar 12, 2014 7:47 PM by Anil Saldanha

    SAML Artifact Binding

    amdonov Newbie

      I have a use case that I've only been able to solve with SAML's Artifact Binding. I was wondering if there is a better approach. If not, I was wondering if artifact binding support could be added to picketlink.

       

      Consider the case where Application 1 serves up a Web page that references images from Application 2.

      If the user hasn't already logged into Application 2, they will be redirected to the IdP. However, the browser won't post the IdP response to Application 2. It just drops it and images show up as broken links. When I use artifact binding, the IdP redirects back to Application 2 with GET. Using the back channel SOAP request, Application 2 retrieves the SAML token, authenticates the user, and serves up the content.

       

      Is there a better way to solve this problem? I'm currently using the Shibboleth Native SP in front of my application, but I'd like to drop the dependency on native code and Apache.


      Thanks

       

      Replying to the answer failed with an error, so I'm trying to edit the original post....

       

      Anil,

       

      Thanks for the reply. I'm sorry, but I don't understand your question regarding portals. Are you suggesting that Application 1 proxy the images from Application 2?

       

      I reviewed the REST API documentation that you provided. It looks like it would enable a service account from Application 1 to access Application 2, but it doesn't tie resource requests on Application 2 to the end user. Is that a correct interpretation? Our access control and auditing requirements require that resource access be tied to a user for all of our applications. We can't use service accounts for communication between applications.


      The only way I can see making a proxy approach work is to use an WS-Trust with Act-As. We've done that in some other cases when we needed brokered trust. However, that forces me to use SOAP anyway. Also, Application 1 would need to maintain a conversation with Application 2 on behalf of each user to avoid repeated STS calls. This seems like a good deal more trouble than using Artifact Binding.

       

      I would greatly appreciate it if you would consider supporting Artifact Binding in a future release. If I've misinterpreted something that you've said or the REST API, please let me know.

       

      Thanks,
      Aaron

       

      Message was edited by: amdonov

        • 1. Re: SAML Artifact Binding
          Anil Saldanha Master

          I am contemplating adding support for SAML Artifact binding to PicketLink for SPs. This is to enable PL SPs to interact with 3rd party IDPs that do artifact binding.

           

          Personally I think doing back channel SOAP interaction is very medieval.  Given that the world is moving toward lightweight REST style architectures, I would suggest simplifying your usecase in some manner that you do your interactions via the front channel (browser).

           

          Do you have an opportunity to construct the page at application 1 similar to how a portal deals with page construction?

           

          Maybe you can mimic the browser behavior using PicketLink REST API

          1 of 1 people found this helpful