Nella maggior parte dei casi, l'integrazione tecnica tra Cloudflare Access e un provider di identità aziendale richiede meno di un'ora: scambio di metadati, alcuni URL, test di autenticazione. Ciò che richiede settimane è ciò che verrà dopo: decidere quali gruppi hanno accesso a quali applicazioni, con quale durata della sessione, con quali requisiti di MFA e cosa fare con i collaboratori esterni su un diverso IdP. La configurazione del protocollo è un dettaglio della documentazione. L’architettura politica è una decisione progettuale.
SAML, OIDC e ciò che conta nella scelta
Cloudflare Access supporta sia SAML 2.0 che OIDC. Per i provider aziendali più grandi – Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud – Cloudflare mantiene guide di integrazione con mappatura esatta dei campi. La scelta tra SAML e OIDC raramente è una decisione tecnica critica; Entrambi funzionano in modo equivalente per il caso d'uso dell'autenticazione di accesso.
La differenza pratica è che OIDC è più semplice da configurare per i provider moderni e restituisce gli attributi direttamente in formato JWT. SAML richiede la mappatura degli attributi in formato di asserzione XML, il che aggiunge attrito nelle configurazioni più complesse, soprattutto quando si desidera passare attributi personalizzati dall'IdP da utilizzare nelle policy. Per le nuove integrazioni con Okta o Azure AD, OIDC è il percorso di minor resistenza.
Più provider di identità contemporaneamente
Una funzionalità di accesso che passa inosservata nei progetti iniziali: la stessa organizzazione può avere più provider configurati e assegnare diversi provider a diverse applicazioni. Un'applicazione accetta l'autenticazione tramite Google Workspace per i dipendenti e tramite GitHub per i collaboratori esterni. Un altro si limita esclusivamente alla Okta aziendale. Un terzo visualizza il menu di scelta affinché l'utente possa selezionare quale fornitore utilizzare.
Ciò risolve lo scenario frequente di aziende con dipendenti in diverse società partner, ciascuna con il proprio Azure AD o Google Workspace. Invece di creare account ospite su tutti i fornitori, Access accetta più fornitori con politiche diverse per fornitore. Il limite pratico non è tecnico, ma gestionale: ogni provider aggiuntivo è un punto di configurazione da mantenere e un vettore di accesso da monitorare.
Sincronizzazione di gruppi e autorizzazioni
Le policy di accesso che fanno riferimento ai gruppi ottengono l'appartenenza direttamente dall'IdP al momento dell'autenticazione. Una policy "allow: group engineering" non è un elenco statico in Cloudflare: è un controllo rispetto al gruppo in Okta o Azure AD nel momento in cui arriva il token di autenticazione. Quando un collaboratore viene aggiunto o rimosso dal gruppo sull'IdP, l'effetto è immediato alla successiva autenticazione, senza sincronizzazione manuale sulla piattaforma Cloudflare.
Ciò ha un’importante conseguenza operativa: il processo di offboarding deve rimuovere l’utente dall’IdP, non semplicemente revocare l’accesso a ogni singola applicazione. Se l'utente è disattivato in Okta, tutte le policy di accesso che dipendono da quell'IdP smettono di funzionare per quell'account. La sessione attiva rimane valida fino alla scadenza, il che rafforza l'importanza di configurare durate di sessione appropriate per ogni applicazione.
Durata della sessione e applicazione dell'AMF per applicazione
La durata della sessione è configurata per applicazione in Access, non a livello globale. Per un'applicazione di monitoraggio interno a bassa sensibilità, sette giorni sono ragionevoli. Per l'accesso SSH all'ambiente di produzione, una sessione di un'ora richiede una riautenticazione frequente, riducendo la finestra per un token compromesso. Per un pannello di amministrazione del database, 15 minuti potrebbero essere più appropriati.
L'MFA può essere richiesta a livello di accesso, indipendentemente da ciò che fa l'IdP. Se l'IdP non applica l'MFA per impostazione predefinita, la policy di accesso potrebbe richiedere l'utilizzo dell'autenticazione a secondo fattore: Access reindirizzerà l'utente per completare l'MFA presso l'IdP se il token non include questa garanzia. Applicazioni diverse possono avere requisiti di garanzia dell'autenticazione diversi senza la necessità di configurare più policy MFA sull'IdP.
Token di servizio per l'accesso da macchina a macchina
Pipeline CI/CD, agenti di monitoraggio, webhook: qualsiasi sistema automatizzato che deve accedere a una risorsa protetta da accesso deve affrontare un problema: non esiste un utente umano che possa passare attraverso il flusso SSO. Access risolve questo problema con i token di servizio: una coppia ID client e segreto client che identifica un servizio come entità attendibile.
Il servizio automatizzato include l'ID client nell'intestazione CF-Access-Client-Id e il segreto in CF-Access-Client-Secret. L'accesso riconosce il token del servizio, valuta la policy associata e consente o nega l'accesso, generando un evento di controllo come qualsiasi altro accesso. I token di servizio hanno una data di scadenza configurabile e possono essere revocati individualmente senza influenzare altri token o utenti.
Come strutturare le policy prima di chiamare
L'errore di progettazione più comune quando si adotta Access è la creazione di criteri per applicazione senza un modello gerarchico. Con decine di applicazioni interne, il mantenimento di policy individuali per ciascuna di esse diventa un onere operativo considerevole. L'alternativa è definire gruppi di accesso riutilizzabili - "accesso di base per tutti i dipendenti", "accesso elevato per il team tecnico", "accesso amministrativo per SRE" - e applicarli come blocchi nelle policy individuali di ciascuna applicazione.
La policy di accesso di una nuova applicazione può ereditare un gruppo base e aggiungere condizioni specifiche, come la postura obbligatoria del dispositivo o restrizioni temporali. Quando il team di tecnici cresce e viene creato un nuovo gruppo nell'IdP, l'aggiornamento dei criteri di gruppo riutilizzabile in Access si propaga a tutte le applicazioni che vi fanno riferimento automaticamente.
Cosa è necessario decidere prima della configurazione
L’integrazione tecnica con l’IdP è l’ultima delle sfide. Il più grande è documentare le decisioni politiche e la loro logica prima di consentire l'accesso in produzione. Quali applicazioni hanno accesso automatico per tutti i dipendenti? Quali richiedono l'approvazione esplicita del gruppo? Come vengono trattati i dipendenti esterni delle aziende partner? Chi mantiene i gruppi nell'IdP allineati alle policy di accesso?
Queste domande non hanno una risposta tecnica: sono decisioni che il team di sicurezza e il team di prodotto devono prendere insieme. I team che arrivano alla configurazione tecnica senza aver risposto a queste domande spesso si ritrovano con policy molto permissive che replicano il problema della VPN con un livello di autenticazione in cima.