Em qualquer grande empresa, e o X5 Retail Group não é exceção, à medida que o desenvolvimento avança, aumenta o número de projetos que requerem autorização do usuário. Com o tempo, é necessária uma transição perfeita dos usuários de um aplicativo para outro e, em seguida, há a necessidade de usar um único servidor Single-Sing-On (SSO). Mas o que fazer quando provedores de identidade como AD ou outros que não possuem atributos adicionais já são utilizados em diversos projetos. Uma classe de sistemas chamada “corretores de identidade” virá em socorro. Os mais funcionais são seus representantes, como Keycloak, gerenciamento de acesso Gravitee, etc. Na maioria das vezes, os cenários de uso podem ser diferentes: interação da máquina, participação do usuário, etc. e tal solução Nossa empresa agora conta com uma corretora de indicação – Keycloak.
Keycloak é um produto de identidade e controle de acesso de código aberto mantido pela RedHat. É a base dos produtos da empresa utilizando SSO - RH-SSO.
Conceitos Básicos
Antes de começar a entender soluções e abordagens, você deve definir os termos e a sequência dos processos:
Identificação é um procedimento para reconhecer um sujeito pelo seu identificador (ou seja, é determinar um nome, login ou número).
Autenticação – este é um procedimento de autenticação (o usuário é verificado por meio de uma senha, a carta é verificada por meio de uma assinatura eletrônica, etc.)
Autorização - trata-se do fornecimento de acesso a um recurso (por exemplo, ao e-mail).
Corretor de identidade Keycloak
Manto-chave é uma solução de gerenciamento de identidade e acesso de código aberto projetada para uso em SI onde padrões de arquitetura de microsserviços podem ser usados.
Keycloak oferece recursos como logon único (SSO), identidade intermediada e login social, federação de usuários, adaptadores de cliente, console de administração e console de gerenciamento de contas.
Funcionalidade básica suportada no Keycloak:
- Login único e logout único para aplicativos de navegador.
- Suporte para OpenID/OAuth 2.0/SAML.
- Identity Brokering – autenticação usando provedores de identidade externos OpenID Connect ou SAML.
- Login social - suporte do Google, GitHub, Facebook, Twitter para identificação do usuário.
- Federação de usuários - sincronização de usuários de servidores LDAP e Active Directory e outros provedores de identidade.
- Ponte Kerberos – uso de um servidor Kerberos para autenticação automática do usuário.
- Admin Console - para gerenciamento unificado de configurações e opções de solução pela Web.
- Console de gerenciamento de contas – para gerenciamento independente de perfis de usuários.
- Customização da solução com base na identidade corporativa da empresa.
- Autenticação 2FA - suporte TOTP/HOTP usando Google Authenticator ou FreeOTP.
- Fluxos de login - autorregistro de usuário, recuperação e redefinição de senha e outros são possíveis.
- Gerenciamento de sessões – os administradores podem gerenciar as sessões dos usuários a partir de um único ponto.
- Token Mappers – vinculação de atributos de usuário, funções e outros atributos necessários em tokens.
- Gerenciamento flexível de políticas entre domínios, aplicativos e usuários.
- Suporte CORS – Os adaptadores cliente têm suporte nativo a CORS.
- Interfaces de provedor de serviços (SPI) – Um grande número de SPIs que permitem personalizar vários aspectos do servidor: fluxos de autenticação, provedores de identidade, mapeamento de protocolo e muito mais.
- Adaptadores cliente para aplicações JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Suporte para trabalhar com vários aplicativos que suportam a biblioteca OpenID Connect Relying Party ou a biblioteca SAML 2.0 Service Provider.
- Expansível usando plug-ins.
Para processos CI/CD, bem como automação de processos de gerenciamento no Keycloak, pode ser utilizada a API REST/API JAVA. A documentação está disponível eletronicamente:
API REST
API JAVA
Provedores de identidade empresarial (no local)
Possibilidade de autenticação de usuários através de serviços de Federação de Usuários.
A autenticação pass-through também pode ser usada - se os usuários se autenticarem em estações de trabalho com Kerberos (LDAP ou AD), eles poderão ser autenticados automaticamente no Keycloak sem a necessidade de inserir seu nome de usuário e senha novamente.
Para autenticação e posterior autorização dos usuários, é possível utilizar um SGBD relacional, mais aplicável para ambientes de desenvolvimento, pois não envolve configurações e integrações demoradas nas fases iniciais dos projetos. Por padrão, Keycloak usa um DBMS integrado para armazenar configurações e dados do usuário.
A lista de SGBDs suportados é extensa e inclui: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e outros. Os mais testados até agora são o cluster Oracle 12C Release1 RAC e Galera 3.12 para MariaDB 10.1.19.
Provedores de identidade – login social
É possível utilizar login de redes sociais. Para ativar a capacidade de autenticar usuários, use o console de administração Keycloack. Não são necessárias alterações no código do aplicativo e esta funcionalidade está disponível imediatamente e pode ser ativada em qualquer estágio do projeto.
Para autenticar usuários, é possível usar provedores de identidade OpenID/SAML.
Cenários típicos de autorização usando OAuth2 no Keycloak
Fluxo de código de autorização - usado com aplicativos do lado do servidor. Um dos tipos mais comuns de permissão de autorização porque é adequado para aplicativos de servidor onde o código-fonte do aplicativo e os dados do cliente não estão disponíveis para terceiros. O processo neste caso é baseado no redirecionamento. O aplicativo deve ser capaz de se comunicar com um agente de usuário (user-agent), como um navegador da web - para receber códigos de autorização de API redirecionados por meio do agente de usuário.
fluxo implícito - usado por aplicativos móveis ou web (aplicativos executados no dispositivo do usuário).
O tipo de permissão de autorização implícita é usado por aplicativos móveis e web onde a privacidade do cliente não pode ser garantida. O tipo de permissão implícita também usa o redirecionamento do agente do usuário, onde o token de acesso é passado ao agente do usuário para uso posterior no aplicativo. Isso disponibiliza o token para o usuário e outros aplicativos no dispositivo do usuário. Este tipo de permissão de autorização não autentica a identidade da aplicação e o próprio processo depende da URL de redirecionamento (previamente registrada no serviço).
O fluxo implícito não oferece suporte a tokens de atualização de token de acesso.
Fluxo de concessão de credenciais do cliente — usado quando o aplicativo acessa a API. Esse tipo de permissão de autorização normalmente é usado para interações entre servidores que devem ocorrer em segundo plano, sem interação imediata do usuário. O fluxo de concessão de credenciais do cliente permite que um serviço web (cliente confidencial) use suas próprias credenciais em vez de representar o usuário para autenticação ao chamar outro serviço web. Para um nível mais elevado de segurança, é possível que o serviço chamador utilize um certificado (em vez de um segredo partilhado) como credenciais.
A especificação OAuth2 é descrita em
Token JWT e seus benefícios
JWT (JSON Web Token) é um padrão aberto () que define uma maneira compacta e independente de transferir informações com segurança entre as partes como um objeto JSON.
De acordo com o padrão, o token consiste em três partes no formato base 64, separadas por pontos. A primeira parte é chamada de cabeçalho, que contém o tipo de token e o nome do algoritmo hash para obtenção da assinatura digital. A segunda parte armazena as informações básicas (usuário, atributos, etc.). A terceira parte é a assinatura digital.
. .
Nunca armazene um token em seu banco de dados. Como um token válido é equivalente a uma senha, armazenar o token é como armazenar a senha em texto não criptografado.
Token de acesso é um token que concede ao seu proprietário acesso a recursos seguros do servidor. Geralmente tem uma vida útil curta e pode conter informações adicionais, como o endereço IP da parte que solicita o token.
Atualizar token é um token que permite aos clientes solicitar novos tokens de acesso após o término de sua vida útil. Esses tokens geralmente são emitidos por um longo período.
As principais vantagens de usar uma arquitetura de microsserviços:
- Capacidade de acessar vários aplicativos e serviços por meio de autenticação única.
- Na ausência de uma série de atributos obrigatórios no perfil do usuário, é possível enriquecer com dados que podem ser adicionados à carga útil, inclusive automatizados e on-the-fly.
- Não há necessidade de armazenar informações sobre sessões ativas, a aplicação do servidor só precisa verificar a assinatura.
- Controle de acesso mais flexível por meio de atributos adicionais na carga útil.
- O uso de uma assinatura de token para o cabeçalho e a carga útil aumenta a segurança da solução como um todo.
Token JWT - composição
Título — por padrão, o cabeçalho contém apenas o tipo de token e o algoritmo usado para criptografia.
O tipo do token é armazenado na chave “typ”. A chave 'type' é ignorada no JWT. Se a chave "typ" estiver presente, seu valor deverá ser JWT para indicar que este objeto é um JSON Web Token.
A segunda chave “alg” especifica o algoritmo usado para criptografar o token. Por padrão, deve ser definido como HS256. O cabeçalho é codificado em base64.
{ "alg": "HS256", "tipo": "JWT"}
carga útil (conteúdo) — a carga útil armazena qualquer informação que precise ser verificada. Cada chave na carga útil é conhecida como "instrução". Por exemplo, você pode entrar no aplicativo 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 email pertence à pessoa que aceita o convite, por isso incluiremos esse endereço no payload armazenando-o na chave "email".
{ "e-mail": "[email protegido]"}
As chaves na carga útil podem ser arbitrárias. No entanto, existem alguns reservados:
- iss (Issuer) – Identifica a aplicação da qual o token está sendo enviado.
- sub (Assunto) - define o assunto do token.
- aud (Audience) é uma matriz de strings ou URIs que diferenciam maiúsculas de minúsculas que é uma lista dos destinatários desse token. Quando o lado receptor recebe um JWT com a chave fornecida, ele deve verificar sua presença nos destinatários - caso contrário, ignore o token.
- exp (Tempo de Expiração) - Indica quando o token expira. O padrão JWT exige que todas as suas implementações rejeitem tokens expirados. A chave exp deve ser um carimbo de data/hora no formato unix.
- nbf (Not Before) é um horário em formato unix que determina o momento em que o token se torna válido.
- iat (Emitido em) - Esta chave representa a hora em que o token foi emitido e pode ser usada para determinar a idade do JWT. A chave iat deve ser um carimbo de data/hora no formato unix.
- Jti (JWT ID) — uma string que define o identificador exclusivo deste token, diferenciando maiúsculas de minúsculas.
É importante entender que a carga não é transmitida de forma criptografada (embora os tokens possam ser aninhados e seja possível transmitir dados criptografados). Portanto, não pode armazenar nenhuma informação secreta. Assim como o cabeçalho, a carga útil é codificada em base64.
Assinatura - assim que tivermos um cabeçalho e uma carga útil, podemos calcular a assinatura.
O cabeçalho e a carga codificados em base64 são obtidos e combinados em uma linha separada por um ponto. Esta string e a chave secreta são então inseridas no algoritmo de criptografia especificado no cabeçalho (chave “alg”). A chave pode ser qualquer string. Sequências mais longas serão preferíveis, pois exigirão mais tempo para serem selecionadas.
{"alg":"RSA1_5","carga útil":"A128CBC-HS256"}
Construindo uma arquitetura de cluster de failover Keycloak
Ao usar um único cluster para todos os projetos, há requisitos maiores para uma solução SSO. Quando o número de projetos é pequeno, esses requisitos não são tão perceptíveis para todos os projetos, porém, com o aumento do número de usuários e integrações, os requisitos de disponibilidade e desempenho aumentam.
Aumentar o risco de falha de SSO único aumenta os requisitos para a arquitetura da solução e os métodos usados para componentes redundantes e leva a um SLA muito rígido. A este respeito, mais frequentemente durante o desenvolvimento ou nas fases iniciais de implementação de soluções, os projectos têm a sua própria infra-estrutura não tolerante a falhas. À medida que o desenvolvimento avança, é necessário estabelecer oportunidades de desenvolvimento e expansão. É mais flexível construir um cluster de failover usando virtualização de contêiner ou uma abordagem híbrida.
Para trabalhar nos modos de cluster Ativo/Ativo e Ativo/Passivo, é necessário garantir a consistência dos dados em um banco de dados relacional - ambos os nós do banco de dados devem ser replicados de forma síncrona entre diferentes data centers distribuídos geograficamente.
O exemplo mais simples de instalação tolerante a falhas.
Quais são os benefícios de usar um único cluster:
- Alta disponibilidade e desempenho.
- Modos de operação de suporte: Ativo/Ativo, Ativo/Passivo.
- Capacidade de escalar dinamicamente - ao usar a virtualização de contêineres.
- Possibilidade de gestão e monitorização centralizada.
- Uma abordagem unificada para identificar/autenticar/autorizar usuários em projetos.
- Interação mais transparente entre diferentes projetos sem envolvimento do usuário.
- A capacidade de reutilizar o token JWT em vários projetos.
- Ponto único de confiança.
- Lançamento mais rápido de projetos usando virtualização de microsserviços/contêineres (sem necessidade de levantar e configurar componentes adicionais).
- É possível adquirir suporte comercial do fornecedor.
O que considerar ao planejar um cluster
SGBD
Keycloak usa um sistema de gerenciamento DBMS para salvar: domínios, clientes, usuários, etc.
Uma ampla variedade de SGBDs é suportada: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vem com seu próprio banco de dados relacional integrado. Recomendado para uso em ambientes leves, como ambientes de desenvolvimento.
Para trabalhar nos modos de cluster Ativo/Ativo e Ativo/Passivo, é necessária consistência de dados em um banco de dados relacional e ambos os nós do cluster de banco de dados são replicados de forma síncrona entre data centers.
Cache distribuído (Infinspan)
Para que o cluster funcione corretamente, é necessária sincronização adicional dos seguintes tipos de caches usando o JBoss Data Grid:
Sessões de autenticação - usadas para salvar dados ao autenticar um usuário específico. As solicitações desse cache normalmente envolvem apenas o navegador e o servidor Keycloak, não o aplicativo.
Tokens de ação – usados para cenários onde o usuário precisa confirmar uma ação de forma assíncrona (via e-mail). Por exemplo, durante um fluxo de esquecimento de senha, o cache actionTokens do Infinispan é usado para rastrear metadados sobre tokens de ação associados que já foram usados, portanto, não podem ser reutilizados.
Cache e invalidação de dados persistentes – usado para armazenar dados persistentes em cache para evitar consultas desnecessárias ao banco de dados. Quando qualquer servidor Keycloak atualiza dados, todos os outros servidores Keycloak em todos os data centers devem saber disso.
Trabalho – Usado apenas para enviar mensagens de invalidação entre nós do cluster e data centers.
Sessões de usuário - usadas para armazenar dados sobre sessões de usuário válidas durante a sessão do navegador do usuário. O cache deve processar solicitações HTTP do usuário final e do aplicativo.
Proteção de força bruta - usada para rastrear dados sobre logins com falha.
Balanceamento de carga
O balanceador de carga é o único ponto de entrada para o keycloak e deve oferecer suporte a sessões fixas.
Servidores de aplicativos
Eles são usados para controlar a interação dos componentes entre si e podem ser virtualizados ou conteinerizados usando ferramentas de automação existentes e escalonamento dinâmico de ferramentas de automação de infraestrutura. Os cenários de implantação mais comuns estão em OpenShift, Kubernates, Rancher.
Isto conclui a primeira parte - a teórica. Na próxima série de artigos serão analisados exemplos de integrações com diversos provedores de identidade e exemplos de configurações.
Fonte: habr.com