[OpenID] Logout Use Case

[Joost van Dijk]

Andrew Arnott wrote:
> Facebook as you know already has a form of single-sign-out.  When I log
> out of lala.com <http://lala.com>, I'm asked whether I want to log out
> of lala.com <http://lala.com> only, or both lala.com <http://lala.com>
> and Facebook.  This seems user friendly enough.  Although it leaves out
> the option of "log out of lala.com <http://lala.com>, Facebook, and
> everything else Facebook has helped you log into."

It may be interesting to take a look at the work Andreas Solberg has
done with SLO for identity federations (not OpenID, but SAML 2.0). He
has some real-world experience with SLO, including the "everything else"
scenario.

He has a demo online:

http://rnd.feide.no/content/how-create-a-fancy-iframe-demo-a-z

See the bottom of that page...

Cheers,

--
Joost van Dijk
SURFnet

> 
> One way this could be done is a simple form of OAuth, where the RP is
> the service provider and the OP is the consumer.  And the OP is thus
> authorized to remote log out the user.  It needs to be OAuth, or
> something like that, rather than a redirect because we can't have the OP
> sequentially redirect the user agent to every RP to log them out of each
> one.  The OP needs to remotely be able to log the user out.  
> 
> In fact, this has some other interesting scenarios as well.  If the user
> logs out of the OP, all RPs could be immediately logged out.  If the
> user's account was compromised, he could even remotely log into the OP
> and force log out /all/ RPs that have received positive assertions from
> that OP.  For this to work, the OP and RP would have had to agree on the
> maximum session length at the RP.
> 
> Thoughts?
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the
> death your right to say it." - S. G. Tallentyre
> 
> 
> On Wed, Sep 30, 2009 at 5:33 AM, Nate Klingenstein <ndk at internet2.edu
> <mailto:ndk at internet2.edu>> wrote:
> 
>     Steven,
> 
>     The real problem is that it's difficult to do it in a way that would
>     be certain to really clear all the various sessions scattered around
>     in a loosely coupled federated environment, and doing "something"
>     may be worse than doing "nothing", if "nothing" makes it clear that
>     the user need to terminate their browser session, for example.  If
>     some RP's don't go to the trouble of associating their application
>     sessions with the provider's sessions, or some OP's don't store the
>     list of RP endpoints, or if the browser gets stranded at some point
>     and is unable to clear a cookie, etc. etc. etc. then the deployer or
>     user's expectations may not be met.
> 
>     Unlike some others on the Shib team, I believe it's still important
>     to implement some form of SLO.  So long as deployers are aware of
>     the limitations, it will address some use cases(such as Jonathan's,
>     where they sound to have relatively tight control of the
>     environment), which is a win.
> 
>     It's not near the top of my list of things that I'd like to see
>     added to the OpenID protocol, but it's definitely feasible with the
>     right caveats, and there are many examples to learn from out there.
> 
>     Thanks for taking the time to read our piles of word salad,
>     Nate.
> 
> 
>     On Sep 30, 2009, at 9:56 AM, Steven Livingstone-Perez wrote:
> 
>         It does seem to me, particularly from reading those documents
>         that despite the technical difficulties outlined there is a
>         potential roadmap to SLO in OpenID - or at least a start :-)Need
>         defining (if not already in the process) and much would be
>         implementation recommendations rather than protocol.
> 
> 
>     _______________________________________________
>     general mailing list
>     general at lists.openid.net <mailto:general at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-general
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general