Summary
When acting as a SP sending an AuthnRequest to an IdP, the request is created with a hard-coded protocol binding. I was testing against http://samltest.id and it looks like they validate that the binding used is HTTP-POST. I am a novice at SAML. Googling around, it sounds like HTTP-POST is the recommended approach to responding to an AuthnRequest. Here is an example and another.
Actual Behavior
IdP validates protocol-binding and rejects AuthnRequest:
2019-10-07 00:40:38,302 - DEBUG [org.opensaml.saml.common.binding.impl.DefaultEndpointResolver:?] - Endpoint Resolver org.opensaml.saml.common.binding.impl.DefaultEndpointResolver: Candidate endpoint binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' did not match 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
2019-10-07 00:40:38,302 - DEBUG [org.opensaml.saml.common.binding.impl.DefaultEndpointResolver:?] - Endpoint Resolver org.opensaml.saml.common.binding.impl.DefaultEndpointResolver: Candidate endpoint binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' not permitted by input criteria
You can see by the last log statement that HTTP-Redirect is not permitted
Expected Behavior
The SP should use HTTP-POST protocol-binding when creating an AuthnRequest so that validation on the IdP side passes.
Configuration
Version
Spring-Security 5.2.0 Spring-Boot 2.2.0.RC-1
@fhanik FYI. Also, thanks for contributing this. It is very much appreciated.
Comment From: fhanik
@blucas Thank you for the report. Glad to already see feedback.
I will mark this as an enhancement, and look into a configuration option for POST vs REDIRECT.
The work around right now is to inject your own Saml2AuthenticationRequestFactory object.
The POST binding let's you send larger messages, that normally wouldn't fit in a redirect. The REDIRECT binding is not subject to cross site request filters that may block them. Both pros and cons.
If you would like to get more involved, you can submit a PR that allows you to configure the preferred binding options on the OpenSamlAuthenticationRequestFactory object.
I haven't fully thought it through yet, but we would work through it together.
Comment From: blucas
@fhanik Thanks for the quick reply.
I will mark this as an enhancement, and look into a configuration option for POST vs REDIRECT. The work around right now is to inject your own Saml2AuthenticationRequestFactory object.
I completely support the idea of a configuration option enhancement. The workaround should work for now.
The POST binding let's you send larger messages, that normally wouldn't fit in a redirect. The REDIRECT binding is not subject to cross site request filters that may block them. Both pros and cons.
Agreed. However, this answer seems to imply that HTTP-REDIRECT is not allowed. Is this answer incorrect? To me it seems logical that the default should be HTTP-POST as the response for AuthnRequest may very well be large. Consider that extra attributes may be sent (such as roles/permissions) which would bloat the SAMLResponse.
If you would like to get more involved, you can submit a PR that allows you to configure the preferred binding options on the OpenSamlAuthenticationRequestFactory object.
I'd love to help if I can. Don't have many spare cycles, but I can give it a shot. At the very least there could just be a setter
Comment From: fhanik
@blucas
Agreed. However, this answer seems to imply that HTTP-REDIRECT is not allowed.
That answer focus on the response from the IDP to the SP,Meaning the actual assertion. The AuthNRequest is the message from the SP to the IDP (the opposite way)
In either case, both POST and REDIRECT are supported bindings. The actual implementations may make a their own rules and can disallow certain bindings.
We can however support both :)
Comment From: blucas
That answer focus on the response from the IDP to the SP,Meaning the actual assertion. The AuthNRequest is the message from the SP to the IDP (the opposite way)
So if the spec states that the response to the AuthNRequest must not use HTTP-Redirect, then why should we allow the AuthNRequest to state the ProtocolBinding requested is HTTP-Redirect? Maybe I misunderstand the purpose of the ProtocolBinding attribute in the AuthNRequest. I assume the SP is asking the IdP to send the response to the AuthNRequest using HTTP-Redirect. Is my assumption correct?
Comment From: fhanik
So if the spec states that the response to the AuthNRequest must not use HTTP-Redirect
I don't believe the spec states that. Both bindings are allowed.
That being said, our default should say Http-Post, as our preferred way of receiving the Response, with a configuration option of Http-Redirect. We can receive it using either Redirect or Post.
Most IDPs don't take the value in the AuthNRequest#ProtocolBinding, instead they go by the configuration set up, and ignore the ProtocolBinding attribute all together.
Comment From: lilalinux
@blucas Could you please share the Saml2AuthenticationRequestFactory workaround?
tyvm
Comment From: jzheaux
@lilalinux Are you looking for the OpenSamlAuthenticationRequestFactory#setProtocolBinding method? I'm not clear on what you are looking for a workaround to.
Comment From: jzheaux
And just to clarify with respect to the conversation about the ProtocolBinding attribute in AuthnRequest payloads, the specification says:
421 In step 5, the identity provider issues a <Response> message to be delivered by the user agent
422 to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer
423 the message to the service provider through the user agent. The message may indicate an error,
424 or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be
425 used, as the response will typically exceed the URL length permitted by most user agents.
So while the schema for AuthnRequest#ProtocolBinding may technically allow Redirect, a SAML 2.0-compliant IdP will only return POST or Artifact.