/
¿Cómo levantar Keycloak como Identity Manager en Entorno local?

¿Cómo levantar Keycloak como Identity Manager en Entorno local?

 

Consideraciones

A partir de la version 6.0.0 de Plataforma desaparece el Identity Manager básico (OAuth2Server) y toda la seguridad se resuelve a través del Identity Manager avanzado (aka Keycloak).

A la hora de desarrollar en local esto implica:

  • Aquellos módulos que necesiten un token (API Manager, BPM Engine, Microservices Manager…) tienen que configurarse para arrancar en local contra Keycloak.

  • El control-panel permite la ejecución stand-alone (se puede arrancar sin Keycloak) si solo se va a desarrollar o corregir bugs de pantallas, aunque si es necesario desplegar configurado con Keycloak para desarrollos sobre otros módulos.

Introducción

En esta guía se describen los pasos para levantar y configurar Keycloak con una configuración por defecto (MariaDB como ConfigDB y con los módulos con sus propiedades precargadas).

Todos los módulos que son susceptibles de usar Keycloak tienen dentro de su fichero /src/main/resources/application.yml

 

image-20241028-114031.png

las propiedades onesaitplatform.authentication.oauth.enabled y onesaitplatform.authentication.oauth.osp-keycloak.

Que permiten habilitar o deshabilitar Keycloak como Identity Manager:

image-20240320-200025.png

Como ejecutar Keycloak

A continuación se indican los pasos para lanzar Keycloak en local:

  • Arrancar la configdb. En caso de que sea la primera vez, o se hayan borrado los esquemas para lanzar un nuevo desarrollo, lanzar tambien el módulo config-init para crear las tablas.

  • Abrir el docker-compose ubicado en devops/build-deploy/docker/modules/keycloak , y modificar la línea de extra_hosts, poner la IP de tu local (no localhost).

 

image-20240403-084754.png
  • Tener levantado Docker o Rancher Desktop en nuestra máquina. Con esto nos vamos a esta ruta en el directorio donde tenemos descargado el código de plataforma: devops/build-deploy/docker/modules/keycloak y ejecutamos:

docker-compose up -d
  • Comprobar que se levanta keycloak:

image-20240320-194352.png
  • En Eclipse, importar como proyecto maven el proyecto keycloak-manager, desde la ruta donde tenemos descargado el código fuente de plataforma: tools/keycloak/onesaitplatform-keycloak-manager

  • Una vez importado el keycloak-manager es posible que se muestre un error de una dependencia de onelog. Se resuelve actualizando en su pom.xml la versión de plataforma a aquella con la que estamos trabajando en local:

image-20240320-194638.png
  • Con un cliente de Base de datos (heidi, dbeaver o similar) entramos a la base de datos de plataforma (onesaitplatform_config) y localizamos la tabla user_token

image-20240320-194954.png
  • Copiamos el token de platform_admin y abrimos el fichero application.yml del proyecto keycloak-manager, para sustituirlo en la propiedad onesaitplatform.api-key

image-20240320-195059.png
  • Volvemos a la tabla y copiamos el token del usuario administrator

image-20240320-195143.png
  • Abrimos el fichero sso_extras.properties del proyecto plugin-security-keycloak y sustituimos la propiedad api-key por la copiada en la tabla.

image-20240320-195250.png

Con esto hecho, arrancamos en orden primero el control-panel y despues el keycloak-manager. Esto hará que el keycloak-manager cree en Keycloak el Realm por defecto de OnesaitPlatform con los roles de plataforma y ya podamos utilizar Keycloak como Identiy Manager.

Nota: Por regla general, no es necesario tener arrancado el keycloak-manager una vez hecho este último paso la primera vez. El keycloak-manager actúa como módulo sincronizador de los Realms que se definen en plataforma con Keycloak, por lo que si no se va a trabajar con Realms lo más probable es que no se necesite. No obstante, cualquier petición que se lance a http://localhost:15500 nos tiene que hacer sospechar que lo tenemos que levantar.

Nota*: Es posible que se tengan problemas al conectarse Keycloak a la base de datos en Windows, debido a que por defecto, MariaDB bloquea conexiones con usuario root de IPs que no sean la local. Para solucionarlo ejecutar en MariaDB:

GRANT ALL ON *.* to root@'%' IDENTIFIED BY 'changeIt!'; FLUSH PRIVILEGES;



 

Related content