En calquera gran empresa, e X5 Retail Group non é unha excepción, a medida que se desenvolve, aumenta o número de proxectos que requiren autorización do usuario. Co paso do tempo, é necesaria a transición perfecta dos usuarios dunha aplicación a outra e, a continuación, é necesario utilizar un único servidor Single-Sing-On (SSO). Pero que pasa cando provedores de identidade como AD ou outros que non teñen atributos adicionais xa se utilizan en varios proxectos. Unha clase de sistemas chamados "corretores de identificación" acudirán ao rescate. Os máis funcionais son os seus representantes, como Keycloak, Gravitee Access management, etc. Na maioría das veces, os casos de uso poden ser diferentes: interacción da máquina, participación do usuario, etc. A solución debe soportar unha funcionalidade flexible e escalable que permita combinar todos os requisitos nun só, e tales solucións a nosa empresa agora ten un corredor de indicación - Keycloak.
Keycloak é un produto de control de acceso e identidade de código aberto mantido por RedHat. É a base para os produtos da empresa que utilizan SSO - RH-SSO.
Conceptos básicos
Antes de comezar a tratar con solucións e enfoques, debes decidir en termos e secuencias de procesos:
Identificación é un procedemento para recoñecer un suxeito polo seu identificador (noutras palabras, esta é a definición dun nome, login ou número).
Autenticación - Este é un procedemento de autenticación (o usuario é verificado cun contrasinal, a carta é verificada cunha sinatura electrónica, etc.)
Autorización - esta é a provisión de acceso a un recurso (por exemplo, ao correo electrónico).
Identity Broker Keycloak
chaveiro é unha solución de xestión de acceso e identidade de código aberto deseñada para o seu uso en IS onde se poden usar patróns de arquitectura de microservizos.
Keycloak ofrece funcións como inicio de sesión único (SSO), identidade intermediada e inicio de sesión social, federación de usuarios, adaptadores de clientes, consola de administración e consola de xestión de contas.
Funcionalidade básica soportada por Keycloak:
- Inicio de sesión único e pecha de sesión único para aplicacións do navegador.
- Compatibilidade con OpenID/OAuth 2.0/SAML.
- Intermediación de identidades: autenticación mediante provedores de identidades SAML ou OpenID Connect externos.
- Inicio de sesión social: soporte de Google, GitHub, Facebook, Twitter para a identificación do usuario.
- Federación de usuarios: sincronización de usuarios de servidores LDAP e Active Directory e outros provedores de identidade.
- Ponte Kerberos - usando un servidor Kerberos para a autenticación automática de usuarios.
- Consola de administración: para a xestión unificada da configuración e das opcións de solución a través da web.
- Consola de xestión de contas: para a autoxestión do perfil de usuario.
- Personalización da solución en función da identidade corporativa da empresa.
- Autenticación 2FA: soporte TOTP/HOTP mediante Google Authenticator ou FreeOTP.
- Fluxos de inicio de sesión: son posibles o auto-rexistro do usuario, a recuperación e restablecemento do contrasinal e outros.
- Xestión de sesións: os administradores poden xestionar as sesións dos usuarios desde un único punto.
- Token Mappers: vincula atributos de usuario, roles e outros atributos necesarios aos tokens.
- Xestión flexible de políticas en ámbitos, aplicacións e usuarios.
- Compatibilidade con CORS: os adaptadores de cliente teñen compatibilidade con CORS incorporada.
- Interfaces de provedores de servizos (SPI) - Un gran número de SPI que che permiten personalizar varios aspectos do servidor: fluxos de autenticación, provedores de identidade, mapeamento de protocolos e moito máis.
- Adaptadores de cliente para aplicacións JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Compatibilidade para traballar con varias aplicacións que admitan a biblioteca OpenID Connect Relying Party ou a biblioteca de provedores de servizos SAML 2.0.
- Ampliable mediante complementos.
Para os procesos CI/CD, así como para a automatización dos procesos de xestión en Keycloak, pódese usar a API REST/JAVA. A documentación está dispoñible electrónicamente:
API REST
API de Java
Provedores de identidade empresarial (on-premise)
Capacidade de autenticar usuarios a través dos servizos da Federación de usuarios.
Tamén se pode usar a autenticación de paso: se os usuarios se autentican en estacións de traballo con Kerberos (LDAP ou AD), entón poden autenticarse automaticamente en Keycloak sen ter que introducir de novo o seu nome de usuario e contrasinal.
Para a autenticación e posterior autorización dos usuarios, é posible utilizar un DBMS relacional, o que é máis aplicable para contornas de desenvolvemento, xa que non implica longas configuracións e integracións nas primeiras fases dos proxectos. De forma predeterminada, Keycloak usa un DBMS integrado para almacenar configuracións e datos de usuario.
A lista de DBMS compatibles é ampla e inclúe: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e outros. Os máis probados ata agora son Oracle 12C Release1 RAC e Galera 3.12 cluster para MariaDB 10.1.19.
Provedores de identidade - inicio de sesión social
É posible utilizar un inicio de sesión desde as redes sociais. Para activar a capacidade de autenticar usuarios, use a consola de administración de Keycloack. Non son necesarios cambios no código da aplicación e esta funcionalidade está dispoñible fóra da caixa e pódese activar en calquera fase do proxecto.
É posible utilizar provedores de identidade OpenID/SAML para a autenticación de usuarios.
Escenarios de autorización típicos usando OAuth2 en Keycloak
Fluxo do código de autorización - usado con aplicacións do lado do servidor. Un dos tipos máis comúns de permisos de autorización porque é moi axeitado para aplicacións de servidor onde o código fonte e os datos do cliente da aplicación non están dispoñibles para persoas alleas. O proceso neste caso baséase na redirección. A aplicación debe poder interactuar cun axente de usuario (axente de usuario), como un navegador web, para recibir códigos de autorización da API redirixidos a través do axente de usuario.
fluxo implícito - utilizado por aplicacións móbiles ou web (aplicacións que se executan no dispositivo do usuario).
O tipo de permiso de autorización implícita úsao aplicacións web e móbiles nas que non se pode garantir a confidencialidade do cliente. O tipo de permiso implícito tamén usa a redirección do axente de usuario, polo cal o token de acceso pásase ao axente de usuario para o seu uso posterior na aplicación. Isto fai que o token estea dispoñible para o usuario e outras aplicacións no dispositivo do usuario. Este tipo de permiso de autorización non autentica a identidade da aplicación e o proceso en si depende dun URL de redirección (rexistrado previamente no servizo).
Implicit Flow non admite os tokens de actualización de tokens de acceso.
Fluxo de concesión de credenciais do cliente — úsanse cando a aplicación accede á API. Este tipo de permisos de autorización úsase normalmente para interaccións de servidor a servidor que deben realizarse en segundo plano sen interacción inmediata do usuario. O fluxo de concesión de credenciais do cliente permite que un servizo web (cliente confidencial) utilice as súas propias credenciais en lugar de suplantar a identidade dun usuario para autenticarse cando chama a outro servizo web. Para un maior nivel de seguridade, é posible que o servizo de chamada use un certificado (en lugar dun segredo compartido) como credencial.
A especificación OAuth2 descríbese en
Token JWT e os seus beneficios
JWT (JSON Web Token) é un estándar aberto () que define un xeito compacto e autónomo de transferir información de forma segura entre partes como un obxecto JSON.
Segundo o estándar, o token consta de tres partes en formato base-64, separadas por puntos. A primeira parte chámase cabeceira, que contén o tipo de token e o nome do algoritmo hash para obter unha sinatura dixital. A segunda parte almacena a información básica (usuario, atributos, etc.). A terceira parte é a sinatura dixital.
. .
Nunca almacene un token na súa base de datos. Dado que un token válido equivale a un contrasinal, almacenalo é como almacenar o contrasinal en texto claro.
Token de acceso é un token que concede ao seu propietario acceso a recursos do servidor seguro. Normalmente ten unha vida útil curta e pode levar información adicional como o enderezo IP da parte que solicita o token.
Token de actualización é un token que permite aos clientes solicitar novos tokens de acceso despois de que caduque a súa vida útil. Estes tokens adoitan emitirse durante un longo período de tempo.
As principais vantaxes do uso na arquitectura de microservizos:
- Capacidade de acceder a varias aplicacións e servizos mediante a autenticación única.
- A falta dunha serie de atributos obrigatorios no perfil de usuario, é posible enriquecer con datos que se poden engadir á carga útil, incluídos os automatizados e sobre a marcha.
- Non é necesario almacenar información sobre sesións activas, a aplicación do servidor só precisa verificar a sinatura.
- Control de acceso máis flexible mediante atributos adicionais na carga útil.
- O uso dunha sinatura de token para a cabeceira e a carga útil aumenta a seguridade da solución no seu conxunto.
Ficha JWT - composición
Título - de forma predeterminada, a cabeceira contén só o tipo de token e o algoritmo utilizado para a criptografía.
O tipo do token gárdase na clave "typ". A clave 'type' é ignorada no JWT. Se a clave "typ" está presente, o seu valor debe ser JWT para indicar que este obxecto é un token web JSON.
A segunda chave "alg" define o algoritmo usado para cifrar o token. Debe establecerse como HS256 por defecto. A cabeceira está codificada en base64.
{ "alg": "HS256", "type": "JWT"}
carga útil (contido) - a carga útil almacena calquera información que deba ser verificada. Cada clave da carga útil coñécese como "reclamación". Por exemplo, só podes entrar na aplicación mediante invitación (promoción pechada). Cando queremos invitar a alguén a participar, enviámoslle unha carta de invitación. É importante comprobar que o enderezo de correo electrónico pertence á persoa que acepta a invitación, polo que incluiremos este enderezo na carga útil, para iso gardámolo na clave "correo electrónico"
{ "correo electrónico": "[protexido por correo electrónico]"}
As claves na carga útil poden ser arbitrarias. Non obstante, hai algúns reservados:
- iss (Emisor): identifica a aplicación desde a que se envía o token.
- sub (Subject): define o asunto do token.
- aud (Audience) é unha matriz de cadeas ou URIs que distinguen entre maiúsculas e minúsculas que é unha lista dos destinatarios deste token. Cando o lado receptor recibe un JWT coa chave dada, debe comprobar a presenza de si mesmo nos destinatarios; se non, ignora o token.
- exp (Tempo de caducidade): indica cando caduca o token. O estándar JWT require que todas as súas implementacións rexeiten os tokens caducados. A clave exp debe ser unha marca de tempo en formato Unix.
- nbf (Non antes) é un tempo en formato Unix que determina o momento no que o token se fai válido.
- iat (Emitido en): esta clave representa o momento en que se emitiu o token e pódese usar para determinar a idade do JWT. A clave iat debe ser unha marca de tempo en formato Unix.
- Jti (ID JWT): unha cadea que define o identificador único deste token, que distingue entre maiúsculas e minúsculas.
É importante entender que a carga útil non se transmite en forma cifrada (aínda que os tokens poden aniñarse e entón é posible transmitir datos cifrados). Polo tanto, non pode almacenar ningunha información secreta. Do mesmo xeito que a cabeceira, a carga útil está codificada en base64.
Sinatura - cando temos título e carga útil, podemos calcular a sinatura.
Codificación Base64: tómanse a cabeceira e a carga útil, combínanse nunha cadea a través dun punto. A continuación, esta cadea e a clave secreta introdúcense no algoritmo de cifrado especificado na cabeceira (chave "alg"). A clave pode ser calquera cadea. As cordas máis longas serán máis preferidas xa que tardarán máis en recollerse.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Construír unha arquitectura de clúster de conmutación por error Keycloak
Cando se usa un único clúster para todos os proxectos, hai máis requisitos para unha solución SSO. Cando o número de proxectos é pequeno, estes requisitos non son tan perceptibles para todos os proxectos, non obstante, cun aumento do número de usuarios e integracións, aumentan os requisitos de dispoñibilidade e rendemento.
O aumento do risco de falla de SSO único aumenta os requisitos para a arquitectura da solución e os métodos utilizados para os compoñentes redundantes e leva a un SLA moi axustado. Neste sentido, con máis frecuencia durante o desenvolvemento ou as primeiras fases de implementación de solucións, os proxectos teñen a súa propia infraestrutura non tolerante a fallos. A medida que o desenvolvemento avanza, é necesario establecer oportunidades para o desenvolvemento e a escala. É máis flexible construír un clúster de conmutación por fallo mediante a virtualización de contedores ou un enfoque híbrido.
Para traballar nos modos de clúster Activo/Activo e Activo/Pasivo, é necesario garantir a coherencia dos datos nunha base de datos relacional; ambos os nodos de bases de datos deben replicarse de forma sincronizada entre diferentes centros de datos xeodistribuídos.
O exemplo máis sinxelo dunha instalación tolerante a fallos.
Cales son os beneficios de usar un único clúster:
- Alta dispoñibilidade e rendemento.
- Soporte para modos de funcionamento: Activo / Activo, Activo / Pasivo.
- Capacidade de escalar dinámicamente cando se usa a virtualización de contedores.
- Posibilidade de xestión e seguimento centralizados.
- Enfoque unificado para a identificación/autenticación/autorización de usuarios en proxectos.
- Interacción máis transparente entre diferentes proxectos sen a implicación dos usuarios.
- A capacidade de reutilizar o token JWT en varios proxectos.
- Punto único de confianza.
- Lanzamento máis rápido de proxectos mediante microservizos/virtualización de contedores (sen necesidade de levantar e configurar compoñentes adicionais).
- É posible adquirir soporte comercial do vendedor.
Que buscar ao planificar un clúster
DBMS
Keycloak usa un sistema de xestión de bases de datos para almacenar: reinos, clientes, usuarios, etc.
Soporta unha ampla gama de DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vén coa súa propia base de datos relacional integrada. Recoméndase usar para ambientes non cargados, como ambientes de desenvolvemento.
Para traballar nos modos de clúster Activo/Activo e Activo/Pasivo, é necesaria a coherencia dos datos nunha base de datos relacional e os dous nodos do clúster de bases de datos replícanse de forma sincronizada entre os centros de datos.
Caché distribuída (Infinspan)
Para que o clúster funcione correctamente, é necesaria unha sincronización adicional dos seguintes tipos de caché mediante JBoss Data Grid:
Sesións de autenticación: utilízase para gardar datos ao autenticar un usuario específico. Normalmente, as solicitudes desta caché só inclúen o navegador e o servidor Keycloak, non a aplicación.
Os tokens de acción úsanse para escenarios nos que o usuario necesita confirmar unha acción de forma asíncrona (a través de correo electrónico). Por exemplo, durante un fluxo de esquecemento do contrasinal, a caché de actionTokens Infinispan utilízase para realizar un seguimento dos metadatos dos tokens de acción asociados que xa se utilizaron, polo que non se pode reutilizar.
Almacenamento en caché e invalidación de datos persistentes: utilízase para almacenar na caché datos persistentes para evitar consultas innecesarias á base de datos. Cando calquera servidor de Keycloak actualiza os datos, todos os demais servidores de Keycloak de todos os centros de datos precisan sabelo.
Traballo: só se usa para enviar mensaxes non válidas entre os nodos do clúster e os centros de datos.
Sesións de usuario: utilízase para almacenar datos sobre sesións de usuario que son válidas durante a duración da sesión do navegador do usuario. A caché debe procesar as solicitudes HTTP do usuario final e da aplicación.
Protección de forza bruta: úsase para rastrexar datos sobre inicios de sesión errados.
Equilibrio de carga
O equilibrador de carga é o único punto de entrada para keycloak e debe admitir sesións persistentes.
Servidores de aplicacións
Utilízanse para controlar a interacción de compoñentes entre si e pódense virtualizar ou contener utilizando ferramentas de automatización existentes e escalado dinámico de ferramentas de automatización de infraestruturas. Os escenarios de implantación máis comúns en OpenShift, Kubernates, Rancher.
Conclúe así a primeira parte, a teórica. Na seguinte serie de artigos analizaranse exemplos de integracións con diversos provedores de identidade e exemplos de configuración.
Fonte: www.habr.com