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 a Dex diferir la autenticación a 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 vez para hablar con dex, luego dex maneja los protocolos para un backend determinado.
Los tokens de identificación son una extensión OAuth2 introducida por OpenID Connect y la característica principal de dex. Los tokens de identificación son tokens web JSON (JWT) firmados por dex y devueltos como parte de la respuesta OAuth2 que da fe de la identidad del usuario final. Un ejemplo de JWT podría verse así:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
Los tokens de identificación contienen afirmaciones estándar que afirman qué aplicación cliente inició la sesión del usuario, cuándo caduca 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 afirmaciones basadas en estándares, otros servicios pueden consumirlos como credenciales de servicio a servicio. Los sistemas que ya pueden consumir tokens de identificación de OpenID Connect emitidos por dex incluyen:
Para obtener detalles sobre cómo solicitar o validar un token de identificación, consulte "Escribir aplicaciones que usan dex" .
Dex se ejecuta de forma nativa sobre cualquier clúster de Kubernetes mediante definiciones de recursos personalizados y puede impulsar la autenticación del servidor API a través del complemento OpenID Connect. Los clientes, como kubernetes-dashboard
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 compatible con dex.
Cuando un usuario inicia sesión a través de dex, la identidad del usuario generalmente se almacena en otro sistema de administración de usuarios: un directorio LDAP, una organización de GitHub, etc. Dex actúa como un enlace 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 administración de usuarios.
Un "conector" es una estrategia utilizada por dex para autenticar a un usuario frente a 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 los conectores, las limitaciones en los protocolos pueden impedir que dex emita tokens de actualización o devuelva reclamos de membresía de grupo. Por ejemplo, debido a que SAML no proporciona una forma no interactiva de actualizar aserciones, si un usuario inicia sesión a través del conector SAML, dex no emitirá un token de actualización a su cliente. Se requiere compatibilidad con el token de actualización para los clientes que requieren acceso sin conexión, como kubectl
.
Dex implementa los siguientes conectores:
Nombre | admite tokens de actualización | apoya el reclamo de los grupos | admite reclamo de nombre de usuario preferido | 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 omisiones de autenticación (#1884) |
GitLab | Sí | Sí | Sí | beta | |
Conexión OpenID | Sí | Sí | Sí | beta | Incluye Salesforce, Azure, etc. |
OAuth 2.0 | No | Sí | Sí | alfa | |
Sí | Sí | Sí | alfa | ||
Sí | No | No | beta | ||
microsoft | Sí | Sí | No | beta | |
Proxy de autenticación | No | Sí | No | alfa | Proxies de autenticación como Apache2 mod_auth, etc. |
Nube de Bitbucket | Sí | Sí | No | alfa | |
Cambio abierto | Sí | Sí | No | alfa | |
Multitud atlassiana | Sí | Sí | Sí * | beta | El reclamo de nombre de usuario preferido debe configurarse a través de la configuración. |
casa rural | Sí | No | Sí | beta | |
Piedra angular de OpenStack | Sí | Sí | No | alfa |
Estable, beta y alfa se definen como:
Todos los cambios o desaprobaciones de las funciones del conector se anunciarán en las notas de la versión.
Consulte nuestra política de seguridad para obtener detalles sobre cómo informar vulnerabilidades.
Cuando finalice toda la codificación y las pruebas, ejecute el conjunto de pruebas:
make testall
Para obtener la mejor experiencia de desarrollador, instale Nix y direnv.
Alternativamente, instale Go y Docker manualmente o usando un administrador de paquetes. Instale el resto de las dependencias ejecutando make deps
.
Para conocer el proceso de lanzamiento, lea la documentación de lanzamiento.
El proyecto tiene la licencia Apache, versión 2.0.