Autenticazione con 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. Introduzione

In questo articolo scoprirai come impostare un login tramite il Secure Assertion Markup Language (SAML).

SAML è un metodo standardizzato per informare le applicazioni e i servizi esterni che un utente è effettivamente chi dice di essere. SAML rende possibile il single sign-on (autenticazione unica) perché può essere usato per autenticare un utente una sola volta e poi comunicare tale autenticazione a più applicazioni. Grazie alla connessione e alla comunicazione tra il cosiddetto "Service Provider" (SP) e il cosiddetto "Identity Provider" (IdP), i dipendenti possono accedere a diverse applicazioni web con un unico login. Nell'architettura SAML, il Service Provider rende disponibile l'applicazione e l'Identity Provider gestisce le identità digitali degli utenti.

SAML è supportato nelle edizioni commerciali di Checkmk e può essere configurato direttamente nell'interfaccia web di Checkmk. Checkmk assume il ruolo di Service Provider. Ad esempio, come descritto nel capitolo sulla configurazione, Entra ID è un esempio di Identity Provider.

Microsoft Entra ID (abbreviato Entra ID) è il nuovo nome di Azure Active Directory (Azure AD) dal 2023. Tuttavia, le schermate e i contenuti dei file di configurazione contenuti in questo articolo utilizzano ancora il vecchio nome Azure AD.

Fino alla versione 2.2.0 di Checkmk, in alternativa, SAML era supportato anche dal modulo Apache mod_auth_mellon, fornito come parte del software Checkmk. A partire dalla versione 2.3.0, mod_auth_mellon non è più incluso nel software Checkmk. Se vuoi utilizzare SAML come utente di Checkmk Raw, devi quindi installare tu stesso mod_auth_mellon. La configurazione basata su questo è descritta nel capitolo dedicato a Checkmk Raw. Tuttavia, non è più supportato da noi.

Il tema della crittografia del trasporto (TLS/SSL) è incluso negli esempi solo in una semplice implementazione dimostrativa. In ambienti di produzione con una propria Autorità di Certificazione (CA) e una corretta gestione dei certificati, ci saranno alcune differenze che dipenderanno dalla tua infrastruttura.

2. Usare SAML in Checkmk

Dopo aver completato tutti i punti del processo di configurazione, il login SAML può essere utilizzato dall'utente in Checkmk. Il testo del pulsante può essere personalizzato, come descritto di seguito.

Ogni utente autorizzato tramite SAML verrà creato automaticamente in Checkmk al primo accesso, a patto che non esista già un utente con lo stesso ID. Se esiste già un utente con lo stesso ID, la creazione dell'utente corrente verrà rifiutata.

I dati dell'utente verranno sincronizzati ogni volta che l'utente si logga a Checkmk.

Affinché SAML funzioni, devono essere soddisfatti diversi prerequisiti:

L'interfaccia web deve essere protetta con HTTPS. Per motivi di sicurezza, gli indirizzi HTTP non sono accettati.
Gli endpoint SAML di Checkmk per ID/metadati e risposte (Assertion Consumer Service) devono essere registrati presso l'IdP. Di seguito mostreremo come è possibile farlo.
I messaggi diretti dall'IdP a Checkmk - risposte alle richieste di autenticazione (obbligatorie solo per l'asserzione) e dichiarazioni di attributi - devono essere firmati con uno degli algoritmi supportati.

2.1. Algoritmi supportati

Checkmk accetta i seguenti algoritmi per comunicare con l'IdP:

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

Checkmk stesso utilizza RSA-SHA256 per firmare le sue richieste.

Se l'IdP non utilizza uno dei suddetti algoritmi per la sua risposta, questa verrà rifiutata da Checkmk.

3. Impostazione di SAML

Per poter utilizzare SAML nelle edizioni commerciali, è necessario prima configurare l'IdP - nel nostro esempio si tratta di Entra ID (chiamato Azure Active Directory fino al 2023). Una volta fatto questo, l'SP, cioè Checkmk, riceve le informazioni necessarie.

3.1. Log in in Entra ID

Registrazione del servizio SAML di Checkmk in Entra ID

Quindi, registra il servizio SAML di Checkmk con Entra ID. Per farlo, chiama Enterprise applications > Create your own application.

Creating your own application in Entra ID.

Assegna un nome arbitrario, preferibilmente significativo, ad es. checkmk-saml. Si consiglia di non nominare l'applicazione semplicemente checkmk per evitare confusione con l'agente Checkmk.

Seleziona l'opzione Integrate any other application you don’t find in the gallery (Non-gallery) e poi clicca sul pulsante Create.

Nella pagina panoramica di Entra ID avrai creato la seguente funzione: Single sign-on > SAML > Basic SAML Configuration:

Overview of application data in Entra ID.

A questo punto Entra ID richiederà altre due informazioni:

Identifier (Entity ID) nel formato https://myserver.com/mysite/check_mk/saml_metadata.py e
Reply URL (Assertion Consumer Service URL) nel formato https://myserver.com/mysite/check_mk/saml_acs.py?acs.

Lascia tutte le altre opzioni invariate al loro valore predefinito o vuote. In particolare, Relay State nel formato Basic SAML Configuration deve rimanere invariato, altrimenti SAML non funzionerà.

Ora chiama Edit > Signing Option > Sign SAML assertion per configurare un Entra ID per le risposte e le verifiche:

Recupero delle informazioni SAML da Entra ID

Vai quindi su Entra ID per trovare le informazioni SAML di cui hai bisogno per Checkmk.

Queste informazioni sono disponibili nella visualizzazione Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On (vedi sopra):

Nel box SAML Certificates, trova il link App Federation Metadata Url. Questo ti servirà nella prossima sezione per impostare SAML in Checkmk (Identity provider metadata).
Il box Attributes & Claims ti porta alla visualizzazione degli attributi dell'utente di Checkmk, es. indirizzo e-mail, nome e cognome:

3.2. Attivazione di SAML nell'interfaccia web di Checkmk

Con le informazioni ottenute in precedenza, imposta la connessione SAML sul lato Checkmk.

Se necessario, aggiungi il certificato TLS emesso dal tuo IdP ai certificati attendibili di Checkmk inserendolo in Setup > Global settings > Trusted certificate authorities for SSL.

Ora apri Setup > Users > SAML authentication. Usa Add connection per iniziare a configurare una nuova connessione:

Assegna un Connection ID e un Name per la nuova connessione. Il Name sarà utilizzato in seguito per dare un nome al pulsante di login di Checkmk.

Poi, nel box Security, specifica se vuoi proteggere le connessioni di accesso con Checkmk o con i tuoi certificati:

Se utilizzi i tuoi certificati, devi specificare Private key e Certificate. I certificati personalizzati sono memorizzati nella directory del sito sotto ~/etc/ssl/saml2/custom/.

Quindi, nel box Connection, come Identity provider metadata inserisci l'URL (es. App Federation Metadata URL) che hai selezionato come descritto nella sezione precedente:

In alternativa, puoi scaricare il file XML dei metadati direttamente da Entra ID e caricarlo nella finestra di dialogo precedente con l'opzione Upload XML file nell'opzione Identity provider metadata. Questo è comodo, ad esempio, se il tuo server Checkmk non ha accesso a internet. Per l'opzione obbligatoria Checkmk server URL, inserisci l'indirizzo che tu - e non Entra ID - usi normalmente per accedere a Checkmk, ad es. https://myserver.com.

Ora dovrai inserire i dati dell'utente nel box Users:

È importante notare che User ID attribute deve essere univoco, ad esempio l'ID utente. Checkmk richiede a Entra ID l'indirizzo completo claim name, cioè l'indirizzo URL che inizia con http, per ogni voce, ad esempio, nell'esempio precedente, l'ID utente è http://schemas.xmlsoap.org/ws/2005/05/identity/claims/userID.

Per definire le responsabilità di tutti gli utenti che si autenticano con SAML in Checkmk, ogni utente può essere assegnato a uno o più gruppi di contatto. Hai diverse opzioni per definire la mappatura in Contact groups.

Puoi utilizzare il sito Roles per assegnare gli utenti a ruoli diversi, in modo da definire utenti normali, amministratori, ecc.

4. SAML in Checkmk Raw

La configurazione descritta in questo capitolo è interessante solo per gli utenti di Checkmk Raw che non possono utilizzare la connessione SAML integrata nelle edizioni commerciali di Checkmk. Il prerequisito è aver installato a livello di sistema il modulo Apache mod_auth_mellon, che non viene fornito con il software Checkmk, secondo le istruzioni riportate nella pagina del progetto. La configurazione basata su di esso è descritta in questo capitolo. Tuttavia, non supportiamo più la connessione SAML tramite mod_auth_mellon.

Le sezioni seguenti descrivono solo la configurazione di mod_auth_mellon per gli IdP eventualmente già in funzione, utilizzando come esempio Active Directory Federation Services (ADFS). La connessione in Checkmk si limita all'ultimo passo delle istruzioni per ADFS. Sul server Checkmk, mod_auth_mellon agisce come provider di servizi per le autenticazioni.

4.1. Log-in con Active Directory Federation Services

Prerequisiti

Accedere a Checkmk utilizzando Active Directory è relativamente semplice: Active Directory Federation Services (ADFS) funge da Identity Provider (IdP), Checkmk fornisce l'autenticazione SAML.

I prerequisiti per questo tutorial sono quindi:

Funzionamento dell'integrazione LDAP-AD
ADFS funzionante come IdP
Server Checkmk con SSL
Un sistema operativo supportato.

La configurazione si svolge in tre fasi:

Configurazione di Apache (un risultato: file XML con metadati).
Configurazione di ADFS: impostazione di un trust relying party con metadati Mellon.
Abilitazione del login in Checkmk stesso.

Configurazione di Apache

Ovviamente si tratta di configurare il server Apache del sito, quindi per prima cosa effettua il log in:

root@linux# omd su mysite

Ora crea una directory per mod_auth_mellon e passa ad essa:

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

Esegui ora mellon_create_metadata specificando il tuo server e il tuo sito con il suffisso mellon:

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

Questo modulo genera tre file: Certificato (.cert), chiave (.key) e metadati statici (.xml). Il file .xml non è necessario e può essere eliminato:

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

Rinomina i file chiave e certificato per semplicità:

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

Ora ottieni i metadati necessari direttamente dal tuo server ADFS (qui myadfs) e salvalo come idp-metadata.xml:

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

Ora hai bisogno del certificato pubblico del server ADFS, che è memorizzato nel file 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

Nel caso in cui ti stessi chiedendo di echo -n: Questo viene utilizzato per terminare la sessione SSL successiva.

Il certificato deve essere caricato nell'archivio di fiducia se, ad esempio, il servizio IdP controlla la catena di certificati. Per maggiori informazioni su questo tema, consulta l'articolo HTTPS.

Come ultimo passo, sostituisci il file di configurazione dell'autenticazione ~/etc/apache/conf.d/auth.conf con la variante seguente, specificando ovviamente il tuo server Checkmk (qui myserver) e il tuo sito (qui mysite). Nota nella seguente configurazione di esempio che il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

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

# 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>

Quindi riavvia Apache:

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

Infine, scarica i metadati Mellon creati dinamicamente in un file XML in modo da poterli importare subito in AD Management:

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

Configurazione di Active Directory

Per creare un trust di parti fidate in ADFS, procedi come segue:

Avvia l'interfaccia ADFS:

Clicca su Add Relying Party Trust:

Lascia l'opzione impostata su Claims aware e continua con il pulsante Avvia:

Ora seleziona Import data on the relying party from a file e specifica il file XML che hai appena scaricato:

Puoi tranquillamente ignorare l'avviso AD FS Management:

Sotto Specify Display Name inserisci ora Checkmk come nome:

Quando assegni i permessi, a scopo di test, per Choose Access Control Policy puoi prima selezionare il valore Permit everyone; in seguito dovrai modificarlo in Permit specific group.

Conferma il riepilogo alla voce Ready to Add Trust:

Infine, conferma la finestra di dialogo Finish e mantieni il segno di spunta su Configure claims issuance policy for this application:

Seleziona il trust di relying party che hai appena creato e avvia l'editor con Edit Claim Issuance Policy… :

Aggiungi una nuova regola nella finestra di dialogo Add Rule…:

Nel primo passo Select Rule Template seleziona Transform to Incoming Claim e conferma:

Nel secondo passo Configure Rule imposta i seguenti valori:

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

FS può ora derivare l'autenticazione per Checkmk dall'autenticazione di Windows, che istruirai per autenticare gli utenti tramite le richieste HTTP nel passaggio successivo.

Configurazione di Checkmk

In Checkmk, alla voce Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, in Current settings ora devi solo attivare l'opzione Activate HTTP header authentication.

4.2. Informazioni aggiuntive per altri sistemi

Entra ID con mod_auth_mellon

Quando Entra ID (chiamato Azure Active Directory fino al 2023) agisce come IdP, ci sono alcune differenze nella procedura di configurazione, ad esempio il nome dell'utente può essere specificato direttamente senza dover essere riscritto.

Prerequisiti per la seguente configurazione di esempio:

Impostare UserPrincipalName nella connessione LDAP come identificatore (maggiori informazioni nella documentazione Microsoft).
App Enterprise personalizzata in Entra ID con UserPrincipalName come attributo "name" (per maggiori informazioni consulta la documentazione Microsoft).

Nella seguente configurazione di esempio, il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

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

#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

Quando NetIQ Access Manager agisce come IdP, ci sono alcune differenze nella procedura di configurazione: ad esempio, il nome dell'utente può essere specificato direttamente senza dover essere riscritto.

Nell'esempio di configurazione che segue, il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

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


# 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. Migrare gli utenti esistenti

Una volta abilitato SAML, puoi migrare gli utenti esistenti da una connessione basata su password a una connessione SAML. Per farlo, seleziona gli account desiderati nella gestione utenti alla voce Setup > Users > Users. Poi avvia la migrazione tramite Migrate selected users.

In una fase intermedia, puoi far cancellare tutti gli attributi.

Dialog with user attributes that can be deleted.

In questa pagina

1. Introduzione
2. Usare SAML in Checkmk
- 2.1. Algoritmi supportati
3. Impostazione di SAML
- 3.1. Log in in Entra ID
  - Registrazione del servizio SAML di Checkmk in Entra ID
  - Recupero delle informazioni SAML da Entra ID
- 3.2. Attivare SAML nell'interfaccia web di Checkmk
4. SAML in Checkmk Raw
- 4.1. Log in con Active Directory Federation Services
- 4.2. Informazioni aggiuntive per altri sistemi
  - Entra ID con mod_auth_mellon
  - NetIQ Access Manager
5. Migrare gli utenti esistenti