Shibboleth Developers

[Chad La Joie <>]

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