Shibboleth Developers

["Scott Cantor" <>]

Peter Schober wrote on 2009-07-16:
> ACK. The more reason to try what we can to offer ways to end a
> session, SLO being part of it. If they still just walk away they only
> have to blame themselfs (and we will spell that out to our users).

That's where I more or less disagree, because I think giving confused people
more ways of doing something (especially ones that IMHO are themselves
confusing in their implications) doesn't really help. I think a single
approach is much more likely to work.

Note that with logout, pretty much by definition, the approach is not only
not singular, it's essentially different per-app. There's no single UI, and
there never will be.

> ACK. But from the above I don't think it's configurable to do this
> with the released IdP right now, is it?

No, I was speaking of what I would do were I faced with the necessity to
implement a technical measure for this. Again, I'm not in that situation at
the moment, nobody here seems to be of the opinion that this is something to
be solved technically.

> That's certainly a new perspective, so I'm glad I wrote the
> above. Like I said before: there seem to be quite a few more reasons
> why the project is "cautious" (to say the least) to go forward with
> SLO, and most of them are not documented anywhere.

I think I've mentioned the fact before that most of the post-SAML work
hasn't addressed logout. I suppose I can add that to the issues page.

But I'm not really cautious about it from a project point of view, it's
merely a question of priorities. Do I think the n-tier work is more
important? Better/more docs? Config improvements? Hell yes. And about a
dozen other things.

It's far better IMHO for somebody (Adam) who cares/wants this to do the
work. It's in turn incumbent on us to shut up about it, and make the
necessary API changes to allow it to plugin. Everybody wins.
 
> From what Adam wrote (one the IdP session expires the IdP loses the
> ability to sent back-channel SLO messages to utilized SPs whose
> session outlived the IdPs session) I thought if the IdP and SPs had a
> stable identifier for a principal a few of the problems related to
> back-channel SLO would be resolved easily: the IdP doesn't need to
> store session indices or transientIds or anything else with the
> session (or even longer than the session, see above). Neither does the
> SP, they just rely on the ePTId-NameID as a primary key to end
> someones session.

Oh, no, sorry, doesn't fix it. Once the IdP loses the session, it doesn't
know which SPs to notify. The identifier isn't the problem there. It isn't
going to just blindly notify every SP in the metadata. ;-)

-- Scott