Single Sign-On

Puoi configurare il tuo account Cloud Identity o Google Workspace per utilizzare il servizio Single Sign-On (SSO). Quando attivi il SSO, agli utenti non viene chiesto di inserire una password quando tentano di accedere ai servizi Google. Vengono invece reindirizzati a un provider di identità (IdP) esterno per l'autenticazione.

L'utilizzo del Single Sign-On può offrire diversi vantaggi:

• Offri un'esperienza migliore agli utenti perché possono utilizzare le proprie credenziali esistenti per l'autenticazione e non devono inserirle così spesso.
• Ti assicuri che il tuo IdP esistente rimanga il sistema di riferimento per l'autenticazione degli utenti.
• Non devi sincronizzare le password con Cloud Identity o Google Workspace.

Per utilizzare SSO, un utente deve disporre di un account utente in Cloud Identity o Google Workspace e di un'identità corrispondente nell'IdP esterno. Pertanto, il servizio SSO viene comunemente utilizzato in combinazione con una fonte autorevole esterna che esegue automaticamente il provisioning degli utenti in Cloud Identity o Google Workspace.

Procedura Single Sign-On

Cloud Identity e Google Workspace supportano SAML (Security Assertion Markup Language) 2.0 per il Single Sign-On. SAML è uno standard aperto per lo scambio di dati di autenticazione e autorizzazione tra un IdP SAML e i fornitori di servizi SAML. Quando utilizzi il servizio SSO per Cloud Identity o Google Workspace, il tuo IdP esterno è l'IdP SAML e Google è il service provider SAML.

Google implementa il binding HTTP POST SAML 2.0. Questo binding specifica la modalità di scambio delle informazioni di autenticazione tra il provider di identità SAML e il fornitore di servizi SAML. Il seguente diagramma illustra un esempio di come funziona questo processo quando utilizzi l'SSO per accedere alla console Google Cloud .

1. Il browser punta alla console Google Cloud (o a qualsiasi altra risorsa Google che richiede l'autenticazione).
2. Poiché non hai ancora eseguito l'autenticazione, la console Google Cloud reindirizza il browser ad Accedi con Google.
3. L'accesso con Google restituisce una pagina di accesso che ti chiede di inserire il tuo indirizzo email.
4. Inserisci il tuo indirizzo email e invia il modulo.
5. L'accesso con Google cerca l'account Cloud Identity o Google Workspace associato al tuo indirizzo email.

6. Poiché l'account Cloud Identity o Google Workspace associato ha abilitato Single Sign-On, Google Sign-In reindirizza il browser all'URL dell'IdP esterno configurato. Prima di eseguire il reindirizzamento, aggiunge due parametri all'URL: RelayState e SAMLRequest.

   • RelayState contiene un identificatore che l'IdP esterno dovrebbe restituire in un secondo momento.

   • SAMLRequest contiene la richiesta di autenticazione SAML, un documento XML che è stato compresso, codificato in Base64 e codificato in URL. In forma decodificata, la richiesta di autenticazione SAML è simile alla seguente:

     <samlp:AuthnRequest
             ProviderName="google.com"
             IsPassive="false"
             AssertionConsumerServiceURL="https://www.google.com/a/example.com/acs"
             ...>
       <saml:Issuer xmlns:saml="...">google.com</saml:Issuer>
       <samlp:NameIDPolicy
             AllowCreate="true"
             Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
     </samlp:AuthnRequest>
     

   Questa richiesta di esempio indica all'IdP esterno di autenticare l'utente, creare un'asserzione SAML per il pubblico google.com e pubblicarla nel servizio Assertion Consumer Service (ACS) all'indirizzo https://www.google.com/a/example.com/acs.

   Il dominio incorporato nell'URL ACS (example.com) corrisponde al dominio principale del tuo account Google Workspace o Cloud Identity.

   Se utilizzi la funzionalità di emittente specifica per il dominio quando configuri il servizio SSO, l'emittente è google.com/a/DOMAIN anziché google.com, dove DOMAIN è il dominio principale del tuo account Cloud Identity o Google Workspace.

   I passaggi eseguiti dall'IdP esterno per eseguire l'autenticazione dipendono dall'IdP e dalla sua configurazione. Ad esempio, potrebbe visualizzare una finestra di dialogo di accesso o richiedere l'MFA o un'impronta. Una volta completati questi passaggi, lo scambio SAML continua:

   

7. L'IdP esterno restituisce una pagina HTML appositamente creata che fa sì che il browser invii immediatamente una richiesta HTTP POST all'URL ACS. Questa richiesta contiene due parametri:

   • RelayState, che contiene il valore originariamente trasmesso all'IdP nella richiesta di autenticazione SAML.

   • SAMLResponse, che contiene l'asserzione SAML codificata in Base64. L'asserzione SAML è un documento XML che indica che l'IdP ha autenticato correttamente l'utente. In forma decodificata, l'asserzione SAML è simile alla seguente:

     <samlp:Response ...>
       ...
       <Assertion x...>
         <Issuer>https://idp.example.org/</Issuer>
         <Signature ...>
           ...
         </Signature>
         <Subject>
           <NameID Format="...:nameid-format:emailAddress">bob@example.org</NameID>
           ...
         </Subject>
         <Conditions NotBefore="..." NotOnOrAfter="...">
           <AudienceRestriction>
             <Audience>google.com</Audience>
           </AudienceRestriction>
         </Conditions>
         <AttributeStatement>
           ...
         </AttributeStatement>
         <AuthnStatement AuthnInstant="..." ...>
           <AuthnContext>
             <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
           </AuthnContext>
         </AuthnStatement>
       </Assertion>
     </samlp:Response>
     

   Questa asserzione di esempio è stata emessa per il pubblico google.com (corrispondente all'emittente della richiesta di autenticazione SAML) e indica che l'IdP https://idp.example.org/ ha autenticato l'utente bob@example.org.

   L'asserzione SAML contiene anche una firma digitale. Il provider di identità crea questa firma utilizzando la chiave privata di un certificato di firma. La chiave privata è nota solo al provider di identità. La chiave pubblica corrispondente fa parte della configurazione SSO in Cloud Identity o Google Workspace e viene condivisa con Google Sign-In.

   L'asserzione SAML contiene anche una firma digitale che consente al service provider SAML di verificare l'autenticità dell'asserzione.

8. Il browser pubblica l'asserzione SAML nell'endpoint ACS di Google.

9. L'endpoint ACS verifica la firma digitale dell'asserzione SAML. Questo controllo viene eseguito per garantire che l'asserzione provenga dal provider di identità esterno attendibile e non sia stata manomessa. Supponendo che la firma sia valida, l'endpoint ACS analizza i contenuti dell'asserzione, verificando le informazioni sul pubblico e leggendo l'attributo NameID.

10. L'endpoint ACS cerca il tuo account utente abbinando NameID dell'asserzione SAML all'indirizzo email principale dell'utente. L'endpoint avvia quindi una sessione.

11. In base alle informazioni codificate nel parametro RelayState, l'endpoint determina l'URL della risorsa a cui intendevi accedere originariamente e viene reindirizzato alla console Google Cloud .

Accesso avviato dall'IdP

Il processo descritto nella sezione precedente viene talvolta definito accesso avviato dal service provider perché inizia dal service provider, che nell'esempio precedente è la console Google Cloud .

SAML definisce anche un flusso alternativo chiamato accesso avviato dall'IdP, che inizia dall'IdP. Google non supporta questo flusso, ma puoi ottenere risultati simili utilizzando il seguente URL per avviare un accesso avviato dal service provider:

https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com/

In questo esempio, DOMAIN è il dominio principale del tuo account Cloud Identity o Google Workspace.

Autenticazione a più fattori

Per proteggere gli account utente da accessi non autorizzati, puoi richiedere agli utenti di fornire un secondo fattore durante l'autenticazione. Esistono due modi per implementare l'autenticazione a più fattori quando si utilizza Single Sign-On:

1. Se il tuo IdP esterno supporta l'autenticazione a più fattori, puoi farla eseguire nell'ambito della procedura di accesso basata su SAML. In questo caso, non è necessaria alcuna ulteriore configurazione in Cloud Identity o Google Workspace.
2. Se il tuo IdP non supporta l'autenticazione a più fattori, puoi configurare il tuo account Cloud Identity o Google Workspace per eseguire la verifica in due passaggi immediatamente dopo che un utente si è autenticato con l'IdP esterno.

Networking

Nel binding di reindirizzamento HTTP SAML 2.0, l'IdP e il service provider non comunicano direttamente. Tutta la comunicazione viene invece inoltrata tramite il browser dell'utente, come mostrato nel seguente diagramma:

Data questa architettura, non è necessario che l'IdP sia esposto a internet o che abbia accesso a internet, purché gli utenti possano accedervi dalla rete aziendale.

Configurazione dell'IdP esterno

Cloud Identity e Google Workspace ti consentono di configurare il Single Sign-On utilizzando le seguenti funzionalità:

• Profili SAML: puoi creare un profilo SAML per ogni IdP che vuoi integrare. Per ogni utente, gruppo o unità organizzativa nel tuo account Cloud Identity o Google Workspace, decidi se deve utilizzare l'SSO e quale profilo SAML deve utilizzare.

• Profilo SAML legacy (precedentemente denominato profilo SSO organizzativo): puoi utilizzare il profilo SAML legacy per l'integrazione con un singolo IdP. Per ogni utente, gruppo o unità organizzativa nel tuo account Cloud Identity o Google Workspace, decidi se deve utilizzare l'SSO o meno.

Il modo corretto per configurare l'IdP dipende dal fatto che utilizzi profili SAML o il profilo SAML legacy. La tabella seguente riepiloga le impostazioni che in genere devono essere configurate in un IdP esterno per garantire la compatibilità.

Passaggi successivi

• Esamina le architetture di riferimento per l'integrazione con un IdP esterno.
• Scopri come configurare il provisioning degli account e il servizio SSO con Microsoft Entra ID o Active Directory.
• Leggi le nostre best practice per la federazione Google Cloud con un IdP esterno.

Collaboratori

Autore: Johannes Passing | Cloud Solutions Architect