Em qualquer grande empresa, e o X5 Retail Group não é exceção, à medida que se desenvolve, aumenta a quantidade de projetos onde é necessária a autorização de usuários. Com o tempo, há uma necessidade de transição sem costura dos usuários de um aplicativo para outro e, então, surge a necessidade de usar um servidor único de Single-Sign-On (SSO). Mas como proceder quando provedores de identificação como AD ou outros, que não possuem atributos adicionais, já estão sendo usados em diversos projetos? A solução pode ser encontrada na classe de sistemas chamada 'brokers de identidade'. Os representantes mais funcionais incluem, por exemplo, Keycloak, Gravitee Access Management, entre outros. Os cenários de uso podem variar: interação entre máquinas, participação de usuários, etc. A solução deve suportar funcionalidades flexíveis e escaláveis, capazes de reunir todos os requisitos em uma única plataforma, e a solução em nossa empresa atualmente é o broker de identidade - Keycloak.
Keycloak é um produto de código aberto projetado para identificação e controle de acesso, mantido pela RedHat. Ele é a base dos produtos da empresa que utilizam SSO - RH-SSO.
Conceitos principais
Antes de começar a entender as soluções e abordagens, é necessário definir os termos e a sequência dos processos:
Identificação — é o procedimento de reconhecimento de um sujeito por seu identificador (em termos simples, é a definição do nome, login ou número).
Autenticação — é o procedimento de autenticação (o usuário é verificado por meio de uma senha, o e-mail é verificado por assinatura eletrônica, etc.)
Autorização — é a concessão de acesso a um recurso (por exemplo, ao e-mail).
Broker de Identidade Keycloak
Keycloak — é uma solução para gerenciamento de identidade e acesso de código aberto, destinada a ser usada em sistemas de informação onde podem ser aplicados padrões de arquitetura de microsserviços.
Keycloak oferece recursos como logon único (SSO), identificação de broker, login social, federação de usuários, adaptadores de cliente, console de administração e console de gerenciamento de contas.
Funcionalidade básica suportada pelo Keycloak:
- Single-Sign On e Single-Sign Out para aplicativos de navegador.
- Suporte para OpenID/OAuth 2.0/SAML.
- Intermediação de Identidade – autenticação através de provedores de identidade externos OpenID Connect ou SAML.
- Login Social – suporte a Google, GitHub, Facebook, Twitter para identificação de usuários.
- Federação de Usuários – sincronização de usuários a partir de servidores LDAP e Active Directory e outros provedores de identidade.
- Ponte Kerberos – utilização de servidor Kerberos para autenticação automática de usuários.
- Console de Administração — para gerenciamento centralizado de configurações e parâmetros da solução via Web.
- Console de Gerenciamento de Contas – para gerenciamento autônomo do perfil dos usuários.
- Customização da solução com base na identidade visual da empresa.
- Autenticação 2FA – suporte a TOTP/HOTP com Google Authenticator ou FreeOTP.
- Fluxos de Login – possibilidade de auto-registro de usuários, recuperação e redefinição de senha, entre outros.
- Gerenciamento de Sessões – administradores podem gerenciar sessões de usuários a partir de um ponto único.
- Mapeadores de Token – vinculação de atributos de usuários, funções e outros atributos necessários em tokens.
- Gerenciamento flexível de políticas através de realms, aplicações e usuários.
- Suporte CORS – adaptadores de cliente têm suporte integrado para CORS.
- Interfaces de Provedor de Serviço (SPI) – uma grande quantidade de SPIs que permitem configurar vários aspectos da operação do servidor: fluxos de autenticação, provedores de identidade, mapeamento de protocolos e muito mais.
- Adaptadores de cliente para aplicações JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Suporte a várias aplicações que utilizam a biblioteca OpenID Connect Relying Party ou a biblioteca SAML 2.0 Service Provider.
- Possibilidade de extensão com o uso de plugins.
Para processos de CI/CD, assim como automação de processos de gerenciamento no Keycloak, pode ser utilizado REST API/JAVA API. A documentação está disponível em formato eletrônico:
REST API
JAVA API
Provedores de identidade de nível empresarial (On-Premise)
Possibilidade de autenticação de usuários através de serviços de Federação de Usuários.
Autenticação única também pode ser utilizada — se os usuários se autenticarem em estações de trabalho com Kerberos (LDAP ou AD), poderão ser autenticados automaticamente no Keycloak sem necessidade de inserir novamente seu nome de usuário e senha.
Para autenticação e autorização contínua de usuários, é possível usar um banco de dados relacional, o que é mais aplicado em ambientes de desenvolvimento, pois não requer configurações e integrações longas nas fases iniciais dos projetos. Por padrão, o Keycloak utiliza um banco de dados embutido para armazenar configurações e dados de usuários.
A lista de bancos de dados suportados é extensa e inclui: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e outros. Os mais testados até o momento são o Oracle 12C Release1 RAC e o Galera 3.12 cluster para MariaDB 10.1.19.
Provedores de identidade — login social
É possível usar credenciais de redes sociais. Para ativar a autenticação de usuários, utiliza-se o console do administrador do Keycloak. Não são necessárias alterações no código das aplicações, e essa funcionalidade está disponível 'pronta para uso' e pode ser ativada em qualquer estágio de implementação do projeto.
Para autenticação de usuários, é possível utilizar provedores de identidade OpenID/SAML.
Cenários típicos de autorização com uso de OAuth2 no Keycloak
Fluxo de Código de Autorização — utilizado com aplicações de servidor (server-side applications). Um dos tipos mais comuns de autorização, pois se adapta bem a aplicações de servidor, onde o código-fonte e os dados do cliente não estão acessíveis externamente. O processo é baseado em redirecionamento. A aplicação deve ser capaz de interagir com o agente do usuário (user-agent), como um navegador da web — recebendo códigos de autorização da API redirecionados através do agente do usuário.
Fluxo Implícito — utilizado por aplicações móveis ou da web (aplicações que operam no dispositivo do usuário).
O tipo de autorização implícita é utilizado por aplicativos móveis e da web, onde a privacidade do cliente não pode ser garantida. Este tipo de autorização também utiliza o redirecionamento do agente do usuário, onde o token de acesso é passado para o agente do usuário para uso posterior no aplicativo. Isso torna o token acessível ao usuário e a outros aplicativos no dispositivo do usuário. Nesse tipo de autorização, não há autenticação da autenticidade do aplicativo, e o próprio processo depende da URL de redirecionamento (registrada anteriormente no serviço).
O Fluxo Implícito não suporta tokens de atualização do token de acesso (refresh tokens).
Fluxo de Client Credentials Grant — é usado para acesso do aplicativo à API. Este tipo de autorização é geralmente utilizado para interações 'servidor-servidor', que devem ser executadas em segundo plano sem interação imediata com o usuário. O Fluxo de Credenciais do Cliente permite que um serviço da web (cliente confidencial) utilize suas próprias credenciais em vez da representação do usuário para autenticação ao chamar outro serviço da web. Para um nível mais alto de segurança, o serviço chamador pode usar um certificado (em vez de um segredo compartilhado) como credenciais.
A especificação OAuth2 é descrita em
Token JWT e suas vantagens
JWT (JSON Web Token) é um padrão aberto (), que define uma forma compacta e autônoma para a transmissão segura de informações entre as partes na forma de um objeto JSON.
De acordo com o padrão, o token consiste em três partes em formato base-64, separadas por pontos. A primeira parte é chamada de cabeçalho (header), que contém o tipo de token e o nome do algoritmo de hash para criação da assinatura digital. A segunda parte armazena as informações principais (usuário, atributos etc.). A terceira parte – a assinatura digital.
..
Nunca armazene o token em seu banco de dados. Pois um token válido é equivalente a uma senha, armazenar um token é como guardar uma senha em texto claro.
Token de acesso — é um token que fornece ao seu proprietário acesso a recursos protegidos do servidor. Normalmente, possui um tempo de vida curto e pode conter informações adicionais, como o endereço IP da parte que solicita este token.
Token de atualização — é um token que permite aos clientes solicitar novos tokens de acesso após o vencimento do prazo de validade. Esses tokens geralmente são emitidos por um longo período.
Principais vantagens da aplicação na arquitetura de microsserviços:
- Possibilidade de acesso a diferentes aplicações e serviços por meio de uma única autenticação.
- Na ausência de vários atributos necessários no perfil dos usuários, é possível enriquecer com dados que podem ser adicionados à carga útil, inclusive de forma automatizada e 'on-the-fly'.
- Não há necessidade de armazenar informações sobre sessões ativas, a aplicação do servidor apenas deve verificar a assinatura.
- Gerenciamento de acesso mais flexível devido a atributos adicionais na carga útil.
- O uso da assinatura do token para o cabeçalho e a carga útil aumenta a segurança da solução como um todo.
Token JWT — composição
Cabeçalho — por padrão, o cabeçalho contém apenas o tipo de token e o algoritmo usado para a criptografia.
O tipo de token é armazenado na chave 'typ'. A chave 'typ' é ignorada no JWT. Se a chave 'typ' estiver presente, seu valor deve ser JWT para indicar que este objeto é um JSON Web Token.
A segunda chave 'alg' define o algoritmo utilizado para criptografar o token. Por padrão, deve ser configurado para HS256. O cabeçalho é codificado em base64.
{ "alg": "HS256", "typ": "JWT"}
Carga útil (conteúdo) — na carga útil, armazena-se qualquer informação que precise ser verificada. Cada chave na carga útil é conhecida como 'declaração'. Por exemplo, em uma aplicação pode-se entrar apenas por convite (promoção fechada). Quando queremos convidar alguém para participar, enviamos um e-mail de convite. É importante verificar se o endereço de e-mail pertence à pessoa que aceita o convite, portanto, incluiremos esse endereço na carga útil, para isso o salvaremos na chave 'e-mail'
{ "email": "example@x5.ru" }
As chaves na carga útil podem ser arbitrárias. No entanto, existem algumas reservadas:
- iss (Emissor) — define a aplicação da qual o token é enviado.
- sub (Assunto) — define o tema do token.
- aud (Público) – um array de strings ou URIs que diferencia maiúsculas de minúsculas, sendo uma lista de destinatários deste token. Quando a parte receptora recebe o JWT com esta chave, ela deve verificar sua presença entre os destinatários — caso contrário, deve ignorar o token.
- exp (Tempo de Expiração) — indica quando o token expira. O padrão JWT requer que em todas as suas implementações tokens expirados sejam rejeitados. A chave exp deve ser um timestamp em formato unix.
- nbf (Não Antes) — este tempo em formato unix define o momento quando o token se tornará válido.
- iat (Emitido Em) — esta chave representa o tempo em que o token foi emitido e pode ser usada para determinar a idade do JWT. A chave iat deve ser um timestamp em formato unix.
- jti (ID do JWT) — uma string que define um identificador único para este token, sendo sensível a maiúsculas e minúsculas.
É importante entender que a carga útil não é transmitida de forma criptografada (embora os tokens possam ser aninhados e permitir a transmissão de dados criptografados). Portanto, não se pode armazenar informações secretas nela. Assim como o cabeçalho, a carga útil é codificada em base64.
Assinatura — quando temos o cabeçalho e a carga útil, podemos calcular a assinatura.
Os dados codificados em base64: cabeçalho e carga útil são combinados em uma string através de um ponto. Em seguida, esta string e a chave secreta são passadas como entrada para o algoritmo de criptografia especificado no cabeçalho (chave "alg"). A chave pode ser qualquer string. Strings mais longas serão preferíveis, pois levará mais tempo para serem quebradas.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Construção da arquitetura de um cluster de Keycloak resistente a falhas
Ao usar um único cluster para todos os projetos, surgem exigências maiores para a solução de SSO. Quando o número de projetos é pequeno, essas exigências não são tão perceptíveis em todos os projetos, no entanto, à medida que o número de usuários e integrações aumenta, as exigências de disponibilidade e desempenho crescem.
O aumento dos riscos de falha do SSO único eleva as exigências para a arquitetura da solução e os métodos de reserva de componentes utilizados, resultando em um SLA muito rigoroso. Devido a isso, é comum que, na fase de desenvolvimento ou nas etapas iniciais de implementação das soluções, os projetos possuam sua própria infraestrutura não tolerante a falhas. À medida que evolui, é necessário incorporar capacidades de desenvolvimento e escalabilidade. A construção de um cluster tolerante a falhas é mais flexível com o uso de virtualização em contêineres ou de uma abordagem híbrida.
Para operar em modo Active/Active e Active/Passive, o cluster requer a garantia da consistência dos dados na base de dados relacional — ambos os nós da base de dados devem ser replicados de forma síncrona entre diferentes data centers geograficamente distribuídos.
O exemplo mais simples de uma instalação tolerante a falhas.
Quais são as vantagens de usar um cluster único:
- Alta disponibilidade e desempenho.
- Suporte a modos de operação: Active/Active, Active/Passive.
- Capacidade de escalabilidade dinâmica — ao usar virtualização em contêineres.
- Capacidade de gestão e monitoramento centralizados.
- Uma abordagem única para a identificação/autenticação/autorização de usuários em projetos.
- Interações mais transparentes entre diferentes projetos sem a participação dos usuários.
- Capacidade de reutilizar o token JWT em diferentes projetos.
- Um único ponto de confiança.
- Implantação mais rápida de projetos com o uso de microsserviços/virtualização em contêineres (não é necessário configurar componentes adicionais).
- Possibilidade de aquisição de suporte comercial do fornecedor.
O que observar ao planejar o cluster
SGBD
Keycloak utiliza um sistema de gerenciamento de SGBD para armazenar: realms, clients, users, etc.
É suportado um amplo espectro de SGBDs: MS SQL, Oracle, MySQL, PostgreSQL. O Keycloak vem com um banco de dados relacional próprio integrado. É recomendado para ambientes de baixa carga — como ambientes de desenvolvimento.
Para operar em modo Active/Active e Active/Passive, é necessário garantir a consistência dos dados na base de dados relacional e ambos os nós do cluster de banco de dados são replicados de forma síncrona entre os data centers.
Cache distribuído (Infinispan)
Para o funcionamento correto do cluster, é necessária a sincronização adicional dos seguintes tipos de cache usando o JBoss Data Grid:
Sessões de autenticação — utilizadas para armazenar dados durante a autenticação de um usuário específico. As requisições desse cache geralmente incluem apenas o navegador e o servidor Keycloak, e não o aplicativo.
Tokens de ação — são utilizados para cenários em que o usuário precisa confirmar uma ação de forma assíncrona (por e-mail). Por exemplo, durante o fluxo de recuperação de senha, o cache actionTokens Infinispan é usado para rastrear metadados sobre os tokens de ação relacionados que já foram utilizados, portanto, eles não podem ser reutilizados.
Cache e invalidação de dados persistentes – usado para armazenar em cache dados permanentes, evitando requisições desnecessárias ao banco de dados. Quando algum servidor Keycloak atualiza dados, todos os outros servidores Keycloak em todos os data centers devem ser informados sobre isso.
Trabalho — usado apenas para enviar mensagens de invalidação entre os nós do cluster e os data centers.
Sessões de usuário — utilizadas para armazenar dados sobre as sessões do usuário, que são válidas durante a sessão do navegador do usuário. O cache deve tratar requisições HTTP do usuário final e do aplicativo.
Proteção contra força bruta — usada para rastrear dados sobre tentativas de login malsucedidas.
O balanceamento de carga
O balanceador de carga é o único ponto de entrada no Keycloak e deve suportar sessões persistentes.
Servidores de aplicativos
Usados para controlar a interação entre os componentes e podem ser virtualizados ou containerizados com o uso de ferramentas de automação existentes e escalonamento dinâmico de infraestrutura. Os cenários de implantação mais comuns são no OpenShift, Kubernetes, Rancher.
Aqui termina a primeira parte — a teórica. Nos próximos ciclos de artigos, serão discutidos exemplos de integrações com diversos provedores de identidade e exemplos de configurações.
Fonte: habr.com
