Page MenuHomePhabricator

Phabricator OAuth 2.0 initiating SSO login from a Third Party website
Closed, WontfixPublic


Problem description: Phabricator lacks a method to initiate OAuth 2.0 SSO from a third party website.

We have an "Intranet" portal, which has links to various web-based applications we use. Phabricator is one of the applications. Users can click the links on the portal, and they'll be redirected to the web application in question, with seamless Single Sign-On (SSO). SSO for the applications is often implemented by using OAuth 2.0 authentication or OpenID Connect against the Identity Provider (IDP) we use. Now the actual problem is that Phabricator does not provide a way to "initiate" the OAuth 2.0 SSO login from Third Party websites (such as our Intranet portal). Instead when users click the "Phabricator" -link on our intranet portal they'll be redirected to the Phabricator login page, where they need to click *again* to choose the authentication method or manually fill in their username/password. We want to make this easier.

OpenID Connect specification (based on OAuth 2.0) describes a method for "Initiating Login from a Third Party", which is exactly what's missing from Phabricator:

Basicly Phabricator needs to provide an URL, say, "https://phabricator.domain.tld/auth/initiate_login", so one can link to that URL from the Third Party website (our portal), which then allows initiating easy and automatic SSO login for users, using the existing external OAuth authentication providers available and configured in Phabricator server. This same method works for *all* of the existing external OAuth authentication providers (Google, Github, Amazon, Facebook, Azure, etc).

As you can see from the OpenID Connect Core Specification the proposed "initiate_login_uri" needs to accept "iss" (=Issuer Identifier) parameter, which basicly tells which OAuth authentication provider to use when initiating the SSO process. An example URL to link to from thirdparty website to initiate the SSO process from Phabricator would be:

(well, the parameter needs to obviously be URL encoded, but you get the idea).

I've implemented a proof-of-concept about this feature by hacking PhabricatorAuthStartController.php to provide the mentioned "initiate_login" uri, which then verifies if the "iss" parameter URL can be found from the configured OAuth authentication providers in Phabricator, and if found, makes a redirect to that OAuth authentication provider starting the SSO process, which then continues just like it normally does between Phabricator and the OAuth Identity Provider. The POC implemention seems to work OK.

Does this sound like something that Phabricator upstream wants to have integrated? Or is there already some existing way to accomplish this? Any feedback? Thoughts? :)

Event Timeline

I don't think this is worth bringing upstream. It very occasionally saves users one click on an otherwise straightforward workflow, but requires significant complexity and maintenance from the upstream.

If you only have one OAuth provider, you can "Allow Auto Login" for that provider to get this behavior in all cases.

Is the actual problem here that you have multiple providers (say, LDAP and also Google OAuth) and that users are confused about which they should use? If so, why do you have multiple providers?

We generally don't consider a root problem of "Phabricator lacks feature" as a reason to accept a feature request. We still need to know the underlying problem.

@epriestley: Yes, we have multiple authentication providers configured and needed in phabricator, and thus "allow auto login" won't work.

@chad: Underlying problem is that we want to have seamless SSO for users coming from our internal portal. In that use case we want to send users to the "start authentication against specific oauth provider" -URL, which makes phabricator redirect the browser to the specified oauth IDP starting the authentication process automatically, and makes the whole SSO process seamless for the end user. This way we can make sure all the users coming from our portal always use the correct IDP, and won't have problems signing in to phabricator.

About "significant complexity and maintenance": this proposed feature is actually a single URL endpoint on phabricator, and it's common shared code for all of the oauth providers in phabricator, meaning it works with *all* of the existing oauth authentication providers.. and it uses the same oauth code that's used today for the enduser manually initiated oauth logins. So not sure about it being "significant complexity".. your viewpoint obviously might differ :)

Why do you have multiple authentication providers?

@epriestley : we need multiple authentication providers because this is a shared phabricator instance, and thus different groups of users need different IDP.

Why are you sharing an instance between two separate groups with separate identity providers?

@epriestley : because it's easier to manage everything from a single instance of phabricator. Phabricator has native support for multiple authentication providers, so I don't see a problem with this.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

This is so rare that we don't even support this in the general case (see T6703). For example, it is not currently possible to configure Phabricator to use two different LDAP providers. Although this is a feature we plan to implement eventually, we've seen very little interest in it and the driving use cases are largely not around running multiple providers for an extended duration (instead, they focus on situations like migrating between providers; see also T2549).

Because we are committing to maintaining upstream features indefinitely, it is very important to us that features in the upstream solve general problems experienced by multiple installs, not problems which are experienced by only one install.

It's also important that we're providing good solutions to real technical problems, not workarounds for problems that companies make for themselves. We sometimes receive requests to implement features which only make sense in the context of some other problem, like a third-party not supporting something or an organization having a very unusual technical policy. For example, Facebook once asked us to implement features because they had put their databases and repository servers in datacenters 3,000 miles apart using NFS replication that caused multiple minutes of replication delay (we declined, and suggested they move their servers closer together).

All of this is explained in more detail in Contributing Feature Requests.

If you believe the feature you want isn't very complex and that you're making a very small request of us: great! You can implement it locally yourself and maintain the patch, which shouldn't be much work since you don't believe it represents a significant burden on the upstream.

If the feature you want is large enough that you don't want to develop or maintain it, we need you to work with us to understand the context your organization exists in, why you have this unusual setup and problem, why this feature is a good technical solution to the problem, and why this isn't just a request to work around a questionable or complex organizational policy by shifting the burden of poor planning onto us.

We will never implement features without first developing this deep understanding of the context they exist in and the problems they're solving, because we're committing to maintaining them indefinitely. This is a huge, long-term burden, so we believe it is reasonable to ask you to bear as much of the burden as you can up front by describing the problem you're facing -- not just requesting a feature -- so we can find different solutions and evolve solutions as other problems arise and needs change. This is explained in more detail in Describing Root Problems.

From the information you've provided, here's my guess about what's going on: it sounds like your organization has an unusual authentication setup with two or more separate SSO authorities. I assume this setup exists for historical reasons (perhaps you acquired another company, or were yourselves acquired, and the two organizations' SSO systems haven't been merged) and causes many other problems, but is very hard to fix. Because fixing that root problem is too difficult, you're trying to work around the problem in other software like Phabricator. Specifically, you're running into an issue where users are confused about which authentication option they should use.

If that's the case, we'd like to see this hypothetical problem description instead of the one you filed:

My company acquired another company three years ago, and we have two completely different SSO systems which don't know about each other. We haven't fixed this in the last three years because it's a lot of work and it's hard to prioritize internally since the two systems are owned by competing teams locked in an internal battle over the same budget. About two years ago, we started using Phabricator, and just associated it with both SSO systems. When new users go to log in they often aren't sure if they should login with LDAP (our SSO system) or Google (the acquired company's SSO system) and sometimes click the wrong one and get confused or worse. We'd like to provide direct links to login with a particular provider, so our two different SSO portals can link to two different login flows...

Then we could reply with something like this:

This isn't a good fit for the upstream, because it would require time and resources to work around an unusual problem your organization has created for itself and would benefit very few (and perhaps zero) other organizations. We recommend you focus on merging your two SSO systems instead, since that seems to be the root of the problem, and would resolve this problem (and probably other problems) without any changes in the Phabricator upstream. If you'd like, we can give you a quote for fixing this via extension at consulting rates, which will be large enough that you might be able to get some leverage on getting the root problem fixed, since it could help you demonstrate that not merging the two SSO systems has a concrete cost to your organization.

That scenario may be way off the mark, but it's the most likely scenario I can construct from the information you've actually provided to us.

Thanks for the detailed reply.

I tried to explain the root problem properly, and I did read the "Contributing Feature Requests" and "Describing Root Problems" docs before posting.. but I guess I didn't manage to explain properly after all.

For us it's as simple as: We have a need to link to Phabricator from an internal website, and we prefer to have automatic SSO for the users, so we need Phabricator to provide an URL which automatically initiates OAuth SSO login.

We already have an implementation of this internally, so I guess we'll maintain that ourselves going forward.

epriestley claimed this task.

Cool, sounds good.