SAML2 Provider AuthNRequest Hardcoded Protocol Binding

[blucas]

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.

[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.

[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

[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 :)

[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?

[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.