Single Logout Channel="back"

[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