User:Wenzel/SSO:AMO-SSO Integration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Replaced content with '(moved this into a [http://docs.google.com/Doc?docid=0Af2UUiQYHLibZGdncGR3eDVfNGR2Zm41bmNz&hl=en Google Doc]).')
 
Line 1: Line 1:
= SPEC: AMO/SSO Integration Prototype =
(moved this into a [http://docs.google.com/Doc?docid=0Af2UUiQYHLibZGdncGR3eDVfNGR2Zm41bmNz&hl=en Google Doc]).
 
== Objectives ==
* Provide users with a single log-in across Mozilla web properties, starting with AMO / AMO Forums
* Secondary: Help evolve the Weave Account Manager standard for delegated authentication
 
== Details ==
=== Association ===
Existing AMO users should easily be able to sign up for an SSO account and associate it with their AMO account, from the profile page.
 
They can disassociate their account there too.
 
=== New User Sign-up ===
SSO users who have never used AMO need to be able to log in via SSO, then fill in their account details to be able to use AMO.
 
* Open questions:
** How to transfer/prefill SSO's user metadata into AMO?
** How to update AMO when SSO metadata (email etc.) changes?
 
=== Login Page ===
The login page currently has a username and password field. Next to it, we'll need a button to "log in via SSO", along with an option to get more information (info popup? help page?) and a link to sign up for a new SSO account.
 
Offering an SSO username/password field right there is [http://www.ja-sig.org/wiki/display/CAS/Using+CAS+without+the+CAS+login+screen possible, albeit discouraged], but might overload the page visually?
 
=== Logout ===
Regular logout on AMO will get rid of the local cookie, but not of the SSO cookie.
 
We ''can'' add the option to forward to the SSO logout page after clearing the AMO cookie (and have it forward us back to AMO).
 
Note: None of this will log us out of third applications, like SUMO.
 
== Ideas ==
=== Transfer User Metadata from SSO to AMO (once) ===
Could piggyback a JSON object into the service ticket verification response that currently looks like this:
 
<pre>
yes
fligtar
</pre>
 
(indicating the ticket was valid, and the user it belongs to is called fligtar).
 
When AMO calls the verification service like this: <code>/verify/?meta=true</code>, this could change to:
 
<pre>
yes
fligtar
{"email": "me@example.com", "firstname": "Flig", "lastname": "Tar"}
</pre>
 
NB: Because target apps are whitelisted by domain, random entities can't harvest data through this, but there is no way to keep AMO from getting the full set of metadata from SSO, if the user didn't want it to. Considering the set of SSO metadata is really small, is that a problem?
 
=== Update AMO Metadata from SSO ===
* on user request only (button: "update data from SSO")?
** - potentially tedious, once we have 20 SSO consumers and all the user wants to do is change their email address.
* automatically on each login?
** + SSO metadata change propagates, as expected
** - AMO metadata stays the same until user logs into it
* notification on each login ("your user data on SSO seems to have changed. Do you want to use these changes on AMO?")?
** + user is in control what changes are made
** - question will be annoying unless remembered

Latest revision as of 15:28, 12 May 2010

(moved this into a Google Doc).