3 SAML

Panoramica

SAML 2.0 authentication può essere utilizzato per accedere a Zabbix.

Se l'accesso SAML è configurato senza provisioning utente JIT, l'utente deve già esistere in Zabbix; la password Zabbix dell'utente non viene utilizzata per l'autenticazione. Dopo un'autenticazione SAML riuscita, Zabbix confronta l'attributo username ricevuto da SAML con un nome utente Zabbix locale esistente.

Provisioning degli utenti

È possibile configurare il provisioning JIT (just-in-time) degli utenti per gli utenti SAML. In questo caso, non è necessario che un utente esista già in Zabbix. L'account utente può essere creato quando l'utente accede a Zabbix per la prima volta.

Oltre al provisioning JIT, è anche possibile abilitare e configurare il provisioning SCIM (System for Cross-domain Identity Management) - gestione continua degli account utente per gli utenti che sono stati creati tramite user provisioning. Il provisioning SCIM richiede un API token di Zabbix (con privilegi di Super admin) per l'autenticazione in Zabbix.

Ad esempio, se un utente viene spostato da un gruppo SAML a un altro, l'utente verrà anche spostato da un gruppo a un altro in Zabbix; se un utente viene rimosso da un gruppo SAML, l'utente verrà anche rimosso dal gruppo in Zabbix e, se non appartiene ad alcun altro gruppo, verrà aggiunto al gruppo di utenti per gli utenti deprovisioned.

Se SCIM è abilitato e configurato, un utente SAML verrà provisioned nel momento in cui l'utente accede a Zabbix e verrà aggiornato continuamente in base alle modifiche in SAML. Gli utenti SAML già esistenti non verranno provisioned e verranno aggiornati solo gli utenti provisioned. Si noti che solo i media validi verranno aggiunti a un utente quando l'utente viene provisioned o aggiornato.

Se SCIM non è abilitato, un utente SAML verrà provisioned (e successivamente aggiornato) nel momento in cui l'utente accede a Zabbix.

Configurazione del provider di identità

Per poter lavorare con Zabbix, un provider di identità SAML (onelogin.com, auth0.com, okta.com, ecc.) deve essere configurato nel seguente modo:

• Assertion Consumer URL deve essere impostato su <path_to_zabbix_ui>/index_sso.php?acs
• Single Logout URL deve essere impostato su <path_to_zabbix_ui>/index_sso.php?sls

Esempi di <path_to_zabbix_ui>: https://example.com/zabbix/ui, http://another.example.com/zabbix, http://<any_public_ip_address>/zabbix

Configurazione di Zabbix

Per utilizzare l'autenticazione SAML, Zabbix deve essere configurato nel modo seguente:

1. La chiave privata e il certificato devono essere archiviati in ui/conf/certs/, a meno che non vengano specificati percorsi personalizzati in zabbix.conf.php.

Per impostazione predefinita, Zabbix cercherà nei seguenti percorsi:

• ui/conf/certs/sp.key - file della chiave privata SP
• ui/conf/certs/sp.crt - file del certificato SP
• ui/conf/certs/idp.crt - file del certificato IDP

2. Tutte le impostazioni più importanti possono essere configurate nel frontend di Zabbix. Tuttavia, è possibile specificare impostazioni aggiuntive nel file di configurazione.

Parametri di configurazione disponibili nel frontend di Zabbix:

Vedere gli esempi di configurazione degli identity provider SAML per l'accesso e il provisioning degli utenti in Zabbix con:

• Microsoft Azure AD
• Okta
• Onelogin

Note sul provisioning SCIM

Per il provisioning SCIM, specificare il percorso del frontend di Zabbix e aggiungervi api_scim.php dal lato del provider di identità, ad esempio:

https://<path-to-zabbix-ui>/api_scim.php

Gli attributi utente utilizzati in Zabbix (username, nome utente, cognome utente e attributi dei media) devono essere aggiunti come attributi personalizzati e, se necessario, lo spazio dei nomi esterno deve essere uguale allo schema utente: urn:ietf:params:scim:schemas:core:2.0:User.

Impostazioni avanzate

Parametri SAML aggiuntivi possono essere configurati nel file di configurazione del frontend di Zabbix (zabbix.conf.php):

• $SSO['SP_KEY'] = '<percorso del file della chiave privata SP>';
• $SSO['SP_CERT'] = '<percorso del file del certificato SP>';
• $SSO['IDP_CERT'] = '<percorso del file del certificato IDP>';
• $SSO['SETTINGS']

Solo le seguenti opzioni possono essere impostate come parte di $SSO['SETTINGS']:

• strict
• baseurl
• compress
• contactPerson
• organization
• sp (solo le opzioni specificate in questo elenco)
  • attributeConsumingService
  • x509certNew
• idp (solo le opzioni specificate in questo elenco)
  • singleLogoutService (solo un'opzione)
    • responseUrl
  • certFingerprint
  • certFingerprintAlgorithm
  • x509certMulti
• security (solo le opzioni specificate in questo elenco)
  • signMetadata
  • wantNameId
  • requestedAuthnContext
  • requestedAuthnContextComparison
  • wantXMLValidation
  • relaxDestinationValidation
  • destinationStrictlyMatches
  • rejectUnsolicitedResponsesWithInResponseTo
  • signatureAlgorithm
  • digestAlgorithm
  • lowercaseUrlencoding

Tutte le altre opzioni verranno prese dal database e non potranno essere sovrascritte. L'opzione debug verrà ignorata.

Inoltre, se la UI di Zabbix si trova dietro un proxy o un load balancer, può essere utilizzata l'opzione personalizzata use_proxy_headers:

• false (predefinito) - ignora l'opzione;
• true - utilizza gli header HTTP X-Forwarded-* per costruire l'URL di base.

Se si utilizza un load balancer per connettersi all'istanza Zabbix, dove il load balancer usa TLS/SSL e Zabbix no, è necessario indicare i parametri 'baseurl', 'strict' e 'use_proxy_headers' come segue:

$SSO['SETTINGS'] = [
    'strict' => false,
    'baseurl' => 'https://zabbix.example.com/zabbix/',
    'use_proxy_headers' => true
];

Esempio di configurazione:

$SSO['SETTINGS'] = [
    'security' => [
        'signatureAlgorithm' => 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha384'
        'digestAlgorithm' => 'http://www.w3.org/2001/04/xmldsig-more#sha384',
        // ...
    ],
    // ...
];

Configurazione del frontend con Kerberos/ADFS

Il file di configurazione del frontend di Zabbix (zabbix.conf.php) può essere utilizzato per configurare l'SSO con autenticazione Kerberos e ADFS:

$SSO['SETTINGS'] = [
    'security' => [
        'requestedAuthnContext' => [
            'urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos',
        ],
        'requestedAuthnContextComparison' => 'exact'
    ]
]; 

In questo caso, nel campo SP name ID della configurazione SAML impostare:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified