[OpenID] What about Logout?

Breno de Medeiros breno at google.com
Wed Apr 8 17:56:30 UTC 2009


On Wed, Apr 8, 2009 at 10:42 AM, Peter Watkins <peterw at tux.org> wrote:
>
> If a user is authenticated to RP1 by virtue of an assertion issued by the
> OP, then what's the value of "logging the user out" of RP1 if the user is
> still logged in to the OP? All the user need do in many OpenID use cases is
> click a few links to have the OP issue new assertions to log the user back in
> to RP1 -- so being logged in to the OP is pretty darn close to being logged
> in to every RP that accepts the OP's assertions. There might be some ancillary
> benefit to the logout-of-RP-only model. For instance, if the RP site has
> some webapp security flaws *and* the OP login assertion process has good
> protection against attacks like CSRF, then logging out of the RP would help
> protect RP assets against attacks on the flawed RP app. But it seems a
> little screwy in a federated identity/authentication system to say the user
> is logged out of the RP if the OP still recognizes the user as logged in there.

This problem is best addressed by use of PAPE extension for
re-authentication. OPs that support PAPE will allow RPs to require
that the user re-authenticates after a certain interval. Logging the
user out from the OP is not a fine-grained enough approach to this.

If your RP is highly secure sensitive you should restrict it ti OPs
supporting the PAPE extension.

>
> A good logout mechanism, and I think SAML had this but my memory is rusty,
> would also have an RP-OP exchange mechanism for the RP to provide to the OP
> some information (URL with a nonce) about how the OP can let the RP know that
> the user has logged out of the OP. Users should have the option of logging
> out of the OP and effectively terminating their sessions at RP1 and RP2
> without their user agent interacting with RP1 or RP2.
>
> Giving the OP a mechanism to log a user out of all RPs would also introduce
> the possibility of realtime OP assertion revocation. Suppose Google is your
> OP, and through analysis of your traffic to Gmail or maybe the Urchin servers
> Google ascertains that your system has been compromised with some malware.
> If the Google OP could send messages to each RP that had relied on an assertion
> about your identity, then Google could limit the malware's ability to damage
> your reputation or assests that you control via webapps that use Google OP
> assertions.
>
> Deron Meranda wrote:
>>> I think it might be a reasonable extension for the OP to provide
>>> a URL to the RP, which the RP can later redirect the user to when
>>> the RP's session is terminated.  This OP-provided URL can
>>> then do whatever the OP wants; such as offering to log the
>>> user out of the OP, etc.  Of course there should be no automatic
>>> action!
>
> I think that's a good option to provide, too. Generally I think logout
> should happen at the OP, but certainly this suggestion is an improvement
> over the idea of logging out of RP1 without any easy way to log out of
> the OP.
>
> -Peter
>
> On Wed, Apr 08, 2009 at 08:08:31AM -0700, Peter Williams wrote:
>> In our environment, a user typically has several SSO sessions open at several RPs, each operating in different (sub) domains. Some subset of them (called them RP1  and RP2) may be sharing session management with Facebook - the OP.
>>
>> We have been told numerous times by folks in control of their business rules that any decision to logout the user from one RP1 MUST not log the user out of RP2. Assuming RP1 and RP2 are both talking to Facebook OP, RP2 must be able to continue to use its association to the OP after a logout exchange between RP1/OP, without the user having to re-authenticate (create a new IDP session).
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)



More information about the general mailing list