Provide a way for consumer to return back to site after logout

[John O'Brien]

When logging out from the consumer application using https://login.launchpad.net/+logout we want to redirect back to the consumer application.

Currently the user sees a login screen and when they login, they get the launchpad login "Welcome" page where they can edit their profile.

[Joshua Hoover (joshuahoover)]

Assigning to Elliot so he can reassign to the best person to work on this.

[Elliot Murphy (statik)]

This cannot be fixed on the ubuntu one side until the SSO provider accepts a query string or other mechanism in order to redirect back to the original site after logging out of SSO. I've mentioned to stuart metcalfe that this is a feature that we would like at some point. I consider this feature request part of SSO branding.

[Martin Albisetti (beuno)]

This is important for us to give the sense of security to our users.

[Stuart Metcalfe (stuartmetcalfe)]

Using this bug to track an initial implementation which will redirect back to the referring site if it's trusted by us. Tentatively assigning to the 2.7.0 release but will confirm details of the planned approach before committing to that.

[Stuart Metcalfe (stuartmetcalfe)]

Here's a first proposal for discussion. This should be compatible with the planned logout broadcast functionality.

Action path: /+logout

Required query string params:

 * return_to=<URL>. If <URL> doesn't exactly match a known trust root (with
    auto-redirect enabled - this is how we're defining full SSO sites) or the
    user hasn't actually logged in to the requesting site within the defined
    session period (see below), the user will see the same result as if the
    params weren't passed (currently that they are logged out but will stay on
    the SSO site and are notified of the logout). If HTTP_REFERER is sent by
    the browser, its hostname must also match <URL>'s hostname. The return will
    not fail if HTTP_REFERER is undefined, it's just an extra check if
    available.
 * user=<uid> (This is the last segment of the user's OpenID URL. eg: 1a2B3c4
    from https://login.ubuntu.com/+id/1a2B3c4). If <uid> doesn't match the
    current SSO session user, the following message will be displayed:
    "<sitename> is attempting to log you out of your session but this isn't the
    account you used to log in. You may be logged in to other sites which we
    can't notify you about. Continue or cancel". 'Continue' continues with the
    workflow below, but for the current SSO user. 'cancel' redirects the user
    to the SSO main account page without logging them out of SSO. The
    message "Logout cancelled" is displayed to the user.

Logout behaviour for valid requests:

Assumptions:

 * trusted sites can have long sessions. let's say up to 365 days.
 * non-trusted sites have a shorter session lifetime of up to 30 days.

(both session lifetime values should be globally configurable on SSO)

Assume the user isn't logged in to other sites if they:

 * have only logged into the requesting site (and no other trusted sites) within
    the defined session duration for trusted sites.
 * haven't logged in to a non-trusted site within the defined duration for
    non-trusted sites.

The user is immediately logged out of SSO.

If the user isn't logged in to other sites, they are redirected back to the
specified return URL.

If the user is logged in to other sites, the following content is displayed """

You have been logged out of <sitename>. You may also need to log out of these
sites which you've used recently:

 * <sitename/URL>

Return to <sitename> (link to return_to)
"""

<sitename/URL> is a list of all sites (trusted and non-trusted) accessed within
the defined session durations, sorted by date order (most recent first), except
for the requesting site. Trusted sites display the printable name. Non-trusted
sites display the trust root. Both are links to the trust root which opens in a
new window/tab.

[Matthew Nuzum (newz)]

Hi, I appreciate the thoroughness of the specification. It's impressive to see the thought put into this.

Let's create three scenarios so that I can understand what will happen in each.

1. Rich is using one of the public university computers. He needs to log into the Ubuntu One interface to download a document to be printed for his next class. He logs in, successfully downloads and prints the file, and then he hits the logout button so that he can quickly get to class. Rich wants to confirm he is successfully logged out before leaving the workstation.

2. Emily visits a web-site that says she must authenticate using her Ubuntu SSO credentials. She clicks the login link, since she's already logged into other services with SSO it merely asks her if she wants to login. She chooses to and is sent to the new site. She decides this is not something she interested in using again and clicks the Logout button for the site. She doesn't want to log out of the other services she uses regularly.

3. Neil comes across a site that looks suspicious. It shows he is logged in and he doesn't like the idea and would prefer to browse this site anonymously. He hovers his mouse over the button and the status bar shows that the logout link points to the Ubuntu SSO service. (In fact, this is a malicious or mis-configured site and the link is not doing what it says it is doing). Neil clicks the link.

Do you think these three scenarios convey the range of features and concerns for this capability? If so, can you help me understand what is going to happen for each?

[Stuart Metcalfe (stuartmetcalfe)]

Here's what would happen based on my original suggestion:

1. Rich is using one of the public university computers. He needs to log into the Ubuntu One interface to download a document to be printed for his next class. He logs in, successfully downloads and prints the file, and then he hits the logout button so that he can quickly get to class. Rich wants to confirm he is successfully logged out before leaving the workstation.

 1. Hit the logout button.
 2. A couple of options:
   a. Rich is *only* an Ubuntu One user: The default Ubuntu One home page is displayed
   b. Rich has recently used his SSO account to log in to other services: Ubuntu SSO page is displayed: "You have been logged out of Ubuntu One. You may also need to log out of these sites which you've used recently: *list of sites Rich has recently used with Ubuntu SSO*"

So, we don't explicitly say "You have been logged out" in case 2a. Here are a few options:

 * Leave it. Is the change in appearance of the consuming site (offering the option to Log in) sufficient to confirm the user's action?
 * Display a "You have been logged out" page on Ubuntu SSO for all cases
 * Send something in the query string back to the consuming site to indicate that the user has logged out

----

2. Emily visits a web-site that says she must authenticate using her Ubuntu SSO credentials. She clicks the login link, since she's already logged into other services with SSO it merely asks her if she wants to login. She chooses to and is sent to the new site. She decides this is not something she interested in using again and clicks the Logout button for the site. She doesn't want to log out of the other services she uses regularly.

 1. Hit the logout button
 2. Ubuntu SSO page displayed: "You have been logged out of <web-site>. You may also need to log out of these sites which you've used recently: *list of sites Emily has recently used with Ubuntu SSO*" Note: Emily has not been logged out of the 'recently used' sites.

This is a worthwhile case to consider for the next phase of this work when we were considering automatically logging the user out globally without intervention.

----

3. Neil comes across a site that looks suspicious. It shows he is logged in and he doesn't like the idea and would prefer to browse this site anonymously. He hovers his mouse over the button and the status bar shows that the logout link points to the Ubuntu SSO service. (In fact, this is a malicious or mis-configured site and the link is not doing what it says it is doing). Neil clicks the link.

Assuming Neil hasn't *actually* logged in to the suspicious site:

 1. Hit the logout button. The site doesn't know his user id so can't pass it along
 2. Ubuntu SSO displays a page: "<site> is attempting to log you out of your session but this isn't the account you used to log in. You may be logged in to other sites which we can't notify you about. Continue or cancel"
   a. Neil clicks "Continue": a couple of options:
     i. The site sends a return URL which isn't recognised. Neil is logged out of Ubuntu SSO and the main login page is displayed with the message "You have been logged out"
     ii. The site sends a return URL ...

[Stuart Metcalfe (stuartmetcalfe)]

Here's a simplified spec following review with newz:

Action path: /+logout

Required query string params:

 * return_to=<URL>. If <URL> doesn't exactly match a known trust root (with auto-redirect enabled - this is how we're defining full SSO sites), the user will see the same result as if the params weren't passed (currently that they are logged out but will stay on the SSO site and are notified of the logout). The same will happen if HTTP_REFERER is sent by the browser; its hostname must also match <URL>'s hostname. The return will not fail if HTTP_REFERER is undefined, it's just an extra check if available.

Logout behaviour for valid requests:

Assumptions:

 * trusted sites can have long sessions. let's say up to 365 days.
 * non-trusted sites have a shorter session lifetime of up to 30 days.

(both session lifetime values should be globally configurable on SSO)

On logout from an external site, the following content is displayed """

You have been logged out.

<big>Return to <sitename> (link to return_to)</big>

----

You have also used these sites recently:

 * <sitename/URL>

"""

<sitename/URL> is a list of all sites (trusted and non-trusted) accessed within the defined session durations, sorted by date order (most recent first), except for the requesting site. Trusted sites display the printable name. Non-trusted sites display the trust root. Both are links to the trust root which opens in a new window/tab. If the user isn't logged in to other sites, this list isn't displayed.

Assume the user isn't logged in to other sites if they:

 * have only logged into the requesting site (and no other trusted sites) within the defined session duration for trusted sites.
 * haven't logged in to a non-trusted site within the defined duration for non-trusted sites.

If a user doesn't have an active SSO session, we don't display the "You have been logged out" message or the list of links but we do display the link back to the requesting site.

Rationale for changes:

 * Removed uid param: although it brought some additional verification, it also complicated the implementation significantly due to a number of edge cases. The end result was additional potential confusion for the user which outweighed the benefits.
 * Removed automatic redirection when user has only ever used one service: this was the primary reason for the uid param. By removing this, it was easier to justify removal of the param. The user will have seen the SSO service before when they signed up so this shouldn't be a confusing experience for them. Logout from a remote site is now a consistent experience and should build trust in the SSO brand.
 * Moved the list of recent sites below the logged out message: visually associating the logged out message with the list of other sites when we aren't actually logging the user out of them could be confusing to users. By separating them in this way, we reduce the association to a more informational list.
 * Only display the list of recent sites to users who are logged in and don't try to determine a different user: this was simplified by removing the uid param. We don't need to attempt to match a different user. If the user has mo...

[Stuart Metcalfe (stuartmetcalfe)]

And here are the updated scenarios:

1. Rich is using one of the public university computers. He needs to log into the Ubuntu One interface to download a document to be printed for his next class. He logs in, successfully downloads and prints the file, and then he hits the logout button so that he can quickly get to class. Rich wants to confirm he is successfully logged out before leaving the workstation.

 1. Hit the logout button.
 2. Ubuntu SSO page is displayed: "You have been logged out. <big>Return to Ubuntu One</big>"

If Rich has recently used SSO to log in to other sites on any computer and his SSO session is still active, a list is displayed. We now explicitly say "You have been logged out". Rich is able to make a decision on whether he needs to log out of other sites if he's used them.

----

2. Emily visits a web-site that says she must authenticate using her Ubuntu SSO credentials. She clicks the login link, since she's already logged into other services with SSO it merely asks her if she wants to login. She chooses to and is sent to the new site. She decides this is not something she interested in using again and clicks the Logout button for the site. She doesn't want to log out of the other services she uses regularly.

 1. Hit the logout button
 2. Ubuntu SSO page displayed: "You have been logged out of <web-site>. You have also used these sites recently: *list of sites Emily has recently used with Ubuntu SSO*"

It should be clear to Emily that she has not been logged out of the other recently used sites, but that she can browse to them.

----

3. Neil comes across a site that looks suspicious. It shows he is logged in and he doesn't like the idea and would prefer to browse this site anonymously. He hovers his mouse over the button and the status bar shows that the logout link points to the Ubuntu SSO service. (In fact, this is a malicious or mis-configured site and the link is not doing what it says it is doing). Neil clicks the link.

 1. Hit the logout button
 2. Ubuntu SSO displays a page:
   a. The site sends a return URL which isn't recognised. Neil is logged out of Ubuntu SSO and the main login page is displayed with the message "You have been logged out"
   b. The site sends a return URL which is recognised, but the HTTP_REFERER is sent and doesn't match the return URL. Neil is logged out of Ubuntu SSO and the main login page is displayed with the message "You have been logged out"
   c. The site sends a return URL which is recognised. Rich's browser doesn't send the HTTP_REFERER header. SSO displays: "You have been logged out. <big>Return to <sitename> (link to return_to)</big>"

[Matthew Nuzum (newz)]

Looks like it's ready to implement.

[Łukasz Czyżykowski (lukasz-czyzykowski)]

Added optional return_to GET argument to /+logout view.

To it to work it must be recognized as valid, which means it has to have RP data in SSO for it. Otherwise it's just ignored.

[Julien Funk (jaboing)]

1. We need to test the following using more than one consumer so it is possible to verify that the user is only logged out from the one site and not all sites using SSO. Is there another consumer setup for staging other than the default consumer?

2. When logging out I don't get the following message, "You have been logged out of <web-site>" as Stu's specification clearly states in his comments on the defect - Instead, I only get the message, ""You have been logged out" - this seems like a defect. Please confirm if it is.

[Łukasz Czyżykowski (lukasz-czyzykowski)]

ad 2. For that to work given RP have to be configured in SSO, otherwise there's no way of getting name just from the URL.

[David Owen (dsowen)]

This doesn't work on staging as implemented. Launchpad, for example, logs out from a /+logout URL (the HTTP Referrer) requesting a return to that same URL, but that doesn't match exactly the trust_root.

[Stuart Metcalfe (stuartmetcalfe)]

This is ready for Ubuntu One, Launchpad and other trusted (known RPConfig) consumers to adopt. It just requires them to append the new return_to argument to the SSO logout redirect. I've tested this:

https://login.ubuntu.com/+logout?return_to=https://one.ubuntu.com/dashboard/

And it provides a link back to the U1 dashboard, logging me in again when I click it. A few notes:

 * The return link needs to be bigger and singled out on the page.
 * Return URLs where they match the trust root don't work (eg: ...?return_to=https://one.ubuntu.com/).

We should have fixes for both of these deployed in the next month.

[Stuart Metcalfe (stuartmetcalfe)]

...

 * It should use the consumer's name rather than the return URL too - will also be fixed in the next release.

[Thomas Herve (therve)]

Shouldn't the return_to parameter properly URL encoded? Would it work both encoded and non-encoded? IE something like ?return_to=https%3A%2F%2Flandscape.canonical.com%2F

[Stuart Metcalfe (stuartmetcalfe)]

Both should work. The one you pasted there won't work on production right now because of a known bug. There's a fix already on staging which you can see here:

https://login.staging.ubuntu.com/+logout?return_to=https%3A%2F%2Flandscape.canonical.com%2F

It's expected on production in the next few days, subject to sysadmin availability.

[Robert Collins (lifeless)]

Launchpad doesn't need to change vis-a-vis this bug. We can if we want to take advantage of the new sso facility. We already have a bug for that (bug 123734)