Logout Use Case
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
Logout Use Case
by Jonathan Coffman-2
::
Rate this Message:
Hey there folks, I'd like to start a conversation around how OpenID might be able to facilitate logout more gracefully. Should I enter my use-case onto the wiki somewhere?
Just to whet your whistle, here's a summary: - We're using OpenID for federated identity and SSO for a network of micro-sites. - Some of those micro-sites live at the same domain, but in different directories, and utilize a multitude of web technologies (php, flat-files, django, plone, etc) - Other micro-sites are on their own domains. Because a large percentage of our RPs (the micro-sites) actually live on the same domain, but on varying infrastructure and technologies it's confusing to the user that when they log-in, they're logged in across the network -- but when logging out they're only logged out from an individual RP. As far as potential solutions, we've come up with a couple of different technical options: - RP1 sends a logout command to the OP which destroys the RP1 and OP session. However, the user may still be logged in locally at RP2 (RP2 could also poll to check if the user is still logged in at the OP at a set schedule) or - OP maintains a list of RPs the user is currently logged in to and upon RP1 killing it's local session and pinging the OP, the OP then 'pushes' a message out to all of the other RPs instructing them to kill the user's session. - Jonathan Coffman @jdcoffman _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Steven Livingstone-Perez
::
Rate this Message:
The second solution seems the most likely to meet real
requirements so long as this OpenID signout could carry an enumerable set of
endpoints that could be easily called to close the session.
/steven
From: jonathan.coffman@...
Sent: Tuesday, September 29, 2009 11:43 PM
To: general@...
Subject: [OpenID] Logout Use Case Just to whet your whistle, here's a summary:
- We're using OpenID for federated identity and SSO for a network of
micro-sites.
- Some of those micro-sites live at the same domain, but in different
directories, and utilize a multitude of web technologies (php, flat-files,
django, plone, etc)
- Other micro-sites are on their own domains.
Because a large percentage of our RPs (the micro-sites) actually live on
the same domain, but on varying infrastructure and technologies it's confusing
to the user that when they log-in, they're logged in across the network -- but
when logging out they're only logged out from an individual RP.
As far as potential solutions, we've come up with a couple of different
technical options:
- RP1 sends a logout command to the OP which destroys the RP1 and OP
session. However, the user may still be logged in locally at RP2 (RP2 could also
poll to check if the user is still logged in at the OP at a set schedule)
or
- OP maintains a list of RPs the user is currently logged in to and upon
RP1 killing it's local session and pinging the OP, the OP then 'pushes' a
message out to all of the other RPs instructing them to kill the user's
session.
- Jonathan Coffman
@jdcoffman
_______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Steven Livingstone-Perez
::
Rate this Message:
The second solution seems the most likely to meet real
requirements so long as this OpenID signout could carry an enumerable set of
endpoints that could be easily called to close the session.
/steven
From: jonathan.coffman@...
Sent: Tuesday, September 29, 2009 11:43 PM
To: general@...
Subject: [OpenID] Logout Use Case Just to whet your whistle, here's a summary:
- We're using OpenID for federated identity and SSO for a network of
micro-sites.
- Some of those micro-sites live at the same domain, but in different
directories, and utilize a multitude of web technologies (php, flat-files,
django, plone, etc)
- Other micro-sites are on their own domains.
Because a large percentage of our RPs (the micro-sites) actually live on
the same domain, but on varying infrastructure and technologies it's confusing
to the user that when they log-in, they're logged in across the network -- but
when logging out they're only logged out from an individual RP.
As far as potential solutions, we've come up with a couple of different
technical options:
- RP1 sends a logout command to the OP which destroys the RP1 and OP
session. However, the user may still be logged in locally at RP2 (RP2 could also
poll to check if the user is still logged in at the OP at a set schedule)
or
- OP maintains a list of RPs the user is currently logged in to and upon
RP1 killing it's local session and pinging the OP, the OP then 'pushes' a
message out to all of the other RPs instructing them to kill the user's
session.
- Jonathan Coffman
@jdcoffman
_______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Nate Klingenstein
::
Rate this Message:
Steven & Jonathan,
Remember that HTTP user-agent sessions are persisted in several ways: some are entirely client-based state in the form of cookies, while others primarily manage server-side state. Pushing out messages to the RP is not necessarily sufficient to either deal with client-based state or deal with session state persisted by the applications themselves once a login context is established via OpenID. I suggest you take some time to read about the way Shibboleth thinks about federated SLO. https://spaces.internet2.edu/display/SHIB2/SLOIssues https://spaces.internet2.edu/display/SHIB2/SLOWebappAdaptation Take care, Nate. On Sep 29, 2009, at 10:53 PM, Steven Livingstone-Perez wrote: > - OP maintains a list of RPs the user is currently logged in to and > upon RP1 killing it's local session and pinging the OP, the OP then > 'pushes' a message out to all of the other RPs instructing them to > kill the user's session. _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Steven Livingstone-Perez
::
Rate this Message:
Thanks for that Nate.
So it does seem a push (via OP callback for apps that have a tcp channel open)/pull (RP polling when it's a client that does not... particularly useful when inside the firewall) approach would need to be used. 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. This may also be useful: https://wiki.aai.niif.hu/index.php/ShibIdpSLO /steven http://livz.org -------------------------------------------------- From: "Nate Klingenstein" <ndk@...> Sent: Wednesday, September 30, 2009 1:05 AM To: "Steven Livingstone-Perez" <weblivz@...> Cc: "Jonathan Coffman" <jonathan.coffman@...>; <general@...> Subject: Re: [OpenID] Logout Use Case > Steven & Jonathan, > > Remember that HTTP user-agent sessions are persisted in several ways: > some are entirely client-based state in the form of cookies, while others > primarily manage server-side state. Pushing out messages to the RP is > not necessarily sufficient to either deal with client-based state or deal > with session state persisted by the applications themselves once a login > context is established via OpenID. > > I suggest you take some time to read about the way Shibboleth thinks > about federated SLO. > > https://spaces.internet2.edu/display/SHIB2/SLOIssues > https://spaces.internet2.edu/display/SHIB2/SLOWebappAdaptation > > Take care, > Nate. > > On Sep 29, 2009, at 10:53 PM, Steven Livingstone-Perez wrote: > >> - OP maintains a list of RPs the user is currently logged in to and upon >> RP1 killing it's local session and pinging the OP, the OP then 'pushes' >> a message out to all of the other RPs instructing them to kill the >> user's session. > > general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Nate Klingenstein
::
Rate this Message:
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@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Andrew Arnott
::
Rate this Message:
Facebook as you know already has a form of single-sign-out. When I log out of lala.com, I'm asked whether I want to log out of lala.com only, or both lala.com and Facebook. This seems user friendly enough. Although it leaves out the option of "log out of lala.com, Facebook, and everything else Facebook has helped you log into."
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@...> wrote: Steven, _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Joost van Dijk
::
Rate this Message:
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@... > <mailto:ndk@...>> 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@... <mailto:general@...> > http://lists.openid.net/mailman/listinfo/openid-general > > > > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > general@... > http://lists.openid.net/mailman/listinfo/openid-general _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Andrew Arnott
::
Rate this Message:
That's a cool idea. The OP sending an iframe that logs the user agent out of all the RPs sounds cool, and simpler than the OAuth idea.
-- 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 7:33 AM, Joost van Dijk <joost.vandijk@...> wrote:
_______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
|
|
Re: Logout Use Case
by Nate Klingenstein
::
Rate this Message:
Andrew,
This is one of the ways that Shibboleth has considered doing it. Many universities' local web SSO packages work this way. It's a great way to do mechanical front-channel logout, but you do have to rely on RP's, OP's, and applications to do the right thing, and that really is where the bulk of the problem lies. In an environment like Facebook's, there's only one identity source and a lot more control over the apps. OpenID should be able to define a fairly simple profile to plumb such a logout interface, and SAML offers a pretty good example. Thanks, Nate. On Sep 30, 2009, at 2:36 PM, Andrew Arnott wrote: > That's a cool idea. The OP sending an iframe that logs the user > agent out of all the RPs sounds cool, and simpler than the OAuth idea. _______________________________________________ general mailing list general@... http://lists.openid.net/mailman/listinfo/openid-general |
| Free embeddable forum powered by Nabble | Forum Help |
