--- title: "Configurare SSO con Google Workspace" description: "Registra una connessione SAML o OIDC Bird in Google Workspace, disattiva la firma della risposta, abilita l'accesso utente e tieni conto del ritardo di configurazione di Google." canonical: "https://bird.com/it-it/documentazione/knowledge-base/account-security/sso-google-workspace" --- # Configurare SSO con Google Workspace Questa pagina copre la parte Google Workspace di una connessione SSO. La parte Bird (verifica di un dominio, test, attivazione e imposizione dell'SSO) è la stessa per ogni provider e si trova in [SSO e provisioning](/docs/knowledge-base/account-security/sso). Google e Bird hanno bisogno ciascuno di valori dall'altro, quindi il punto di partenza dipende dal protocollo. Tieni aperti entrambi mentre lavori. Due comportamenti di Google causano la maggior parte dei primi test falliti, e nessuno dei due segnala nulla a Bird: - **Attiva l'accesso utente prima di testare.** Una nuova app SAML personalizzata parte disattivata per tutti. Finché non la abiliti per le persone che eseguiranno l'accesso, Google rifiuta dal proprio lato e la finestra di test non mostra nulla. - **Attendi qualche minuto dopo il salvataggio.** Google applica le modifiche a un'app SAML (firma della risposta, formato Name ID, accesso utente) con un ritardo di circa due-quattro minuti. Un test eseguito in quella finestra temporale riporta la configurazione precedente, che sembra un problema di Bird ma non lo è. ## SAML Per SAML, parti da Bird. L'Entity ID e l'Assertion Consumer Service URL di una connessione SAML derivano dalla connessione stessa, quindi creala con **I have not set up my provider yet**, registra i valori che mostra e torna a **Supply the details**. [Configurare SAML senza valori segnaposto](/docs/knowledge-base/account-security/sso) illustra il flusso. Google non pubblica un URL di metadati per un'app SAML personalizzata. Scarica il file di metadati dalla console di amministrazione Google e incollane il contenuto in **Supply the details** sulla connessione Bird, scegliendo l'opzione metadata-document. I nomi dei campi di Google non corrispondono a quelli di Bird: | In Bird, sotto **Register these with your identity provider** | In Google Workspace | | ------------------------------------------------------------- | -------------------- | | Assertion Consumer Service URL | ACS URL | | Entity ID | Entity ID | | Sign-in URL for this connection | Start URL (optional) | ### Disattivare Signed response Lascia **Signed response** deselezionato. Se selezionato, Google firma la risposta ma lascia l'assertion al suo interno senza firma, e Bird verifica la firma dell'assertion stessa, quindi ogni accesso viene rifiutato con un errore di firma che sembra un problema di certificato. Deselezionandolo si ripristina un'assertion firmata e gli accessi riescono. ### Identificare i membri tramite indirizzo email Imposta **Name ID format** su `EMAIL`. Gli altri formati di Google non funzionano con Bird: - `UNSPECIFIED` viene rifiutato direttamente. - `PERSISTENT` viene rifiutato perché il formato non corrisponde a quello atteso dalla connessione. Google invia comunque l'indirizzo email del membro come valore, quindi non è l'identificatore opaco e mai riassegnato che un formato persistente dovrebbe trasportare. Google non offre un identificatore opaco per il NameID, quindi `EMAIL` è l'unica scelta utilizzabile. Questo rende l'indirizzo permanente per chiunque acceda tramite questa connessione: se la tua organizzazione lo riassegna, la persona successiva che lo riceve eredita l'account Bird. Leggi [Come vengono identificati i membri](/docs/knowledge-base/account-security/sso) prima di fare affidamento su questo. ### Validità dell'assertion e certificati Google firma le assertion con validità da cinque minuti prima dell'emissione a cinque minuti dopo, intervallo accettato da Bird. Google gestisce il certificato di firma e la sua data di scadenza, e non offre controllo sulla rotazione per un'app SAML personalizzata. Annota la scadenza mostrata sulla connessione Bird e pianifica la sostituzione dei metadati prima che arrivi, perché il giorno in cui scade ogni accesso tramite la connessione fallisce. ## OIDC Per OIDC, parti dalla console Google Cloud. Bird ha bisogno dell'issuer, del client ID e del client secret per creare una connessione OIDC, quindi registra prima l'applicazione su Google. Il **Redirect URI** di Bird è lo stesso per ogni connessione ed è mostrato in **Add connection** prima di creare qualsiasi cosa, quindi puoi registrarlo subito. Crea le credenziali client OAuth nella console Google Cloud per il progetto che serve i tuoi utenti Workspace, e copia il client ID e il secret in Bird con `https://accounts.google.com` come **Issuer**. Bird legge il discovery document da lì e si autentica verso il token endpoint con `client_secret_basic`. Registra il **Redirect URI** di Bird come redirect URI autorizzato sul client. Il percorso OIDC di Google non prevede un passaggio app-tile: un client OAuth personalizzato non compare nel launcher delle app Google, quindi i membri partono dalla pagina di accesso di Bird o da un link che fornisci tu. ## Passi successivi - [SSO e provisioning](/docs/knowledge-base/account-security/sso): verificare un dominio, testare la connessione e imporre l'SSO - [Configurare SSO con Okta](/docs/knowledge-base/account-security/sso-okta) - [Configurare SSO con Microsoft Entra ID](/docs/knowledge-base/account-security/sso-microsoft-entra-id) ## Related resources - [Should I use an API key or an OAuth token, and how do I rotate one?](/explained/platform/api-key-or-oauth-token-and-how-do-i-rotate-one) (answer) - [Authentication & API keys](/docs/guides/authentication) (docs) [Get an implementation brief](/learn/workspace?topic=account-access)