2 Replies Latest reply on Jan 24, 2013 2:45 PM by Gregory Hayes

    PicketLink ProtocolBinding on Redirect

    Gregory Hayes Newbie

      I've been encountering an interesting issue when integrating PicketLink with a CA Federated IDP. CA's IDP is very strict, and it requires a redirect binding, and returns a post to the SP. I've read that the SAML Web Browser SSO Profile says that the IDP should not respond back via http redirect, but should stick to http post. This is the behavior implemented by CA, but PicketLink runs into a problem...


      This is an example of the decoded redirect AuthnRequest PicketLink generates:


      <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"









          <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://xx.xx.xx.xx:8080/employee/</saml:Issuer>

          <samlp:NameIDPolicy AllowCreate="true"





      Please note the line in bold. That is the ProtocolBinding specified for the IDP to return the SAML Response. This should read "ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST". Without this change the IDP gives me a syntax error (since it doesn't send an SAML response as a redirect.) Manually decoding the request, fixing this syntax, and resubmitting the encoded URL to the IDP works like a charm. So does authenticating first at the IDP and being redirected back to the SP. However, this is inconvenient and pretty ugly. Certainly not something I could expect the app's users to do.


      I've tried setting the IDPUsesPostBinding to true, setting the param strictPostBinding in the jboss-web.xml. I've done everything but patching the source (if IDPUsesPostBinding is true, the request should be using the ProtocolBinding of SAML_HTTP_POST_BINDING)


      If anyone else has encountered this problem, and knows a way to help let me know. If I can change the ProtocolBinding we are sending, then everything will "just work" -- unfortunately, I haven't found a way to change it




        • 1. Re: PicketLink ProtocolBinding on Redirect
          Gregory Hayes Newbie

          To investigate further, I downloaded the source from:




          I took a quick look at the logic which is happening in the SPAuthenticationHandler. Currently, there is a check which sets ProtocolBinding based on bindingType. This is incorrect. The binding type is "how we are connecting to the IDP", and the ProtocolBinding specifies "how the IDP is connecting back to the SP." Right now, if you are binding via POST it uses the POST ProtocolBinding, and if you are binding via REDIRECT, it uses the REDIRECT ProtocolBinding. From a code perspective the fix is simple:


          from ./org/picketlink/identity/federation/web/handlers/saml2/SAML2AuthenticationHandler.java (line 365 down):


          String bindingType = getSPConfiguration().getBindingType();

          boolean isIdpUsesPostBinding = getSPConfiguration().isIdpUsesPostBinding();


          if (bindingType != null) {

              if (bindingType.equals("POST")) {


              } else if ((bindingType.equals("REDIRECT")) && (isIdpUsesPostBinding)) {


              } else if (bindingType.equals("REDIRECT")) {


              } else {

                  throw logger.samlInvalidProtocolBinding();




          (lines in bold are my changes)


          This would check the IDPUsesPostBinding boolean from the picketlink.xml and properly format the SAML AuthnRequest. Could a developer with commit access review this change? I'll also open a bug report with the same information as this post and the diff against 2.1.6.Final.


          BTW - How do you compile PicketLink from source? There doesn't seem to be a "build" directory in the sources linked above, and I'd like to test out the change.




          • 2. Re: PicketLink ProtocolBinding on Redirect
            Gregory Hayes Newbie

            PicketLink correctly formats the AuthnRequest in version 2.1.2 (but not after) This is probably introduced by correcting bug PLFED 342