dex - Un proveedor OpenID Connect federado

Dex es un servicio de identidad que utiliza OpenID Connect para impulsar la autenticación de otras aplicaciones.

Dex actúa como un portal hacia otros proveedores de identidad a través de "conectores". Esto permite que dex delegue la autenticación en servidores LDAP, proveedores SAML o proveedores de identidad establecidos como GitHub, Google y Active Directory. Los clientes escriben su lógica de autenticación una sola vez para comunicarse con dex, y luego dex maneja los protocolos para un backend determinado.

Tokens de ID

Los tokens de ID son una extensión de OAuth2 introducida por OpenID Connect y la característica principal de dex. Los tokens de ID son JSON Web Tokens (JWT) firmados por dex y devueltos como parte de la respuesta OAuth2 que certifica la identidad del usuario final. Un ejemplo de JWT podría tener este aspecto:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg

Los tokens de ID contienen claims estándar que indican qué aplicación cliente inició la sesión del usuario, cuándo expira el token y la identidad del usuario.

{
  "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"
}

Debido a que estos tokens están firmados por dex y contienen claims basados en estándares, otros servicios pueden consumirlos como credenciales de servicio a servicio. Los sistemas que ya pueden consumir tokens de ID de OpenID Connect emitidos por dex incluyen:

• Kubernetes
• AWS STS

Para obtener detalles sobre cómo solicitar o validar un token de ID, consulta "Creación de aplicaciones que usan dex".

Kubernetes y Dex

Dex se ejecuta de forma nativa sobre cualquier clúster de Kubernetes utilizando Custom Resource Definitions y puede impulsar la autenticación del servidor de API a través del plugin de OpenID Connect. Los clientes, como kubelogin y kubectl, pueden actuar en nombre de los usuarios que pueden iniciar sesión en el clúster a través de cualquier proveedor de identidad que dex soporte.

• Puedes encontrar más documentación sobre cómo ejecutar dex como autenticador de Kubernetes aquí.
• Puedes encontrar más información sobre empresas y proyectos que usan dex, aquí.

Conectores

Cuando un usuario inicia sesión a través de dex, la identidad del usuario generalmente se almacena en otro sistema de gestión de usuarios: un directorio LDAP, una organización de GitHub, etc. Dex actúa como un intermediario entre una aplicación cliente y el proveedor de identidad ascendente. El cliente solo necesita comprender OpenID Connect para consultar a dex, mientras que dex implementa una variedad de protocolos para consultar otros sistemas de gestión de usuarios.

Un "conector" es una estrategia utilizada por dex para autenticar a un usuario contra otro proveedor de identidad. Dex implementa conectores dirigidos a plataformas específicas como GitHub, LinkedIn y Microsoft, así como protocolos establecidos como LDAP y SAML.

Dependiendo de las limitaciones de los conectores en los protocolos, dex puede verse impedido de emitir tokens de actualización o devolver claims de pertenencia a grupos. Por ejemplo, dado que SAML no proporciona una forma no interactiva de renovar las aserciones, si un usuario inicia sesión a través del conector SAML, dex no emitirá un token de actualización a su cliente. El soporte de tokens de actualización es necesario para los clientes que requieren acceso sin conexión, como kubectl.

Dex implementa los siguientes conectores:

Estable, beta y alpha se definen como:

• Estable: bien probado, en uso activo y no cambiará de maneras incompatibles con versiones anteriores.
• Beta: probado y con pocas probabilidades de cambiar de maneras incompatibles con versiones anteriores.
• Alpha: puede no estar probado por los mantenedores principales y está sujeto a cambios de maneras incompatibles con versiones anteriores.

Todos los cambios o desaprobaciones de características de los conectores se anunciarán en las notas de versión.

Documentación

Consulta la documentación oficial para guías de inicio, configuración y uso.

Notificar una vulnerabilidad

Consulta nuestra política de seguridad para obtener detalles sobre cómo notificar vulnerabilidades.

Obtener ayuda

• Para solicitudes de funciones y errores, abre un issue.
• Para discusión general sobre el uso y el desarrollo de Dex:
  • únete al #dexidp en el Slack de CNCF
  • abre una nueva discusión

Contribuciones

Consulta CONTRIBUTING.md para la configuración de desarrollo, las pautas y cómo enviar pull requests.

Licencia

El proyecto está licenciado bajo la Apache License, Versión 2.0.