Shibboleth Developers

[Scott Cantor <>]

André Cruz wrote:
> Ok. So we've narrowed the problem of the single-sign-out to "what to 
> send on the back channel request to the application"..

I think it should be avoided. For one thing, you're talking about 
issuing local loopback calls in the middle of the SOAP logout request. I 
can already see problems with clustered scenarios because a lot of times 
a server can't talk to itself through the balancer due to the network 
configuration.

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

The IdP always has to remember that information, you can't implement 
logout any other way. In theory an IdP can send a name change message in 
the middle of a session. The IdP isn't the problem, it's the SP that has 
to track all the changes. The IdP can't just change the name and start 
using it without sending a notification, though, it would have to use 
the original name in a logout request.

And the TTL nonsense should be gone now.

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

I suppose, but I'm not planning to try this yet. If somebody else wants 
to, they can write a logout service handler with the features they want. 
It definitely won't be in 2.0. Maybe later.

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

Non-SSL redirects are probably going to break when you try and do logout 
in the middle of an SSL frameset, or at the least you'll get a lot of 
warnings and dialogs, and probably it will end up breaking the chain of 
redirects at some point.

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

The expiration gets updated every request (timeout, remember?) I have to 
be able to efficiently track back to the NameID record so I can keep it 
from expiring too soon.

The reason I do the timeouts that way is to avoid having to physically 
read and write the whole session record just to touch the "last access" 
field.

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

Explicit deletion of a session is the simple case, it's the natural 
deaths where I either track back or end up with stale records. But that 
wouldn't be a terrible problem, it's the timeout updating that requires 
the back-pointers, plus handling name changes, although that's a pretty 
advanced case.

-- Scott