Introducción

En Q4 vamos a incorporar Keycloak como Identity Manager avanzado, para aquellos escenarios en los que se necesite una configuración más avanzada y personalizada: múltiples repositorios de usuarios y proveedores de autenticación (user federation), integración con otros IM (identity brokering), personalización del flujo de autenticación y sesiones…

A continuación se va a detallar cómo se ha enfocado la integración con este IM Open Source. No obstante, esto es una primera aproximación, y como todo lo que se integra en plataforma, está sujeto a cambios según vayamos recogiendo feedback de los productos y proyectos.

Glosario Keycloak

Below there are terms within Keycloak:

• Admin Console: Web-based GUI where you can “click out” all configurations required by your instance to work as you desire. 

• Users: Entities that are able to log into the protected system. They have a set of editable attributes and can be a part of a group and/or have specific roles assigned to them.

• Role: A type or category of user that exists within an organization. Applications often base on roles to restrict access to resources.  

• Groups: Entities that are used to manage a set of users. Similarly to users, groups have editable attributes and you can also assign roles to a group. Users that become members of a group inherit their attributes and roles.

• Realm: A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control.

• Client: Entities that can request Keycloak to authenticate a user. Most often, clients are applications and services which want to use Keycloak to secure themselves. Clients may also be entities wanting to request identity information or an access token so that they can securely invoke other services secured by Keycloak.

• Identity Token: A token providing identity information about the user. Part of the OpenID Connect specification.

• Access Token: A token that can be provided as part of an HTTP request. 

Keycloak Realms

Los Realms de Keycloak se van a corresponder con los verticales de la plataforma, para que en un entorno Multitenant, cada cliente tenga su propio Realm de Keycloak, que en definitiva es una instancia independiente. Dicho Realm podrán configurarlo en base a sus necesidades sin que afecte al resto. Cada Realm tendrá sus propias URLs, providers, clients…

Keycloak Clients

Los clientes de Keycloak se corresponderán con el concepto de realm de plataforma, de tal forma que los realms que se den de alta en plataforma, estarán accesibles para la autenticación via Keycloak, con los mismos roles, usuarios y client secret. En un entorno Multitenant, cada vertical tendrá únicamente los clientes que les corresponden.

Providers

El provider por defecto que vendrá configurado en las instalaciones con este IM será el nuestro propio, el de los usuarios existentes en la base de datos de configuración (ConfigDB). No obstante, se podrán añadir los “built-in” como LDAP y Kerberos, e incluso desarrollos propios externos.

Configuración avanzada

Además de la integración que ofrecemos con plataforma, es posible configurar y extender Keycloak mediante los mecanismos que se explican en la documentación de la herramienta: https://www.keycloak.org/documentation