Shibboleth Developers

[Kristof BAJNOK <>]

Hi Chad, all,

Adam is currently working on adding SLO support to the IdP (both back and 
front-channel, see previous posts for details). We know it's hard and it 
will never solve the logout problem in general. However we think there are 
use cases when it might be appropriate (kiosks for example).

Of course, we are aware that you would unlikely merge large bunches of code 
of somebody else. However, even if the outcome of the development will 
never be part of the official idp release (although that would be very much 
appreciated), we want to be aligned to your expectations, especially in 
those areas, which involve current or forthcoming idp functionality.

I just vaguely summarize Adam's points (as far as I understand them):

1. Sending SOAP requests is achievable by adapting commons-httpclient 
library's HttpConnection object to HTTPOutTransport. However it's not 
obvious, what kind of certificate checking is necessary, because the SP 
cert in the metadata is not necessarily the same as the one the SP answers 
HTTPS requests.

2. Treating NameID as a normal attribute is an issue, because you have to 
resolve all the attributes to the user to get the NameIDs for different 
SPs. Adam suggests storing the NameID (and SessionIndex) into the user's 
session.

3. Because back-channel requests may be blocked for a longer period of time, 
we need to ensure all logout code is reentrant.

4. For front-channel bindings we need to store logout contexts in 
StorageService. This context would store all SPs and corresponding 
NameID/SessionIndex values and the global status of the logout process as 
well. It needs to be looked up by each issued logout request SAML message 
ID, because LogoutResponse does not carry any other information, just the 
InResponseTo. We also need to set timeouts for the logout process.

We would really like to hear your opinion about this, because we don't want 
to diverge too far. Besides email, we are open to have a quick discussion 
over VC, if talking is preferred... :)

Cheers,
Kristof

PS: I think there is one serious concern about SLO which is not mentioned in 
[[SLOIssues]]. The SP's session can well outlive the IdP session (or 
wherever the user's nameIDs are stored). This results in logging out from 
fewer SPs than the user is actually logged in -- despite it is a Success. 
On the other hand the IdP cannot store the association forever. If the SP 
session could be limited to be shorter than the IdP session, that would be 
sufficient, but AFAIK there is no limit in the SP session lifetime provided 
that there is regular user activity.
-- 
Kristof BAJNOK
Systems Engineer / Middleware
NIIF / Hungarnet
Hungary