PicketLink ProtocolBinding on Redirect
syncomm Jan 23, 2013 10:31 PMI'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"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
AssertionConsumerServiceURL="http://xx.xx.xx.xx:8080/employee/"
Destination="https://xx.xx.xx.xx/affwebservices/public/saml2sso"
ID="ID_04154f2b-0bdc-4755-8a9a-c849dee2d3b6"
IssueInstant="2013-01-24T02:43:46.679Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Version="2.0"
>
<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"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
/>
</samlp:AuthnRequest>
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
Greg
-