Single Logout Channel="back"
Prog
programmierstudi at gmx.de
Thu Dec 4 14:36:25 EST 2014
Am 04.12.2014 um 00:39 schrieb Cantor, Scott:
> On 12/3/14, 10:48 PM, "Prog" <programmierstudi at gmx.de> wrote:
>> This extension circumvents the need for the client presenting the shib
>> context at every ServiceProvider (which would very likely require Third
>> Party Cookies to be accepted by the client as Scott Cantor just
>> mentioned) by having the IdP map all SP's the entity authenticated to to
>> the particular IdP session.
> That only works if every application is using the SP session, which is
> almost never the case. Otherwise you're back to needing a cookie to get
> the application handled most of the time.
Unless you are using backchannel communication between SP and
application which the post title suggested. As mentioned in an earlier
thread by Tomaz several other features have to be implemented in the
application (session mapping and soap communication).
>> Obviously the SP does not distinguish between
>> different IdP sessions (though it has the information to do so) but just
>> sends notifications for all sessions it carries for the particular
>> NameId. (If i missed any configuration detail here, i would very much
>> appreciate comments on that.)
> If you're talking about SessionIndex, the SP should only be looking at
> sessions that have the matching SessionIndex. If it's not present, then it
> will be looking at all of them. I don't recall if the SP includes the
> SessionIndex when it requests a logout, but I thought it did.
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.
>> Finally the IdP session in the client that
>> did NOT call the logout will still remain and authenticate the user to
>> the app again without asking for credentials. This might even be
>> considered as a feature but should always be kept in mind as a potential
>> security issue.
> That shouldn't happen unless the IdP end is broken (but since the V2
> design precludes all this from really working, I can't imagine that you
> haven't run into something along that line).
>
> -- Scott
>
Well, it is what i observed in our setup. 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). 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.
However i am going to analyze this session indexing stuff etc.
Thanks,
Michael
More information about the users
mailing list