Chi possiede l’account è la prima decisione architetturale

Prima di ragionare su ruoli, team e policy conviene rispondere a una domanda sola: l’account con cui una persona lavora appartiene all’azienda o alla persona? Tutto il resto discende da lì.

Con Enterprise Managed Users l’azienda provisiona gli account dal proprio identity provider attraverso SCIM e li autentica via SAML o OIDC. GitHub documenta come partner Entra ID, Okta e PingFederate, con il vincolo esplicito che mescolare Okta ed Entra ID per SSO e SCIM non è supportato; gli IdP non partner devono parlare SAML 2.0 e SCIM 2.0. L’account nasce dentro l’enterprise e non esiste da nessun’altra parte. Lo si riconosce dallo username: GitHub normalizza l’identificatore ricevuto dall’IdP e vi appende l’enterprise shortcode, cioè il suffisso dopo l’underscore che vedi in ogni handle nella forma nome_shortcode. Su GitHub.com lo shortcode lo scegli in fase di creazione dell’enterprise e non è più modificabile; con la data residency viene generato in modo casuale e non è esposto, ma resta nello username. La normalizzazione trasforma i caratteri non alfanumerici in trattini e preserva il maiuscolo/minuscolo, quindi identificatori diversi nell’IdP possono collidere sullo stesso username: in quel caso viene creato solo il primo account e gli altri falliscono in silenzio.

Con gli account personali la persona porta un account che ha creato lei su GitHub.com e che continuerà a esistere quando cambierà lavoro. L’azienda può imporre il SAML single sign-on, ma il SSO controlla l’accesso alle risorse, non la proprietà dell’account: revocare l’identità nell’IdP chiude la porta dell’enterprise, non cancella l’account.

Un elemento che ricorre nelle domande è il setup user, lo username shortcode_admin creato da GitHub e non provisionato dall’IdP. Non entra via SSO, accede dal login standard di GitHub.com e serve a tre cose: configurare autenticazione e provisioning, eseguire SCIM con il proprio personal access token e rientrare nell’enterprise quando l’IdP è indisponibile. Attenzione a non confondere gli enterprise recovery codes con i recovery code della 2FA personale: sono due insiemi distinti.

Che cosa cambia nel lavoro quotidiano

Il perimetro di un managed user è chiuso. Vede i repository pubblici di GitHub.com, ma non può interagirvi: niente issue, pull request, discussion, commenti, reaction, star, watch o fork fuori dall’enterprise. Non può creare repository pubblici né gist, i repository che possiede sono necessariamente privati e il profilo non è personalizzabile. Lui e i contenuti che produce sono visibili solo agli altri membri dell’enterprise: dall’esterno non può essere trovato, menzionato o invitato, e non può seguire utenti fuori dall’enterprise. Poiché i repository pubblici non esistono in questo modello, la visibilità condivisa a livello aziendale si ottiene con gli internal repositories.

La conseguenza operativa è netta: chi deve contribuire all’open source o collaborare con un cliente esterno ha bisogno di un secondo account personale, tenuto separato. Con gli account personali il problema non si pone, ma si paga in controllo, e resta comunque il vincolo che gli outside collaborators si aggiungono ai singoli repository, non alle organization o ai team. Nel modello managed esiste invece il ruolo guest collaborator, con accesso limitato per impostazione predefinita e senza visibilità sugli internal repository, salvo nelle organization di cui è membro.

Infine, il passaggio da account personali a managed users non è un interruttore: richiede un enterprise account nuovo e una migrazione.

Autenticazione e autorizzazione sono due domande diverse

Autenticazione risponde a “chi sei”, autorizzazione a “che cosa puoi fare”. Con i managed users l’IdP fa la prima e governa il ciclo di vita dell’account; GitHub fa la seconda. Con gli account personali l’autenticazione è di GitHub.com, eventualmente affiancata dall’IdP via SAML.

L’autorizzazione si compone a strati. A livello di enterprise ci sono ruoli come Enterprise owner, Billing manager, App manager, Security manager, Guest collaborator e i custom enterprise roles; le policy dell’enterprise fissano il tetto di ciò che le organization possono concedere. Dentro l’organization agiscono Organization owner, member, moderator, billing manager, security manager, GitHub App manager e i custom organization roles, insieme alle base permissions. L’accesso effettivo al codice arriva poi dai repository roles, assegnati a persone o a team.

Sui team il modello managed introduce un vincolo: collegando un team a un gruppo dell’IdP la membership si gestisce solo nell’IdP, il team va svuotato prima del collegamento, un team collegato non può essere padre o figlio di un altro e non si può assegnare il ruolo di team maintainer. Se l’ingresso in un team porta l’utente in un’organization di cui non era membro, GitHub ce lo aggiunge automaticamente; scollegando il gruppo, chi era entrato solo per quella via viene rimosso. Gli accessi ai repository, invece, restano da configurare su GitHub.

Che cosa verifica l’esame

  • Scenario: “vogliamo revocare l’accesso disattivando l’utente nell’IdP e ritrovarci l’account chiuso.” → Solo con Enterprise Managed Users. Con gli account personali il SAML SSO blocca l’accesso, non l’esistenza dell’account.
  • Confusione tipica: pensare che i quattro scenari siano intercambiabili. GHEC con data residency vive su un dominio dedicato in ghe.com, con endpoint API sul sottodominio dell’enterprise, e richiede i managed users. GHES è un’istanza che ospita gli account in casa e, nella documentazione fissata a enterprise-server 3.21, prevede autenticazione esterna via CAS, LDAP o SAML: i managed users non c’entrano.
  • Dettaglio SAML: configurato a livello di enterprise obbliga i membri ad autenticarsi via SAML prima di accedere alle risorse dell’organization, inclusi gli internal repository; configurato sulla singola organization questo requisito sugli internal repository non si applica.
  • Trappola sullo username: il suffisso non è decorativo. Se una domanda mostra un handle con underscore e shortcode, stai guardando un enterprise con managed users.