Single Logout Channel="back"

[Prog]

Thank you Scott for the hints about session indexing. In another older 
thread you suggested to decrease the lifetime of the NameID to a 
minimum. I have set the lifetime of the transientId to PT1S. Now we get 
different transients on every login, even for the same user. I bet, 
though i did not verify this far, that now we only have one 
shibsessionId being sent by an SP to the application on Logout consequently.

By now, i cannot fully estimate the implications by decreasing the 
lifetime that rigorously. Does it just inhibit attribute queries (we 
only push)? I found at least that session mapping for SLO purposes seems 
not to be implied. Furthermore i am going to switch to crypto 
transients, which you mentioned as being another alternative.

Could you by chance point me to other/similar 'surprises' we might run 
into, which are not mentioned on the wiki?

By usage of the NIIF extension, customization of the participating 
services where necessary (get rid of app sessions/logout 
implementation), adjusting all session lifetimes so that a given IdP 
session always survives related SP sessions which in turn always survive 
related app sessions (at least by a remaining reference in the SPs 
cache), the usage of ultra-short living transients and logout 
communication via backchannel the IdP-initiated global logout seems to 
work very well. Of course everything depends on the existence of the IdP 
cookie on logout initiation and integration of new services as well as 
federating with other IdPs or clustering our IdP now have additional impact.

Regards,

Michael


Am 04.12.2014 um 20:51 schrieb Cantor, Scott:
> On 12/4/14, 7:36 PM, "Prog" <programmierstudi at gmx.de> wrote:
>
>
>> Hmm, i guess i have to dig deeper into what is requested and responded
>> and maybe analyze the sources. The documentation on session indexing
>> seems to be very poor or i did not find out where or what to look for.
> I thought it automatically sent the SessionIndex to the IdP, and I just
> verified that it does. It's not configurable. (That assumes the IdP sends
> a SessionIndex up front, which Shibboleth always does. If not, of course
> the SP won't send one in the logout request.)
>
>> Well, it is what i observed in our setup.
> Unless you rebuilt the session cache layer, which you couldn't do in a
> plugin alone, you can't support logout properly. It's really that simple.
> You can get around it by only using transients and never sending the same
> NameID twice, otherwise it's *going* to fail. It just does not track
> NameID/SP mappings properly, they get overwritten with whatever was most
> recent. That's what breaks all this.
>
> This is true even if the activity is in separate IdP sessions, so the end
> result is that you'll "orphan" the original IdP session from being seen by
> the logout if the SP sends a logout request later against a NameID that
> matches one issued in both the IdP sessions.
>
>> User clicks NIIF global IdP
>> logout. IdP sends Logout Requests to all SPs the user has been
>> authenticated to. SPs delete all sessions for the particular NameId
>> (observed, but not sure about that, see above).
> The SP's Logout handler runs inside an applicationId at the SP, and the
> sessions it terminates have to be for that applicationId, I believe. I'd
> have to check more. That complicates things enormously, when there are
> multiple applicationIds in the picture.
>
>> SPs notify applications
>> via backchannel if needed and respond to the initial logout request by
>> the IdP. In case the particular same NameId (=subject) has sessions in
>> another client, every session except the IdP session for that client
>> will be logged out by the procedure just described. So the user will not
>> be logged out from the IdP in that client. This might be weakness of the
>> NIIF implementation which i think could easily log out all IdP sessions
>> for a particular NameId, if this is what someone wants to achieve.
> I don't think you can achieve that, per my comment above. Essentially, the
> only way you could ever hit multiple IdP sessions is if they share a
> NameID with an SP, and if they did, the session cache can't track it
> accurately.
>
> -- Scott
>