En cualquier gran empresa, y X5 Retail Group no es una excepción, a medida que se desarrolla, aumenta el número de proyectos que requieren autorización de usuario. Con el tiempo, se requiere una transición fluida de los usuarios de una aplicación a otra y, luego, existe la necesidad de utilizar un único servidor Single-Sing-On (SSO). Pero, ¿qué pasa cuando los proveedores de identidad como AD u otros que no tienen atributos adicionales ya se usan en varios proyectos? Una clase de sistemas llamados "intermediarios de identificación" vendrán al rescate. Los más funcionales son sus representantes, como Keycloak, la gestión de Gravitee Access, etc. La mayoría de las veces, los casos de uso pueden ser diferentes: interacción de la máquina, participación del usuario, etc. La solución debe admitir una funcionalidad flexible y escalable que pueda combinar todos los requisitos en uno, y tales soluciones, nuestra empresa ahora tiene un corredor de indicaciones: Keycloak.
Keycloak es un producto de control de acceso e identidad de código abierto mantenido por RedHat. Es la base para los productos de la empresa que utilizan SSO - RH-SSO.
conceptos
Antes de comenzar a tratar con soluciones y enfoques, debe decidir en términos y secuencia de procesos:
Identificación es un procedimiento para reconocer a un sujeto por su identificador (en otras palabras, esta es la definición de un nombre, nombre de usuario o número).
Autentificación - este es un procedimiento de autenticación (el usuario se verifica con una contraseña, la carta se verifica con una firma electrónica, etc.)
Autorización - esta es la provisión de acceso a un recurso (por ejemplo, al correo electrónico).
Capa de clave de agente de identidad
Capa clave es una solución de administración de acceso e identidad de código abierto diseñada para usar en IS donde se pueden usar patrones de arquitectura de microservicio.
Keycloak ofrece funciones como inicio de sesión único (SSO), identidad intermediada e inicio de sesión social, federación de usuarios, adaptadores de clientes, consola de administración y consola de gestión de cuentas.
Funcionalidad básica compatible con Keycloak:
- Single-Sign On y Single-Sign Out para aplicaciones de navegador.
- Compatibilidad con OpenID/OAuth 2.0/SAML.
- Intermediación de identidad: autenticación mediante OpenID Connect externo o proveedores de identidad SAML.
- Inicio de sesión social: soporte de Google, GitHub, Facebook, Twitter para la identificación del usuario.
- Federación de usuarios: sincronización de usuarios de servidores LDAP y Active Directory y otros proveedores de identidad.
- Puente Kerberos: uso de un servidor Kerberos para la autenticación automática de usuarios.
- Consola de administración: para la gestión unificada de la configuración y las opciones de solución a través de la Web.
- Consola de gestión de cuentas: para la autogestión del perfil de usuario.
- Personalización de la solución en base a la identidad corporativa de la empresa.
- Autenticación 2FA: compatibilidad con TOTP/HOTP mediante Google Authenticator o FreeOTP.
- Flujos de inicio de sesión: registro automático del usuario, recuperación y restablecimiento de contraseña, y otros son posibles.
- Gestión de sesiones: los administradores pueden gestionar las sesiones de los usuarios desde un único punto.
- Asignadores de tokens: vinculación de atributos de usuario, roles y otros atributos requeridos a los tokens.
- Gestión flexible de políticas en todo el ámbito, la aplicación y los usuarios.
- Compatibilidad con CORS: los adaptadores de cliente tienen compatibilidad con CORS integrada.
- Interfaces de proveedores de servicios (SPI): una gran cantidad de SPI que le permiten personalizar varios aspectos del servidor: flujos de autenticación, proveedores de identidad, mapeo de protocolos y más.
- Adaptadores de cliente para aplicaciones JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Compatibilidad para trabajar con varias aplicaciones compatibles con la biblioteca OpenID Connect Relying Party o la biblioteca de proveedores de servicios SAML 2.0.
- Ampliable mediante complementos.
Para procesos de CI/CD, así como automatización de procesos de gestión en Keycloak, se puede utilizar la API REST/API JAVA. La documentación está disponible electrónicamente:
REST API
API de JAVA
Proveedores de identidad empresarial (en las instalaciones)
Capacidad para autenticar a los usuarios a través de los servicios de federación de usuarios.
También se puede usar la autenticación de paso: si los usuarios se autentican en estaciones de trabajo con Kerberos (LDAP o AD), entonces se pueden autenticar automáticamente en Keycloak sin tener que ingresar su nombre de usuario y contraseña nuevamente.
Para la autenticación y autorización adicional de los usuarios, es posible utilizar un DBMS relacional, que es más aplicable a los entornos de desarrollo, ya que no implica configuraciones e integraciones prolongadas 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 admitidos es extensa e incluye: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle y otros. Los más probados hasta ahora son Oracle 12C Release1 RAC y el clúster Galera 3.12 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 a los usuarios, utilice la consola de administración de Keycloack. No se requieren cambios en el código de la aplicación y esta funcionalidad está disponible de forma inmediata y se puede activar en cualquier etapa del proyecto.
Es posible utilizar proveedores de identidad OpenID/SAML para la autenticación de usuarios.
Escenarios típicos de autorización usando OAuth2 en Keycloak
Flujo de código de autorización - utilizado con aplicaciones del lado del servidor. Uno de los tipos más comunes de permiso de autorización porque es muy adecuado para aplicaciones de servidor donde el código fuente de la aplicación y los datos del cliente no están disponibles para personas externas. El proceso en este caso se basa en la redirección. La aplicación debe poder interactuar con un agente de usuario (agente de usuario), como un navegador web, para recibir códigos de autorización de 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).
El tipo de permiso de autorización implícita es utilizado por aplicaciones móviles y web donde no se puede garantizar la confidencialidad del cliente. El tipo de permiso implícito también utiliza la redirección del agente de usuario, por lo que 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. Este tipo de permiso de autorización no autentica la identidad de la aplicación y el proceso en sí se basa en una URL de redirección (previamente registrada con el servicio).
El flujo implícito no admite tokens de actualización de token de acceso.
Flujo de concesión de credenciales de cliente — se utilizan cuando la aplicación accede a la API. Este tipo de permiso de autorización generalmente se usa para interacciones de servidor a servidor que deben realizarse en segundo plano sin interacción inmediata del usuario. El flujo de concesión de credenciales de cliente permite que un servicio web (cliente confidencial) use sus propias credenciales en lugar de suplantar a un usuario para autenticarse al llamar a otro servicio web. Para un mayor nivel de seguridad, es posible que el servicio que llama use un certificado (en lugar de un secreto compartido) como credencial.
La especificación OAuth2 se describe en
Token JWT y sus beneficios
JWT (JSON Web Token) es un estándar abierto () que define una forma compacta y autónoma de 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 denomina 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 la firma digital.
. .
Nunca almacene un token en su base de datos. Debido a que un token válido es equivalente a una contraseña, almacenar el token es como almacenar la contraseña en texto claro.
token de acceso es un token que otorga a su propietario acceso a recursos seguros del servidor. Por lo general, tiene una vida útil corta y puede contener información adicional, como la dirección IP de la parte que solicita el token.
token de actualización es un token que permite a los clientes solicitar nuevos tokens de acceso después de que haya expirado su vida útil. Estos tokens generalmente se emiten por un largo período de tiempo.
Las principales ventajas de usar en la arquitectura de microservicios:
- Capacidad para acceder a varias aplicaciones y servicios a través de la autenticación de una sola vez.
- En ausencia de una serie de atributos obligatorios en el perfil de 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 las sesiones activas, la aplicación del servidor solo necesita verificar la firma.
- Control de acceso más flexible a través de 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
Título - por defecto, el encabezado contiene solo el tipo de token y el algoritmo utilizado para el cifrado.
El tipo del token se almacena en la clave "typ". La clave 'tipo' 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. Debe establecerse en HS256 de forma predeterminada. El encabezado está codificado en base64.
{ "algo": "HS256", "tipo": "JWT"}
carga útil (contenido) - la carga útil almacena cualquier información que deba verificarse. Cada clave en la carga útil se conoce como un "reclamo". Por ejemplo, puedes ingresar a la aplicación solo por invitación (promoción cerrada). Cuando queremos invitar a alguien a participar, le enviamos una carta de invitación. Es importante comprobar 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 el payload, para ello la almacenamos en la clave "email"
{ "correo electrónico": "[email protected]"}
Las claves en la carga útil pueden ser arbitrarias. Sin embargo, hay algunos reservados:
- iss (Emisor): identifica la aplicación desde la que se envía el token.
- sub (Asunto) - define el asunto del token.
- aud (Audiencia) es una matriz de cadenas que distinguen entre mayúsculas y minúsculas o URI que es una lista de los destinatarios de este token. Cuando el lado receptor recibe un JWT con la clave dada, debe verificar su presencia en los destinatarios; de lo contrario, ignore el token.
- exp (Tiempo de caducidad): indica cuándo caduca el token. El estándar JWT requiere que todas sus implementaciones rechacen tokens caducados. La clave exp debe ser una marca de tiempo en formato Unix.
- nbf (Not Before) es un tiempo en formato unix que determina el momento en que el token se vuelve válido.
- iat (Emitido en): esta clave representa la hora en que se emitió el token y se puede usar para determinar la antigüedad del JWT. La clave iat debe ser una marca de tiempo en formato Unix.
- Jti (JWT ID): una cadena que define el identificador único de este token, distingue entre mayúsculas y minúsculas.
Es importante entender que la carga útil no se transmite en forma encriptada (aunque los tokens se pueden anidar y luego es posible transmitir datos encriptados). Por lo tanto, no puede almacenar ninguna información secreta. Al igual que el encabezado, la carga útil está codificada en base64.
Firma - cuando tenemos un título y payload, podemos calcular la firma.
Codificado en Base64: se toman el encabezado y la carga útil, se combinan en una cadena a través de un punto. Luego, esta cadena y la clave secreta se ingresan en el algoritmo de cifrado especificado en el encabezado (clave "alg"). La clave puede ser cualquier cadena. Se preferirán las cuerdas más largas, ya que llevará más tiempo recogerlas.
{"alg":"RSA1_5","carga útil":"A128CBC-HS256"}
Creación de una arquitectura de clúster de conmutación por error Keycloak
Cuando se utiliza un solo clúster para todos los proyectos, existen mayores requisitos para una solución de SSO. Cuando el número de proyectos es pequeño, estos requisitos no son tan notorios para todos los proyectos, sin embargo, con un aumento en el número de usuarios e integraciones, los requisitos de disponibilidad y rendimiento aumentan.
El aumento del riesgo de falla única de SSO aumenta los requisitos para la arquitectura de la solución y los métodos utilizados para los componentes redundantes y conduce a un SLA muy estricto. En este sentido, más a menudo durante el desarrollo o las primeras etapas de implementación de soluciones, los proyectos tienen su propia infraestructura no tolerante a fallas. A medida que avanza el desarrollo, se requiere establecer oportunidades para el desarrollo y la escala. Es más flexible crear un clúster de conmutación por error mediante la virtualización de contenedores o un enfoque híbrido.
Para trabajar en los modos de clúster Activo/Activo y Activo/Pasivo, es necesario garantizar la coherencia 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 distribuidos geográficamente.
El ejemplo más simple de una instalación tolerante a 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.
- Capacidad de escalar dinámicamente, cuando se utiliza la virtualización de contenedores.
- Posibilidad de gestión y seguimiento centralizado.
- Enfoque unificado para la identificación/autenticación/autorización de usuarios en proyectos.
- Interacción más transparente entre diferentes proyectos sin la participación del usuario.
- La capacidad de reutilizar el token JWT en varios proyectos.
- Único punto de confianza.
- Lanzamiento más rápido de proyectos utilizando microservicios/virtualización de contenedores (sin necesidad de levantar y configurar componentes adicionales).
- Es posible comprar soporte comercial del proveedor.
Qué buscar al planificar un clúster
DBMS
Keycloak utiliza un sistema de gestión de base de datos para almacenar: dominios, 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 no cargados, como entornos de desarrollo.
Para trabajar en los modos de clúster Activo/Activo y Activo/Pasivo, se requiere coherencia de datos en una base de datos relacional, y ambos nodos de clúster de base de datos se replican sincrónicamente entre 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é mediante JBoss Data Grid:
Sesiones de autenticación: se utilizan para guardar datos al autenticar a un usuario específico. Las solicitudes de este caché generalmente solo incluyen el navegador y el servidor Keycloak, no la aplicación.
Los tokens de acción se utilizan para escenarios en los que el usuario necesita confirmar una acción de forma asíncrona (por correo electrónico). Por ejemplo, durante un flujo de olvido de contraseña, la memoria caché actionTokens Infinispan se utiliza para realizar un seguimiento de los metadatos sobre los tokens de acción asociados que ya se han utilizado, por lo que no se pueden reutilizar.
Almacenamiento en caché e invalidación de datos persistentes: se utiliza para almacenar en caché datos persistentes para evitar consultas innecesarias a la base de datos. Cuando cualquier servidor Keycloak actualiza los datos, todos los demás servidores Keycloak en todos los centros de datos deben saberlo.
Trabajo: solo se usa para enviar mensajes no válidos entre los nodos del clúster y los centros de datos.
Sesiones de usuario: se utiliza para almacenar datos sobre las sesiones de usuario que son válidas durante la sesión del navegador del usuario. La memoria caché debe procesar solicitudes HTTP del usuario final y la aplicación.
Protección de fuerza bruta: se utiliza para rastrear datos sobre inicios de sesión fallidos.
Balanceo de carga
El equilibrador de carga es el único punto de entrada a keycloak y debe admitir sesiones persistentes.
Servidores de aplicaciones
Se utilizan para controlar la interacción de los componentes entre sí y pueden virtualizarse o contenerse utilizando las herramientas de automatización existentes y el escalado dinámico de las herramientas de automatización de la infraestructura. Los escenarios de implementación más comunes en OpenShift, Kubernates, Rancher.
Con esto concluye la primera parte, la teórica. En la próxima serie de artículos, se analizarán ejemplos de integraciones con varios proveedores de identidad y ejemplos de configuraciones.
Fuente: habr.com