Authentification via SAML

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. Introduction

Dans cet article, vous apprendrez comment configurer un login via le langage SAML (Secure Assertion Markup Language) dans Checkmk.

Le SAML est une méthode standardisée permettant d’informer les applications et services externes qu’un utilisateur est bien celui qu’il prétend être. Le SAML rend possible l’authentification unique (SSO) car il permet d’authentifier un utilisateur une seule fois, puis de transmettre cette authentification à plusieurs applications. Grâce à la connexion et à la communication entre ce que l'on appelle le « fournisseur de services » (SP) et ce que l'on appelle le « fournisseur d'identité » (IdP), les employés peuvent ainsi accéder à diverses applications web avec un seul login. Dans l'architecture SAML, le fournisseur de services met l'application à disposition et le fournisseur d'identité gère les identités numériques des utilisateurs.

SAML est pris en charge dans les éditions commerciales de Checkmk et peut être configuré directement dans l’interface web de Checkmk. Checkmk assume le rôle de fournisseur de services. Par exemple, comme décrit dans le chapitre consacré à la configuration, Entra ID est un exemple de fournisseur d’identité.

Microsoft Entra ID (en abrégé : Entra ID) est le nouveau nom d'Azure Active Directory (Azure AD) depuis 2023. Toutefois, les captures d'écran et le contenu des fichiers de configuration figurant dans cet article utilisent toujours l'ancien nom Azure AD.

Jusqu’à la version 2.2.0 de Checkmk, SAML était également pris en charge par le module Apache mod_auth_mellon, fourni avec le logiciel Checkmk. À partir de la version 2.3.0, mod_auth_mellon n’est plus inclus dans le logiciel Checkmk. Si vous souhaitez utiliser SAML en tant qu’utilisateur de Checkmk Community CRE , vous devez donc installer mod_auth_mellon vous-même. La configuration correspondante est décrite dans le chapitre consacré à Checkmk Community. Toutefois, elle n’est plus prise en charge par nos soins.

L'ensemble du thème du chiffrement de transport (TLS/SSL) n'est abordé dans les exemples que sous la forme d'une implémentation simple à des fins de démonstration. Dans les environnements de production disposant de votre propre autorité de certification (CA) et d'une gestion appropriée des certificats, il existera certaines différences qui dépendront de votre propre infrastructure.

2. Utilisation de SAML dans Checkmk

Une fois que vous avez suivi toutes les étapes du processus de configuration, l'utilisateur peut utiliser le login SAML dans Checkmk. Le texte du bouton peut être personnalisé, comme décrit ci-dessous.

Tout utilisateur autorisé par SAML sera automatiquement créé dans Checkmk lors de sa première connexion, à condition qu’il n’existe pas déjà un utilisateur portant le même identifiant. Si un utilisateur portant le même identifiant existe déjà, la création de l’utilisateur actuel sera refusée.

Les données de l'utilisateur seront synchronisées à chaque fois que celui-ci se connectera à Checkmk.

Plusieurs conditions préalables doivent être remplies pour que SAML fonctionne :

L'interface web doit être sécurisée par HTTPS. Pour des raisons de sécurité, les adresses HTTP ne sont pas acceptées.
Les ressources SAML de Checkmk pour l’ID/les métadonnées et les réponses (Assertion Consumer Service) doivent avoir été enregistrées auprès de l’IdP. Nous vous montrons ci-dessous comment procéder.
Les messages envoyés par l’IdP à Checkmk — réponses aux demandes d’authentification (obligatoires uniquement pour l’assertion) et déclarations d’attributs — doivent être signés à l’aide de l’un des algorithmes pris en charge.

2.1. Algorithmes pris en charge

Checkmk accepte les algorithmes suivants pour la communication avec l’IdP :

RSA-SHA256
RSA-SHA384
RSA-SHA512
ECDSA-SHA256
ECDSA-SHA384
ECDSA-SHA512

Checkmk utilise lui-même RSA-SHA256 pour signer ses requêtes.

Si le fournisseur d'identité (IdP) n'utilise aucun des algorithmes ci-dessus pour sa réponse, celle-ci sera rejetée par Checkmk.

3. Configuration de SAML

Pour pouvoir utiliser SAML dans les éditions commerciales, l’IdP doit d’abord être configuré. Dans notre exemple, il s’agit d’Entra ID (appelé Azure Active Directory jusqu’en 2023). Une fois cette étape effectuée, le SP, c’est-à-dire Checkmk, reçoit alors les informations requises.

3.1. Connexion à Entra ID

Enregistrement du service SAML Checkmk dans Entra ID

Ensuite, enregistrez le service SAML de Checkmk auprès d'Entra ID. Pour ce faire, rendez-vous sur Enterprise applications > Create your own application.

Creating your own application in Entra ID.

Attribuez un nom arbitraire, de préférence significatif, par exemple « checkmk-saml ». Nous vous recommandons de ne pas nommer l'application simplement « checkmk » afin d'éviter toute confusion avec l'agent Checkmk.

Sélectionnez l'option « Integrate any other application you don’t find in the gallery (Non-gallery) », puis cliquez sur le bouton « Create ».

Sur la page d'aperçu d'Entra ID, vous aurez créé la fonction suivante : Single sign-on > SAML > Basic SAML Configuration :

Overview of application data in Entra ID.

À ce stade, Entra ID vous demandera deux informations supplémentaires :

l'Identifier (Entity ID) au format https://myserver.com/mysite/check_mk/saml_metadata.py, et
l'Reply URL (Assertion Consumer Service URL) au format https://myserver.com/mysite/check_mk/saml_acs.py?acs.

Laissez toutes les autres options inchangées à leur valeur par défaut ou vides. En particulier, l'Relay State dans l'Basic SAML Configuration doit rester inchangée, sinon SAML ne fonctionnera pas.

Appelez maintenant Edit > Signing Option > Sign SAML assertion pour configurer un identifiant Entra ID pour les réponses et les vérifications :

Récupération des informations SAML depuis Entra ID

Ensuite, rendez-vous sur Entra ID pour trouver les informations SAML dont vous avez besoin pour Checkmk.

Celles-ci sont disponibles dans la vue de la table « Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On » (voir ci-dessus) :

Dans la case de dialogue « SAML Certificates », recherchez l'App Federation Metadata URL. Vous en aurez besoin dans la section suivante pour configurer SAML dans Checkmk (Identity provider metadata).
La case « Attributes & Claims » vous permet d'accéder à une vue des attributs utilisateurs pour Checkmk, par exemple l'adresse électronique, le prénom et le nom :

3.2. Activation de SAML dans l'interface web de Checkmk

À l'aide des informations obtenues précédemment, configurez la connexion SAML côté Checkmk.

Si nécessaire, ajoutez le certificat TLS émis par votre IdP aux certificats de confiance dans Checkmk en le saisissant dans Setup > Global settings > Trusted certificate authorities for SSL.

Ouvrez maintenant Setup > Users > SAML authentication. Utilisez l'option « Add connection » pour commencer à configurer une nouvelle connexion :

Attribuez un nom de login (Connection ID) et un nom d'utilisateur (Name) à la nouvelle connexion. Le nom de login (Name) sera utilisé par la suite pour nommer le bouton de login Checkmk.

Ensuite, dans la case « Security », indiquez si vous souhaitez sécuriser les connexions d'accès avec Checkmk ou avec vos propres certificats :

Si vous utilisez vos propres certificats, vous devez indiquer l'Private key et l'Certificate. Les certificats personnalisés sont stockés dans le répertoire d'instances sous ~/etc/ssl/saml2/custom/.

Ensuite, dans la case « Connection », saisissez comme « Identity provider metadata » l'URL (par exemple, l'URL des métadonnées de la fédération d'applications) que vous avez sélectionnée comme décrit dans la section précédente :

Vous pouvez également télécharger le fichier XML de métadonnées directement depuis Entra ID et le charger dans le dialogue ci-dessus en utilisant l’option « Upload XML file » dans le champ « Identity provider metadata ». Cette méthode est pratique, par exemple, si votre serveur Checkmk n’a pas accès à l’internet. Pour le champ obligatoire « Checkmk server URL », saisissez l’adresse que vous — et non Entra ID — utilisez normalement pour accéder à Checkmk, par exemple https://myserver.com.

Vous devez maintenant saisir les informations d'utilisateur dans la case « Users » :

Vous devez également obtenir ces informations comme décrit dans la section précédente. Il est important de noter que l’User ID attribute doit être unique, par exemple l’identifiant utilisateur. Checkmk exige ici l’claim namee complète provenant d’Entra ID, c’est-à-dire l’adresse URL commençant par http, pour chaque entrée, par exemple, dans l’exemple ci-dessus, l’identifiant utilisateur est http://schemas.xmlsoap.org/ws/2005/05/identity/claims/userID.

Afin de définir les responsabilités de tous les utilisateurs qui s’authentifient via SAML dans Checkmk, chaque utilisateur peut être affecté à un ou plusieurs groupes de contact. Vous disposez de différentes options pour définir l’affectation dans l’Contact groups.

Vous pouvez utiliser l'Roles pour affecter des utilisateurs à différents rôles afin de définir des utilisateurs normaux, des administrateurs, etc.

4. SAML dans Checkmk Community

La configuration décrite dans ce chapitre ne concerne que les utilisateurs de Checkmk Community qui ne peuvent pas utiliser la connexion SAML intégrée aux éditions commerciales de Checkmk. La condition préalable est que vous ayez installé le module Apache mod_auth_mellon, qui n’est pas fourni avec le logiciel Checkmk, à l’échelle du système conformément aux instructions figurant sur la page du projet. La configuration basée sur ce module est décrite dans ce chapitre. Toutefois, nous ne prenons plus en charge la connexion SAML via mod_auth_mellon.

Les sections suivantes décrivent uniquement la configuration de mod_auth_mellon pour tout IdP déjà en service, en prenant pour exemple Active Directory Federation Services (ADFS). La connexion dans Checkmk lui-même se limite à la dernière étape des instructions ADFS. Sur le serveur Checkmk, mod_auth_mellon fait office de fournisseur de services pour les authentifications.

4.1. Connexion avec Active Directory Federation Services

Prérequis

La connexion à Checkmk via Active Directory est en principe relativement simple : Active Directory Federation Services (ADFS) sert de fournisseur d'identité (IdP), Checkmk assure l'authentification SAML.

Les prérequis pour ce tutoriel sont donc les suivants :

Une intégration LDAP-AD opérationnelle
Un ADFS opérationnel en tant qu’IdP
Serveur Checkmk avec SSL
Un système d'exploitation pris en charge.

La configuration s'effectue en trois étapes :

Configuration d'Apache (résultat : fichier XML contenant des métadonnées).
Configuration d'ADFS : mise en place d'une relation de confiance avec les métadonnées Mellon.
Activation du login dans Checkmk même.

Configuration d'Apache

Il s'agit bien sûr de configurer le serveur Apache de l'instance elle-même ; connectez-vous donc d'abord à celui-ci :

root@linux# omd su mysite

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Créez maintenant un répertoire pour mod_auth_mellon et accédez-y :

OMD[mysite]:~$ mkdir etc/apache/mellon
OMD[mysite]:~$ cd etc/apache/mellon

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Exécutez maintenant mellon_create_metadata en précisant votre serveur ainsi que votre instance avec le suffixe mellon :

OMD[mysite]:~/etc/apache/mellon$ mellon_create_metadata https://myserver "https://myserver/mysite/mellon"

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Ce module génère trois fichiers : le certificat (.cert), la clé (.key) et les métadonnées statiques (.xml). Le fichier .xml n'est pas obligatoire et peut être supprimé :

OMD[mysite]:~/etc/apache/mellon$ rm *.xml

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Renommez les fichiers de clé et de certificat pour plus de simplicité :

OMD[mysite]:~/etc/apache/mellon$ mv .key mellon.key
OMD[mysite]:~/etc/apache/mellon$ mv .cert mellon.cert

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Récupérez maintenant les métadonnées requises directement depuis votre serveur ADFS (ici myadfs) et enregistrez-les sous le nom idp-metadata.xml :

OMD[mysite]:~/etc/apache/mellon$ wget --no-check-certificate -O ./idp-metadata.xml https://myadfs/FederationMetadata/2007-06/FederationMetadata.xml

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Vous avez maintenant besoin du certificat public du serveur ADFS, qui est stocké dans le fichier 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.pem

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Au cas où vous vous poseriez des questions sur le fichier « echo -n » : Ce fichier sert à mettre fin à la session SSL suivante.

Le certificat devrait, voire doit, être téléchargé dans le magasin de confiance si, par exemple, le service IdP checke la chaîne de certificats. Pour plus d’informations sur ce thème, consultez l’article sur le HTTPS.

Pour finir, remplacez le fichier de configuration d’authentification ~/etc/apache/conf.d/auth.conf par la variante suivante — en précisant bien sûr votre serveur Checkmk (ici myserver) et votre site (ici mysite). Notez dans l’exemple de configuration suivant que le chemin d’accès au répertoire d’installation dans la ligne commençant par LoadModule peut varier en fonction de la distribution utilisée :

~/etc/apache/conf.d/auth.conf

# Set this to the Name of your {CMK} 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 {CMK} 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 "{CMK} SAML Login"
		MellonEnable auth
		Require valid-user

		# Get Username
		# ADFS sends username as DOMAIN\username pair.
		# {CMK} 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>

Copier le contenu du fichier dans le presse-papiers

Le contenu du fichier a été copié avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Redémarrez ensuite Apache :

OMD[mysite]:~/etc/apache/mellon$ omd restart apache

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Enfin, vous téléchargez maintenant les métadonnées Mellon créées dynamiquement sous forme de fichier XML afin de pouvoir les importer immédiatement dans la gestion d’AD :

OMD[mysite]:~/etc/apache/mellon$ wget https://myserver/mysite/mellon/metadata -o metadata.xml

Copier les instructions dans le presse-papiers

Instruction(s) copiée(s) avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

Configuration d'Active Directory

Pour créer une relation de confiance entre parties dans ADFS, procédez comme suit :

Lancez l'interface ADFS :

Cliquez sur « Add Relying Party Trust » :

Laissez l'option réglée sur «Claims aware» et cliquez sur le bouton «Start» :

Sélectionnez maintenant « Import data on the relying party from a file » et indiquez le fichier XML que vous venez de télécharger :

Vous pouvez ignorer l'avertissement « AD FS Management » sans risque :

Sous « Specify Display Name », saisissez maintenant « Checkmk » comme nom :

Lors de l'attribution des autorisations, à des fins de test, vous pouvez d'abord sélectionner la valeur Permit everyone pour l'Choose Access Control Policy ; vous devrez ensuite la remplacer par Permit specific group.

Vérifiez le récapitulatif sous « Ready to Add Trust » :

Enfin, confirmez le dialogue « Finish » et cocher la case sur « Configure claims issuance policy for this application » :

Sélectionnez la confiance de partie de confiance que vous venez de créer, puis lancez l'éditeur via Edit Claim Issuance Policy… :

Ajoutez une nouvelle règle dans le dialogue suivant via « Add Rule… » :

À la première étape, sélectionnez « Transform to Incoming Claim » et confirmez :

À la deuxième étape, sous « Configure Rule », définissez les valeurs suivantes :

Incoming claim type: Windows account name
Outgoing claim type: Name ID
Outgoing name ID format: Transient Identifier

Cette étape achève également la configuration d'ADFS. FS peut désormais dériver l'authentification pour Checkmk à partir de l'authentification Windows, que vous configurez pour authentifier les utilisateurs via des requêtes HTTP à l'étape suivante.

Configuration de Checkmk

Dans Checkmk, sous Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, au niveau de l'Current settings, il vous suffit désormais d'activer l'option Activate HTTP header authentication.

4.2. Informations supplémentaires pour d'autres systèmes

Entra ID avec mod_auth_mellon

Lorsque Entra ID (appelé Azure Active Directory jusqu'en 2023) fait office de fournisseur d'identité (IdP), la procédure de configuration présente certaines différences ; par exemple, le nom d'utilisateur peut être spécifié directement sans avoir besoin d'être réécrit.

Conditions préalables pour l'exemple de configuration suivant :

Définissez UserPrincipalName dans la connexion LDAP comme identifiant (pour plus d'informations, consultez la documentation Microsoft).
Application d'entreprise personnalisée dans Entra ID avec UserPrincipalName comme attribut « name » (pour plus d'informations, consultez la documentation Microsoft).

Veuillez noter dans l'exemple de configuration suivant que le chemin d'accès au répertoire d'installation dans la ligne commençant par LoadModule peut varier en fonction de la distribution utilisée :

~/etc/apache/conf.d/auth.conf

#Set this to the Name of your {CMK} 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 {CMK} 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 {CMK} 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>

Copier le contenu du fichier dans le presse-papiers

Contenu du fichier copié avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

NetIQ Access Manager pour la gestion des accès

Lorsque NetIQ Access Manager fait office de fournisseur d'identité (IdP), la procédure de configuration présente certaines différences ; par exemple, le nom d'utilisateur peut être spécifié directement sans avoir besoin d'être réécrit.

~/etc/apache/conf.d/auth.conf


# Set this to the Name of your {CMK} 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 {CMK} 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 {CMK} 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>

Copier le contenu du fichier dans le presse-papiers

Le contenu du fichier a été copié avec succès dans le presse-papiers !

L'accès en écriture au presse-papiers a été refusé !

5. Migrer les utilisateurs existants

Une fois que vous avez activé SAML, vous pouvez migrer les utilisateurs existants d'une connexion par mot de passe vers la connexion SAML. Pour ce faire, checkez les comptes souhaités dans la gestion des utilisateurs sous « Setup > Users > Users ». Lancez ensuite la migration via « Migrate selected users ».

Au cours d'une étape intermédiaire, vous pouvez faire supprimer certains attributs.

Dialog with user attributes that can be deleted.

Last modified: Mon, 08 Dec 2025 12:40:19 GMT via commit 40b37331d

Sur cette page

1. Introduction
2. Utilisation de SAML dans Checkmk
- 2.1. Algorithmes pris en charge
3. Configuration de SAML
- 3.1. Connexion à Entra ID
  - Enregistrement du service SAML de Checkmk dans Entra ID
  - Récupération des informations SAML depuis Entra ID
- 3.2. Activation de SAML dans l'interface web de Checkmk
4. SAML dans Checkmk Community
- 4.1. Connexion avec Active Directory Federation Services
- 4.2. Informations supplémentaires pour d'autres systèmes
  - Entra ID avec mod_auth_mellon
  - NetIQ Access Manager
5. Migrer les utilisateurs existants

Authentification avec SAML

1. Introduction

2. Utilisation de SAML dans Checkmk

2.1. Algorithmes pris en charge

3. Configuration de SAML

3.1. Connexion à Entra ID

Enregistrement du service SAML Checkmk dans Entra ID

Récupération des informations SAML depuis Entra ID

3.2. Activation de SAML dans l'interface web de Checkmk

4. SAML dans Checkmk Community

4.1. Connexion avec Active Directory Federation Services

Prérequis

Configuration d'Apache

Configuration d'Active Directory

Configuration de Checkmk

4.2. Informations supplémentaires pour d'autres systèmes

Entra ID avec mod_auth_mellon

NetIQ Access Manager pour la gestion des accès

5. Migrer les utilisateurs existants