Partial logout feature in upcoming IdP release

[Cantor, Scott]

On 1/20/13 9:46 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
>
>1) When you write "Due to a design limitation in this version"
>do you man this version of the enhanced logout functionality
>or a design limitation in the 2.x series of the IdP?

The latter.

>2) What does "...the IdP's ability to terminate all of the
>sessions associated with an identifier" mean?

I doubt I can explain it well in an email, it might take some time and a
whiteboard.

A logout request contains a NameID and a SessionIndex and that's how the
IdP is supposed to lookup the session. I can't do that reliably because
the cache doesn't allow for one name to be mapped back to more than one SP
at a time, so all but the last one that was saved off will fail with a "no
session found" error. (The IdP also didn't handle SessionIndex properly.)

>I thought that if I had two LoginHandlers, one using
>username/password and one using X.509, I still only had one
>session with the IdP--a session that tracked (possibly) two
>authentication events each with (most likely) distinct
>authentication durations. And once that IdP session either
>timed out due to inactivity or is otherwise terminated then
>any "time left" for the authentication duration of a
>LoginHandler did not matter because the IdP no longer "knew
>who I was".

I'm talking about the SAML logout concept of a session defined in the
standard. The sessions there are between the IdP and SP, and they're keyed
by NameID and SessionIndex.

What you're talking about is internal machinery to support SSO. That's
sort of between the user and the IdP, and the sessions I'm dealing with
are between the IdP and the SPs. They're not directly connected except
that they're both sets of data that are stored within the "master" IdP
session. The logout implementation is trying to track from the information
in the request to that session. That isn't based on any of your login
handlers.

>3) Suppose I have decided for my IdP to forgo all SOAP endpoints (no
>artifact resolution or attribute query), put multiple IdPs
>behind a load balancer that does SSL termination, and rely on
>"persistence/server affinity/sticky sessions" managed by the
>load balancer (no Terracotta or other techniques, and I am
>willing to pay the cost to the user when there is a fail over).
>
>Since you write "...over both SOAP and front-channel bindings"
>I should still be able to leverage this new limited logout functionality,
>correct?

Well, if you don't support SOAP, then it would only work over the
front-channel, but yes, it's subject to the same limitations as everything
else is. If you guarantee stickyness, then it would work and if not, some
of the logout requests would fail.

>I understand that the SP must support the front-channel
>binding of course.

Yes. An SP that's starting the logout process always favors that anyway
since it's more applicable.

-- Scott