Accedi con il team tramite SSO

Cosa creerai

Al termine di questo tutorial avrai:

• una connessione SAML tra il tuo server Control Center e un provider di identità (usiamo Okta come esempio),
• un utente di cui viene eseguito automaticamente il provisioning al primo accesso e
• una policy di appartenenza agli spazi di lavoro che hai scelto deliberatamente.

Ti serve un server che amministri (il proprietario del server — l’operatore dell’installazione) e un’applicazione IdP che puoi configurare. Prevedi 20 minuti.

1. Apri le impostazioni dell’accesso single sign-on

Accedi a Control Center, poi vai in Impostazioni → Server → Accesso single sign-on. La schermata permette di passare da SAML a OpenID Connect, e c’è anche una scheda Provisioning utenti (SCIM). Resta su SAML.

Tutto in questa schermata vale per l’intero server: un solo IdP autentica le persone di ogni spazio di lavoro, quindi solo il proprietario del server può modificarla.

2. Incolla i metadati dell’IdP

In Okta, apri la scheda Sign On della tua applicazione e copia l’XML dei metadati (oppure scaricalo e incolla il contenuto del file). Di nuovo in Control Center, incollalo in XML dei metadati dell’IdP e premi Testa connessione.

Il messaggio a comparsa riporta l’endpoint di accesso dell’IdP — prova che i metadati sono stati analizzati, che il certificato è stato letto e che il server è in grado di costruire una richiesta di accesso a partire da essi (il test verifica tutto tranne il round-trip del browser). Se fallisce, l’XML non era un EntityDescriptor completo (la scheda SAML di Okta lo chiama “Metadata URL”; apri l’URL e copia ciò che restituisce). Lo stesso pulsante in OpenID Connect verifica invece il documento di discovery del tuo issuer. Per individuare anche un certificato in scadenza e vedere se l’IdP riconosce Control Center, usa il verificatore del passaggio 6.

3. Registra Control Center presso l’IdP

Premi Copia metadati SP e passali a chi configura il lato Okta (oppure leggi i due valori che ti chiedono):

• URL ACS: https://<your-server>/saml/acs
• ID entità: https://<your-server>/saml

Gli URL derivano dall’origine che raggiungono i browser dei tuoi utenti. Se il server gira dietro un tunnel o un reverse proxy, assicurati che l’origine sia stabile (Impostazioni → Server → Connessione e stato → Condividi questo server mostra l’URL pubblico) — oppure fissa l’ID entità esplicitamente nel campo ID entità SP.

Dietro un NAT?

L’accesso SAML non richiede un IP pubblico né un dominio: l’IdP non si connette mai al tuo server — è il browser dell’utente a trasportare il round-trip, quindi localhost, LAN, VPN, Tailscale o un tunnel funzionano tutti. Due cose da non confondere:

• l’origine usata dal browser deve corrispondere all’URL ACS / all’ID entità registrati presso l’IdP (fissa l’ID entità se gli utenti raggiungono il server da più di un’origine),
• il provisioning SCIM è l’eccezione — l’IdP chiama direttamente il tuo server, quindi serve un tunnel o un URL pubblico (esegui il provisioning degli utenti con SCIM).

4. Scegli cosa concede un accesso

Due policy decidono cosa fa un primo accesso:

• Aggiungi gli utenti a ogni workspace al primo accesso — lasciala attiva per un deployment con una sola squadra, in cui l’SSO equivale a fiducia. Disattivala quando più squadre o clienti condividono il server: ogni nuovo arrivato ha allora bisogno di un invito esplicito a uno spazio di lavoro, che è l’impostazione predefinita più sicura.
• Esegui il provisioning degli utenti sconosciuti al primo accesso — attiva per impostazione predefinita; disattivala per rifiutare chiunque il cui account non esista già.

Se vuoi, mappa un attributo che contiene i nomi dei gruppi (in Okta è comunemente groups) e traduci i gruppi in ruoli con la mappa — per esempio {"platform-leads": "admin"}. L’SSO non può mai concedere il ruolo proprietario.

5. Attiva la connessione ed esegui un accesso

Attiva Usa SAML per l’accesso, premi Salva connessione, poi apri una finestra di navigazione privata su https://<your-server>/saml/login. Accedi su Okta e torni al client web — con l’accesso effettuato, il tuo account creato e la sua appartenenza concessa in base alla policy che hai scelto.

Lo stesso punto di ingresso compare nella schermata di connessione web (Accedi con SAML) appena digiti l’indirizzo del server — il modulo si adatta a ciò che offre il server (OpenID Connect mostra Accedi con OpenID Connect). Il pulsante apre l’accesso in una nuova scheda; al termine del round-trip, la scheda in attesa riprende la sessione automaticamente. La schermata di configurazione del server dell’app desktop fa lo stesso: digita l’URL del server, compare un pulsante Accedi con SAML che apre il browser e l’app effettua l’accesso al termine del round-trip.

6. Verifica da questa pagina

Prima di distribuire l’SSO, o quando un accesso non riesce, controlla qui i singoli elementi. Il verificatore viene eseguito interamente nel tuo browser: legge i metadati che incolli in questa scheda e applica le stesse regole del server. Se gli fornisci l’indirizzo del tuo server, chiede anche a quel server se l’accesso SAML è attivo.

Individua ciò che Testa connessione nell’app non può vedere: un certificato di firma prossimo alla scadenza, un IdP che pretende richieste firmate e, con l’accesso di prova, se l’IdP riconosce Control Center.

Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.

IdP metadata XMLLoad a file

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

SP entity ID (optional)

Only if you pinned one in the app.

Check metadata

Passaggi successivi

• Affida al tuo IdP anche il controllo del ciclo di vita: esegui il provisioning e il deprovisioning degli utenti con SCIM.
• Il tuo IdP parla OpenID Connect invece di SAML? Collega un provider OpenID Connect.
• Vuoi sapere cosa verifica davvero il round-trip nel browser? Come funziona l’accesso singolo.