Administración centralizada de grupos de usuarios con Keycloak y AzureAD.

Cada vez que nos logueamos en un servicio web público o corporativo, es muy probable que nuestras credenciales sean manejadas por un sistema de acceso e identidades (IAM). Gracias a IAM, nuestro usuario puede acceder a varias aplicaciones y servicios usando las mismas credenciales. En este post, iremos más allá, cubriendo la gestión de grupos de usuarios y permisos centralizados, basándonos en Azure AD y Keycloak. Además, usaremos Jenkins como servicio final y veremos el proceso. Si queréis añadir otra aplicación o servicio a un IAM, este post también servirá como guía base, previamente asegurándose si la aplicación soporta su integración con IAM.

Definiendo la solución

En un sistema de acceso centralizado necesitamos tener un servicio de administración de identidad o proveedor de identidad (con las siglas IdP en inglés).

En este caso tenemos a Azure Active Directory (Azure AD) desde el cual se gestionará los usuarios y grupos de usuarios por parte de un administrador. Azure AD es accedido por Keycloak, nuestro broker de identidad, para consultar las identidades y grupos alojados en Azure AD.

Tras ello, Keycloak se encargará de presentar los datos de las identidades al servicio final. Por último, el servidor final, en este caso Jenkins, accederá a Keycloak para validar las solicitudes de acceso recibidas por los usuarios.

En el siguiente esquema tenemos una visión general de cómo sería el flujo:

En el resto de post explicaremos detalladamente los protocolos y los componentes, qué función tienen y cómo se configuran.

Protocolos que intervienen en la solución

Desde Jenkins como servicio final hasta Keycloak, el funcionamiento depende del protocolo que se use, bien OpenID Connect (OIDC) o Security Assertion Markup Language (SAML).

• En el caso de OIDC, cada vez que un usuario intenta acceder a una aplicación o servicio que use OIDC, dicho acceso es redirigido a su proveedor de identidad, donde el usuario tras identificarse es autenticado y tras ello es redirigido a la aplicación o servicio. En este caso, el usuario y el password los introducimos en un formulario ofrecido por el proveedor de identidad.
• En el caso de SAML, cada vez que un usuario intenta acceder a una aplicación o servicio que use SAML, dicha aplicación o servicio recoge la solicitud de identificación del usuario y verifica en el proveedor de identidad si ya está logueado. En caso de que no lo esté, el proveedor de identidad solicita las credenciales al usuario y manda una aserción a la aplicación o servicio indicando si el usuario debe tener acceso o no. Al igual que en OIDC, el usuario y el password los introducimos en un formulario ofrecido por el proveedor de identidad.

Y entonces, ¿cuál es la diferencia más significativa entre OIDC y SAML? Bien, SAML es un protocolo más antiguo y robusto que data del 2005. SAML utiliza XML para su formato de datos de identidad y es ampliamente utilizado en la administración.

Sin embargo, OIDC es un protocolo relativamente nuevo (2014) diseñado para ser fácil de adoptar y utilizar. OIDC es una extensión de OAuth2 y usa estructuras de datos de tipo JSON. OIDC se utiliza en sectores bancarios, aplicaciones móviles y aplicaciones web de una sola página (SPA). Aunque SAML es más potente, OIDC es más liviano y fácil de usar.

¿Pero entonces cuál elegimos? Básicamente, debes elegir el protocolo que soporta el servicio o aplicación que estés configurando.

Por la parte de Keycloak no es inconveniente el tener varios servicios o aplicaciones que usen protocolos distintos, ya que puedes configurar un protocolo diferente por cada aplicación. Keycloak se conectaría con dicho servicio o aplicación usando el protocolo configurado específicamente para él.

Desde la parte de Keycloak al proveedor de identidad también hay que establecer cuál es el protocolo compatible entre ambas partes. Keycloak tiene un listado de compatibilidad de proveedores de identidades (sociales y privados) bastante amplio.

¿Cómo puedo integrar Keycloak con mis aplicaciones o servicios?

Lo primero de todo es saber si la aplicación o servicio final soporta los protocolos de identidad de Keycloak (OIDC o SAML) y en caso afirmativo necesitamos conocer si es necesario instalar algún plugin adicional a dicha aplicación. En el caso de Jenkins será necesario instalar el plugin OpenId Connect Authentication.

¿Dónde residen los usuarios y grupos que Keycloak provee?

Keycloak tiene dos opciones para alimentar su base de datos de usuarios y grupos:

• Registro local: dentro de Keycloak podemos definir usuarios, grupos de usuarios y roles y relacionarlos entre sí. De esa manera, tenemos definidas las identidades dentro de la base de datos de Keycloak. En este caso, Keycloak funciona como un proveedor de identidad.

• Proveedor de identidad externo: aunque Keycloak puede definir su listado de identidades, grupos y roles internamente, también se puede enlazar con uno o varios proveedores de identidad para descargar sus identidades. En este último caso, Keycloak podemos decir que se comporta como un Broker de Identidad, donde las tareas de administración de identidades y grupos se las delega al proveedor de identidad, quedando únicamente la tarea de verificar identidades entre el proveedor de identidad y el servicio o aplicación final. Este caso resulta especialmente útil cuando ya se dispone de un proveedor de identidad con las identidades y los grupos correctamente definidos, ya que evita el tener que duplicar identidades, credenciales, grupos y sus tareas de gestión, evitando además el problema de sincronización entre diferentes proveedores de identidad.

En la solución propuesta en este post, Keycloak actúa como broker de identidad y Azure AD como proveedor de identidad.

Implementando la solución

Bien, ¿y cómo integramos Azure Active Directory con Keycloak y Jenkins? En esta sección os contamos los aspectos más relevantes de la integración de estos componentes.

Preparar Azure AD

Azure AD es un servicio de administración de identidad basado en la nube y dedicado especialmente para empresas. Azure AD permite que los empleados de una empresa puedan acceder a recursos como Microsoft 364, Azure portal y varios más como estos.

La plataforma de identidad de Azure habilita servicios de identidad y acceso únicamente para aplicaciones registradas.

Es por ello que tenemos que:

1. Crearnos un registro de aplicación (Manage → app registration) en Azure AD
2. En token-configuration añadimos Groups para introducir los grupos del usuario en el token
3. Configuramos cuál será la URL de la aplicación (Authentication →Web →Redirect URIs) donde se mandará la respuesta de autenticación. Por ejemplo, la URL de la aplicación podría ser:

https://keycloak.demo.es/auth/realms/dev/broker/oidc/endpoint

Donde en dicha URL:

• keycloak.demo.es: nombre del servidor Keycloak
• dev: nombre del Realm

Configurar Keycloak

Keycloak admite la configuración con realms. Cada realm es un espacio donde se puede administrar usuarios, aplicaciones, roles y grupos. El realm que vamos a crear se llamará Production y contendrá la configuración Keycloak referente al proveedor de identidad Azure AD y la configuración referente al cliente Jenkins.

Keycloak: Enlazar contra el proveedor de identidad

Por cada Realm, Keycloak puede configurar varios proveedores de identidad. En nuestro caso, únicamente vamos a configurar el acceso a Azure AD. Dentro de la lista extensa de opciones que nos ofrece Keycloak para acceder a Azure AD, sabemos que Microsoft y OpenID Connect funcionan para leer las identidades, pero existen diferencias.

Una diferencia importante entre ambas elecciones es que la de Microsoft no permite leer los grupos de un usuario dentro de Azure AD, con lo que deberíamos crearnos los grupos manualmente en Keycloak y asignarlos a cada usuario.

Como deseamos evitar redundancia de operaciones y problemas de sincronización de grupos entre Azure AD y Keycloak hemos optado por usar la opción OpenID Connect donde podemos leer los grupos de usuarios de AD.

Para configurar OpenId Connect tenemos que indicarle que lea las identidades desde el registro de aplicación configurado previamente en Azure AD. Estos son los valores reportados por Azure AD que tenemos que introducir en Keycloak para indicarle el Azure AD endpoint.

• Authorization URL = https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize
• Token URL = https://login.microsoftonline.com/organizations/oauth2/v2.0/token
• Logout URL = https://login.microsoftonline.com/organizations/oauth2/v2.0/logout
• User Info URL = https://graph.microsoft.com/oidc/userinfo

Igualmente, a Keycloak también tenemos que indicarle las credenciales (clientId y ClientSecret) del registro de aplicación que creamos en Azure AD. El clientID es el identificador del registro de aplicación, mientras que el ClientSecret es el valor de cualquier secreto activo que tenga el registro de aplicación.

Finalmente, tenemos que indicar el campo de identidad que será enviado para preguntar por la autorización, normalmente es email y en el promt debemos indicar Login para hacer que Azure AD muestre su ventana de autenticación al usuario final.

Para validar que la integración Azure AD y Keycloak está finalizada, vamos a usar un cliente existente en Keycloak que nos servirá para conectarnos en Keycloak usando las identidades de Azure AD.

En Keycloak vamos a Clients > Security-admin-console:

En este punto, la primera vez tenemos que introducir nuestro email para que se almacene en la DB de Keycloak y confirmar el acceso. Esto nos llevará a una ventana de inicio de Keycloak donde ya podremos ver nuestro usuario logueado. Como en KeyCloak el usuario con el que queremos acceder no tiene permisos veríamos un error 403, pero aun así veremos el usuario logueado.

Keycloak: Mapeo de grupos a roles

Keycloak ha sido capaz de descargar identidades y los grupos a los que pertenecen dichas identidades en Azure AD. Por ejemplo, en Azure AD tenemos un usuarioDev1 y un usuarioDev2 donde ambos usuarios son miembros del grupo Desarrolladores.

Lo que se pretende es que el grupo Desarrolladores de Azure AD tenga un clon de identidades y grupos en Jenkins, con lo que en Jenkins se pudieran loguear los usuarios usuarioDev1 y usuarioDev2, y ambos usuarios tengan las reglas definidas en el role Desarrolladores de Jenkins.

En este punto tenemos que transformar el grupo de Azure AD llamado “Desarrolladores” en el Role de Keycloak llamado ‘Desarrolladores’. Para ello, creamos en Keycloak manualmente el role ‘Desarrolladores’ y creamos una regla para que todos los usuarios descargados de Azure AD que pertenezcan al grupo de Azure AD ‘Desarrolladores’ sean asignados al role de Keycloak ‘Desarrolladores’.

Para ello, en Keycloak nos vamos a nuestro Identity Provider > OIDC > Mappers > Add Mapper y asignamos el siguiente mapeo:

• Mapper type: Advanced Claim to Role
• Claims
  • Key: groups
  • Value: ID of the group Desarrolladores in AD
• Role: Desarrolladores

Una vez configurado este mapper, podemos loguearnos en Keycloak con el usuario usuarioDev1 y veremos como queda asignado automáticamente al role de ‘Desarrolladores’.

Keycloak: Crear el cliente Jenkins

Dentro de Keycloak necesitamos definirnos una entrada Client para referenciar a Jenkins indicando la URL de Jenkins (desde donde provienen las solicitudes) y la URI de redirección (hasta donde se puede responder). Por ejemplo:

• Root URL: https://my-jenkins/
• Home URL: https://my-jenkins/
• Valid redirect URIs: https://my-jenkins/*

Igualmente, es necesario crear una secret ‘Client Secret’ para este cliente. Esta secret la usaremos cuando configuremos Jenkins para que pueda loguearse contra Keycloak.

Preparar Jenkins

Por último, que quedaría por configurar Jenkins. Para ello instalaremos el plugin OpenId Connect Authentication y lo configuraremos para que apunte al cliente Jenkins que definimos en Keycloak y para definir qué campos intervienen en la autenticación y autorización. Con lo que la configuración del plugin de Jenkins podría quedar así:

• authorizationServerUrl: "https://my-keycloak.foo/auth/realms/myRealm/protocol/openid-connect/auth"
• endSessionEndpoint: "https://my-keycloak.foo/auth/realms/myRealm /protocol/openid-connect/logout"
• tokenServerUrl: "https://my-keycloak.foo/auth/realms/myRealm/protocol/openid-connect/token"
• userInfoServerUrl: "https://my-keycloak.foo/auth/realms/myRealm/protocol/openid-connect/userinfo"
• fullNameFieldName: "email"
• groupsFieldName: "groups"
• userNameField: "email"
• scopes: "openid, profile, group-membership, roles, groups, …”

En Jenkins también debemos tener definidos los diferentes roles locales con la asignación detallada de acciones (read, configure, delete…) sobre los diferentes recursos (overall, credentials…) descritos en la siguiente tabla:

Es necesario resaltar que es importante definir los roleNames de Jenkins igual a los roleNames de Keycloak para hacer la relación de usuario - role en Jenkins. Siguiendo nuestro ejemplo, deberíamos crear en Jenkins un role llamado ‘Desarrolladores’ y asignarle los permisos que consideremos.

Conclusiones y otras alternativas

Teniendo en cuenta que la centralización de la autenticación y autorización de distintos servicios o aplicaciones se puede llevar a cabo usando herramientas OpenSource como Keycloak, y aprovechando su compatibilidad con los proveedores de identidad comúnmente extendidos como Azure AD, podemos diseñar una centralización de la autenticación y/o la autorización de usuarios según las necesidades de los servicios y aplicaciones.

Al esquema propuesto en este post, podemos comentar la alternativa de gestionar los grupos directamente desde Keycloak, evitando que Keycloak tenga que consultar los grupos desde Azure AD. De esta manera, la gestión de grupos se realizaría por el administrador del servicio Keycloak.

El administrador de Azure AD únicamente gestionaría las identidades, aunque puede gestionar los grupos de dichas identidades para otros propósitos. En este último caso, estos grupos no serían leídos por Keycloak y no afectarían a esta alternativa. Esta alternativa es ideal si el control sobre los grupos de Azure AD no está permitido o no es ágil.

• Foto de portada de Annie Spratt en Unsplash.