Esegui il provisioning degli utenti con SCIM

Usa questa guida quando vuoi il controllo del ciclo di vita: l’offboarding deve revocare l’accesso in modo automatico, non limitarsi a bloccare gli accessi futuri. SCIM è il protocollo push che gli IdP (Okta, Entra ID e altri) usano esattamente per questo.

Prerequisiti

• SSO già funzionante (il tutorial SSO o la guida OIDC),
• un server che l’IdP possa raggiungere via HTTPS — le chiamate SCIM provengono dall’IdP, non dal browser dell’utente. Usa il tunnel integrato (Impostazioni → Server → Connessione e stato → Condividi questo server → Cloudflared/ngrok/Tailscale) oppure un URL pubblico. Un server raggiungibile solo tramite il relay WebSocket non può ricevere i push SCIM; lì il provisioning JIT funziona comunque, questa guida no.

Passaggi

1. Apri Impostazioni → Server → Accesso single sign-on → la scheda Provisioning utenti (SCIM). La scheda mostra l’endpoint, ad es. https://<your-server>/scim/v2/Users.
2. Premi Genera token (o Rigenera token se ne esiste già uno) — il token bearer compare una sola volta in una finestra di dialogo e viene copiato negli appunti. Conservalo nel tuo gestore di password; il server ne mantiene solo una copia verificabile a tempo costante.
3. Nelle impostazioni di provisioning del tuo IdP, attiva SCIM con:
   • URL di base: l’endpoint qui sopra
   • Autenticazione: Authorization: Bearer <token>
   • ID utente: userName (email) oppure externalId — entrambi corrispondono
4. Prova con un utente: invialo dal tuo IdP, verifica che compaia (la create SCIM fissa l’externalId del provider sull’account, lo stesso fissaggio che imposta il primo accesso SSO).

Che cosa fa il deprovisioning

Quando l’IdP invia active: false (o DELETE), SCIM rifiuta l’operazione se l’account è proprietario di uno spazio di lavoro (trasferisci prima la proprietà). Negli altri casi:

1. viene revocata prima ogni credenziale dei dispositivi — le sessioni attive decadono entro pochi secondi,
2. viene rimossa ogni appartenenza agli spazi di lavoro,
3. l’account viene contrassegnato come disattivato (non potrà più accedere, qualunque cosa dica in seguito l’IdP, finché non viene riattivato esplicitamente).

La riga dell’utente sopravvive: l’attribuzione su ticket, messaggi e commit è permanente. La riattivazione (SCIM active: true) ripristina l’accesso ma non le appartenenze: per quelle servono un nuovo invito o la policy di appartenenza automatica al momento dell’accesso.

Risoluzione dei problemi

• 401 a ogni chiamata: il token è cambiato; rigeneralo e aggiorna l’IdP.
• L’endpoint non è raggiungibile: il tunnel è inattivo oppure il server è solo relay. SCIM richiede HTTPS diretto; il JIT continua a funzionare in ogni caso.
• Errori di push dei gruppi (501): sono intenzionali: la mappatura gruppo→ruolo avviene all’accesso a partire dagli attributi di gruppo SAML/OIDC, non dai gruppi inviati.