Due meccanismi che partono dallo stesso IdP
Un’enterprise che collega GitHub al proprio identity provider ha davanti due integrazioni distinte, e il blueprint chiede esplicitamente di saperle distinguere. SCIM governa gli account: li crea, li aggiorna, li sospende. Team synchronization governa l’appartenenza ai team: allinea l’elenco dei membri di un team a un gruppo dell’IdP, e nient’altro. Partono dalla stessa sorgente di verità, ma agiscono su oggetti diversi e si configurano in punti diversi della console.
SCIM (System for Cross-domain Identity Management) è il protocollo con cui l’IdP esegue il provisioning: quando una persona viene assegnata all’applicazione GitHub l’account nasce, quando cambiano i suoi attributi vengono propagati, quando viene disattivata o rimossa dall’assegnazione GitHub invalida le sessioni attive e disabilita l’account. I dati non spariscono: l’username viene sostituito con un hash di quello originale, con lo short code dell’enterprise in coda se previsto, e una riattivazione lato IdP ripristina il nome precedente. SCIM trasporta anche informazioni sui gruppi, ed è così che negli enterprise con account gestiti i gruppi dell’IdP pilotano i team.
Team synchronization non fa niente di tutto questo. La documentazione è netta: non è un servizio di provisioning degli utenti e, salvo casi limite, non invita nessuno a entrare in un’organization. Aggiunge a un team persone che sono già membri dell’organization e le toglie quando escono dal gruppo. Si abilita da Enterprise settings, sezione Authentication security, con Enable for Entra ID; l’unico comportamento regolabile impedisce di reinvitare membri usciti in passato, e non ritira le invitation già generate.
Requisiti e vincoli di ciascuno
Team synchronization a livello di enterprise richiede Microsoft Entra ID come IdP, un tenant commerciale e non Gov Cloud, SAML SSO applicato alle organization dell’enterprise e un’utenza Entra con ruolo Global Administrator o Privileged Role Administrator; le autorizzazioni concesse sono di sola lettura su gruppi e profili. Esistono soglie di scala documentate per membri di un team, membri di un’organization e numero di team: superarle non blocca nulla, ma degrada la sincronizzazione.
SCIM ha invece il vincolo che genera la maggior parte degli errori di progettazione: non si configura sull’enterprise account se l’enterprise non è nato per gli Enterprise Managed Users. In un GHEC con account personali, chi vuole il provisioning automatico deve configurare SAML SSO e SCIM a livello di organization, non di enterprise. Negli enterprise EMU l’ordine è obbligato: prima l’autenticazione, SAML oppure OIDC, poi SCIM. Il provisioning via REST API non è supportato con OIDC, e mescolare due IdP partner per SSO e SCIM non è una configurazione supportata.
Quando un team è collegato a un gruppo dell’IdP la membership non si tocca più da GitHub: va cambiata nell’IdP. Quel team non può essere parent né child di un altro team, non ammette il ruolo di team maintainer, e i membri aggiunti a mano vanno rimossi prima del collegamento. Con Entra ID valgono solo i security group: niente gruppi annidati, niente gruppi Microsoft 365. I permessi sui repository restano invece una decisione presa su GitHub, non ereditata dall’IdP.
Che cosa cambia con lo scenario di deployment
In GHEC con account personali SAML autentica ma non amministra il ciclo di vita: l’account continua a esistere anche dopo l’uscita della persona, perché è suo. In GHEC con EMU l’account è dell’azienda e SCIM lo governa dalla nascita alla sospensione; qui i team si guidano con i gruppi provisionati via SCIM, non con la feature Team synchronization, pensata per gli enterprise con SAML e account personali. GHEC with data residency poggia su EMU, quindi eredita lo stesso modello di autenticazione e provisioning. In GHES l’autenticazione esterna passa da CAS, LDAP o SAML e la team synchronization qui descritta è una funzionalità del cloud: se un comportamento riguarda l’istanza self-hosted, verificalo sulla versione in uso, perché il riferimento qui è enterprise-server 3.21.
Il deprovisioning è la prova del nove
È uscendo che si scopre di aver configurato solo metà del sistema. Se esiste solo team synchronization, togliere una persona dal gruppo la fa uscire dal team, ma l’account resta attivo, la licenza resta consumata e ogni altro accesso sopravvive intatto: membership diretta nell’organization, collaboratore su un singolo repository, un secondo team. Disabilitare del tutto team synchronization non rimuove i membri già assegnati, che conservano l’accesso ai repository. Con SCIM, invece, la rimozione nell’IdP disabilita davvero l’account e chiude le sessioni.
Negli enterprise EMU la rimozione da un gruppo collegato a un team fa uscire dal team e, se l’appartenenza all’organization derivava solo da quel gruppo, anche dall’organization; se la persona era entrata per altre strade, resta dentro. Per gli enterprise non EMU esiste una policy di offboarding che rimuove dall’enterprise chi perde l’ultima organization, e vale allo stesso modo se la rimozione arriva da SCIM, dall’interfaccia web o dalla REST API; non tocca enterprise owner e billing manager.
All’esame lo scenario è quasi sempre questo: leggi che cosa deve succedere e scegli il meccanismo. Se il testo parla di creare, sospendere o riattivare account e di liberare licenze, la risposta è SCIM. Se parla di mantenere allineati team esistenti a gruppi esistenti senza toccare gli account, è team synchronization. La confusione da evitare è credere che la seconda faccia deprovisioning, o che SCIM si configuri a livello di enterprise anche fuori da EMU.