Dove si configura SAML: organizzazione o enterprise
Il SAML single sign-on collega gli account GitHub all’anagrafica aziendale: l’utente resta su GitHub, ma al momento dell’accesso alle risorse protette viene rediretto all’identity provider (IdP) per autenticarsi e poi rimandato indietro. GitHub tiene traccia del legame fra account e external identity presente nell’IdP.
La prima decisione da amministratore è il livello. A livello di organization puoi far convivere IdP diversi per gruppi diversi, introdurre SAML gradualmente e mantenere i repository internal raggiungibili anche senza passare dall’IdP. A livello di enterprise account la configurazione è una sola e vale per tutte le organizzazioni possedute: le organizzazioni non possono sovrascriverla e la configurazione enterprise ha la precedenza su quelle locali. In quel caso l’accesso a qualunque risorsa delle organizzazioni, repository internal compresi, passa dall’IdP.
C’è un vincolo che l’esame ama: SCIM non si configura su un enterprise account a meno che non sia stato creato per gli Enterprise Managed Users. Se ti serve il provisioning automatico degli account su GHEC con account personali, SCIM va configurato a livello di organizzazione. Allo stesso modo, la team synchronization a livello enterprise funziona solo con Microsoft Entra ID.
Quando sposti la configurazione da organizzazione a enterprise non sei obbligato a rimuovere prima quella locale, ma è consigliato: dopo lo spostamento ogni membro ha una sola identità SAML valida per tutte le organizzazioni, i membri vengono rimossi dai team se elimini la team synchronization dell’organizzazione, e nessuno riceve una notifica automatica del cambio. Scarica e conserva i single sign-on recovery codes: sono il modo per rientrare quando l’IdP non è disponibile.
Autorizzare PAT e chiavi SSH: il punto in cui gli utenti si bloccano
L’attivazione di SAML non tocca solo il browser. Alcune credenziali devono essere autorizzate verso l’organizzazione prima di poter accedere alle sue risorse, ed è qui che arrivano i ticket: il clone via HTTPS o via SSH fallisce anche se l’utente ha appena fatto login sull’IdP.
Richiedono l’autorizzazione SSO il personal access token (classic), il fine-grained personal access token, la user SSH key, l’OAuth app access token e il GitHub App user access token. Per i token di app l’autorizzazione viene concessa automaticamente se l’utente autorizza l’app durante una sessione SAML o OIDC attiva. Non richiedono invece autorizzazione SSO il GitHub App installation access token, il refresh token, le deploy key e il GITHUB_TOKEN di Actions, perché queste ultime sono credenziali con ambito repository.
Due sfumature da amministratore. L’autorizzazione è un’azione dell’utente sul proprio token, non un’operazione che puoi fare al posto suo: tu puoi revocarla. E la revoca non è simmetrica, perché per i fine-grained PAT gli owner non possono revocare l’autorizzazione SSO come fanno con i classic PAT e le chiavi SSH. Infine, quando promuovi SAML da organizzazione a enterprise, le credenziali già autorizzate restano valide, ma tutto ciò che non era mai stato autorizzato per quella organizzazione va autorizzato ora.
Sulla durata della sessione, l’IdP comanda: se l’asserzione contiene l’attributo SessionNotOnOrAfter GitHub ne rispetta il valore, altrimenti applica la propria scadenza predefinita e obbliga a riautenticarsi.
Imporre la 2FA e chi resta fuori
L’autenticazione a due fattori si impone dalle stesse pagine. Su un’organizzazione vai in Settings, sezione Security, Authentication security, e attivi Require two-factor authentication for everyone in your organization; puoi affiancarci Only allow secure two-factor methods, che restringe la scelta a passkey, security key, app di autenticazione e app mobile GitHub. A livello di enterprise l’equivalente è Require two-factor authentication for the enterprise and all of its organizations, che si applica a tutte le organizzazioni possedute.
Gli effetti non sono uguali per tutti, ed è una domanda classica. I member restano membri e continuano a consumare una licenza, ma non accedono alle risorse dell’organizzazione finché non attivano la 2FA; lo stesso vale per chi la disattiva dopo l’attivazione della policy. Gli outside collaborator e gli account bot vengono invece rimossi, perdono l’accesso ai repository e ai fork dei repository privati, e vanno reinvitati: se attivano la 2FA e accettano l’invito entro tre mesi ritrovano privilegi e impostazioni. Nota anche che l’owner unico non può disattivare la propria 2FA senza prima togliere il requisito, e che questa policy non è disponibile per gli enterprise con managed user, dove il secondo fattore è responsabilità dell’IdP.
Scegliere il provider e capire SAML contro OIDC
GitHub documenta il supporto per AD FS, Entra ID, Okta, OneLogin, PingOne e Shibboleth, con supporto limitato per qualunque IdP conforme a SAML 2.0. Il criterio di scelta non è solo il protocollo: serve capire quali funzioni collaterali ti servono, perché la team synchronization enterprise vincola a Entra ID.
La differenza fra i protocolli si vede negli scenari di deployment. Su GHEC con account personali l’unica opzione è SAML: l’account resta dell’utente e SAML aggiunge una restrizione di accesso. Su GHEC con Enterprise Managed Users gli account sono creati e governati dall’IdP via SCIM, i managed user non possono pubblicare contenuti pubblici né collaborare fuori dall’enterprise, e l’autenticazione può essere SAML oppure OIDC. L’OIDC è disponibile solo con Entra ID, con un’integrazione per tenant, e porta un vantaggio concreto: GitHub applica le condizioni IP della conditional access policy dell’IdP sull’interfaccia web, al cambio di indirizzo IP e a ogni autenticazione con PAT o chiave SSH. GHEC with data residency su GHE.com richiede obbligatoriamente EMU, quindi eredita gli stessi vincoli. Su GHES l’autenticazione si configura invece sull’istanza e le opzioni disponibili dipendono dalla release: prima di rispondere a una domanda operativa, verifica la documentazione della versione in uso.
Confusione tipica da evitare all’esame: SAML autentica, SCIM provisiona, e i due non si attivano nello stesso punto né con gli stessi prerequisiti.