Shibboleth Developers

[André Cruz <>]

On 2007/06/06, at 18:13, Scott Cantor wrote:

> But the back-channel case is the one that is very difficult.
>
> > What parameters will this method receive? Applications won't know  
> > NameIDs
> > so will we be able to specify one of the user's attributes to be  
> sent
> > as a parameter to the logout URL of the application? Or maybe the  
> REMOTE_USER
> > (this may raise privacy issues for some)...
>
> I don't know, that's the point.

Ok. So we've narrowed the problem of the single-sign-out to "what to  
send on the back channel request to the application"..

In the edge cases where the only attribute the application received  
is one that identifies a class of users (ex. member of Campus C) the  
nameID seems to be the only way an application can identify the user.  
But even if we expose it to the application so it can store it for  
later, can't this nameID change over time? I was under the impression  
that the CryptoShibID for example had a timestamp in it. So the IdP  
has to remember which nameid was sent to which application? Is this  
feasible? What if the TTL of the nameID expires before the  
application session does?

I understand that in these cases back-channel requests won't work but  
that's life. I don't think this is the normal case, normally the  
attributes that the application received allow the identification of  
the user if these attributes are sent on the back-channel request for  
the logout. If this is not the case then the application either: uses  
front-channel requests for logout (which has it's own set of  
problems, I know, but can work) or uses the SP session instead of a  
custom one.

What I mean is that maybe it's not possible to cater for every need,  
but most of the applications can be covered by one of this methods.

> > And as a lot of web applications need/want persistent sessions  
> > telling the users to close the browser is not an alternative.
>
> It is the only alternative, IMHO. Firefox does restore sessions,  
> but as long as SSL is used, it won't restore those, so generally  
> the advice still holds that shutting down the browser is both  
> reliable and essentially necessary anyway.

We don't use SSL in our applications. This decision was not mine but  
I have to live with it.

> As Chad always tells me, the point of logout is not to  
> comprehensively make it work, it's to clear the IdP session and if  
> you're lucky hit a couple of important locally controlled apps. I  
> can live with that, but I know from these conversations that people  
> are not hearing this. They just see logout and think "it will work".

I share Chad's opinions. You give the tools and we make the best of  
them. :)

> > Humm.. Search for something not using the key with the Storage  
> > API? I'm guessing you'll have to maintain another storage just to  
> > relate sessionids and nameids. :)
>
> That's the simple part, the problem is cleanup, making sure that  
> the mappings go away in conjunction with the session. It will  
> require backpointers between records.

What's the problem with having an expiration date (the same) on both  
the records? Then you would use the same process to expire both records.
Either way when you expire a session you have the nameID so you can  
delete the nameID->session record.. Maybe I'm missing something here...

Hope I've helped.
André