Non-standard extension to discriminate logout endpoints
Description
Environment
Activity
Wired up new functionality in logout flow. Tested successfully, it picks a "better" endpoint now based on the ACS if it's available.
Extended SAML2SPSession to store the ACS.
Added a BestMatchLocationCriterion to OpenSAML and extended the endpoint resolver base class to handle resolveSingle by evaluating it if present and returning the candidate that matches the longest substring from the front of the match criterion.
Unit test seems to be getting the right answer for the logout use case.
The complex part left is plumbing the ACS out of the LogoutPropagationContext somewhere that would be picked up by the deeply generic action that calls the resolver.
The related problem with this kind of case is that the session cache only stores one session per SP entityID, so when you have the typical case where there are multiple apps on a single Shibboleth SP with overrides, but one entityID, it's impossible to track them both for logout.
This is still worth doing in isolation because it doesn't make that worse, it just makes the one possible logout more likely to work. But I'll file a separate issue on possibly extending the cache API to track multiple sessions per entityID.
With my head back in this, I think what I had in mind (or at least what I'm thinking now) is the idea of storing off the vhost of the original SSO response when the SP session is stored. Then that would be used during logout to identify the "best" endpoint to use, which is likely to work a lot more often than just picking the first one.
To be honest when I went back and looked at this I couldn't remember why I thought it made sense, so I wouldn't bother until/unless I manage to remember.
If we always picked the first one (which we probably do), then if it's entityID-based all you'd have to do is put them in that order. So I don't know what I was thinking, and my guess is I was not.
Occurred to me that a conceivable extension to the logout code would be to implement a non-standard behavior of picking a SingleLogoutService endpoint to use based on matching the hostname in the endpoint to the entityID, when there are multiple choices to pick from.
It isn't technically meant to be possible to have multiple endpoints like this, but a lot of broken deployments try and get away with it to deal with virtual hosting, so if you're just picking an endpoint anyway, it may be worthwhile to have an option to pick based on a more likely heuristic.