You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The order of precedence for security.relyingparty.{id}.assertingparty.signlesignon.sign-request should be like this:
Use whatever the application declares sign-request to be
Use what comes back from the metadata-url query
Otherwise, default to true
But it is currently like this:
Use what comes back from the metadata-url query
Use whatever the application declares sign-request to be
Otherwise, default to true
The text was updated successfully, but these errors were encountered:
jzheaux
changed the title
SamlRelyingPartyAutoConfiguration ignores sign-request when metadata-url is used
Saml2RelyingPartyAutoConfiguration ignores sign-request when metadata-url is used
Jan 10, 2023
@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?
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.
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.
Related to spring-projects/spring-security#11818
The order of precedence for
security.relyingparty.{id}.assertingparty.signlesignon.sign-request
should be like this:sign-request
to bemetadata-url
querytrue
But it is currently like this:
metadata-url
querysign-request
to betrue
The text was updated successfully, but these errors were encountered: