dex
v2.41.1
Dex é um serviço de identidade que usa OpenID Connect para gerar autenticação para outros aplicativos.
Dex atua como um portal para outros provedores de identidade por meio de “conectores”. Isso permite que o dex adie a autenticação para servidores LDAP, provedores SAML ou provedores de identidade estabelecidos como GitHub, Google e Active Directory. Os clientes escrevem sua lógica de autenticação uma vez para conversar com dex e, em seguida, dex lida com os protocolos para um determinado back-end.
ID Tokens são uma extensão OAuth2 introduzida pelo OpenID Connect e o principal recurso do dex. Os ID Tokens são JSON Web Tokens (JWTs) assinados por dex e retornados como parte da resposta OAuth2 que atesta a identidade do usuário final. Um exemplo de JWT pode ser parecido com:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
Os tokens de ID contêm declarações padrão que afirmam qual aplicativo cliente conectou o usuário, quando o token expira e a identidade do usuário.
{
"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 "
}Como esses tokens são assinados por dex e contêm declarações baseadas em padrões, outros serviços podem consumi-los como credenciais de serviço a serviço. Os sistemas que já podem consumir tokens OpenID Connect ID emitidos pela dex incluem:
Para obter detalhes sobre como solicitar ou validar um token de ID, consulte "Escrever aplicativos que usam dex" .
O Dex é executado nativamente em qualquer cluster Kubernetes usando definições de recursos personalizadas e pode conduzir a autenticação do servidor API por meio do plug-in OpenID Connect. Clientes, como kubernetes-dashboard e kubectl , podem agir em nome de usuários que podem fazer login no cluster por meio de qualquer provedor de identidade compatível com dex.
Quando um usuário faz login por meio de dex, a identidade do usuário geralmente é armazenada em outro sistema de gerenciamento de usuários: um diretório LDAP, uma organização GitHub, etc. Dex atua como uma correção entre um aplicativo cliente e o provedor de identidade upstream. O cliente só precisa entender o OpenID Connect para consultar o dex, enquanto o dex implementa uma série de protocolos para consultar outros sistemas de gerenciamento de usuários.
Um "conector" é uma estratégia usada pelo dex para autenticar um usuário em outro provedor de identidade. Dex implementa conectores direcionados a plataformas específicas, como GitHub, LinkedIn e Microsoft, bem como protocolos estabelecidos como LDAP e SAML.
Dependendo das limitações dos conectores nos protocolos, pode impedir que o dex emita tokens de atualização ou retorne reivindicações de associação ao grupo. Por exemplo, como o SAML não fornece uma maneira não interativa de atualizar asserções, se um usuário fizer login por meio do conector SAML dex não emitirá um token de atualização para seu cliente. O suporte ao token de atualização é necessário para clientes que exigem acesso offline, como kubectl .
Dex implementa os seguintes conectores:
| Nome | suporta tokens de atualização | apoia reivindicação de grupos | suporta reivindicação preferencial_username | status | notas |
|---|---|---|---|---|---|
| LDAP | sim | sim | sim | estável | |
| GitHub | sim | sim | sim | estável | |
| SAML2.0 | não | sim | não | estável | AVISO: Sem manutenção e provavelmente vulnerável a desvios de autenticação (#1884) |
| GitLab | sim | sim | sim | beta | |
| Conexão OpenID | sim | sim | sim | beta | Inclui Salesforce, Azure, etc. |
| OAuth 2.0 | não | sim | sim | alfa | |
| sim | sim | sim | alfa | ||
| sim | não | não | beta | ||
| Microsoft | sim | sim | não | beta | |
| AuthProxy | não | sim | não | alfa | Proxies de autenticação como Apache2 mod_auth, etc. |
| Nuvem Bitbucket | sim | sim | não | alfa | |
| OpenShift | sim | sim | não | alfa | |
| Multidão Atlassiana | sim | sim | sim * | beta | A reivindicação preferencial_username deve ser configurada por meio de configuração |
| Gitea | sim | não | sim | beta | |
| Pedra angular do OpenStack | sim | sim | não | alfa |
Estável, beta e alfa são definidos como:
Todas as alterações ou descontinuações dos recursos do conector serão anunciadas nas notas de lançamento.
Consulte nossa política de segurança para obter detalhes sobre como relatar vulnerabilidades.
Quando toda a codificação e testes estiverem concluídos, execute o conjunto de testes:
make testallPara obter a melhor experiência do desenvolvedor, instale Nix e direnv.
Alternativamente, instale Go e Docker manualmente ou usando um gerenciador de pacotes. Instale o restante das dependências executando make deps .
Para o processo de lançamento, leia a documentação de lançamento.
O projeto está licenciado sob a Licença Apache, Versão 2.0.
