Skip to content

Saml2 metadata includes SingleLogoutService even if saml2 logout is disabled / not configured #10607

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dvanbler opened this issue Dec 13, 2021 · 1 comment
Assignees
Labels
in: saml2 An issue in SAML2 modules type: breaks-passivity A change that breaks passivity with the previous release type: bug A general bug
Milestone

Comments

@dvanbler
Copy link
Contributor

Describe the bug
When accessing a saml2 relying party's metadata via the Saml2MetadataFilter endpoint, the downloaded metadata.xml file includes a SingeLogoutService element even though I have disabled or not configured saml2 logout.

To Reproduce

  • in a WebSecurityConfigurerAdapter, disable saml2 logout: http.saml2Logout().disable()
  • configure a saml2 relying party - do not specify any logout configuration for either the relying party or the asserting party.
  • configure the saml2 metadata filter
  • visit the saml2 metadata url and inspect the downloaded metadata.xml
  • notice that the metadata contains a SingleLogoutService element

Expected behavior
If saml2 logout is disabled, then relying party metadata should not advertise a single logout service.

@dvanbler dvanbler added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Dec 13, 2021
@eleftherias eleftherias added in: saml2 An issue in SAML2 modules and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 14, 2021
@jzheaux
Copy link
Contributor

jzheaux commented Jan 3, 2022

If saml2 logout is disabled, then relying party metadata should not advertise a single logout service.

While I see your point, we can't do as you describe. The reason is that the DSL is setting up a filter chain while the relying party registration is potentially coming from an external repository. It would be too aggressive for the DSL to try and configure your repository.

That said, I believe there are two issues that can be addressed here in order to help:

First, this ticket alerted me to the issue that the filter chain does not support a null single logout service location, which is a bug. Since each registration can represent a single tenant, it's reasonable to have saml2Logout enabled in the filter chain, but have single logout un-configured for certain tenants. I've created #10674 to address this.

Second, it's odd that any application not wanting to use the SAML 2.0 Logout feature would need to remove the single logout service location from each registration. Since it's optional, it should instead be provided. Let's use this issue to address this.

@jzheaux jzheaux added the type: breaks-passivity A change that breaks passivity with the previous release label Jan 3, 2022
@jzheaux jzheaux added this to the 5.7.0-M1 milestone Jan 3, 2022
jzheaux added a commit that referenced this issue Jan 3, 2022
@jzheaux jzheaux closed this as completed in 45b7fed Jan 3, 2022
jzheaux added a commit that referenced this issue Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: saml2 An issue in SAML2 modules type: breaks-passivity A change that breaks passivity with the previous release type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants