 |
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 Secure Assertion Markup Language (SAML).
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 (SSO) porque puede utilizarse para autentificar a un usuario una vez y luego comunicar esa autenticación a múltiples aplicaciones. Con la ayuda de la conexión y comunicación entre el llamado "Proveedor de Servicios" (SP) y el llamado "Proveedor de Identidad" (IdP), es posible que los empleados accedan a varias aplicaciones web con un solo inicio de sesión. En la arquitectura SAML, el Proveedor de Servicios pone la aplicación a disposición y el Proveedor de Identidad gestiona las identidades digitales de los usuarios.
SAML es compatible con las ediciones comerciales de Checkmk y puede configurarse directamente en la interfaz web de Checkmk. Checkmk asume el papel de Proveedor de Servicios. Por ejemplo, como se describe en el capítulo de configuración, Entra ID es un ejemplo de Proveedor de Identidades.
 |
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 contenidos en este artículo siguen utilizando el antiguo nombre Azure AD. |
Hasta la versión de Checkmk 2.2.0, como alternativa, SAML también era compatible con el módulo de 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. Por tanto, si quieres utilizar SAML como usuario de Checkmk Raw, debes instalar tú mismo mod_auth_mellon. La configuración basada en esto se describe en el capítulo sobre Checkmk Raw. Sin embargo, ya no recibimos soporte para ello.
|
Todo el tema de la encriptación del transporte (TLS/SSL) sólo 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 una gestión adecuada de los certificados, habrá algunas diferencias que dependerán de tu propia infraestructura. |
2. Utilizar SAML en Checkmk
Una vez que hayas pasado por todos los puntos del proceso de configuración, el inicio de sesión SAML puede ser utilizado por el usuario en Checkmk. El texto del botón se puede personalizar, 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 de usuario se sincronizarán cada vez que el usuario inicie sesión en Checkmk.
Se deben cumplir varios requisitos previos para que SAML funcione:
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 con el IdP. A continuación te mostramos cómo hacerlo.
Los mensajes dirigidos por el IdP a Checkmk -respuestas a solicitudes de autenticación (sólo obligatorias para la aserción) y declaraciones de atributos- deben estar firmados con uno de los algoritmos admitidos.
2.1. Algoritmos admitidos
Checkmk acepta los siguientes algoritmos para la comunicación con el IdP:
RSA-SHA256
RSA-SHA384
RSA-SHA512
ECDSA-SHA256
ECDSA-SHA384
ECDSA-SHA512
El propio Checkmk utiliza RSA-SHA256 para firmar sus solicitudes.
Si el IdP no utiliza ninguno de los algoritmos anteriores para su respuesta, ésta será rechazada por Checkmk.
3. Configurar SAML
Para poder utilizar SAML en las ediciones comerciales, primero hay que configurar el IdP, que en nuestro ejemplo es Entra ID (llamado Azure Active Directory hasta 2023). Una vez hecho esto, se suministra la información necesaria al SP, es decir, a Checkmk.
3.1. Registro en Entra ID
Registro del servicio Checkmk SAML en Entra ID
A continuación, registra el servicio Checkmk SAML en Entra ID. Para ello, llama a Enterprise applications > Create your own application.
Asigna un nombre arbitrario, preferiblemente significativo, por ejemplo checkmk-saml. Te recomendamos que no nombres 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 pulsa el botón Create.
En la página general de Entra ID habrás creado la siguiente función: Single sign-on > SAML > Basic SAML Configuration:
Llegados a este punto, Entra ID necesitará 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 cambios en su valor por defecto o vacías. En particular, el Relay State en el 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 ID de Entra para respuestas y verificaciones:
Recuperar información SAML del Entra ID
A continuación, ve a Entra ID para encontrar la información SAML que necesitas para Checkmk.
Está disponible en la vista de tabla Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On (ver más 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 los atributos de usuario para Checkmk, por ejemplo, dirección de correo electrónico, nombre y apellidos:
3.2. Activar 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 allí Add connection para empezar a configurar una nueva conexión:
Asigna un Connection ID y un Name para la nueva conexión. El Name se utilizará después para dar nombre al botón de inicio de sesión de Checkmk.
A continuación, en la caja Security, especifica si quieres asegurar 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 en ~/etc/ssl/saml2/custom/.
A continuación, en la caja Connection, introduce como Identity provider metadata la URL (por ejemplo, URL de metadatos de App Federation) que seleccionaste como se describe en la sección anterior:
Como alternativa, puedes descargar el archivo XML de metadatos directamente de Entra ID y cargarlo en el diálogo anterior con la opción Upload XML file en Identity provider metadata. Esto es conveniente, por ejemplo, si tu servidor Checkmk no tiene acceso a internet. Para la obligatoria Checkmk server URL, introduce la dirección que tú -y no Entra ID- utilizas normalmente para acceder a Checkmk, por ejemplo https://myserver.com.
Ahora tendrás que introducir los datos del usuario en la caja Users:
También tienes que obtener esta información como se describe en la sección anterior. Es importante tener en cuenta que User ID attribute debe ser único, por ejemplo, el ID de usuario. En este caso, Checkmk necesita 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 autentiquen con SAML en Checkmk, cada usuario puede asignarse a uno o varios grupos de contacto. Tienes varias opciones para definir el mapeo en Contact groups.
Puedes utilizar el Roles para asignar usuarios a diferentes roles con el fin de definir usuarios normales, administradores, etc.
4. SAML en Checkmk Raw
|
La configuración descrita en este capítulo sólo es de interés para los usuarios de Checkmk Raw que no puedan 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 sólo describen la configuración de mod_auth_mellon para los IdP que ya estén en funcionamiento, utilizando como ejemplo los Servicios de Federación de Directorio Activo (ADFS). 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 autentificaciones.
4.1. Iniciar sesión con los Servicios de Federación de Active Directory
Requisitos previos
Iniciar sesión en Checkmk utilizando Active Directory es, básicamente, relativamente sencillo: Active Directory Federation Services (ADFS) actúa como proveedor de identidad (IdP), Checkmk proporciona la autenticación SAML.
Los requisitos previos para este tutorial son los siguientes
Funcionamiento de la integración LDAP-AD
Funcionamiento de ADFS como IdP
Servidor Checkmk con SSL
Un sistema operativo compatible.
La configuración se realiza en tres pasos:
Configuración de Apache (un resultado: archivo XML con metadatos).
Configuración de ADFS: establecimiento de una confianza de parte fiduciaria con metadatos de Mellon.
Habilitación del inicio de sesión en el propio Checkmk.
Configuración de Apache
Se trata, por supuesto, de configurar el propio servidor Apache del site, así que primero inicia sesión allí:
root@linux# omd su mysiteAhora crea un directorio para mod_auth_mellon y pasa a él:
OMD[mysite]:~$ mkdir etc/apache/mellon
OMD[mysite]:~$ cd etc/apache/mellonAhora ejecuta mellon_create_metadata especificando tu servidor así como tu site con el sufijo mellon:
OMD[mysite]:~/etc/apache/mellon$ mellon_create_metadata https://myserver "https://myserver/mysite/mellon"Este módulo genera tres archivos: Certificado (.cert), clave (.key) y metadatos estáticos (.xml). El archivo .xml no es necesario y puedes eliminarlo:
OMD[mysite]:~/etc/apache/mellon$ rm *.xmlCambia el nombre de los archivos de clave y certificado para simplificar:
OMD[mysite]:~/etc/apache/mellon$ mv .key mellon.key
OMD[mysite]:~/etc/apache/mellon$ mv .cert mellon.certAhora obtén los metadatos necesarios directamente de tu servidor ADFS (aquí myadfs) y guárdalos como idp-metadata.xml:
OMD[mysite]:~/etc/apache/mellon$ wget --no-check-certificate -O ./idp-metadata.xml https://myadfs/FederationMetadata/2007-06/FederationMetadata.xmlAhora necesitas el certificado público del servidor ADFS, que se guarda en el archivo idp-public-key.pem:
OMD[mysite]:~/etc/apache/mellon$ echo -n | openssl s_client -connect myadfs:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -pubkey -noout > idp-public-key.pemEn caso de que te estés preguntando por el 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 comprueba la cadena de certificados. Para más información sobre este tema, consulta el artículo 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). Observa 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 en función de la distribución utilizada:
# Set this to the Name of your Checkmk site, e.g.
#Define SITE
Define SITE mysite
# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server. auth_mellon uses this
# to generate the needed URLs in the metadata
ServerName https://myserver
# Load the module.
<IfModule !mod_auth_mellon.c>
LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so
</IfModule>
# Only enable this for debugging purposes
#MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.txt
#MellonDiagnosticsEnable On
<Location /${SITE}>
# Use SAML auth only in case there is no Checkmk authentication
# cookie provided by the user and whitelist also some other required URLs
<If "! %{HTTP_COOKIE} =~ /^(.*;)?auth_${SITE}/ && \
! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/automation.py' && \
! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">
MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
MellonEndpointPath "/${SITE}/mellon"
MellonDefaultLoginPath "/${SITE}/check_mk/"
Order allow,deny
Allow from all
MellonSecureCookie On
MellonCookieSameSite None
AuthType Mellon
AuthName "Checkmk SAML Login"
MellonEnable auth
Require valid-user
# Get Username
# ADFS sends username as DOMAIN\username pair.
# Checkmk just wants the username.
RewriteEngine on
RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
RequestHeader edit X-Remote-User "^.*\\\(.*)$" "$1"
# When SAML auth fails, show the login page to the user. This should only happen,
# if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
# A failed login at the IDP will not return you here at all.
ErrorDocument 401 '<html> \
<head> \
<meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
</head> \
<body> \
SAML authentication failed, redirecting to login page. \
<a href="/${SITE}/check_mk/login.py">Click here</a>. \
</body> \
</html>'
</If>
# This header is also needed after authentication (outside of the If clause)
RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
RequestHeader edit X-Remote-User "^.*\\\(.*)$" "$1"
</Location>A continuación, reinicia Apache:
OMD[mysite]:~/etc/apache/mellon$ omd restart apachePor último, pero no menos importante, ahora descarga los metadatos de Mellon creados dinámicamente como un archivo XML para que puedas importarlos a AD Management de inmediato:
OMD[mysite]:~/etc/apache/mellon$ wget https://myserver/mysite/mellon/metadata -o metadata.xmlConfigurar Directorio Activo
Para crear una parte de confianza en ADFS, haz lo siguiente:
Inicia la interfaz ADFS:
Haz clic en Add Relying Party Trust:
Deja la opción establecida en Claims aware y continúa con el botón Iniciar:
Ahora selecciona Import data on the relying party from a file y especifica el archivo XML que acabas de descargar:
Puedes ignorar sin problemas la advertencia AD FS Management:
En Specify Display Name introduce ahora Checkmk como nombre:
Cuando asignes permisos, para hacer pruebas, para el Choose Access Control Policy puedes seleccionar primero el valor Permit everyone; más tarde deberías cambiarlo por Permit specific group.
Confirma el resumen en Ready to Add Trust:
Por último, confirma el diálogo Finish y mantén el checkmark en Configure claims issuance policy for this application:
Selecciona la confianza de la parte de confianza 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 Select Rule Template selecciona Transform to Incoming Claim y confirma:
En el segundo paso Configure Rule establece los siguientes valores:
Incoming claim type:
Windows account nameOutgoing claim type:
Name IDOutgoing name ID format:
Transient Identifier
Esto también completa la configuración de ADFS. Ahora FS puede derivar la autenticación para Checkmk de la autenticación de Windows, a la que darás instrucciones para autenticar a los usuarios mediante peticiones HTTP en el siguiente paso.
Configurar Checkmk
En Checkmk, en Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, en Current settings ahora sólo 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:
Establecer UserPrincipalName en la conexión LDAP como identificador (más información en la documentación de Microsoft).
Custom Enterprise App en Entra ID con UserPrincipalName como atributo "name" (para más información, consulta la documentación de Microsoft).
Observa 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 en función de la distribución utilizada:
#Set this to the Name of your Checkmk site, e.g.
# Define SITE mysite
Define SITE mysite
# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server.
# auth_mellon uses this to generate the needed URLs in the metadata.
ServerName https://myserver
# Load the module.
<IfModule !mod_auth_mellon.c>
LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so
</IfModule>
# Only enable this for debugging purposes
# MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.log
# MellonDiagnosticsEnable On
<Location /${SITE}>
# Use SAML auth only in case there is no Checkmk authentication
# cookie provided by the user and whitelist also some other required URLs.
<If "! %{HTTP_COOKIE} =~ /^auth_${SITE}/ && \
! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/automation.py' && \
! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">
RequestHeader unset X-Remote-User
MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
# Azure-AD-specific: Not needed because in metadata:
#MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
MellonEndpointPath "/${SITE}/mellon"
MellonDefaultLoginPath "/${SITE}/check_mk/"
Order allow,deny
Allow from all
MellonSecureCookie On
MellonCookieSameSite None
AuthType Mellon
MellonEnable auth
require valid-user
# Azure-AD-specific:
# Get Username
# If your assertion offers the username for Checkmk in an attribute you can set it directly as the remote user (REMOTE_USER):
MellonUser "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
RequestHeader set X-Remote-User "%{MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name}e" env=MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
# When SAML auth fails, show the login page to the user. This should only happen, if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
# A failed login at the IDP will not return you here at all.
ErrorDocument 401 '<html> \
<head> \
<meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
</head> \
<body> \
SAML authentication failed, redirecting to login page. \
<a href="/${SITE}/check_mk/login.py">Click here</a>. \
</body> \
</html>'
</If>
# Azure-AD-specific:
# This header is also needed after authentication (outside of the If clause)
RequestHeader set X-Remote-User "%{MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name}e" env=MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
</Location>NetIQ Access Manager
Cuando NetIQ Access Manager actúa como IdP, existen algunas diferencias en el procedimiento de configuración, por ejemplo, el nombre de usuario se puede especificar directamente sin necesidad de reescribirlo.
Observa 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 en función de la distribución utilizada:
# Set this to the Name of your Checkmk site, e.g.# Define SITE mysite
# Define SITE mysite
Define SITE mysite
# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server. auth_mellon uses this to generate the needed URLs in the metadata.
ServerName https://myserver.mydomain.tld
# Load the module.
<IfModule !mod_auth_mellon.c>
LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so
</IfModule>
# Only enable this for debugging purposes
#MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.log
#MellonDiagnosticsEnable On
<Location /${SITE}>
# Use SAML auth only in case there is no Checkmk authentication
# Cookie provided by the user and whitelist also some other required URLs.
<If "! %{HTTP_COOKIE} =~ /^auth_${SITE}/ && \
! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">
MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
# NetIQ-specific: Not needed because in metadata:
#MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
MellonEndpointPath "/${SITE}/mellon"
MellonDefaultLoginPath "/${SITE}/check_mk/"
Order allow,deny
Allow from all
MellonSecureCookie On
MellonCookieSameSite None
AuthType Mellon
MellonEnable auth
require valid-user
# NetIQ-specific:
# Even though it is set as 'optional' in https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
# a NetIQ Access Manager requires it to be set.
# Specified in oasis link above - line 396
MellonOrganizationName "<countrycode>" "<your organisation name>"
# Specified in oasis link above - line 443 / 452
MellonOrganizationURL "<countrycode>" "<your organisation url>"
# Specified in oasis link above - line 454
MellonOrganizationDisplayName "<countrycode>" "<your organisation display name>"
# NetIQ-specific:
# If your assertion offers the username for Checkmk in an attribute you can set it directly as the remote user (REMOTE_USER)
MellonUser "myusername"
# NetIQ-specific:
# If the assertion does contain the username (and was set to MellonUser) then you can set the header directly.
RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
# When SAML auth fails, show the login page to the user. This should only happen,
# if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
# A failed login at the IDP will not return you here at all.
ErrorDocument 401 '<html> \
<head> \
<meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
</head> \
<body> \
SAML authentication failed, redirecting to login page. \
<a href="/${SITE}/check_mk/login.py">Click here</a>. \
</body> \
</html>'
# This header is also needed after authentication (outside of the If clause)
RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
</Location>5. Migrar usuarios existentes
Una vez que hayas habilitado SAML, puedes migrar los usuarios existentes de una conexión basada en contraseña a la conexión SAML. Para ello, check las cuentas deseadas 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.
