🕎 🧕🏿 👋🏽 SSO en arquitectura de microservicios. Usamos Keycloak. Número de parte 1 🤸🏻 🤾🏿 🐦

En cualquier empresa grande, X5 Retail Group no es una excepción, ya que la cantidad de proyectos donde se requiere autenticación de usuario aumenta a medida que crece la cantidad de proyectos. Con el tiempo, se requiere una transición sin problemas de los usuarios de una aplicación a otra y luego es necesario usar un solo servidor Single-Sing-On (SSO). Pero, ¿qué pasa cuando proveedores de identidad como AD u otros que no tienen atributos adicionales ya se utilizan en varios proyectos? Una clase de sistemas llamados "corredores de identidad" vendrá al rescate. Los más funcionales son sus representantes, como Keycloak, Gravitee Access management, etc. La mayoría de las veces, los escenarios de uso pueden ser diferentes: interacción con la máquina, participación del usuario, etc. La solución debe admitir una funcionalidad flexible y escalablecapaz de combinar todos los requisitos en uno, y esa solución en nuestra empresa ahora es un corredor de indicadores: Keycloak.

Keycloak es un producto de código abierto para autenticación y control de acceso compatible con RedHat. Es la base de los productos de la compañía que utilizan SSO - RH-SSO.

Conceptos básicos

Antes de comenzar a lidiar con decisiones y enfoques, debe determinar los términos y la secuencia de los procesos: la

identificación es el proceso de reconocer a un sujeto por su identificador (en otras palabras, es determinar un nombre, inicio de sesión o número).

La autenticación es un procedimiento de autenticación (se verifica al usuario con una contraseña, se verifica el correo electrónico mediante firma electrónica, etc.) La

autorización es la provisión de acceso a algún recurso (por ejemplo, correo electrónico).

Keycloak Identity Broker

Keycloak es una solución de gestión de acceso e identidad de código abierto diseñada para su uso en circuitos integrados donde se pueden usar patrones de arquitectura de microservicios.

Keycloak ofrece características tales como inicio de sesión único (SSO), identificación de corredores e inicio de sesión social, federación de usuarios, adaptadores de clientes, una consola de administrador y una consola de administración de cuentas.

Funcionalidad básica compatible con Keycloak:

Single-Sign On y Single-Sign Out para aplicaciones basadas en navegador.
Soporte para OpenID / OAuth 2.0 / SAML.
Identity Brokering: autenticación mediante proveedores de identidad externos OpenID Connect o SAML.
Inicio de sesión social: soporte para Google, GitHub, Facebook, Twitter para la identificación del usuario.
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 los procesos de CI / CD, así como la automatización de los procesos de gestión en Keycloak, se puede utilizar la API REST API / JAVA. La documentación está disponible en formato electrónico:

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

Proveedores de identidad empresarial (en las instalaciones)

La capacidad de autenticar usuarios a través de los servicios de la Federación de usuarios.

La autenticación de paso también se puede utilizar: si los usuarios se autentican en estaciones de trabajo con Kerberos (LDAP o AD), se pueden autenticar automáticamente con Keycloak sin tener que volver a ingresar su nombre de usuario y contraseña.

Para la autenticación y autorización adicional de los usuarios, es posible utilizar un DBMS relacional, que es más aplicable para entornos de desarrollo, ya que no implica configuraciones e integraciones a largo plazo en las primeras etapas de los proyectos. De forma predeterminada, Keycloak utiliza un DBMS incorporado para almacenar configuraciones y datos de usuario.

La lista de DBMS compatibles es extensa e incluye: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle y otros. Los más probados en este momento son Oracle 12C Release1 RAC y Galera 3.12 cluster para MariaDB 10.1.19.

Proveedores de identidad - inicio de sesión social

Es posible utilizar un inicio de sesión desde las redes sociales. Para activar la capacidad de autenticar usuarios, se utiliza la consola de administración de Keycloack. No se requieren cambios en el código de la aplicación y esta funcionalidad está disponible "fuera de la caja" y se puede activar en cualquier etapa del proyecto.

Para autenticar a los usuarios, es posible usar proveedores de identidad OpenID / SAML.

Escenarios de autorización típicos que usan OAuth2 en Keycloak

Flujo de código de autorización : se utiliza con aplicaciones del lado del servidor. Uno de los tipos más comunes de permisos de autorización, ya que es muy adecuado para aplicaciones de servidor en las que el código fuente de la aplicación y los datos del cliente no son accesibles para personas externas. El proceso en este caso se basa en la redirección. La aplicación debe poder interactuar con el agente de usuario (agente de usuario), como un navegador web, para recibir códigos de autorización API redirigidos a través del agente de usuario.

Flujo implícito : utilizado por aplicaciones móviles o web (aplicaciones que se ejecutan en el dispositivo del usuario).

Las aplicaciones móviles y web utilizan un tipo implícito de permiso de autorización donde no se puede garantizar la privacidad del cliente. El tipo de permiso implícito también utiliza la redirección del agente de usuario, y el token de acceso se pasa al agente de usuario para su uso posterior en la aplicación. Esto hace que el token esté disponible para el usuario y otras aplicaciones en el dispositivo del usuario. Con este tipo de permiso de autorización, la aplicación no se autentica y el proceso en sí depende de una URL de redireccionamiento (previamente registrada en el servicio).

El flujo implícito no admite tokens de actualización.
Flujo de concesión de credenciales de cliente : se utiliza cuando la aplicación accede a la API. Este tipo de permiso de autorización se usa generalmente para interacciones de servidor a servidor que deben ejecutarse en segundo plano sin interacción inmediata del usuario. El flujo de credenciales del cliente permite que el servicio web (el cliente confidencial) use sus propias credenciales en lugar de suplantar al usuario para la autenticación al llamar a otro servicio web. Para un mayor nivel de seguridad, es posible que el servicio de llamadas use un certificado (en lugar de un secreto compartido) como credenciales.

La especificación OAuth2 se describe en
RFC-6749
RFC-8252
RFC-6819

Token JWT y sus ventajas

JWT (JSON Web Token) es un estándar abierto ( https://tools.ietf.org/html/rfc7519 ) que define un método compacto e independiente para transferir información de forma segura entre las partes como un objeto JSON.

Según el estándar, el token consta de tres partes en formato base 64, separadas por puntos. La primera parte se llama encabezado, que contiene el tipo de token y el nombre del algoritmo hash para obtener una firma digital. La segunda parte almacena la información básica (usuario, atributos, etc.). La tercera parte es una firma digital.

<encabezado codificado>. <carga útil codificada>. <firma>
Nunca guarde un token en su base de datos. Debido a que un token válido es equivalente a una contraseña, almacenar un token es como almacenar una contraseña en texto sin cifrar.
Un token de acceso es un token que le da acceso a su propietario a los recursos protegidos del servidor. Por lo general, tiene una vida útil corta y puede transportar información adicional, como la dirección IP de la parte que solicita este token.

Un token de actualización es un token que permite a los clientes solicitar nuevos tokens de acceso después de que su vida haya expirado. Estas fichas generalmente se emiten por un largo período.

Principales ventajas de la aplicación en arquitectura de microservicios:

La capacidad de acceder a diversas aplicaciones y servicios a través de una autenticación única.
En ausencia de una serie de atributos requeridos en el perfil del usuario, es posible enriquecerlo con datos que se pueden agregar a la carga útil, incluidos los automatizados y sobre la marcha.
No es necesario almacenar información sobre sesiones activas, la aplicación del servidor solo debe verificar la firma.
Control de acceso más flexible con atributos adicionales en la carga útil.
El uso de una firma de token para el encabezado y la carga útil aumenta la seguridad de la solución en su conjunto.

Token JWT - Composición

Encabezado : de forma predeterminada, el encabezado contiene solo el tipo de token y el algoritmo utilizado para el cifrado.

El tipo de token se almacena en la tecla "typ". La tecla "typ" se ignora en el JWT. Si la clave typ está presente, su valor debe ser JWT para indicar que este objeto es un token web JSON.

La segunda clave alg define el algoritmo utilizado para cifrar el token. De manera predeterminada, debe establecerse en HS256. El encabezado está codificado en base64.

{"alg": "HS256", "typ": "JWT"}
Carga útil (contenido) : la carga útil almacena cualquier información que deba verificarse. Cada clave en la carga útil se conoce como una "declaración". Por ejemplo, la aplicación solo se puede ingresar por invitación (promoción cerrada). Cuando queremos invitar a alguien a participar, le enviamos una carta de invitación. Es importante verificar que la dirección de correo electrónico pertenece a la persona que acepta la invitación, por lo que incluiremos esta dirección en la carga útil, para esto la guardaremos en la clave de "correo electrónico"

{"email": "example@x5.ru"}
Las claves en la carga útil pueden ser arbitrarias. Sin embargo, hay algunos reservados:

iss (Emisor): define la aplicación desde la que se envía el token.
sub (Asunto): define el tema del 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 .

Es importante comprender que la carga útil no se transmite en forma encriptada (aunque los tokens se pueden incrustar y luego es posible transmitir datos encriptados). Por lo tanto, es imposible almacenar información secreta en él. Al igual que el encabezado, la carga útil está codificada en base64.
Firma : cuando tenemos un encabezado y una carga útil, podemos calcular la firma.

Base64 codificada: se toman el encabezado y la carga útil, se combinan en una línea a través de un punto. Luego, esta línea y la clave secreta se envían a la entrada del algoritmo de cifrado especificado en el encabezado (clave "alg"). La clave puede ser cualquier cadena. Las cadenas más largas serán preferibles, ya que llevará más tiempo hacer coincidir.

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

Arquitectura del clúster de conmutación por error de Keycloak

Cuando se usa un solo clúster para todos los proyectos, hay mayores requisitos para una solución para SSO. Cuando el número de proyectos es pequeño, estos requisitos no son tan notables para todos los proyectos, pero con un aumento en el número de usuarios e integraciones, aumentan los requisitos de accesibilidad y productividad.

Aumentar el riesgo de falla de un único SSO aumenta los requisitos para la arquitectura de la solución y los métodos utilizados para la redundancia de componentes y conduce a un SLA muy ajustado. En este sentido, con mayor frecuencia al desarrollar o en las primeras etapas de implementación de soluciones, los proyectos tienen su propia infraestructura sin tolerancia a fallas. A medida que se desarrolla, debe establecer la posibilidad de desarrollo y escalamiento. Lo más flexible es crear un clúster de conmutación por error utilizando la virtualización de contenedores o un enfoque híbrido.

Para trabajar en clústeres Activo / Activo y Activo / Pasivo, es necesario garantizar la consistencia de los datos en una base de datos relacional: ambos nodos de la base de datos deben replicarse sincrónicamente entre diferentes centros de datos geodistribuidos.

El ejemplo más simple de una instalación a prueba de fallas.

¿Cuáles son los beneficios de usar un solo clúster?

Alta disponibilidad y rendimiento.
Soporte para modos de funcionamiento: activo / activo, activo / pasivo.
La capacidad de escalar dinámicamente, cuando se usa la virtualización de contenedores.
Posibilidad de gestión centralizada y seguimiento.
Enfoque unificado para la identificación / autenticación / autorización de usuarios en proyectos.
Interacción más transparente entre varios proyectos sin participación del usuario.
La capacidad de reutilizar el token JWT en varios proyectos.
Punto único de confianza.
Lanzamiento más rápido de proyectos utilizando microservicios / virtualización de contenedores (no es necesario generar y configurar componentes adicionales).
Tal vez la adquisición de soporte comercial del vendedor.

Cosas a tener en cuenta al planificar un clúster

DBMS

Keycloak utiliza un sistema de gestión DBMS para guardar: reinos, clientes, usuarios, etc.
Se admite una amplia gama de DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak viene con su propia base de datos relacional incorporada. Se recomienda su uso para entornos sin carga, como los entornos de desarrollo.

Para operar en clústeres Activo / Activo y Activo / Pasivo, es necesario asegurar la consistencia de los datos en una base de datos relacional, y ambos nodos del clúster de la base de datos se replican sincrónicamente entre los centros de datos.

Caché Distribuida (Infinspan)

Para que el clúster funcione correctamente, se requiere una sincronización adicional de los siguientes tipos de caché utilizando JBoss Data Grid:

Sesiones de autenticación: se utilizan para guardar datos durante la autenticación de un usuario específico. Las solicitudes de este caché generalmente incluyen solo el navegador y el servidor Keycloak, no la aplicación.

Fichas de acción: se utilizan para escenarios en los que el usuario necesita confirmar la acción de forma asincrónica (por correo electrónico). Por ejemplo, durante el flujo de contraseña olvidada, el caché actionTokens Infinispan se usa para rastrear metadatos sobre marcadores de acción relacionados que ya se han utilizado, por lo que no se puede reutilizar.

Almacenamiento en caché e invalidación de datos persistentes: se utiliza para almacenar en caché datos persistentes para evitar consultas innecesarias en la base de datos. Cuando un servidor Keycloak actualiza los datos, todos los demás servidores Keycloak en todos los centros de datos deben ser conscientes de esto.

Trabajo: se utiliza solo para enviar mensajes de invalidación entre nodos del clúster y centros de datos.

Sesiones de usuario: se utilizan para guardar datos sobre sesiones de usuario que son válidos para la sesión del navegador de un usuario. El caché debe manejar las solicitudes HTTP del usuario final y la aplicación.

Protección de fuerza bruta: se utiliza para rastrear datos de inicio de sesión fallidos.

Balanceo de carga

El equilibrador de carga es un único punto de entrada en keycloak y debe admitir sesiones fijas.

Servidor de aplicaciones

Se utilizan para controlar la interacción de los componentes entre ellos y se pueden virtualizar o contenerizar mediante las herramientas de automatización existentes y las herramientas de automatización de infraestructura de escala dinámica. Los escenarios de implementación más comunes en OpenShift, Kubernetes, Rancher.

Sobre esto, la primera parte, teórica, ha terminado. En la siguiente serie de artículos, se discutirán ejemplos de integraciones con varios proveedores de identificación y ejemplos de configuración.

SSO en arquitectura de microservicios. Usamos Keycloak. Número de parte 1