Shibboleth Developers

[Chad La Joie <>]

Hey Adam, haven't heard much from you guys on the SLO stuff recently. 
Just wanted to note that if you need API changes be sure to submit 
something to JIRA.

Adam Lantos wrote:
> 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

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