User:Clouserw/AMO/Auth: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{draft}}
{{draft}}


=== Current flow and challenges ===
= Proposal to convert AMO to use Firefox Accounts =


User is given a single button for login/register and a link underneath for admins/editors.  Regular users click the "log in/register" button, go through browserid flow, and are logged in.  Privileged users click the link, are prompted with the local authentication form, and are logged in after that.  This is a potentially confusing split for the end users and also leads to two code paths which I'd like to avoid.  Security has made it a requirement that privileged users must give an additional token (with more requirements) before they are authenticated to AMO so browserid is not good enough.
Converting AMO to use FxA would increase FxA numbers, simplify the AMO code, centralize our authentication at Mozilla, and reduce our vulnerability footprint by keeping all account info in one place.  AMO has had 50,000 unique successful logins in April and 200,000 since the start of the year (stats as of the end of April).


===Proposed Solution===
<span style="color:red">This is a work in progress.  Feedback encouraged.</span>


# User is shown a login/register button that launches browserid
=== Proposed Flow ===
# User authenticates (regular users are done at this point)
# If User is privileged they are shown a second form with a single password field[1]
# User must authenticate here before they are allowed to continue.  Failure to authenticate results in no session created.


This provides us with a single branch out of the "normal" flow but fulfills the additional requirements Security has requested.
This is based heavily on the [https://www.lucidchart.com/documents/view/769cc8ee-64c7-456c-aceb-c4c6a43929dd/0 Marketplace transition to Firefox Accounts].


[1] The single password field is for legacy reasons only.  It would be possible to use other forms of verifying a users identity here also.
[[File:amo_fxa.png]]
 
=== Engineering Considerations ===
 
* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1Osi25WmZDLtp7hCt-tMqOceI06yRAQ4G50KqsXHGXUs/edit Engineering Estimate]
 
* AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums).  Removing all that code will be very good.
 
=== Q & A ===
 
* On certain administrative forms and when users try to delete their add-on we re-prompt for their password.  FxA doesn't support this functionality.  How will we deal with that?
** I think we'll just omit it for now.  Most administrative actions have moved to the CLI, and we have backups and logs for the other use cases.
 
* The [https://forums.mozilla.org/ AMO forums] still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system.  Three active proposals include:  letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).
 
* What if someone uses an FxA account that doesn't match their AMO account?
** Do we need to worry about this case?  If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.
 
* FxA supports creating a "pre-verified" account which essentially means you don't need to confirm your email address. If we know a user has confirmed their address (or we confirm it first) and they are logged in (or we email them a link to follow) this could be used to avoid an email. It also allows the user to change their email address during the transition if perhaps they signed up to AMO with me@work.com and want to switch to me@personal.com.
** This sounds like it may be more trouble than it's worth.  I'm going to sketch out the proposal without it and get feedback.

Latest revision as of 15:58, 13 May 2015

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Proposal to convert AMO to use Firefox Accounts

Converting AMO to use FxA would increase FxA numbers, simplify the AMO code, centralize our authentication at Mozilla, and reduce our vulnerability footprint by keeping all account info in one place. AMO has had 50,000 unique successful logins in April and 200,000 since the start of the year (stats as of the end of April).

This is a work in progress. Feedback encouraged.

Proposed Flow

This is based heavily on the Marketplace transition to Firefox Accounts.

Amo fxa.png

Engineering Considerations

  • AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums). Removing all that code will be very good.

Q & A

  • On certain administrative forms and when users try to delete their add-on we re-prompt for their password. FxA doesn't support this functionality. How will we deal with that?
    • I think we'll just omit it for now. Most administrative actions have moved to the CLI, and we have backups and logs for the other use cases.
  • The AMO forums still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system. Three active proposals include: letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).
  • What if someone uses an FxA account that doesn't match their AMO account?
    • Do we need to worry about this case? If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.
  • FxA supports creating a "pre-verified" account which essentially means you don't need to confirm your email address. If we know a user has confirmed their address (or we confirm it first) and they are logged in (or we email them a link to follow) this could be used to avoid an email. It also allows the user to change their email address during the transition if perhaps they signed up to AMO with me@work.com and want to switch to me@personal.com.
    • This sounds like it may be more trouble than it's worth. I'm going to sketch out the proposal without it and get feedback.
Retrieved from "https://wiki.mozilla.org/index.php?title=User:Clouserw/AMO/Auth&oldid=1074441"