dex - Un proveedor OpenID Connect federado

Dex es un servicio de identidad que utiliza [OpenID Connect][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-io] (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][standard-claims], 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][kubernetes]
• [AWS STS][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][scopes] o devolver claims de [pertenencia a grupos][scopes]. 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:

Nombre	Soporta tokens de actualización	Soporta claim de grupos	Soporta claim de preferred_username	Estado	Notas
LDAP	sí	sí	sí	estable
GitHub	sí	sí	sí	estable
SAML 2.0	no	sí	no	estable	ADVERTENCIA: Sin mantenimiento y probablemente vulnerable a evasiones de autenticación (#1884)
GitLab	sí	sí	sí	beta
OpenID Connect	sí	sí	sí	beta	Incluye Salesforce, Azure, etc.
OAuth 2.0	no	sí	sí	alpha
Google	sí	sí	sí	alpha
LinkedIn	sí	no	no	beta
Microsoft	sí	sí	no	beta
AuthProxy	no	sí	no	alpha	Proxies de autenticación como Apache2 mod_auth, etc.
Bitbucket Cloud	sí	sí	no	alpha
OpenShift	sí	sí	no	alpha
Atlassian Crowd	sí	sí	sí *	beta	El claim preferred_username debe configurarse mediante la configuración
Gitea	sí	no	sí	beta
OpenStack Keystone	sí	sí	no	alpha

Estable, beta y alpha se definen como: