Shibboleth Developers

[Scott Cantor <>]

André Cruz wrote:
> I'm guessing this only applies to applications that maintain their own 
> sessions.

Yes, but that seems to be most of them. At OSU, I have been successful 
in discouraging developers from using insecure application server 
session mechanisms as a security vehicle, but I don't think that's 
common. And it's becoming less common here, admittedly.

> These will have to implement a remote method that can be 
> invoked to logout a specific user/session.

There are both front and back channel cases. For a front channel, the 
application has to expose an endpoint to redirect to and then send the 
user back, basically just a copy of how the logout process works in the 
first place. This isn't terribly hard, but it's also prone to breaking 
the UI, and it's also impossible to do a UI for this in an accessible 
manner, something a lot of places are pretty keen on.

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. Either we tell it that a logout occurs, 
or the application has to ask, arguably on every single request, which 
clearly doesn't work.

But there are cases where only the NameID could possibly be used as a 
unique hint, and I don't see applications bothering to maintain the 
information needed; if they were doing that, they'd just as well be 
using the session cache.

More likely it's a polling approach and the application has to 
periodically check to see whether the session is still alive. Or more 
likely just not expose the SOAP logout facility. I think that's probably 
the best answer, there just isn't any way to do certain things well, 
that's why the front-channel option exists.

> Only if the applications want to participate in the Single Logout will 
> they need to implement it.. I don't have a problem with this.

And I don't think most applications will do so. But this is old ground, 
there's no point in rehashing it. You're not going to change my mind and 
I probably can't change yours.

> Other than the Application-maintained sessions what's the problem with 
> the IdP notifying the SPs that a certain user's sessions are to be 
> terminated?

Nothing other than confusing the hell out of the user (you're kind of 
logged out of some stuff, but not all), but that's begging the question.

> For me Single-Sign-On is just as important as 
> Single-Sign-Out. It does not make sense to deploy one without the other. 

All I can tell you is that I disagree with you. And I feel compelled to 
point out that Cardspace does not support logout. As we move toward a 
client-centric approach to SSO, you will see logout continue to 
disappear into the desktop.

> 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.

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".

> 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.

-- Scott