Shibboleth Developers

["Scott Cantor" <>]

Adam Lantos wrote on 2009-07-15:
> There is no need to 'generate' nameidentifiers in Logout code. If the
> idp caches all the generated nameids in the session, logout code can
> use that instead of the resolver / nameid encoders.

You in fact must do this. There is no way you can derive the right NameID to 
send from the resolver, not when transients are involved. It will be 
different each time.

> Unfortunately OpenSAML XML interfaces are not Serializable, so I
> cannot put the NameID itself there - but I'm pretty sure I need to
> store all relevant attributes (namequalifier and spprovidedid as
> well). Probably I'll create a value object for that instead of storing
> bunch of Strings separately.

Yes, you must preserve the exact NameID.

> The requesting SP itself wouldn't wait for more than a couple of
> seconds, so timing is really critical (another idea is to launch more
> back-channel requests concurrently from a ThreadPool, but this would
> make things far more complex).

The SP is likely to have to wait a really long time if it expects this to 
work, so that's one of the reasons back-channel isn't something I think works 
well in practice. The IdP can spin up threads and make concurrent SOAP calls, 
but the original SP is stuck waiting on an answer.

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

That's what SessionNotOnOrAfter is for. It is not true that user activity 
indefinitely extends the session. That's a "lifetime" issue. Activity affects 
timeout behavior only. SessionNotOnOrAfter caps the session lifetime.

>>  No, if the IdP tells the SP to logout and the SP doesn't destroy the
>> session then the SP needs to report back that the logout failed.  If
>> the SP doesn't perform according to the spec there isn't anything we
>> can do about it.  If the session is already destroyed I think the SP is
>> simply supposed to respond with "Success".

Different issue (Adam explained it below), but I'd have to check on that. I 
think the SP probably returns an UnknownPrincipal error, which the IdP could 
check if it chose.

> Consider the following scenario:
> 
> 1, user logs into SP1 with very long session time
> 2, the idp session times out, information about SPs are lost
> 3, user logs into SP2
> 4, user triggers SLO
> 5, idp sends logout request to SP2
> 6, user gets SLO Success message, but the session at SP1 still lives.
> 
> However this is the same 'keep the user informed about what is
> happening when one logs in or out' thing.

Right, it's simply one of the many reasons I think logout doesn't work well. 
SSO is simply incompatible with kiosks, IMHO. Short timeouts together with 
disabling it are a much better approach than logout is.

-- Scott