Shibboleth Developers

[Adam Lantos <>]

Sure, I clearly get it, that's why I said earlier that probably SLO is
not something you'd officially support nor recommend nor even include
it in releases for the time being.



On Sun, Jul 12, 2009 at 8:42 PM, Chad La 
Joie<>
 wrote:
> I know what Andreas did and we've expressed to him some concern with the way
> that iframes are handled in various browsers.  These concerns *may* be
> resolved in the current browsers, we don't know and we've asked for
> confirmation but as of yet have not received any.
>
> Also, to be blunt, I'm not much concerned with how the community reacts.
>  Not because I don't care but because in general people tend not to look too
> closely at something if it gets them to something that looks like what they
> want.  I'm very concerned about introducing something that may have security
> issues that deployers, in general, don't understand and so therefore make
> ill-advised decision about.  As has been pretty clear, I'd much rather say
> "no, there are real issues here so we're not doing that yet" rather than let
> them get bit by something later on down the road.
>
> Adam Lantos wrote:
>>
>> 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
>>>
>>>
>
> --
> 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
>
>