Shibboleth Developers

[Adam Lantos <>]

Chad,

Backchannel and frontchannel SLO works pretty stable, frontchannel SLO
has some user interface like Andreas' solution. I'm refactoring,
cleaning up, and documenting the code now. After this is done, I will
separate the code (which part is general idp functionality - eg.
back-channel soap request stack - and which is SLO-only) and post
parts here for review process.

I should set up some demo application where you can view the plugin working.


For now I have these two changes to the idp codebase:

- [FEATURE] Add SAML2 NameID to ServiceInformation in Session.

https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=commitdiff;h=5a016768c42206a481d7981d8dfbb0daf780704d


- [BUG] Destroy indexed sessions correctly.
(https://bugs.internet2.edu/jira/browse/SIDP-333)

https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=commitdiff;h=59031076df727248a859dc7efa90d6fc73be7da3



thanks,
 Adam


On Wed, Aug 5, 2009 at 9:59 AM, Chad La 
Joie<>
 wrote:
> 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
>
>