Related to https://github.com/spring-projects/spring-security/issues/11818

The order of precedence for security.relyingparty.{id}.assertingparty.signlesignon.sign-request should be like this:

  1. Use whatever the application declares sign-request to be
  2. Use what comes back from the metadata-url query
  3. Otherwise, default to true

But it is currently like this:

  1. Use what comes back from the metadata-url query
  2. Use whatever the application declares sign-request to be
  3. Otherwise, default to true

Comment From: philwebb

@jzheaux Do we need to change this when check?. Do you consider this a bug or something we should only change in 3.1. I wonder if it can break existing applications if we change things now?

Comment From: jzheaux

The behavior that this is causing it with configurations like this:

metadata-url: ...
sign-request: ...

The sign-request property is getting ignored. I think this would be surprising and would consider it a bug. IOW, it seems clear to me that if a property is specified, it would be expected for that property to get applied. That said, there is a workaround, which is to declare a RelyingPartyRegistrationRepository bean.

Do we need to change this when check?

Possibly. IIRC, the difficulty was it being able to tell the difference between whether the signRequest property in Saml2RelyingPartyProperties is set to true or is simply unset. It seems to me that this property would need to be a Boolean so that it can be null and it can be clear that the application left it unset.