Dex est un service d'identité qui utilise OpenID Connect pour piloter l'authentification d'autres applications.
Dex agit comme un portail vers d'autres fournisseurs d'identité via des « connecteurs ». Cela permet à Dex de différer l'authentification auprès des serveurs LDAP, des fournisseurs SAML ou des fournisseurs d'identité établis tels que GitHub, Google et Active Directory. Les clients écrivent leur logique d'authentification une fois pour parler à dex, puis dex gère les protocoles pour un backend donné.
Les jetons d'identification sont une extension OAuth2 introduite par OpenID Connect et la fonctionnalité principale de dex. Les jetons d'identification sont des jetons Web JSON (JWT) signés par dex et renvoyés dans le cadre de la réponse OAuth2 qui atteste de l'identité de l'utilisateur final. Un exemple de JWT pourrait ressembler à :
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
Les jetons d'identification contiennent des revendications standard affirmant quelle application client a connecté l'utilisateur, quand le jeton expire et l'identité de l'utilisateur.
{
"iss" : " http://127.0.0.1:5556/dex " ,
"sub" : " CgcyMzQyNzQ5EgZnaXRodWI " ,
"aud" : " example-app " ,
"exp" : 1492882042 ,
"iat" : 1492795642 ,
"at_hash" : " bi96gOXZShvlWYtal9Eqiw " ,
"email" : " [email protected] " ,
"email_verified" : true ,
"groups" : [
" admins " ,
" developers "
],
"name" : " Jane Doe "
}
Étant donné que ces jetons sont signés par dex et contiennent des revendications basées sur des normes, d'autres services peuvent les utiliser en tant qu'informations d'identification de service à service. Les systèmes qui peuvent déjà consommer les jetons d'identification OpenID Connect émis par dex incluent :
Pour plus de détails sur la façon de demander ou de valider un jeton d'identification, consultez « Écrire des applications qui utilisent dex » .
Dex s'exécute de manière native sur n'importe quel cluster Kubernetes à l'aide de définitions de ressources personnalisées et peut piloter l'authentification du serveur API via le plugin OpenID Connect. Les clients, tels que kubernetes-dashboard
et kubectl
, peuvent agir au nom des utilisateurs qui peuvent se connecter au cluster via n'importe quel fournisseur d'identité pris en charge par Dex.
Lorsqu'un utilisateur se connecte via dex, son identité est généralement stockée dans un autre système de gestion des utilisateurs : un annuaire LDAP, une organisation GitHub, etc. Dex agit comme une cale entre une application client et le fournisseur d'identité en amont. Le client n'a besoin que de comprendre OpenID Connect pour interroger dex, tandis que dex implémente un ensemble de protocoles pour interroger d'autres systèmes de gestion d'utilisateurs.
Un « connecteur » est une stratégie utilisée par dex pour authentifier un utilisateur auprès d'un autre fournisseur d'identité. Dex implémente des connecteurs qui ciblent des plates-formes spécifiques telles que GitHub, LinkedIn et Microsoft ainsi que des protocoles établis tels que LDAP et SAML.
En fonction des connecteurs, les limitations des protocoles peuvent empêcher dex d'émettre des jetons d'actualisation ou de renvoyer des revendications d'appartenance à un groupe. Par exemple, étant donné que SAML ne fournit pas de moyen non interactif d'actualisation des assertions, si un utilisateur se connecte via le connecteur SAML, dex n'émettra pas de jeton d'actualisation à son client. La prise en charge du jeton d'actualisation est requise pour les clients nécessitant un accès hors ligne, tels que kubectl
.
Dex implémente les connecteurs suivants :
Nom | prend en charge les jetons d'actualisation | soutient la revendication des groupes | prend en charge la revendication de nom d'utilisateur préféré | statut | remarques |
---|---|---|---|---|---|
LDAP | Oui | Oui | Oui | écurie | |
GitHub | Oui | Oui | Oui | écurie | |
SAML2.0 | Non | Oui | Non | écurie | AVERTISSEMENT : non maintenu et probablement vulnérable aux contournements d'authentification (#1884) |
GitLab | Oui | Oui | Oui | bêta | |
Connexion OpenID | Oui | Oui | Oui | bêta | Inclut Salesforce, Azure, etc. |
OAuth 2.0 | Non | Oui | Oui | alpha | |
Oui | Oui | Oui | alpha | ||
Oui | Non | Non | bêta | ||
Microsoft | Oui | Oui | Non | bêta | |
AuthProxy | Non | Oui | Non | alpha | Proxy d'authentification tels que Apache2 mod_auth, etc. |
Nuage Bitbucket | Oui | Oui | Non | alpha | |
OuvrirShift | Oui | Oui | Non | alpha | |
Foule Atlassienne | Oui | Oui | Oui * | bêta | La revendication de nom d'utilisateur préféré doit être configurée via la configuration |
Gitéa | Oui | Non | Oui | bêta | |
Clé de voûte OpenStack | Oui | Oui | Non | alpha |
Stable, bêta et alpha sont définis comme :
Toutes les modifications ou dépréciations des fonctionnalités du connecteur seront annoncées dans les notes de version.
Veuillez consulter notre politique de sécurité pour plus de détails sur le signalement des vulnérabilités.
Une fois le codage et les tests terminés, veuillez exécuter la suite de tests :
make testall
Pour la meilleure expérience de développeur, installez Nix et direnv.
Vous pouvez également installer Go et Docker manuellement ou à l'aide d'un gestionnaire de packages. Installez le reste des dépendances en exécutant make deps
.
Pour le processus de publication, veuillez lire la documentation de la version.
Le projet est sous licence Apache, version 2.0.