RelayState value and SLO?

[Cantor, Scott]

> The vendor is expecting that the logout process to redirect the user upon
> logout to a location specified in the RelayState.
> Is this a reasonable expectation?

RelayState has to be returned to the system with the response message, and we do. We do not allow for SPs to regain control of the UI, and if they perform a redirect at the end it's just swallowed by an IFRAME through which the response is being sent. We can't guarantee a response to the SP while still being able to report the SLO results to the user unless we maybe opened a new window, and that wouldn't be acceptable to most people either.

The problem is that we want to guarantee a response gets sent back, but if we want to report the results to the user, then the user would have to either trigger the response (which means they won't) or we'd have to set a timer, and that would prevent the user from digesting the results (of course the result is almost always "logout didn't work").

One reason we really have to make sure we respond is that there are broken systems that don't log the user out until they get the response. That's a major bug, but I know for a fact ADFS behaves that way in at least one deployment I have to interact with, and I suspect it may be an actual ADFS bug outright. So issuing the response is what I care about, not allowing the SP to render anything. The hidden IFRAME guarantees the response without depending on the user or compromising the reporting of the results.

If the SP needs its RelayState to finish its cleanup (though that would be a bug), we do include it.

> Or is this one of those implementation specific details?

The user interface of SLO isn't specified and therefore SLO in general is not fully interoperable at that level. My view is that the logout lands at the IdP, not the SP, and that's the way Marvin happened to implement it, deliberately or not.

-- Scott