vCenter Single Sign-On consente ai componenti di vSphere di comunicare tra loro tramite un meccanismo di token sicuro.

vCenter Single Sign-On utilizza i seguenti servizi.
  • Autenticazione degli utenti tramite federazione del provider di identità esterno o provider di identità integrato di vCenter Server. Il provider di identità integrato supporta account locali, Active Directory o OpenLDAP, Autenticazione integrata di Windows (IWA) e ulteriori meccanismi di autenticazione (come smart card e RSA SecurID).
  • Autenticazione degli utenti della soluzione tramite certificati.
  • Security Token Service (STS).
  • SSL per il traffico sicuro.

Provider di identità integrato di vCenter Server

vCenter Server include un provider di identità integrato. Per impostazione predefinita, vCenter Server utilizza il dominio vsphere.local come origine identità (ma è possibile cambiare dominio durante l'installazione). È possibile configurare il provider di identità integrato in vCenter Server in modo che utilizzi Active Directory (AD) come origine identità mediante LDAP/S, OpenLDAP/S o Autenticazione integrata Windows (IWA). Tali configurazioni consentono ai clienti di accedere a vCenter Server utilizzando i loro account AD.

vCenter Server e un provider di identità esterno

In vSphere 7.0 e versioni successive, è possibile configurare vCenter Server per un provider di identità esterno tramite l'autenticazione federata. In questa configurazione, si sostituisce vCenter Server come provider di identità.

vSphere supporta i provider di identità seguenti.

  • vSphere 7.0 e versioni successive: Active Directory Federation Services (AD FS)
  • vSphere 8.0 Update 1 e versioni successive: Okta
  • vSphere 8.0 Update 2 e versioni successive: Microsoft Entra ID (in precedenza denominato Azure AD)
  • A partire da vSphere 8.0 Update 3: PingFederate

Quando si configura vSphere per l'utilizzo di un provider di identità esterno, il provider di identità esterno interagisce con le origini identità per conto di vCenter Server.

Accesso dell'utente con l'autenticazione federata del provider di identità di vCenter Server

Quando si utilizza un provider di identità esterno per eseguire l'autenticazione con vCenter Server, vCenter Server reindirizza la richiesta di accesso al provider di identità esterno. Il provider di identità esterno esegue l'autenticazione dell'utente con il proprio servizio directory, quindi emette un token per vCenter Server che viene utilizzato per l'accesso dell'utente.

Ad esempio, la figura seguente illustra in dettaglio il flusso di accesso dell'utente per la federazione del provider di identità di vCenter Server tramite AD FS.

Figura 1. Accesso dell'utente di vCenter Server tramite la federazione del provider di identità AD FS

Questa figura illustra il flusso del processo di accesso dell'utente a vCenter Server tramite la federazione del provider di identità AD FS.

vCenter Server, AD FS e Active Directory interagiscono come indicato di seguito:

  1. L'utente inizia dalla pagina di arrivo di vCenter Server inserendo un nome utente.
  2. Se il nome utente è associato a un dominio federato, vCenter Server reindirizza la richiesta di autenticazione ad AD FS.
  3. Se necessario, AD FS chiede all'utente di accedere con le credenziali di Active Directory.
  4. AD FS esegue l'autenticazione dell'utente con Active Directory.
  5. AD FS genera un token di sicurezza con le informazioni sul gruppo provenienti da Active Directory.
  6. vCenter Server utilizza il token per consentire all'utente di accedere.
A questo punto, l'utente è stato autenticato e può visualizzare e modificare tutti gli oggetti previsti dai privilegi di cui il suo ruolo dispone.
Nota: Inizialmente, a ogni utente viene assegnato il ruolo Nessun accesso. Affinché un utente possa accedere, un amministratore di vCenter Server deve assegnargli almeno il ruolo Sola lettura. Vedere la documentazione di Sicurezza di vSphere.

Se il provider di identità esterno non è raggiungibile, il processo di accesso riporta l'utente alla pagina di destinazione di vCenter Server, dove viene visualizzato un messaggio informativo. Gli utenti possono comunque accedere utilizzando i loro account locali nell'origine identità vsphere.local.

L'interazione tra vCenter Server e Okta, Microsoft Entra ID o PingFederate è simile a quella di AD FS, ad eccezione del fatto che vCenter Server utilizza VMware Identity Services. Vedere Processo di autenticazione di VMware Identity Services.

Accesso dell'utente tramite il provider di identità integrato in vCenter Server

Nella figura seguente viene mostrato il flusso di accesso dell'utente quando vCenter Server funge da provider di identità.

Figura 2. Accesso dell'utente tramite il provider di identità integrato in vCenter Server
Quando l'utente accede a vSphere Client, il server Single Sign-On stabilisce l'handshake di autenticazione.
  1. Un utente esegue l'accesso a vSphere Client con nome utente e password per accedere al sistema vCenter Server oppure a un altro servizio vCenter.
  2. vSphere Client passa le informazioni di accesso al servizio vCenter Single Sign-On, che controlla il token SAML di vSphere Client. Se vSphere Client ha un token valido, vCenter Single Sign-On controlla se l'utente si trova nell'origine identità configurata (ad esempio Active Directory).
    • Se viene utilizzato solo il nome utente, vCenter Single Sign-On esegue il controllo nel dominio predefinito.
    • Se nel nome utente è incluso un nome dominio (DOMAIN\user1 o user1@DOMAIN), vCenter Single Sign-On controlla tale dominio.
  3. Se l'utente può eseguire l'autenticazione nell'origine identità, vCenter Single Sign-On restituisce un token che rappresenta l'utente per vSphere Client.
  4. vSphere Client passa il token al sistema vCenter Server.
  5. vCenter Server controlla con il server vCenter Single Sign-On che il token sia valido e non sia scaduto.
  6. Il server vCenter Single Sign-On restituisce il token al sistema vCenter Server, utilizzando il framework di autorizzazione di vCenter Server per consentire l'accesso dell'utente.
A questo punto, l'utente è stato autenticato e può visualizzare e modificare tutti gli oggetti previsti dai privilegi di cui il suo ruolo dispone.
Nota: Inizialmente, a ogni utente viene assegnato il ruolo Nessun accesso. Affinché un utente possa accedere, un amministratore di vCenter Server deve assegnargli almeno il ruolo Sola lettura. Vedere la documentazione di Sicurezza di vSphere.

Accesso per gli utenti della soluzione

Gli utenti della soluzione sono un set di servizi utilizzati nell'infrastruttura di vCenter Server, ad esempio le estensioni di vCenter Server. In vCenter Single Sign-On potrebbero essere autenticate anche le estensioni di VMware e le estensioni di terze parti.

Nota: vCenter Server utilizza i certificati degli utenti della soluzione solo per le comunicazioni interne. I certificati degli utenti della soluzione non vengono utilizzati per le comunicazioni esterne.

La figura seguente mostra il flusso di accesso per gli utenti della soluzione.

Figura 3. Accesso per gli utenti della soluzione
L'handshake tra un utente della soluzione, vCenter Single Sign-On e altri componenti vCenter segue i passaggi indicati nel testo seguente.
  1. L'utente della soluzione tenta di connettersi a un servizio vCenter Server.
  2. L'utente della soluzione viene reindirizzato a vCenter Single Sign-On. Se l'utente della soluzione è nuovo per vCenter Single Sign-On, deve presentare un certificato valido.
  3. Se il certificato è valido, vCenter Single Sign-On assegna un token SAML (token di connessione) all'utente della soluzione. Il token viene firmato da vCenter Single Sign-On.
  4. L'utente della soluzione viene quindi reindirizzato a vCenter Single Sign-On e può eseguire attività in base alle proprie autorizzazioni.

    La volta successiva in cui l'utente della soluzione deve eseguire l'autenticazione, può utilizzare il token SAML per accedere a vCenter Server.

Per impostazione predefinita, questo handshake è automatico perché VMCA fornisce agli utenti della soluzione i certificati durante l'avvio. Se i criteri dell'azienda richiedono certificati firmati da un'autorità di certificazione di terze parti, è possibile sostituire i certificati degli utenti della soluzione con certificati firmati da un'autorità di certificazione di terze parti. Se tali certificati sono validi, vCenter Single Sign-On assegna un token SAML all'utente della soluzione. Vedere Sostituzione dei certificati utente soluzione con certificati personalizzati tramite Certificate Manager.

Crittografia supportata in vSphere

La crittografia AES, ovvero il livello di crittografia più elevato, è supportata. La crittografia supportata influisce sulla sicurezza quando vCenter Single Sign-On utilizza Active Directory come origine identità.

Influisce anche sulla sicurezza ogni volta che un host ESXi o vCenter Server viene associato ad Active Directory.