Shibboleth Developers

[Adam Lantos <>]

Chad,


On Wed, Jul 15, 2009 at 5:11 PM, Chad La 
Joie<>
 wrote:
>
>
> Kristof BAJNOK wrote:
>>
>> 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.
>
> This will always be true.  Putting in the Session, which I do agree is a
> good idea, doesn't get around that, its just a means of caching the value.

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.

FYI, I store nameid value and format in the ServiceInfo now, see commit
https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=commitdiff;h=5a016768c42206a481d7981d8dfbb0daf780704d

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.


>> 3. Because back-channel requests may be blocked for a longer period of
>> time, we need to ensure all logout code is reentrant.
>
> There are a number of issues related to this, reentrant code is only one of
> them.

Can you mention some?

Current profile handler code is also reentrant, there's no guarantee
to have only one service thread running at a time, especially with
bigger workloads.

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

Of course front-channel bindings are easier to handle from this perspective.


>> 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.
>
> You can do all of that and the profile handlers have access to the storage
> service.

yup, that's not too difficult to implement.

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

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.


> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Chad La Joie, Software Engineer, Net Services
> Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
> phone +41 44 268 15 75, fax +41 44 268 15 68
> ,
>  http://www.switch.ch
>
>


--
 Adam