<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<div class="moz-forward-container">
<div class="moz-forward-container"> <br>
I have a web application which is spread across two different
domain names, let's say domain1.com and domain2.com.<br>
<br>
I successfully implemented SSO in this application with
Shibboleth, however I'm not sure how to properly implement SLO.<br>
<br>
Let's assume the following scenario:<br>
<br>
1. The user navigates to domain1.com and authenticates via an
IdP.<br>
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.<br>
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.<br>
<br>
This results in the following error: <br>
opensaml::FatalProfileException at (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://domain1.com/Shibboleth.sso/SLO/Redirect">https://domain1.com/Shibboleth.sso/SLO/Redirect</a>)<br>
Status: urn:oasis:names:tc:SAML:2.0:status:Requester<br>
Sub-Status:
urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal<br>
<br>
And in IdP logs we can see:<br>
WARN [org.opensaml.profile.action.impl.LogEvent:76] - An
error event occurred while processing the request:
SessionNotFound<br>
<br>
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.<br>
<br>
I've considered several possible solutions:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I conclude that my scenario is rather uncommon and thus
unsupported in Shibboleth, so any solution would be a
compromise.<br>
<br>
Am I correct in my conclusion, or am I missing something here?<br>
<br>
</div>
</div>
</body>
</html>