Shibboleth Developers

[Adam Lantos <>]

Chad,

I fully agree with you regarding the issues SLO introduces, but I've
also seen what Andreas achieved with SLO support in SimpleSAMLphp and
IMO Shibboleth should try that way, too. Even if it won't ever be
officially supported, I think we can craft together some experimental
code (maybe supporting only some of the bindings, eg. only
front-channel bindings as Andreas did[1]) to see how the community
reacts.


[1] 
https://rnd.feide.no/content/front-channel-single-logout-deployment-profile



On Sun, Jul 12, 2009 at 8:05 PM, Chad La 
Joie<>
 wrote:
> I'll have to discuss it with Scott.  I haven't studied the SLO profile
> enough to say for certain what the IdP needs to retain.  I probably won't
> spend much time doing so until people can propose some real solutions to the
> issues that are out there.  The consistent willingness to screw the user by
> ignoring the issues is, I think, very unfortunate.
>
> Adam Lantos wrote:
>>
>> Chad,
>>
>> Do you mean the transient nameid is not intended to remain the same as
>> long as the user is in the same session? That's not what I'd normally
>> expect. What happens if the SP decides to issue an AttributeQuery
>> after a few minutes? Will it fail, because the NameID is just -
>> expired?
>>
>> The NameID is a required element in the LogoutRequest. If you use
>> transient NameIDs with that sematics it would imply that you must put
>> a different NameID in the LogoutRequest, that's just weird. Or did I
>> overlook something in the SAML specs? Maybe I don't understand the
>> importance of SessionIndex (so far I thought that's an optional
>> identifier to support multiple sessions for the same principal;
>> LogoutRequest specs say that by omitting this you can terminate all
>> sessions for the principal which is identified by the NameID the
>> request carries).
>>
>>
>>
>> On Sun, Jul 12, 2009 at 6:30 PM, Chad La 
>> Joie<>
>> wrote:
>>>
>>> In most cases this won't work.  The large majority of people use a
>>> transient
>>> name identifier which is only good for a couple minutes.  By the time a
>>> user
>>> goes to log out the IdP will have forgotten it already.  Instead what
>>> should
>>> be used is the session index.  Since SLO isn't supported yet I doubt
>>> that's
>>> kept around in the ServiceInformation but that would be the logical place
>>> for it.
>>>
>>> Adam Lantos wrote:
>>>>
>>>> Chad, Dharam,
>>>>
>>>> I'm also in the middle of some experimental work with slo.
>>>> The first part was pretty straightforward, I can get the list of SPs
>>>> user is logged into from the idp session. But I cannot easily access
>>>> to the nameid. Right now I'm hackig it around and have the
>>>> attributeresolver to resolve nameid for the principal and the given
>>>> SP. But the code is really disgusting, and pretty much inefficient as
>>>> attribute resolver resolves all attributes and I've found no other way
>>>> to circumvent the resolver.
>>>>
>>>> I'd love to see the NameID in the idp session (more specifically
>>>> inside the ServiceInformation objects). I've quickly ran through the
>>>> authentication/profile code, and found out that the ServiceInformation
>>>> is populated by the AuthnManager right before the NameId is computed
>>>> by the Profile Handler. So there's no easy way I can see to add NameID
>>>> to that.
>>>>
>>>> I believe the NameID should belong to the Session/ServiceInformation.
>>>> What do you think?
>>>>
>>>>
>>>> thanks,
>>>>  Adam
>>>>
>>>>
>>>> On Sun, Jul 12, 2009 at 4:56 PM, Chad La 
>>>> Joie<>
>>>> wrote:
>>>>>
>>>>> All of that information is stored in the Session (which relying parties
>>>>> a
>>>>> user has longed in to, when, which authentication method was used,
>>>>> etc).
>>>>>
>>>>> Dharam Veer wrote:
>>>>>>
>>>>>> Hi,
>>>>>> I need to support the SLO (even though it has many usability issues as
>>>>>> described in Shibboleth wiki). Have been going through the code and
>>>>>> not
>>>>>> able
>>>>>> to figure out certain things.
>>>>>>
>>>>>> - IDP is supposed to send the logout request to all the participants
>>>>>> who
>>>>>> have authenticated
>>>>>>
>>>>>> From code perspective if you could point out the method (or a way)
>>>>>> using
>>>>>> which I could see all the participants (service providers) who have
>>>>>> authenitcated ?
>>>>>>
>>>>>> Regards & thanks
>>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>> --
>>> 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
>>>
>>>
>
> --
> 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
>
>