User:Clouserw/AMO/Auth: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{draft}}
{{draft}}
=== Current flow and challenges ===


On AMO 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.
= Proposal to convert AMO to use Firefox Accounts =


On Builder users are given a form to log in.  Builder takes those credentials and talks directly to the AMO database to verify them.  We'd like to remove that direct access to the db and simplify this flow.
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).


On forums.amo phpBB(!) takes those credentials and talks directly to the AMO database to verify them.  We'd like to remove that direct access to the db as well as fix the auth problems phpBB has (capital letters, etc.).
<span style="color:red">This is a work in progress.  Feedback encouraged.</span>


Security has made it a requirement that privileged users on AMO must give an additional token (with more requirements) before they are authenticated to AMO so Browserid alone is not good enough there.
=== Proposed Flow ===


===Proposed Solution===
This is based heavily on the [https://www.lucidchart.com/documents/view/769cc8ee-64c7-456c-aceb-c4c6a43929dd/0 Marketplace transition to Firefox Accounts].   
# {{done|}} Builder flips to using Browserid as its only authentication (for both admins and regular users).  Builder continues to retrieve account id, homepage, display_name, etc. from the AMO database directly.  (Since both AMO and browserid have independently confirmed the user owns the address this remains secure).
# AMO builds a simple API end point for user data including the information Browserid is using (and specifically *not* password data). This API endpoint is behind oauth and accessible only to specific oauth keys (in this case, builder's and the forums).  ('''todo:clouserw''': file this bug)
# Builder uses that API and we remove the direct database access from builder.
# We add Browserid support to the forums as the sole means of logging in. The forums will hit the same Users API that Builder hits to retrieve display_name, etc.  ('''rabbithole''': none of us has done oauth with php before)
# AMO switches to using Browserid as its primary authentication.  The transition is:
* User is shown a login/register button that launches Browserid
* User authenticates
** If the user authenticates successfully and had a local password set, we set the local password to null (or "browserid::" if we want to follow the current format)
** Regular users are done at this point
* If User is privileged they are shown a second form with a single password field[1].  This is their password that is currently in the database (sha hash)
** User must authenticate here before they are allowed to continue.  Failure to authenticate results in no session created.


This provides us with a single flow of code and fulfills the additional requirements the security team has requested. Once this has been implemented, we can increase the security of administrative accounts on AMO by converting them to bcrypt without affecting any other services.  '''Setting the user's password to null means they can't go back to the old login form'''
[[File:amo_fxa.png]]


[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.
=== Engineering Considerations ===


=== Open Questions ===
* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1Osi25WmZDLtp7hCt-tMqOceI06yRAQ4G50KqsXHGXUs/edit Engineering Estimate]
* How can a user register for a new account on builder?
 
** Possible to create an oauth API to make accounts automatically but would need a=legal and a=fligtar as there are some developer agreements that users need to see.  In the short term you'd have to do what we do now: send the user to AMO to register first.
* 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.
** We may consider to NOT force syncing the Builder with AMO account. This is needed only for uploading the add-on to AMO. This feature might be enabled for synced accounts. If the user wishes to use the Builder without creating an account on AMO, some features will be disabled. If later on the user will create an account on AMO (possibly from the link near "upload to AMO") these features might be enabled. This does not require a lot of coding.
 
* Administrative users on builder and the forums are not asked for additional credentials.  Will this need to be added?
=== Q & A ===
* When someone first joins a privileged group on AMO they won't have a local password set. How do they log in?
 
** In that case we should prompt them to set one right after the browserid auth.
* 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"