¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.dev
Miguel Ángel Díaz Corchero 01/02/2024 Cargando comentarios…
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.
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.
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).
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.
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.
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.
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.
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:
https://keycloak.demo.es/auth/realms/dev/broker/oidc/endpoint
Donde en dicha URL:
keycloak.demo.es:
nombre del servidor Keycloakdev:
nombre del RealmKeycloak 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.
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/authorizeToken URL =
https://login.microsoftonline.com/organizations/oauth2/v2.0/tokenLogout URL =
https://login.microsoftonline.com/organizations/oauth2/v2.0/logoutUser Info URL =
https://graph.microsoft.com/oidc/userinfoIgualmente, 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 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’.
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.
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.
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.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.