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.
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 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:
UNSPECIFIEDviene rifiutato direttamente.PERSISTENTviene 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 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: verificare un dominio, testare la connessione e imporre l'SSO
- Configurare SSO con Okta
- Configurare SSO con Microsoft Entra ID
Risorse correlate
Continua con la documentazione, le guide e gli esempi per questo argomento.