SSO e provisioning

Il single sign-on (SSO) consente ai membri di accedere a Bird tramite il proprio identity provider anziché usare una password Bird separata. Bird supporta connessioni SAML 2.0 e OpenID Connect (OIDC).

La configurazione è un'attività dell'Owner dell'organizzazione e i controlli si trovano nella pagina Single sign-on della tua organizzazione. Un membro con il permesso SSO può gestire le connessioni senza essere un Owner.

L'accesso personale con Google o GitHub è separato dall'SSO dell'organizzazione. Vedi Login, password e MFA.

Come funziona l'SSO

Una connessione SSO copre uno o più domini email verificati, come yourcompany.com. I membri su quei domini si autenticano con il tuo identity provider. I loro permessi Bird derivano comunque dai ruoli nell'organizzazione e nello spazio di lavoro.

Cosa comporta la configurazione

Un Owner dell'organizzazione e un amministratore dell'identity provider completano la configurazione:

1. Dimostra di essere il proprietario del dominio. Bird ti fornisce un record DNS da pubblicare per ogni dominio email coperto dalla connessione. L'applicazione non può essere attivata finché il dominio non è verificato.
2. Configura la connessione. Per SAML, fornisci i metadati dell'identity provider oppure l'URL di accesso e i certificati di firma. Per OIDC, fornisci l'issuer e le credenziali client. Copia i dettagli del service provider o del redirect di Bird nel tuo identity provider.
3. Testa la connessione. Completa un accesso di test prima di attivare la connessione. Qualunque protocollo tu abbia scelto, una bozza il cui test ha esito positivo viene attivata automaticamente, a condizione che la tua organizzazione abbia un dominio verificato e non superi il limite di connessioni attive.
4. Scegli se rendere l'SSO obbligatorio. Quando l'SSO è facoltativo, i membri possono usare l'SSO o un altro metodo di accesso disponibile. Quando è obbligatorio, i membri devono completare l'SSO per accedere all'organizzazione. Rendere l'SSO obbligatorio richiede una connessione attiva e almeno un dominio verificato.

L'obbligo di SSO ha effetto immediato, su ogni richiesta, e non solo al prossimo accesso. Un membro la cui sessione corrente non è stata stabilita tramite il tuo identity provider perde l'accesso all'organizzazione finché non accede di nuovo tramite esso, quindi pianifica la modifica in base alla giornata del tuo team anziché comunicarla a posteriori. Gli Owner dell'organizzazione fanno eccezione: un Owner mantiene l'accesso con la propria password Bird, ed è questo che impedisce a una connessione mal configurata di bloccare tutti.

Configura il tuo identity provider

Il passaggio 2 è la metà che varia in base al provider: lo stesso valore ha un nome diverso in ciascuno, e ciascuno ha un'impostazione che rifiuta ogni accesso se è sbagliata. I nomi dei campi di Bird sono quelli nella pagina della connessione, sotto Register these with your identity provider.

• Configura l'SSO con Okta
• Configura l'SSO con Google Workspace
• Configura l'SSO con Microsoft Entra ID

Per qualsiasi altro provider SAML 2.0 o OpenID Connect, i quattro passaggi precedenti costituiscono l'intero processo.

Configurare SAML senza valori segnaposto

L'Entity ID e l'Assertion Consumer Service URL di una connessione SAML derivano dalla connessione stessa, quindi non esistono finché non la crei. Questo crea un circolo vizioso: il tuo identity provider ha bisogno di quei valori, e quei valori hanno bisogno della connessione.

Crea prima la connessione. In Add connection, scegli SAML e poi I have not set up my provider yet. La connessione viene creata come bozza senza dettagli dell'identity provider, e aprendola vengono mostrati i valori da registrare sotto Register these with your identity provider. Configura il tuo provider con quei valori, poi torna indietro e usa Supply the details sulla stessa connessione, in qualsiasi formato tu li abbia:

• un metadata URL, che viene recuperato e letto
• il metadata document stesso, per un provider che distribuisce un file anziché ospitarlo
• l'entity ID, sign-in URL e signing certificates, inseriti direttamente

Un documento caricato viene letto per estrarre quei tre valori e non viene conservato.

Finché i dettagli non vengono forniti, la connessione resta una bozza: non gestisce accessi e non può essere attivata.

Come vengono identificati i membri

Una connessione SAML identifica ogni membro tramite il NameID inviato dal tuo provider, e quell'identificatore è permanente per chiunque acceda. La configurazione di una connessione non ti chiede quale formato usare. Se hai fornito un metadata URL o un documento, leggiamo ciò che il tuo provider dichiara e associamo la connessione a quello. Se hai inserito i dettagli manualmente non ci sono metadati da leggere, quindi la connessione viene associata a un ID permanente.

Quello che controlli è il valore che sta dietro. Imposta lo username dell'applicazione sul tuo provider su qualcosa di opaco e mai riassegnato, e invia l'indirizzo separatamente come attributo email. Un indirizzo email come identificatore è più debole per sempre: se l'indirizzo viene riassegnato, la persona successiva che lo riceve eredita l'account Bird.

I metadati indicano cosa il tuo provider può inviare; la configurazione dell'applicazione decide cosa effettivamente invia, e i due possono differire. Quindi l'accesso di test nel passaggio 3 riporta l'identificatore e il formato che l'asserzione ha effettivamente trasmesso, e quel rapporto è il modo in cui verifichi che i due concordino prima che qualcuno si affidi alla connessione. Rifiutiamo anche un identificatore etichettato come persistent che in realtà è un indirizzo email.

Se il test riporta un formato che non ti aspettavi, hai due modi per correggerlo, e quello giusto dipende da cosa c'è di sbagliato:

• Il provider sta inviando il valore sbagliato. Cambia lo username dell'applicazione sul tuo provider, poi ripeti il test. Di solito questa è la correzione giusta, perché l'identificatore opaco è quello che vale la pena conservare.
• La connessione è associata al valore sbagliato. Apri Edit sulla connessione e cambia il formato del NameID con quello inviato dal tuo provider.

Esegui una delle due operazioni prima che i membri inizino ad accedere. Una volta che lo hanno fatto, i loro account sono collegati all'identificatore in vigore, quindi il formato è fisso e la modifica viene rifiutata. Crea una nuova connessione per il nuovo formato.

Sostituire un provider

I dettagli dell'identity provider di una connessione SAML possono essere sostituiti finché nessuno ha effettuato l'accesso. Una volta che i membri l'hanno usata, i loro account sono collegati agli identificatori inviati dal provider corrente, quindi la sostituzione viene rifiutata. Crea una nuova connessione per il nuovo provider. Su una connessione OIDC puoi ruotare il client secret in qualsiasi momento, il che non cambia ciò che identifica i membri, ma il provider stesso non può essere sostituito.

L'accesso di test nel passaggio 3 non conta. Un test non collega alcun account e non concede alcun accesso, quindi una connessione che hai configurato e testato ma non ancora resa disponibile al tuo team può ancora essere reindirizzata.

Cosa cambia per il tuo team

Una connessione può concedere l'accesso predefinito all'organizzazione e allo spazio di lavoro a un membro al suo primo accesso SSO riuscito. Configura quell'accesso predefinito in modo esplicito; in caso contrario, invita i membri e assegna i ruoli prima che accedano. Vedi Utenti, team e ruoli.

Sospendere una connessione impedisce nuovi accessi tramite essa. Rivedi le appartenenze Bird e le sessioni attive separatamente quando qualcuno lascia la tua azienda.

Passaggi successivi

• Login, password e MFA: sicurezza dell'account individuale, incluso l'accesso personale con Google/GitHub
• Utenti, team e ruoli: come funzionano ruoli e permessi una volta che i membri sono dentro
• Autenticazione e chiavi API: il riferimento per l'autenticazione lato sviluppatore