[BC] User Authentication

[Jeremie Patonnier]

Hello :)

We have a long standing issues with authentication so far for the Browser
Compat project.

We are not yet in a position where it is super urgent to have a final
decision on this but I wish to start the discussion to figure out what
direction we should go.

The way I understand things is the following:

We need authentication for the following reason:

- We want to control the write access to the API in order to prevent
vandalism
- We need to manage data life cycle (update data, reverse data to a
previous state)
- We need to fine tune users right to interact with the data

Those needs indicate that we need to provide a way to let user in in a
secured way. However, we don't need to be the identity provider and we can
relay on third party for this.

So I suggest that we do not host our own identity service and relay on
third party for this. I suggest that we start with GitHub and Google as
identity provider, then I would like we support any OAuth2 enabled identity
provider.

That would also have the benefit to get ride of hosting sensible user data
(like e-mails) and just focus on user profile management for our own need
(access level to the data).

This is very rough and your opinion is really needed, please tell us what
you think :)
Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[John Whitlock]

This reminds me of the discussion that Justin Crawford initiated in May
2015:

https://groups.google.com/forum/#!topic/mozilla.dev.mdn/c3HimY6hcUY

My summary of that discussion:

MDN has limited people doing moderation. Ideally, they should be able to
see all content contributions from a single dashboard, and to see all the
contributions by a new user. If they ban a user on MDN, they should be
banned across all content sites. If they ban an IP, same thing.

There's some non-ideal things - a MDN page update has different patterns
than a BrowserCompat (BC) content update, so the "differences in this edit"
pages will be different.

However, if MDN grows an authentication provider than BC can use, then it
would be possible to view a user's contributions across both properties. If
MDN exposes IP bans to BC, BC could also ban those IPs.

There's also the question of "will other tech companies create MDN accounts
just to update BC data?" Some say the webplatform.org project is proof
that they won't.

Justin's argument is that we build BC for MDN first, and cut the features
that try to grow a community around BC.

In practice, there's a lot of overlap in the BC code either way. In one
case, BC only allows authentication via the MDN auth provider (which needs
to be written). In the other case, BC uses GitHub, Facebook, Google,
whatever, and you can optionally link to MDN via the MDN auth provider
(which needs to be written).

No one volunteered to write the MDN auth provider. Also, authentication
questions aren't a blocker for data cleanup, contribution UI development,
etc., so it got deferred.

John

[the.s...@gmail.com]

The other thing to consider is whether it makes sense to use Firefox accounts as an initial authentication method, then build out from there. This would support our earliest adopters quickly and easily.

[Justin Crawford]

>
> MDN has limited people doing moderation. Ideally, they should be able to
> see all content contributions from a single dashboard, and to see all the
> contributions by a new user. If they ban a user on MDN, they should be
> banned across all content sites. If they ban an IP, same thing.
>

John’s summary is good. Our decision to aim for authentication integration
with MDN came from long conversations on community channels as well as
survey analysis and one-on-one conversations with key stakeholders. Like
John said, there aren’t enough admin-editor-moderators to keep track of two
distinct content communities. Also, our analysis (review of all compat
contributions over a year, survey with lots of respondents, plus 1:1
conversations with active compat data contributors) didn’t clearly indicate
that a content community devoted to compat data could stand alone (we think
there are only a few hundred heavy maintainers of this information in the
world, and a lot are already maintaining it elsewhere). Unless new data has
emerged, I don’t recommend revisiting those decisions.

The above only applies to one kind of user. We have more, I think:
1) The above summary applies to “MDN users”. They maintain data in
compatibility tables as part of their regular MDN contribution experience.
They find an error or a gap and fix it. They create a new documentation
page and create the compat table at the same time. Etc. Our earlier
decision was to aim for an experience that approaches seamlessness,
particularly when it comes to authentication.
2) “API users” who have access to large amounts of browser compatibility
data will want to do something more programmatic. They will use different
interfaces and might need greater authority in the system in order to
accomplish bulk actions. We could give this kind of account to anyone
inclined to create a tool for putting in data — for example, a contributor
who wanted to programmatically feed caniuse or kangax data into
browsercompat could get this kind of account, or a browser vendor. We’d
need some kind of process to enable such trust, but I think it would be
premature to optimize for more than a handful of users like this.
3) A small group will be granted all privileges in the system as
admin-editor-moderators, just like on MDN. A seamless MDN experience for
them is probably very hard to build, but maybe seamless authentication is
possible.

Justin

On Mon, Feb 8, 2016 at 10:25 AM, John Whitlock <jwhi...@mozilla.com>

> _______________________________________________
> dev-mdn mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdn
>



--
Justin Crawford
hoos...@mozilla.com

[Jeremie Patonnier]

Hi :)

Thank you John and Justin for the whole background reminder :)

I wish to clarified a few points around that.

2016-02-08 23:40 GMT+01:00 Justin Crawford <hoos...@mozilla.com>:

> MDN has limited people doing moderation. Ideally, they should be able to
>> see all content contributions from a single dashboard, and to see all the
>> contributions by a new user. If they ban a user on MDN, they should be
>> banned across all content sites. If they ban an IP, same thing.
>>
>
> John’s summary is good. Our decision to aim for authentication integration
> with MDN came from long conversations on community channels as well as
> survey analysis and one-on-one conversations with key stakeholders. Like
> John said, there aren’t enough admin-editor-moderators to keep track of two
> distinct content communities. Also, our analysis (review of all compat
> contributions over a year, survey with lots of respondents, plus 1:1
> conversations with active compat data contributors) didn’t clearly indicate
> that a content community devoted to compat data could stand alone (we think
> there are only a few hundred heavy maintainers of this information in the
> world, and a lot are already maintaining it elsewhere).
>

Yes, the project goal is still to go that way. However, regarding the lack
of dev ressources and the necessity to move forward, it is necessary to
work around authentication in some pragmatical ways:

- A short terms solution to set up the basic auth architecture in order
to unlock the work for the contribution UI
- A long term goal which provide SSO between MDN and browsercompat.org

Those two goals are part of the project roadmap and we've never stopped
considering a transparent auth mechanism between MDN and BC.

> Unless new data has emerged, I don’t recommend revisiting those decisions.
>

That's the key point, a new data has emerged: Mozilla is decommissioning
Persona (and MDN is not a standardized identity provider) and MDN dev
ressources are getting shorter. Because of that, being able to provide a
common profile management over some SSO is pretty hard and will require
some in-depth development within Kuma. Currently it looks like we aren't
able to afford such development.

So the reasonable direction at that specific moment is to invest into using
some known identity providers (GitHub, Google, etc.), using known standards
(OAuth2) and make sure BC is able to work with that basic authentication
infrastructure. As MDN will need to do the same one way or another (GitHub
is already used to authenticate MDN users), once this would have been done,
it would be possible to define how to provide SSO. But in the meantime, BC
needs to have some basic infrastructure available and that's what we should
focus on now.

So in short: SSO between MDN and BC, yes but not at that stage of the
project. In any case, we need to agree on an auth architecture that will be
able to suite both MDN and BC whatsoever.

[John Whitlock]

I’m not sure we save a lot of effort by going with Google, GitHub, etc.
auth for BrowserCompat (BC), especially if that’s what we’re going to do
for MDN as well. I think it is better to decide on what MDN auth will be,
and then rely on MDN authentication for BC.

“Authentication” covers a lot of concerns, and you can’t cleanly split them
up and treat them independently. Some of the aspects:

* Identity - Who is the user? Is this the same user on this site as the
other site? How do I identify this user to other users?
* Clients - What technology is a user using to access the system? What are
the capabilities? What is the interface?
* User Authentication - In what ways can a user assert their identify? Is
there one or more than one? Can they add and remove them?
* Authorization - What is a user allowed to do on a system? What is the
process for adding and removing authorization? Who can do it?
* Request Credentials - How does a user assert their identity when making a
request? How does this change with different clients?
* Login and Account Setup - What is the user interface for creating an
account? For logging into a system? For modifying their account? For
recovering lost credentials?

Here’s the situation today with MDN (developer.mozilla.org):

*Identity - MDN users have a unique username (public) and a primary email
(private, changeable) that they choose at signup. They have a profile page
where they can add a bio and photo, as well as links to themselves on other
websites.
* Clients - MDN users use a web browser to access the site.
* User Authentication - MDN users can use Persona and GitHub to
authenticate.
* Authorization - MDN uses Django’s authorization system, with superusers,
staff users, and permission groups. There are also feature flags that can
be tied to users, groups, etc.
* Request Credentials - A session cookie is used for browser access
* Login and Account Setup - Browser sign in starts with authenticating with
GitHub or Persona. If the GitHub/Persona account is known, a session cookie
is sent for the associated user. If unknown, new account setup begins,
perhaps using the username and email for defaults (it has been a while
since I setup my MDN account). Account recovery is through a Bugzilla bug
and administrator intervention.

Here’s today’s situation on BrowserCompat (browsercompat.herokuapp.com):

* Identify - BC users have a unique username (public) and a primary email
(private, changeable) that they choose at signup. The system chooses a
database ID that is their primary identifier.
* Clients - BC users primarily interact with the API through HTTP requests,
such as JavaScript requests from the (browser-based) contribution and
moderation (C&M) interface. A web interface is provided for prototypes,
login, and account maintenance.
* User Authentication - BC users can use a username and password or Firefox
Accounts to log in. The FxA account auth is currently broken (bug 1229037)
* Authorization - BC uses Django’s authorization system, with superusers,
staff users, and permissions groups. The permission groups are mapped to
API permissions, currently“change-resource”, “delete-resource” and
“import-mdn”.
* Request Credentials - An OAuth2 token provisioned by the API is used for
most HTTP requests. A session cookie is used for web clients directly on
the API server, including when visiting the API server to provision an
OAuth2 token.
* Login and Account Setup - With Firefox Accounts (FxA), a user
authenticates with FxA, which is a login for a known FxA account, and goes
to account creation for an unknown FxA account. With username and password,
a user has to pick if they are logging in or creating an account first. A
user can recover an account by requesting a password reset through their
primary email.

Here’s what I’d like:

* Identify - Users have a unique username and primary email on MDN. BC
users have an MDN username and a BC UUID.
* Clients - Users use a web browser to access MDN and BC web-based sites.
Users primarily access the BC API through JS and backend HTTP requests,
such as from the C&M UI.
* User Authentication - MDN users can use FxA and GitHub to authenticate.
More auth methods are added using a test-first process similar to this one:
https://medium.com/on-startups/how-adding-one-button-increased-our-signups-by-3x-27988ea3d254
. BC users authenticate through their MDN account.
* Authorization - MDN uses Django’s authentication system. BC permissions
are based on permissions in MDN’s system, communicated through a non-public
MDN API.
* Request Credentials - MDN and BC uses local session cookies for browser
access. The BC API uses an OAuth2 token provisioned by MDN.
* Login and Account Setup - MDN sign-in begins with authenticating with
GitHub or FxA. Known credentials means a login, new credentials a signup.
BC sign-in begins with MDN sign-in., automatically creating an BC
UUID-based account for new MDN credentials. BC is a trusted OAuth2 relier,
and is provided OAuth2 tokens without user approval. Account recovery is
via the user’s chosen auth providers, or Bugzilla bug.

With this, a typical user interaction could be:

* A logged-in MDN visitor sees out-of-date contribution data on a reference
page. They click a “edit this data” button.
* Their browser flashes as it bounces between MDN and BC. They land on the
BC C&M site, logged in and displaying their MDN username.
* They edit the data, save, and click “return to MDN”
* Their new contribution appears on the MDN reference page

The work, in rough order, would be:

* MDN adds OAuth2 provider support.
* BC adds MDN as an OAuth2 provider. MDN marks BC as a trusted OAuth2
relier.
* BC drops FxA
* BC drops username+password auth
* BC drops usernames, email
* MDN adds a user data API, authenticated with OAuth2 for non-public
information, and maybe supporting JSON Web Token for detailing permissions
* BC drops local permissions, and relies on MDN user data API for BC
permissions
* MDN drops Persona auth
* MDN adds FxA auth
* Detail work around new account creation (for example, a user without an
MDN account wants to contribute BC data)

The benefits are:

* Identity is simple - your identity is your MDN account
* One place to add or change user authentication
* One place to add or change user authorization
* Most login and account interface work is on one website
* No PII at all stored in BC database

The costs are:

* MDN grows an OAuth2 provider
* MDN grows a user data API
* Manual migration of 14 current browsercompat accounts.
* Additional corner cases around account creation
* Local BC development requires configuring MDN auth, or using a
non-production auth system

As one of the people who will probably have to migrate MDN away from
Persona, this feels like less work to me, since I only need to setup FxA
and other auth providers for one website. It is also extendable to future
micro-services. I think the time to do this is now, when the number of BC
user accounts is still small.

John

[Sebastian Zartner]

Thank you for the very detailed information, John!

I mainly agree with you, though I am wondering if BC doesn't have to have
its own auth system at some point. I guess it feels weird for new users
being redirected to create an account on MDN if they just want to add BC
data, especially if they are adding data for another client.
Though that's still up in the air. Restricting authentication and
authorization via MDN as a first step and as long as the data is only used
by MDN sounds good to me.

And I especially like the simplicity of the workflow to update the data you
see on MDN. It just needs to be made clear to users why they are redirected
to another page and that a new account got created automatically on BC when
they get there for the first time.

Sebastian