This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
En este artículo aprenderás a configurar un inicio de sesión mediante el lenguaje de marcado de aserción segura (SAML) en Checkmk.
SAML es un método estandarizado para informar a aplicaciones y servicios externos de que un usuario es realmente quien dice ser. SAML hace posible el single sign-on, ya que permite autenticar a un usuario una sola vez y luego comunicar esa autenticación a múltiples aplicaciones. Gracias a la conexión y la comunicación entre el denominado «proveedor de servicios» (SP) y el denominado «proveedor de identidades» (IdP), los empleados pueden acceder a diversas aplicaciones web con un único inicio de sesión. En la arquitectura SAML, el proveedor de servicios pone a disposición la aplicación y el proveedor de identidades gestiona las identidades digitales de los usuarios.
SAML es compatible con las ediciones comerciales de Checkmk y se puede configurar directamente en la interfaz web de Checkmk. Checkmk asume el papel de proveedor de servicios. Por ejemplo, tal y como se describe en el capítulo de configuración, Entra ID es un ejemplo de proveedor de identidad.
Microsoft Entra ID (abreviado: Entra ID) es el nuevo nombre de Azure Active Directory (Azure AD) desde 2023. Sin embargo, las capturas de pantalla y el contenido de los archivos de configuración que aparecen en este artículo siguen utilizando el nombre antiguo, Azure AD. |
Hasta la versión 2.2.0 de Checkmk, como alternativa, SAML también era compatible con el módulo Apache
mod_auth_mellon, que se suministraba como parte del software de Checkmk.
A partir de la versión 2.3.0, mod_auth_mellon ya no se incluye en el software de Checkmk.
Si quieres utilizar SAML como usuario de Checkmk Community
, debes instalar mod_auth_mellon por tu cuenta.
La configuración basada en esto se describe en el capítulo de Checkmk Community.
Sin embargo, ya no es compatible con nuestro soporte.
Todo el tema del cifrado de transporte (TLS/SSL) solo se incluye en los ejemplos en una implementación sencilla y de demostración. En entornos de producción con tu propia autoridad de certificación (CA) y el manejo adecuado de los certificados, habrá algunas diferencias que dependerán de tu propia infraestructura. |
2. Uso de SAML en Checkmk
Una vez que hayas completado todos los pasos del proceso de configuración, el usuario podrá utilizar el inicio de sesión SAML en Checkmk. El texto del botón se puede personalizar, tal y como se describe a continuación.

Cualquier usuario autorizado por SAML se creará automáticamente en Checkmk la primera vez que inicie sesión allí, siempre que no exista ya un usuario con el mismo ID. Si ya existe un usuario con el mismo ID, se rechazará la creación del usuario actual.
Los datos del usuario se sincronizarán cada vez que el usuario inicie sesión en Checkmk.
Para que SAML funcione, deben cumplirse varios requisitos previos:
La interfaz web debe estar protegida con HTTPS. Por motivos de seguridad, no se aceptan direcciones HTTP.
Los endpoints SAML de Checkmk para ID/metadatos y respuestas (Assertion Consumer Service) deben haberse registrado en el IdP. A continuación te mostramos cómo hacerlo.
Los mensajes que el IdP envía a Checkmk —respuestas a solicitudes de autenticación (obligatorias solo para la aserción) y declaraciones de atributos— deben estar firmados con uno de los algoritmos compatibles.
2.1. Algoritmos compatibles
Checkmk acepta los siguientes algoritmos para comunicarse con el IdP:
RSA-SHA256
RSA-SHA384
RSA-SHA512
ECDSA-SHA256
ECDSA-SHA384
ECDSA-SHA512
Checkmk utiliza RSA-SHA256 para firmar sus solicitudes.
Si el IdP no usa ninguno de los algoritmos anteriores para su respuesta, Checkmk la rechazará.
3. Configuración de SAML
Para poder usar SAML en las ediciones comerciales, primero hay que configurar el IdP. En nuestro ejemplo, se trata de Entra ID (llamado Azure Active Directory hasta 2023). Una vez hecho esto, se le proporciona al SP, es decir, a Checkmk, la información necesaria.
3.1. Iniciar sesión en Entra ID
Registrar el servicio SAML de Checkmk en Entra ID
A continuación, registra el servicio SAML de Checkmk en Entra ID. Para ello, ve a Enterprise applications > Create your own application.

Asigna un nombre arbitrario, preferiblemente significativo, por ejemplo, checkmk-saml.
Recomendamos no nombrar la aplicación simplemente checkmk para evitar confusiones con el agente Checkmk.
Selecciona la opción Integrate any other application you don’t find in the gallery (Non-gallery) y, a continuación, haz clic en el botón Create.
En la página de vista general de Entra ID habrás creado la siguiente función: Single sign-on > SAML > Basic SAML Configuration:

En este punto, Entra ID te pedirá dos datos más:
el Identifier (Entity ID) en el formato
https://myserver.com/mysite/check_mk/saml_metadata.py, yel Reply URL (Assertion Consumer Service URL) en el formato
https://myserver.com/mysite/check_mk/saml_acs.py?acs.
Deja todas las demás opciones sin cambiar, con su valor por defecto o vacías. En particular, el Relay State en Basic SAML Configuration debe permanecer sin cambios; de lo contrario, SAML no funcionará.
Ahora llama a Edit > Signing Option > Sign SAML assertion para configurar un Entra ID para las respuestas y verificaciones:

Recuperación de la información SAML de Entra ID
A continuación, ve a Entra ID para encontrar la información SAML que necesitas para Checkmk.
Esto está disponible en la vista de tabla «Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On» (ver arriba):
En la caja «SAML Certificates», busca el «App Federation Metadata URL». Lo necesitarás en la siguiente sección para configurar SAML en Checkmk (Identity provider metadata).
La caja «Attributes & Claims» te lleva a una vista de tabla de los atributos de usuario de Checkmk, por ejemplo, la dirección de correo electrónico, el nombre y los apellidos:

3.2. Activación de SAML en la interfaz web de Checkmk
Con la información obtenida anteriormente, configura la conexión SAML en el lado de Checkmk.
Si es necesario, añade el certificado TLS emitido por tu IdP a los certificados de confianza en Checkmk introduciéndolo en Setup > Global settings > Trusted certificate authorities for SSL.
Ahora abre Setup > Users > SAML authentication. Utiliza Add connection allí para empezar a configurar una nueva conexión:

Asigna un «Connection ID» y un «Name» a la nueva conexión. El «Name» se utilizará posteriormente para nombrar el botón de inicio de sesión de Checkmk.
A continuación, en la caja «Security», especifica si quieres proteger las conexiones de acceso con Checkmk o con tus propios certificados:

Si utilizas tus propios certificados, debes especificar el Private key y el Certificate.
Los certificados personalizados se almacenan en el directorio del site bajo ~/etc/ssl/saml2/custom/.
A continuación, en la caja «Connection», introduce como «Identity provider metadata» la URL (por ejemplo, la URL de metadatos de App Federation) que seleccionaste tal y como se describe en la sección anterior:

También puedes descargar el archivo XML de metadatos directamente desde Entra ID y subirlo en el diálogo anterior con la opción «Upload XML file» en «Identity provider metadata».
Esto resulta útil, por ejemplo, si tu servidor Checkmk no tiene acceso a internet.
En el campo obligatorio «Checkmk server URL», introduce la dirección que tú —no Entra ID— utilizas normalmente para acceder a Checkmk, p. ej., https://myserver.com.
Ahora tendrás que introducir los datos de usuario en la caja Users:

También debes obtener esta información tal y como se describe en la sección anterior.
Es importante tener en cuenta que el User ID attribute debe ser único, por ejemplo, el ID de usuario.
Checkmk requiere aquí el claim name completo de Entra ID, es decir, la dirección URL que empieza por http, para cada entrada;
por ejemplo, en el ejemplo anterior, el ID de usuario es http://schemas.xmlsoap.org/ws/2005/05/identity/claims/userID.
Para definir las responsabilidades de todos los usuarios que se autentican con SAML en Checkmk, se puede asignar a cada usuario a uno o varios grupos de contacto. Tienes varias opciones para definir el mapeo en Contact groups.
Puedes usar el Roles para asignar usuarios a diferentes roles con el fin de definir usuarios normales, administradores, etc.
4. SAML en Checkmk Community
La configuración que se describe en este capítulo solo es relevante para los usuarios de Checkmk Community que no pueden utilizar la conexión SAML integrada en las ediciones comerciales de Checkmk.
El requisito previo es que hayas instalado el módulo de Apache |
Las siguientes secciones solo describen la configuración de mod_auth_mellon para cualquier IdP que ya esté en funcionamiento, utilizando Active Directory Federation Services (ADFS) como ejemplo.
La conexión en el propio Checkmk se limita al último paso de las instrucciones de ADFS.
En el servidor Checkmk, mod_auth_mellon actúa como proveedor de servicios para las autenticaciones.
4.1. Iniciar sesión con los Servicios de federación de Active Directory
Requisitos previos
Iniciar sesión en Checkmk usando Active Directory es, básicamente, relativamente sencillo: Active Directory Federation Services (ADFS) actúa como proveedor de identidad (IdP), mientras que Checkmk proporciona la autenticación SAML.
Los requisitos previos para este tutorial son, por lo tanto:
Integración LDAP-AD en funcionamiento
ADFS operativo como IdP
Servidor Checkmk con SSL
Un sistema operativo compatible.
La configuración se realiza en tres pasos:
Configuración de Apache (resultado: archivo XML con metadatos).
Configuración de ADFS: establecer una relación de confianza con los metadatos de Mellon.
Habilitación del inicio de sesión en el propio Checkmk.
Configuración de Apache
Por supuesto, se trata de configurar el servidor Apache del propio sitio, así que inicia sesión allí primero:
Ahora crea un directorio para mod_auth_mellon y switch a él:
Ahora ejecuta mellon_create_metadata especificando tu servidor y tu site con el sufijo mellon:
Este módulo genera tres archivos: certificado (.cert), clave (.key) y metadatos estáticos (.xml).
El archivo .xml no es necesario y se puede eliminar:
Cambia el nombre de los archivos de clave y certificado para simplificar:
Ahora obtén los metadatos necesarios directamente de tu servidor ADFS (aquí myadfs) y guárdalos como idp-metadata.xml:
Ahora necesitas el certificado público del servidor ADFS, que está almacenado en el archivo idp-public-key.pem:
Por si te estás preguntando qué es echo -n:
Se utiliza para finalizar la siguiente sesión SSL.
El certificado debería, o incluso debe, cargarse en el almacén de confianza si, por ejemplo, el servicio IdP checkea la cadena de certificados. Para obtener más información sobre este tema, consulta el artículo sobre HTTPS. |
Como paso final, sustituye el archivo de configuración de autenticación ~/etc/apache/conf.d/auth.conf por la siguiente variante, especificando, por supuesto, tu servidor Checkmk (aquí myserver) y tu site (aquí mysite).
Ten en cuenta en el siguiente ejemplo de configuración que la ruta del directorio de instalación en la línea que comienza por LoadModule puede variar dependiendo de la distribución utilizada:
A continuación, reinicia Apache:
Por último, pero no menos importante, ahora descargas los metadatos de Mellon creados dinámicamente como un archivo XML para que puedas importarlos a AD Management de inmediato:
Configuración del directorio Active Directory
Para crear una relación de confianza de parte confiable en ADFS, haz lo siguiente:
Inicia la interfaz de ADFS:

Haz clic en «Add Relying Party Trust»:

Deja la opción en «Claims aware» y continúa con el botón «Start»:

Ahora selecciona «Import data on the relying party from a file» y especifica el archivo XML que acabas de descargar:

Puedes ignorar tranquilamente la advertencia WARN de «AD FS Management»:

En «Specify Display Name», introduce ahora «Checkmk» como nombre:

Al asignar permisos, con fines de prueba, para el Choose Access Control Policy puedes seleccionar primero el valor Permit everyone; más adelante deberás cambiarlo por Permit specific group.

Confirma el resumen en «Ready to Add Trust»:

Por último, confirma el diálogo «Finish» y mantén la checkmark en «Configure claims issuance policy for this application»:

Selecciona la confianza de la parte confiable que acabas de crear y, a continuación, inicia el editor con «Edit Claim Issuance Policy…»:

Añade una nueva regla en el siguiente diálogo a través de «Add Rule…»:

En el primer paso de «Select Rule Template», selecciona «Transform to Incoming Claim» y confirma:

En el segundo paso de Configure Rule, configura los siguientes valores:
Incoming claim type:
Windows account nameOutgoing claim type:
Name IDOutgoing name ID format:
Transient Identifier

Este paso también completa la configuración de ADFS. Ahora FS puede derivar la autenticación para Checkmk a partir de la autenticación de Windows, a la que le indicas que autentifique a los usuarios mediante solicitudes HTTP en el siguiente paso.
Configuración de Checkmk
En Checkmk, en Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, en el Current settings, ahora solo tienes que activar la opción Activate HTTP header authentication.

4.2. Información adicional para otros sistemas
Entra ID con mod_auth_mellon
Cuando Entra ID (llamado Azure Active Directory hasta 2023) actúa como IdP, hay algunas diferencias en el procedimiento de configuración; por ejemplo, el nombre de usuario se puede especificar directamente sin necesidad de reescribirlo.
Requisitos previos para la siguiente configuración de ejemplo:
Configura UserPrincipalName en la conexión LDAP como identificador (más información en la documentación de Microsoft).
Aplicación empresarial personalizada en Entra ID con UserPrincipalName como atributo «name» (para más información, consulta la documentación de Microsoft).
Ten en cuenta en la siguiente configuración de ejemplo que la ruta del directorio de instalación en la línea que empieza por LoadModule puede variar dependiendo de la distribución que uses:
NetIQ Access Manager
Cuando NetIQ Access Manager actúa como IdP, hay algunas diferencias en el procedimiento de configuración; por ejemplo, el nombre de usuario se puede especificar directamente sin necesidad de reescribirlo.
Ten en cuenta en el siguiente ejemplo de configuración que la ruta del directorio de instalación en la línea que empieza por LoadModule puede variar según la distribución que uses:
5. Migrar usuarios existentes
Una vez que hayas habilitado SAML, puedes migrar a los usuarios existentes de una conexión basada en contraseña a la conexión SAML. Para ello, check las cuentas que quieras en la gestión de usuarios, en «Setup > Users > Users». A continuación, inicia la migración a través de «Migrate selected users».

En un paso intermedio, puedes eliminar cualquier atributo.

