Single Log Out with multiple domains

[Cantor, Scott]

On 12/2/16, 3:40 AM, "users on behalf of Oleg Kostenko" <users-bounces at shibboleth.net on behalf of oleg.kostenko at actimind.com> wrote:

> As far as I understand, on the step 2 of the above scenario the SP session record in the IdP session storage is
> updated with a new transient nameID, and the old nameID is discarded. As a consequence, the logout request
> issued from domain1.com cannot be satisfied, as it uses the old nameID.

The IdP tracks only one SPSession per entityID per IdPSession. That will not be changed.

> 1. Create two logical SPs for the two domains by using ApplicationOverride with different entityIDs. While this
> generally solves the problem, the drawback is that the two domains no longer act as a solid application from the
> IdP point of view.

Separate entityIDs is necessary for SAML logout anyway, see below.

> During SLO, IdP asks the user if he wants to log out from another domain. This is unwanted behavior: the logout
> from another domain must be automatic and transparent.

You don't control the experience of logout. You can talk about what Shibboleth does and then if the IdP is not Shibboleth the experience may be somethiing else entirely. And Shibboleth itself will change over time and people can and do change their logout behavior to work how they choose. You can't control that from the SP.
 
> 2. Share the SP session cookie between two domains (for example, by sending it as a GET-parameter of a
> redirect).

You don't need to send it in a redirect and doing that would be insecure. You can control the cookie domain with the cookieProps setting to get shared semantics across vhosts in a common domain. That probably is your best choice.

> 3. I suspect it is possible to solve this by configuring IdP (maybe something related to nameID generation?),

It's not.

> but IdP in general is not something I have control over. I need to create a solution that doesn't require changes
> to IdP configuration in most situations.

Then you definitely need to accept that the UI at the IdP is not subject to your control, per my comment above.

> 5. Don't use SAML logout at all, and instead, redirect to the IdP's proprietary logout handler. The problem is
> that IdP will try to propagate logout to every SP in it's session cache, including my SP. It would send logout
> request to the first SingleLogoutService found in the SP metadata, but if the latest login request was from
> another domain, the logout request would fail (nameID mismatch again?).

The SP itself does not support what you're doing either. It cannot handle logout to specific vhosts when an entityID spans two or more of them, for the simple reason that SAML can't handle it. There was no allowance for specifying the SLO endpoint in the LogoutRequest, so that was a limitation that never got addressed in the spec and it happens to prevent this kind of thing from working.

> I conclude that my scenario is rather uncommon and thus unsupported in Shibboleth, so any solution would be a
> compromise. Am I correct in my conclusion, or am I missing something here?

You've identified 3-4 different things that are essentially reasons why this doesn't work, spanning SAML itself and both Shibboleth products. If it makes you feel better, you've done a very astute analysis of the various cases.

-- Scott