👨🏾‍🤝‍👨🏻 👩‍✈️ 🧐 SSO na arquitetura de microsserviço. Usamos Keycloak. Número da peça 1 🧚🏽 ✈️ 🚻

Em qualquer empresa grande, o X5 Retail Group não é exceção, pois o número de projetos em que a autenticação do usuário é necessária aumenta à medida que o número de projetos aumenta. Com o tempo, é necessária uma transição contínua de usuários de um aplicativo para outro e, em seguida, é necessário usar um único servidor Single-Sing-On (SSO). Mas e quando provedores de identidade como o AD ou outros que não possuem atributos adicionais já são usados em vários projetos. Uma classe de sistemas chamados "agentes de identidade" virá em socorro. Os mais funcionais são seus representantes, como Keycloak, gerenciamento de Gravitee Access, etc. Na maioria das vezes, os cenários de uso podem ser diferentes: interação da máquina, participação do usuário etc. A solução deve oferecer suporte a funcionalidades flexíveis e escalonáveis,capaz de combinar todos os requisitos em um, e essa solução em nossa empresa agora é um corretor de indicadores - Keycloak.

Keycloak é um produto de código aberto para autenticação e controle de acesso suportado pelo RedHat. É a base para os produtos da empresa usando SSO - RH-SSO.

Conceitos Básicos

Antes de começar a lidar com decisões e abordagens, você deve determinar os termos e a sequência de processos:

Identificação é o processo de reconhecimento de um assunto por seu identificador (em outras palavras, é determinar um nome, login ou número).

A autenticação é um procedimento de autenticação (o usuário é verificado com uma senha, o email é verificado por assinatura eletrônica, etc.)

Autorização é o fornecimento de acesso a algum recurso (por exemplo, email).

Corretor de identidade de Keycloak

O Keycloak é uma solução de gerenciamento de acesso e identidade de código aberto projetada para uso em ICs onde padrões de arquitetura de microsserviço podem ser usados.

O Keycloak oferece recursos como logon único (SSO), identificação do broker e logon social, federação de usuários, adaptadores de clientes, um console de administrador e um console de gerenciamento de contas.

Funcionalidade básica suportada no Keycloak:

Conexão única e saída única para aplicativos baseados no navegador.
Suporte para OpenID / OAuth 2.0 / SAML.
Corretagem de identidade - autenticação usando provedores de identidade externos do OpenID Connect ou SAML.
Login social - suporte para Google, GitHub, Facebook, Twitter para identificação do usuário.
User Federation – LDAP Active Directory .
Kerberos bridge – Kerberos .
Admin Console — Web.
Account Management Console – .
.
2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
Login Flows – , .
Session Management – .
Token Mappers – , .
realm, application .
CORS Support – CORS.
Service Provider Interfaces (SPI) – SPI, : , , .
JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
, OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
plugins.

Para processos de CI / CD, bem como a automação de processos de gerenciamento no Keycloak, a API REST API / JAVA pode ser usada. A documentação está disponível em formato eletrônico:

API REST https://www.keycloak.org/docs-api/8.0/rest-api/index.html
API JAVA https://www.keycloak.org/docs-api/8.0/javadocs /index.html

Provedores de identidade corporativa (no local)

A capacidade de autenticar usuários através dos serviços de Federação de Usuário.

A autenticação de passagem 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 com o Keycloak sem precisar digitar novamente o nome de usuário e a senha.

Para autenticação e autorização adicional dos usuários, é possível usar um DBMS relacional, o mais aplicável aos ambientes de desenvolvimento, pois não implica configurações e integrações de longo prazo nos estágios iniciais dos projetos. Por padrão, o Keycloak usa um DBMS interno para armazenar configurações e dados do usuário.

A lista de DBMSs suportados é extensa e inclui: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e outros. Os mais testados no momento são o cluster Oracle 12C Release1 RAC e Galera 3.12 para MariaDB 10.1.19.

Provedores de identidade - login social

É possível usar um login nas redes sociais. Para ativar a capacidade de autenticar usuários, o console administrativo do Keycloack é usado. Alterações no código do aplicativo não são necessárias e essa funcionalidade está disponível "pronta para uso" 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 o OAuth2 no Keycloak

Fluxo do código de autorização - usado com aplicativos do lado do servidor. Um dos tipos mais comuns de permissões de autorização, pois é adequado para aplicativos de servidor nos quais o código-fonte do aplicativo e os dados do cliente não estão acessíveis a pessoas de fora. O processo neste caso é baseado no redirecionamento. O aplicativo deve poder interagir com o agente do usuário (agente do usuário), como um navegador da Web - para receber códigos de autorização da API redirecionados pelo agente do usuário.

Fluxo implícito - usado por aplicativos móveis ou da Web (aplicativos em execução no dispositivo do usuário).

Um tipo implícito de permissão de autorização é usado por aplicativos móveis e da Web em que 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, e o token de acesso é passado ao agente do usuário para uso posterior no aplicativo. Isso torna o token disponível para o usuário e outros aplicativos no dispositivo do usuário. Com esse tipo de permissão de autorização, o aplicativo não é autenticado e o próprio processo depende de uma URL de redirecionamento (anteriormente registrada no serviço).

O fluxo implícito não suporta tokens de atualização.
Fluxo de concessão de credenciais do cliente - usado quando o aplicativo acessa a API. Esse tipo de permissão de autorização geralmente é usado para interações entre servidores que devem ser executadas em segundo plano sem interação imediata do usuário. O fluxo de credenciais do cliente permite que o serviço da Web (o cliente confidencial) use suas próprias credenciais em vez de se passar por usuário para autenticação ao chamar outro serviço da Web. Para um nível mais alto de segurança, é possível que o serviço de chamada use um certificado (em vez de um segredo compartilhado) como credenciais.

A especificação OAuth2 está descrita em
RFC-6749
RFC-8252
RFC-6819

Token JWT e suas vantagens

JWT (JSON Web Token) é um padrão aberto ( https://tools.ietf.org/html/rfc7519 ) que define um método compacto e independente para transferir com segurança informações entre 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 de hash para obter uma assinatura digital. A segunda parte armazena as informações básicas (usuário, atributos, etc.). A terceira parte é uma assinatura digital.

<cabeçalho codificado>. <carga útil codificada>. <assinatura>
Nunca salve um token no seu banco de dados. Como um token válido é equivalente a uma senha, armazenar um token é como armazenar uma senha em texto não criptografado.
Um token de acesso é um token que fornece ao proprietário acesso aos recursos protegidos do servidor. Geralmente, tem uma vida útil curta e pode transportar informações adicionais, como o endereço IP da parte que solicitou esse token.

Um token de atualização é um token que permite que os clientes solicitem novos tokens de acesso após o término da vida útil. Esses tokens geralmente são emitidos por um longo período.

Principais vantagens da aplicação na arquitetura de microsserviços:

A capacidade de acessar vários aplicativos e serviços por meio de autenticação única.
Na ausência de vários atributos necessários no perfil do usuário, é possível enriquecer com dados que podem ser adicionados à carga, incluindo automatizados e dinâmicos.
Não há necessidade de armazenar informações sobre sessões ativas; o aplicativo do servidor deve verificar apenas a assinatura.
Controle de acesso mais flexível com 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

Cabeçalho - por padrão, o cabeçalho contém apenas o tipo de token e o algoritmo usado para criptografia.

O tipo de token é armazenado na tecla "typ". A chave "typ" é ignorada no JWT. Se a chave de tipo estiver presente, seu valor deverá ser JWT para indicar que este objeto é um Token da Web JSON.

A segunda chave alg define o algoritmo usado para criptografar o token. Por padrão, ele deve ser definido como HS256. O cabeçalho é codificado em base64.

{"alg": "HS256", "typ": "JWT"}
Carga útil (conteúdo) - a carga útil armazena qualquer informação que precise ser verificada. Cada chave na carga útil é conhecida como "declaração". Por exemplo, o aplicativo pode ser inserido apenas por convite (promoção fechada). Quando queremos convidar alguém para participar, enviamos uma carta de convite a ele. É 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 alguns reservados:

iss (Emissor) - define o aplicativo a partir do qual o token é enviado.
sub (Assunto) - define o tópico do token.
aud (Audience) – URI, . JWT , — .
exp (Expiration Time) — , . JWT , . Exp unix .
nbf (Not Before) — unix , , .
iat (Issued At) — , JWT. iat unix .
Jti (JWT ID) — , c .

É importante entender que a carga útil não é transmitida na forma criptografada (embora os tokens possam ser incorporados e, em seguida, seja possível transmitir dados criptografados). Portanto, é impossível armazenar qualquer informação secreta nele. Como o cabeçalho, a carga útil é codificada em base64.
Assinatura - quando temos um cabeçalho e uma carga útil, podemos calcular a assinatura.

Codificado em Base64: cabeçalho e carga útil, são combinados em uma linha através de um ponto. Em seguida, essa linha e a chave secreta são enviadas para a entrada do algoritmo de criptografia especificado no cabeçalho (chave "alg"). A chave pode ser qualquer sequência. Cordas mais longas serão preferíveis, pois levará mais tempo para combinar.

{"alg": "RSA1_5", "carga": "A128CBC-HS256"}

Arquitetura de Cluster de Failover de Keycloak

Ao usar um único cluster para todos os projetos, há um aumento nos requisitos para uma solução para SSO. Quando o número de projetos é pequeno, esses requisitos não são tão perceptíveis para todos os projetos, mas com um aumento no número de usuários e integrações, os requisitos de acessibilidade e produtividade aumentam.

Aumentar o risco de falha de um único SSO aumenta os requisitos para a arquitetura da solução e os métodos usados para redundância de componentes e leva a um SLA muito rígido. Nesse sentido, mais freqüentemente ao desenvolver ou nos estágios iniciais da implementação de soluções, os projetos têm sua própria infraestrutura não tolerante a falhas. À medida que você desenvolve, você precisa estabelecer a possibilidade de desenvolvimento e dimensionamento. O mais flexível é criar um cluster de failover usando a virtualização de contêiner ou uma abordagem híbrida.

Para trabalhar em clusters 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 datacenters distribuídos geograficamente.

O exemplo mais simples de uma instalação à prova de falhas.

Quais são os benefícios de usar um único cluster:

Alta disponibilidade e desempenho.
Suporte para modos de operação: Ativo / Ativo, Ativo / Passivo.
A capacidade de escalar dinamicamente - ao usar a virtualização de contêiner.
Possibilidade de gerenciamento e monitoramento centralizados.
Abordagem unificada para identificação / autenticação / autorização de usuários em projetos.
Interação mais transparente entre vários projetos sem a participação 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 microsserviços / virtualização de contêiner (sem necessidade de aumentar e configurar componentes adicionais).
Talvez a aquisição de suporte comercial do fornecedor.

Coisas a considerar ao planejar um cluster

DBMS

O Keycloak usa um sistema de gerenciamento de DBMS para salvar: regiões, clientes, usuários etc.
Uma grande variedade de DBMSs é suportada: MS SQL, Oracle, MySQL, PostgreSQL. O Keycloak vem com seu próprio banco de dados relacional embutido. É recomendado o uso para ambientes não carregados, como ambientes de desenvolvimento.

Para operar em clusters Ativo / Ativo e Ativo / Passivo, é necessário garantir a consistência dos dados em um banco de dados relacional, e os dois nós do cluster de banco de dados são replicados de forma síncrona entre os datacenters.

Cache Distribuído (Infinspan)

Para que o cluster funcione corretamente, é necessária uma sincronização adicional dos seguintes tipos de cache usando o JBoss Data Grid:

Sessões de autenticação - usadas para salvar dados durante a autenticação de um usuário específico. As solicitações desse cache normalmente incluem apenas o navegador e o servidor Keycloak, não o aplicativo.

Tokens de ação - usados para cenários em que o usuário precisa confirmar a ação de forma assíncrona (via email). Por exemplo, durante o fluxo de senhas para esquecer, o cache actionTokens Infinispan é usado para rastrear metadados sobre marcadores de ação relacionados que já foram usados, para que não possam ser reutilizados.

Armazenamento em cache e invalidação de dados persistentes - usado para armazenar em cache dados persistentes para evitar consultas desnecessárias ao banco de dados. Quando um servidor Keycloak atualiza dados, todos os outros servidores Keycloak em todos os datacenters devem estar cientes 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 salvar dados sobre sessões de usuário válidas para a sessão do navegador de um usuário. O cache deve manipular solicitações HTTP do usuário final e do aplicativo.

Proteção de força bruta - usada para rastrear dados de login com falha.

Balanceamento de carga

O balanceador de carga é um ponto de entrada único no keycloak e deve suportar sessões persistentes.

Servidor de aplicação

Eles são usados para controlar a interação dos componentes entre si e podem ser virtualizados ou contêineres usando as ferramentas de automação existentes e escalando dinamicamente as ferramentas de automação da infraestrutura. Os cenários de implantação mais comuns no OpenShift, Kubernetes, Rancher.

Sobre isso, a primeira parte - teórica - acabou. Na série de artigos a seguir, serão discutidos exemplos de integrações com vários provedores de identificação e exemplos de configuração.

SSO na arquitetura de microsserviço. Usamos Keycloak. Número da peça 1