dex - Un fournisseur OpenID Connect fédéré

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 déléguer l'authentification à des serveurs LDAP, des fournisseurs SAML ou des fournisseurs d'identité établis comme GitHub, Google et Active Directory. Les clients écrivent leur logique d'authentification une seule fois pour parler à dex, puis dex gère les protocoles pour un backend donné.

ID Tokens

Les ID Tokens sont une extension d'OAuth2 introduite par OpenID Connect et la fonctionnalité principale de dex. Les ID Tokens sont des JSON Web Tokens (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 ID Tokens contiennent des revendications standard qui attestent de l'application cliente avec laquelle l'utilisateur s'est connecté, de la date d'expiration du jeton et de 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"
}

Comme ces jetons sont signés par dex et contiennent des revendications basées sur des standards, d'autres services peuvent les consommer comme identifiants de service à service. Les systèmes qui peuvent déjà consommer les ID Tokens OpenID Connect émis par dex incluent :

• Kubernetes
• AWS STS

Pour plus de détails sur la façon de demander ou de valider un ID Token, consultez "Writing apps that use dex".

Kubernetes et Dex

Dex s'exécute nativement sur n'importe quel cluster Kubernetes à l'aide de Custom Resource Definitions et peut piloter l'authentification du serveur API via le plugin OpenID Connect. Des clients, tels que kubelogin 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.

• Plus de documentation pour exécuter dex comme authentificateur Kubernetes peut être trouvée ici.
• Vous pouvez en savoir plus sur les entreprises et les projets qui utilisent dex, ici.

Connecteurs

Lorsqu'un utilisateur se connecte via dex, l'identité de l'utilisateur 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 passerelle entre une application cliente et le fournisseur d'identité en amont. Le client n'a besoin de comprendre que OpenID Connect pour interroger dex, tandis que dex implémente un ensemble de protocoles pour interroger d'autres systèmes de gestion des 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 plateformes spécifiques telles que GitHub, LinkedIn et Microsoft, ainsi que des protocoles établis comme LDAP et SAML.

Selon les connecteurs, les limitations des protocoles peuvent empêcher dex d'émettre des refresh tokens ou de renvoyer des revendications de group membership. Par exemple, comme SAML ne fournit pas de moyen non interactif de rafraîchir les assertions, si un utilisateur se connecte via le connecteur SAML, dex n'émettra pas de refresh token à son client. La prise en charge des refresh tokens est requise pour les clients qui nécessitent un accès hors ligne, comme kubectl.

Dex implémente les connecteurs suivants :

Stable, bêta et alpha sont définis comme suit :

• Stable : bien testé, en usage actif et ne changera pas de manière incompatible avec les versions antérieures.
• Bêta : testé et peu susceptible de changer de manière incompatible avec les versions antérieures.
• Alpha : peut ne pas être testé par les principaux mainteneurs et est susceptible de changer de manière incompatible avec les versions antérieures.

Tous les changements ou dépréciations des fonctionnalités des connecteurs seront annoncés dans les notes de version.

Documentation

Consultez la documentation officielle pour les guides de démarrage, de configuration et d'utilisation.

Signaler une vulnérabilité

Veuillez consulter notre politique de sécurité pour plus de détails sur la façon de signaler des vulnérabilités.

Obtenir de l'aide

• Pour les demandes de fonctionnalités et les bogues, ouvrez une issue.
• Pour une discussion générale sur l'utilisation et le développement de Dex :
  • rejoignez le #dexidp sur le Slack de la CNCF
  • ouvrez une nouvelle discussion

Contribuer

Veuillez consulter CONTRIBUTING.md pour la configuration de développement, les directives et la façon de soumettre des pull requests.

Licence

Le projet est sous licence Apache License, Version 2.0.