Page MenuHomePhabricator

Support OAuth providers in the cluster
Closed, ResolvedPublic

Description

Immediate goal is to support the OAuth-based integrations (JIRA and Asana). We can't really do anything about, say, VPN'd on-premesis JIRA installs, but anything accessible over the public internet can work, and Asana can always work.

To get these integrations working, we need to let instances have Asana and JIRA auth providers. However, they shouldn't permit registration (all user accounts should be tied to central Phacility accounts). In the Asana case, you must also edit locked configuration to enable the integration, and there's no way for administrators to do that right now.

The simplest approach is probably:

  • Build admin console workflows for configuring JIRA and Asana.
  • After an instance administrator makes updates, sync the instance.
  • When an integration is configured, the sync creates or enables the respective auth provider, configuring it correctly and forcing it to login-only.

This also allows users to log in to their instance with their JIRA/Asana OAuth credentials instead of their Phacility credentials.

The tougher part is allowing login to a Phacility account with OAuth credentials, and how this is generally likely to be confusing:

  • We could simply enable this, but the account link won't (and can't) synchronize to instances, which feels confusing.
  • We can't ever do it for JIRA, unless we change how central auth works and pre-prompt you for an instance, which defeats the whole purpose of central auth.
  • Maybe we just don't?

Leaving central auth as username+password generally feels OK to me, but the downside is that the signup workflow is now involved:

  • Administrator invites all users via email.
  • They accept the invite and register username + password accounts with no prefilling.
  • They click through to their instance.
    • Currently, they'd be given a choice between central OAuth (correct) and Asana (wrong), but we could remove this choice.
  • They go through central OAuth, then need to know that they have to go to Settings to link an external account, although this doesn't feel too messy.
  • If they survive this intake gauntlet, mycompany.phacility.com starts working in a reasonable way, although every time they try to log in they now have a similar choice between central OAuth (probably harder) and Asana OAuth (probably easier). But I think that's comprehensible.

Details

Commits
Restricted Differential Revision / Restricted Diffusion Commit

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added projects: Phacility, Auth.
epriestley moved this task to Do After Launch on the Phacility board.
epriestley added a subscriber: epriestley.
epriestley updated the task description. (Show Details)Mar 3 2015, 7:25 PM

Is there any reason that you can't simply allow registrations via other OAuth providers which implicitly registers accounts in the cluster (and links them)? This way an administrator could enable the JIRA provider with a white list on the email address domains allowed, and then everyone can just login with their JIRA account (obviously each new person that registers on the instance would increase the billing amount per month).

  • Primarily, their username may collide with a Phacility username, and this seems hard to resolve in a way that makes any sense to users.
  • We don't want them to lose access to their Phacility account if they leave the company.
  • We don't have any account synchronization code in the upstream, and don't really want to add it since it would only serve Phacility use cases.

In theory, we could:

  • Add some kind of concept of "unnamed" accounts in the case of collisions which don't have a username yet, and ask users to pick one the first time they log in.
    • I think this is plausible from a technical and product perspective, but a lot of work/mess and I don't think it's helpful outside of Phacility.
  • Deal with losing access in a soft way (e.g., note to the user that they only have one in-cluster oauth source associated with their account and won't be able to log in if they get kicked off that instance). We could just show this prominently when they join or create a second instance, since it isn't relevant until then. This isn't a big deal, it's just bad if someone working at Widget Corp launches a personal instance for a side project and then gets fired suddenly and is locked out of their account.
  • But writing the sync stuff is a mess any way you cut it, and the "unnamed" accounts are in the same boat as this.

There are various half-measures we can take here which are less messy, like letting anyone with a verified @domain.com address join an instance, without doing the JIRA and reverse-oauth-sync parts, but it's not clear how much of a use case there is for the various levels of things here.

Oh, and that also wouldn't solve the problem that central auth was aimed at solving, which is:

  • If you type phacility.com into your browser (instead of mycompany.phacility.com), you should eventually end up on your instance.
epriestley added a revision: Restricted Differential Revision.Mar 30 2015, 9:40 PM
epriestley added a commit: Restricted Diffusion Commit.Mar 30 2015, 11:30 PM
chad added a subscriber: chad.Jul 24 2015, 8:42 PM
marklu added a subscriber: marklu.Jul 29 2015, 11:14 PM

The original driver here was a very complex one (requiring instance-level, non-registration OAuth links to services) but that never went through.

Since, then a much easier use case has come up a couple times, which is basically just enabling Google OAuth to central Phacility. One of the downsides for this:

We could simply enable this, but the account link won't (and can't) synchronize to instances, which feels confusing.

...is true for stuff like Asana/JIRA, but immaterial for Google (and, today, for GitHub, Facebook, Twitter, and so on, since we don't actually use their APIs, although we might in the future).

We should probably resolve T6707 first and I don't want to just turn on every OAuth provider, but I think Google is the most common by far and is quite reasonable to enable (I don't currently anticipate using the API token for anything, so that would moot not having access to it on instances).

This will also create some level of support cost as users mess stuff up, but this is probably modest and mostly resolvable through tooling.

turadg added a subscriber: turadg.Oct 22 2015, 6:44 PM
epriestley moved this task from Backlog to The Queue on the Prioritized board.Oct 24 2015, 4:49 PM
talshiri removed a subscriber: talshiri.Dec 15 2015, 9:56 PM
epriestley moved this task from The Queue to Paused on the Prioritized board.Feb 7 2016, 4:15 AM
epriestley moved this task from Paused to The Queue on the Prioritized board.Jun 13 2016, 2:21 PM

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

epriestley moved this task from The Queue to Paused on the Prioritized board.Jun 13 2016, 5:48 PM

A substantial number of users have linked Google accounts in production and we haven't heard about any issues, so I think that aspect of things is in good shape.

epriestley closed this task as Resolved.Feb 13 2019, 12:16 PM

I think there's not much actionable here and this has all more or less resolved:

  • We support Google auth centrally, and could add support for other central providers (like Facebook, if Facebook-for-Work somehow takes off) if demand existed.
  • Instances that want Asana/JIRA for the integrations can file a support ticket and we set them up as non-login/non-registration.There isn't a huge amount of demand for this today, but it works fine as non-login/non-registration.
  • Private clusters will open this up more broadly (no Phacility auth required, editable auth providers).