@phuzion requested OpenID auth, and I see no reason not to support it.
@epriestley said it looks like we could start with this http://gitorious.org/lightopenid/lightopenid/blobs/master/openid.php
No ETA on this, but I think it'd be cool.
codeblock | |
Sep 28 2011, 9:24 PM |
F6891439: Screen Shot 2019-09-26 at 6.52.36 PM.png | |
Sep 27 2019, 1:54 AM |
F6891431: dex-provider.png | |
Sep 27 2019, 1:54 AM |
F6891436: Screen Shot 2019-09-26 at 6.51.05 PM.png | |
Sep 27 2019, 1:54 AM |
@phuzion requested OpenID auth, and I see no reason not to support it.
@epriestley said it looks like we could start with this http://gitorious.org/lightopenid/lightopenid/blobs/master/openid.php
No ETA on this, but I think it'd be cool.
Restricted Differential Revision |
Status | Assigned | Task | ||
---|---|---|---|---|
Wontfix | codeblock | T524 OpenID Authentication as an Auth Option | ||
Restricted Maniphest Task | ||||
Restricted Maniphest Task | ||||
Restricted Maniphest Task | ||||
Restricted Maniphest Task |
This is now practical, and I built half a version based on D3122, but I'm somewhat disinclined to pursue it further in the upstream. In particular:
I'm not necessarily totally opposed to doing this at some point, but interest seems very low and cost relatively high. This can be built as an extension today, so maybe that's the best route forward? Here's my half-implementation:
{P865}
{P866}
If you dump all that into a library and have Phabricator load it, it will get you sort of half-ish way there.
I referenced this recently in conjunction with a request for SAML auth, since many of the same arguments against OpenID apply to SAML. While it's on my mind, two other notes:
I'm not sure how I'd even test OpenID these days. Offhand, I haven't seen any provider offering OpenID in years.
OpenID seems to have been supplanted by "OpenID Connect", which is (as far as I can tell) just OAuth 2.0 with a prescribed API structure that has no technical relationship to the original OpenID protocol. So that's perhaps a tentative "maybe" -- e.g., I implemented Okta OAuth in T13394, which is also known as "Okta OpenID Connect", but this is completely different from what "OpenID" meant at the time this task was filed.
If you want to auth against some internal OpenID service which is real OpenID and has been running since 2010, I probably have no realistic way to test that code actually works.
Apologies, I should have provided more context. We've been futzing with this project which OIDC. We'd be looking to ensure that it works with Dex.
OIDC is just OAuth2 in a ghost costume, so the implementation is nearly trivial.
If you have a staging environment, drop these two files into phabricator/src/extensions/:
<?php final class PhabricatorDexAuthProvider extends PhabricatorOAuth2AuthProvider { public function getProviderName() { return pht('Dex'); } protected function getProviderConfigurationHelp() { return PhabricatorEnv::getURI($this->getLoginURI()); } protected function newOAuthAdapter() { return new PhutilDexAuthAdapter(); } protected function getLoginIcon() { return 'Dex'; } }
<?php final class PhutilDexAuthAdapter extends PhutilOAuthAuthAdapter { private $wellKnownConfiguration; public function getAdapterType() { return 'dex'; } public function getDexBaseURI() { return new PhutilURI('http://127.0.0.1:5556/dex'); } public function getAdapterDomain() { return $this->getDexBaseURI()->getDomain(); } public function getAccountID() { return $this->getOAuthAccountData('sub'); } public function getAccountEmail() { return $this->getOAuthAccountData('email'); } public function getAccountName() { return null; } public function getAccountImageURI() { return null; } public function getAccountURI() { return null; } public function getAccountRealName() { return $this->getOAuthAccountData('name'); } protected function getAuthenticateBaseURI() { return $this->getWellKnownConfiguration('authorization_endpoint'); } protected function getTokenBaseURI() { return $this->getWellKnownConfiguration('token_endpoint'); } public function getScope() { return 'openid profile email'; } public function getExtraAuthenticateParameters() { return array( 'response_type' => 'code', ); } public function getExtraTokenParameters() { return array( 'grant_type' => 'authorization_code', ); } public function getAccessToken() { return $this->getAccessTokenData('access_token'); } protected function loadOAuthAccountData() { $uri = $this->getWellKnownConfiguration('userinfo_endpoint'); $future = new HTTPSFuture($uri); $token = $this->getAccessToken(); $future->addHeader('Authorization', "Bearer {$token}"); list($body) = $future->resolvex(); try { $result = phutil_json_decode($body); return $result; } catch (PhutilJSONParserException $ex) { throw new PhutilProxyException( pht('Expected valid JSON response from OIDC account data request.'), $ex); } } private function getWellKnownConfiguration($key) { if ($this->wellKnownConfiguration === null) { $uri = $this->getDexBaseURI(); $path = $uri->getPath(); $path = rtrim($path, '/').'/.well-known/openid-configuration'; $uri->setPath($path); $uri = phutil_string_cast($uri); $future = new HTTPSFuture($uri); list($body) = $future->resolvex(); $data = phutil_json_decode($body); $this->wellKnownConfiguration = $data; } if (!isset($this->wellKnownConfiguration[$key])) { throw new Exception( pht( 'Expected key "%s" in well-known configuration!', $key)); } return $this->wellKnownConfiguration[$key]; } }
In the second file, modify getDexBaseURI() to point at your Dex server.
Pick a client ID and secret and create a corresponding adapter in Auth → Login and Registration. It should look like this. Note the circled callback URL:
Dex should have the same config, here's what my modified config-dev.yaml file looks like:
That was good enough to get things working for me:
If it works for you, I'll polish these up and upstream them, although the final versions may look slightly different since I'd like to chip away at T6703 before bringing more providers upstream.