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
Describe the bug
Each RelyingParty can specify its own logout URL properties, but doing that results in having to change the RequestMatcher used by Saml2LogoutRequest/ResponseFilter manually to match those different URLs. It could be confusing to allow multiple relying parties to be defined with different locations that ultimately have no effect (or an undefined effect) on the behavior.
In both the logout request and logout response filters, the payload validation is going to check the URI against the registration's configured URI anyway. With that said, we should resolve the RequestMatcher based on what's in the RelyingPartyRegistration.
Expected behavior Saml2LogoutRequestFilter and Saml2LogoutResponseFilter should consider singleLogoutServiceLocation and singleLogoutServiceResponseLocation in the RequestMatcher.
Both the login filters and logout filters match on requests that contain either SAMLRequest or SAMLResponse as a parameter. If the Logout filters match on any request, they will try to process requests for login as well, causing problems.
marcusdacoregio
changed the title
SAML 2.0 Logout filters should match on any request by default
SAML 2.0 Logout filters should consider RelyingPartyRegistration logout properties
May 10, 2022
With that said, we should resolve the RequestMatcher based on what's in the RelyingPartyRegistration.
Though it's likely that the path for the filter and the path in the registration will be the same, it seems valuable to consider scenarios when they could reasonably be different. One example is if a legacy URL, like /saml/SingleLogout from Spring Security SAML Extension, is forwarded to /logout/saml2/slo. In that case, the RP metadata still says that the endpoint is /saml/SingleLogout.
Whether this is the ideal way to do something like that remains to be seen. I think it would be good to complete spring-projects/spring-security-samples#76 before proceeding with this ticket.
Another scenario to consider is that sometimes the logout link is clicked when the user is already logged out. In this circumstance, the relying party must be looked up from the URL in order to still provide a logout response to the IdP.
Describe the bug
Each
RelyingParty
can specify its own logout URL properties, but doing that results in having to change theRequestMatcher
used bySaml2LogoutRequest/ResponseFilter
manually to match those different URLs. It could be confusing to allow multiple relying parties to be defined with different locations that ultimately have no effect (or an undefined effect) on the behavior.In both the logout request and logout response filters, the payload validation is going to check the URI against the registration's configured URI anyway. With that said, we should resolve the
RequestMatcher
based on what's in theRelyingPartyRegistration
.Expected behavior
Saml2LogoutRequestFilter
andSaml2LogoutResponseFilter
should considersingleLogoutServiceLocation
andsingleLogoutServiceResponseLocation
in theRequestMatcher
.Related:
The text was updated successfully, but these errors were encountered: