Single Log Out with multiple domains

[Oleg Kostenko]

Hello,

I have a web application which is spread across two different domain 
names, let's say domain1.com and domain2.com.

I successfully implemented SSO in this application with Shibboleth, 
however I'm not sure how to properly implement SLO.

Let's assume the following scenario:

1. The user navigates to domain1.com and authenticates via an IdP.
2. Then he switches to domain2.com. The SP negotiates with the IdP and 
the user is automatically authenticated, because there's already a valid 
IdP session.
3. Then he switches back to domain1.com and initiates a logout. The SP 
terminates its session and sends SAML logout request to the IdP.

This results in the following error:
     opensaml::FatalProfileException at 
(https://domain1.com/Shibboleth.sso/SLO/Redirect)
     Status: urn:oasis:names:tc:SAML:2.0:status:Requester
     Sub-Status: urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal

And in IdP logs we can see:
     WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error 
event occurred while processing the request: SessionNotFound

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.

I've considered several possible solutions:

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. 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.

2. Share the SP session cookie between two domains (for example, by 
sending it as a GET-parameter of a redirect). This seems to perfectly 
solve the problem, but I'm concerned whether it is a correct way to do 
this. I have to rely on undocumented behaviour of Shibboleth, such as SP 
cookie name generation algorythm and the fact that the cookie can be 
shared across domains.

3. I suspect it is possible to solve this by configuring IdP (maybe 
something related to nameID generation?), 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.

4. Implement the application logic so that the login and logout requests 
to IdP are always issued from the same domain. This seems to be an 
unreasonably complex solution, as it assumes creation of a secondary SSO 
system in the application.

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?). I could remove 
SLO services from the SP metadata, but that would, in turn, result in SP 
not being able to receive logout requests at all, even if they were 
originated from some other SP or IdP itself.

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161202/1bfe38f9/attachment.html>