Add option to disable outbound logout
Description
Environment
Activity
Scott Cantor April 5, 2022 at 2:55 PM
This isn't functioning correctly because the second decision-state is still hard-wired to the presence of the extension in the request. Need to adjust flow to capture original decision in a flow variable to check later.
Scott Cantor June 11, 2021 at 6:39 PM
Documented.
Scott Cantor June 11, 2021 at 6:05 PM
Replaced dual decision states in flow with an action and some custom events.
Added idp.logout.assumeAsync, defaults false.
Tested and behaves as expected.
Scott Cantor June 9, 2021 at 10:25 PM
At the point in the SLO flow where the Async flag is checked, the inbound message context and metadata lookup is set up and complete. So in principal we could turn the current brute force check for the Async extension in the message into an action bean that does that and honors an option that implies Async if the inbound request's metadata has no logout endpoints. That doesn't appear to do radical harm to the flow.
Scott Cantor June 9, 2021 at 10:12 PM
A middle ground might be an option that "implies" the Asynch extension if there are no endpoints. Non-broken SPs don't need their metadata mucked with, but we could do something along the lines of how we support optional encryption based on key absence and treat no logout endpoint to use for the response as implying that the request, if one comes in, is asynch, even if it's not.
The drawback is no LogoutResponse back to the SP but the Shibboleth SP never cares about responses and I haven't run into one yet that did that wasn't so broken it couldn't be trusted anyway.
SPs routinely botch or outright ignore logout support and end up supporting SP to IdP logout either intentionally or accidentally but blow the other direction. The IdP config now doesn't distinguish these cases in the SAML2.SLO profile bean so when you enable logout and the metadata has endpoints, it just assumes both are supported.
Removing the metadata doesn't help because the IdP then breaks on the inbound logout requests because of no response endpoint to use. That could be fixed perhaps, but would be fairly invasive and complex to pull off. Without ruling that out, the other way to go is just to be explicit in the config and allow logout to be turned off in just the outbound direction with a flag on the profile bean (and by extension via a tag in the SP's metadata).