Verständnisfrage zur Reihenfolge beim Logout

[Martin Lunze]

Am Dienstag, den 30.07.2013, 15:08 +0200 schrieb Peter Schober:
> * Martin Lunze <martin.lunze at tu-dresden.de> [2013-07-30 09:02]:
> > I have two service providers (SP) working together with one and the same
> > identity provider (IdP).
> 
> Are those SPs of the same version? Test with `shibd -v`.
> 

Normally, they should.
But it's better if i ask the system-administrators.

> > To test at which position the user is redirected to which URL at the SP
> > and IdP i have installed firebug for mozilla.
> > Since i am no expert in using firebug, i couldn't collect much
> > information.
> 
> Have a look at the Mozilla Firefox extension "SAML tracer". It will
> show you HTTP Request and Response headers, and will also decode
> front-channel SAML protocol messages for you. HTTP Requests containing
> SAML messages will show an orange "SAML" image and by clicking on one
> of those lines a "SAML" tab appears in the split window. There you
> will see the fully decoded logout request.
> I'm guessing that the SP staying on the IdP is sending the async
> extension, and the one returning to the SP is not.
> 

Thanks for this hint.
I will test it.

> > I also want to know how you are using logout.
> 
> Not.
> 
> You did read the SLOIssues topic in the wiki?
> 

Of course.

> (My) Short version: If you control all the SPs your IdP will ever
> federate with (and have an IdP that supports SLO) you can very likely
> make SLO work reliably. Then you add another SP management cars about
> (which of course does not support SLO) and your "single" logout breaks
> down.
> 

Principally we want to connect local SP, which are located at our
university, to our IdP and therefor we require they implement the SLO
like we want.

> Many have cooked up various ways to log out the subject from select
> few local ("important") systems, potentially leaving any other SPs
> (the institution cares less about) stranded with sessions. In addition
> they may or may not tell the subject to close the browser, fingers
> crossed that this will do something useful.
> 
> > If i am right, the user is only logged out at IdP side and at the
> > side of the SP, which has initiated the logout and NOT logged out
> > from all SP he logged in.
> 
> When using the 2.4 IdP and enabling an SLO binding in metadata, yes.
> 

Okay. The most important point for us is, that the session on the side
of IdP will be closed, so that if people leave their workplace and don't
lock their computers, nobody else can hack "all" SP which are connected
to our IdP.

I think therefor it should be good enough.

> > Thats why i would prefer that the logout-site of the IdP is the last
> > site the user gets shown, in every case!
> > So he can see where he is/was logged in and has the opportunity to log
> > out from the other SP.
> 
> Just out of curiosity: How exactly would you expect an average
> computer user to do that, log out from those other SPs? Based on the
> entityIds of those SPs (or display names, if you changed logout.jsp
> sufficiently)?

At the moment i show them only a message at the logout.jsp explaining,
they are logged out from IdP but could be logged in in other SP.
Then i list all entityIds of the SP's the user has logged in during his
last session and tell him to check if all sessions are closed or not.

I am waiting for shibboleth 3 and maybe sometime there will be a rule in
the dfn-aai which requires that everybody has to include SLO :)

I know at the moment there is no perfect solution :-/

> -peter
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 
MfG
Martin Lunze

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
Trefftz-Bau, HRSK 151
Zellescher Weg 12-14
01062 Dresden

+49 351 463-35881
martin.lunze at tu-dresden.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6160 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20130801/4bb69523/attachment-0001.bin