Spring Security 5.3 allows an application to configure how to send AuthnRequests via RelyingPartyRegistration.ProviderDetails.isSignAuthnRequest and RelyingPartyRegistration.ProviderDetails.binding.

There are two ways these could potentially be set.

The first is via properties.

The sso-url (the location to where AuthnRequests are sent) can already be configured per identity provider like so:

spring:
  security:
    saml2:
      relyingparty:
        registration:
          registrationId:
            identityprovider:
              sso-url: https://idp.example.org/SSO.saml2

Possibly, an application could also provide sso-binding to indicate whether to redirect or post AuthnRequests. An application could also provide sso-sign to indicate whether or not to sign the AuthnRequest:

spring:
  security:
    saml2:
      relyingparty:
        registration:
          registrationId:
            identityprovider:
              sso-url: https://idp.example.org/SSO.saml2
              sso-binding: redirect
              sso-sign: false

(Note that when considering these property names, it would be good to remember that this login request metadata may be coupled with logout request metadata in the future - another option, then, may be to evolve the sso-url property to sso.url and thus introduce sso.binding and sso.sign)

The second is isSignAuthnRequest can be inferred.

The application can configure a list of signing credentials:

spring:
  security:
    saml2:
      relyingparty:
        registration:
          registrationId:
            signing.credentials:
              - private-key-location: "classpath:private.key"
                certificate-location: "classpath:certificate.crt"
              - ...

In the absence of any signing credentials, it's readily apparent that the application does not intend to sign any AuthnRequests, so isSignAuthnRequest can be set to false.

Comment From: mbhave

@jzheaux Are post and redirect the only two values for sso-binding?

Comment From: jzheaux

Good question, @mbhave. The SAML 2.0 spec (link 412) allows for HTTP-Artifact as well, but it's a less common binding these days for that step in the handshake. Older providers like Tivoli and Shibboleth support it, but newer ones like Keycloak and Auth0 do not.

The bindings that are commonly in use today for each SP-initiated message are:

  • AuthnRequest: HTTP-POST and HTTP-Redirect
  • LogoutRequest: HTTP-POST, HTTP-Redirect, and SOAP

Spring Security 5.3 supports both post and redirect for AuthnRequests, but does not support LogoutRequests.

As a side note, it might be nice for the field to be of type Saml2MessageBinding.

Comment From: mbhave

Closed via https://github.com/spring-projects/spring-boot/commit/8659102650817b28b05b03d69c46e7a901860122

Comment From: jzheaux

Thanks!