Integrazione SSO automatica: come funziona end to end

Distribuire un programma di Cybersecurity awareness a diecimila collaboratori porta con sé un costo che quasi nessuno mette sul tavolo all’inizio: creare e mantenere diecimila account. Ogni assunzione, ogni uscita, ogni cambio di reparto è un utente in più da configurare su una piattaforma in più, con una password in più che il collaboratore dimenticherà. Il login sembra un dettaglio secondario finché non lo si moltiplica per l’organico di un grande gruppo, e a quel punto smette di esserlo.

L’SSO elimina questo attrito, ma di solito viene venduto come una casella da spuntare (“ha l’SSO? sì”) senza spiegare cosa succede davvero tra il momento in cui il collaboratore fa click e quello in cui entra nel programma. Quel “cosa succede davvero” è ciò che decide se l’integrazione si risolve in un pomeriggio o diventa un progetto di settimane. Il DBIR di Verizon colloca anno dopo anno le credenziali rubate tra i principali vettori di accesso iniziale alle organizzazioni, quindi ridurre il numero di password che ogni collaboratore gestisce non è solo comodità, ma superficie di attacco che si riduce.

Cosa risolve l’SSO (e cosa no) in una piattaforma di awareness

Il single sign-on (SSO) è il meccanismo attraverso cui un collaboratore accede alla piattaforma con le stesse credenziali aziendali che già usa per gli altri strumenti, senza creare né ricordare un nome utente e una password propri della piattaforma. L’autenticazione non la risolve la piattaforma: la delega all’identity provider (IdP) dell’organizzazione, che sa già chi è quella persona.

È esattamente questo ciò che risolve, e conviene essere precisi sul confine. L’SSO risponde alla domanda ”questa persona è chi dice di essere?” nel momento dell’accesso. Non risponde a ”questa persona dovrebbe esistere nella piattaforma?”. Questa seconda domanda (la creazione, la disattivazione e l’aggiornamento degli account) è il provisioning, ed è un problema diverso che si risolve con un altro pezzo. Confondere i due è la causa più comune per cui un deployment “con SSO” continua a nascondere lavoro manuale.

Come funziona il flusso di autenticazione SSO end to end?

Lo standard alla base della maggior parte di queste integrazioni è SAML 2.0. In SAML ci sono due attori: l’identity provider (IdP), ovvero il sistema aziendale dove vive l’identità del collaboratore, e il service provider (SP), che in questo caso è la piattaforma di awareness. Il flusso end to end, quando il collaboratore parte dalla piattaforma, è questo:

1. Il collaboratore entra nella piattaforma e questa rileva che non c’è una sessione attiva.
2. La piattaforma (SP) reindirizza il browser all’IdP aziendale con una richiesta di autenticazione firmata.
3. L’IdP autentica il collaboratore con le proprie regole: password, secondo fattore, criteri di accesso condizionale, qualsiasi cosa l’organizzazione abbia configurato.
4. Se l’autenticazione è valida, l’IdP restituisce al browser un’asserzione SAML firmata, un documento che afferma “questa persona è chi dice di essere, e questi sono i suoi attributi”.
5. La piattaforma valida la firma di quell’asserzione rispetto al certificato dell’IdP, legge gli attributi e apre la sessione.

Il collaboratore vede una cosa sola: fa click ed entra. Tutto lo scambio della richiesta, dell’asserzione e della validazione della firma avviene in millisecondi e senza che debba digitare nulla. L’altro punto di partenza possibile è l’inverso, quando il collaboratore parte dal portale aziendale (IdP-initiated) e da lì salta alla piattaforma già autenticato, ma la meccanica dell’asserzione firmata è la stessa.

Ciò che conta per chi valuta la piattaforma è che la fiducia non si appoggia su una password condivisa tra due sistemi, ma sulla crittografia: l’SP si fida dell’IdP perché può verificarne la firma, non perché custodisce un segreto. È questa la ragione per cui l’SSO è più sicuro che replicare le password, ed è la stessa logica di delegare al sistema giusto che applichiamo quando spieghiamo perché ci integriamo via API e non via agente.

SSO e provisioning degli utenti sono la stessa cosa?

No, e tenerli distinti è ciò che permette al programma di scalare senza lavoro manuale. L’SSO autentica; il provisioning crea, aggiorna e disattiva gli account. Un collaboratore può autenticarsi via SSO solo se il suo account esiste già nella piattaforma, quindi il provisioning è il passo precedente da risolvere a parte.

Il provisioning si risolve in due modi senza inserire gli account a mano, e non sono equivalenti. Quello che sostiene il programma nel tempo è la sincronizzazione dalla directory: la piattaforma si connette alla directory aziendale, tramite LDAP oppure importando da Microsoft Entra ID o Google, e mantiene l’elenco dei collaboratori allineato alla fonte di verità dell’organizzazione. Quando qualcuno entra o esce dall’azienda, il cambiamento si propaga senza che il responsabile del programma debba toccare nulla.

L’altra opzione, più semplice da avviare, è importare l’elenco manualmente da un file CSV, quando non si vuole collegare l’intera directory. Funziona per il primo avvio, ma è una fotografia di un momento e non riflette gli ingressi né le uscite successive. La disattivazione, inoltre, è il caso più importante dal punto di vista della cybersecurity: un collaboratore che ha lasciato l’azienda ma ha ancora un account attivo è una falla.

Per questo il provisioning basato sulla directory, dove la disattivazione del collaboratore nel sistema aziendale trascina il suo stato nella piattaforma, è quello che chiude la falla alla radice. È lo stesso principio della fonte di verità unica per l’elenco che sta dietro a come funziona la sincronizzazione della directory con Microsoft Entra ID (ex Azure AD).

Cosa rende un’integrazione SSO “automatica” e non un progetto di settimane?

La differenza tra un’integrazione di un pomeriggio e una che dura settimane non sta nello standard (SAML è lo stesso per tutti) ma in quanta parte del montaggio dipende dallo scambio manuale di file di configurazione. Un’integrazione automatica riduce quel montaggio a tre cose risolte in modo pulito:

1. Scambio di metadata invece di configurazione manuale. L’IdP e la piattaforma si descrivono a vicenda con un file di metadata standard (URL, certificati, identificatori). Caricare quei metadata da una parte all’altra sostituisce il copia-incolla di campi singoli, che è dove compaiono gli errori difficili da diagnosticare.
2. Mappatura esplicita degli attributi. L’asserzione dell’IdP porta con sé attributi (nome, email, reparto, magari il Paese della filiale) e la piattaforma deve sapere a quale campo va ciascuno. Definire quella mappatura una volta, con criterio, è ciò che evita di doverla ritoccare ogni volta che entra un nuovo collaboratore.
3. Un IdP per tenant quando ci sono più organizzazioni. In un gruppo con filiali, ciascuna può avere il proprio identity provider. Un’architettura multi-tenant permette a ogni filiale di connettere il suo IdP senza pestare i piedi alle altre, cosa che diventa necessaria quando si sostiene un programma multilingua con HQ in Spagna e filiali in America Latina.

Quando queste tre cose sono risolte, aggiungere l’SSO smette di essere una milestone di progetto e diventa un passo di configurazione. Il collaboratore non vede nulla di tutto ciò, che è esattamente l’obiettivo.

Come si inserisce l’SSO nell’architettura di SMARTFENSE?

SMARTFENSE risolve l’autenticazione delegandola all’identity provider di ogni organizzazione. La piattaforma supporta l’autenticazione universale via SAML 2.0, che le permette di integrarsi con qualsiasi IdP che parli lo standard, e inoltre importa e autentica i collaboratori direttamente da Microsoft Entra ID e Google, e ammette l’autenticazione da Auth0. Il provisioning è coperto dall’altro binario: sincronizzazione degli utenti tramite directory LDAP e importazione dagli stessi provider, in modo che l’elenco dei collaboratori resti allineato alla fonte di verità dell’organizzazione.

Per i casi che devono andare oltre ciò che risolve la configurazione (automatizzare assunzioni e uscite con logica propria, o collegare l’elenco a un altro sistema interno), la piattaforma espone una API REST documentata con OAuth 2.0 e JSON per la gestione degli utenti e dei risultati. L’elenco completo di queste integrazioni di identità e directory è nella pagina delle integrazioni della piattaforma, e come si gestiscono i collaboratori una volta dentro si vede in utenti e gruppi intelligenti.

Il risultato, visto dall’operatività del programma, è che il team responsabile non amministra password né inserisce account a mano: l’identità la risolve il sistema che già la possedeva, e la piattaforma si occupa del suo compito, che è misurare e cambiare il comportamento delle persone.

Domande frequenti

SSO significa che SMARTFENSE conserva le password dei miei collaboratori?
No. Con l’SSO la piattaforma non vede né archivia mai la password aziendale. L’autenticazione avviene nell’identity provider dell’organizzazione, che restituisce un’asserzione firmata; la piattaforma verifica solo quella firma per aprire la sessione.

Posso usare l’SSO senza sincronizzare tutta la mia directory?
Sì. L’autenticazione via SSO e il provisioning degli account sono pezzi indipendenti. Si può autenticare via SAML e caricare l’elenco importandolo da un file CSV, oppure sincronizzare la directory via LDAP per mantenere allineate assunzioni e uscite. Sono decisioni separate.

Cosa succede quando un collaboratore lascia l’azienda?
Se il provisioning è basato sulla directory, la disattivazione del collaboratore nel sistema aziendale si propaga alla piattaforma e il suo accesso si chiude senza intervento manuale. È il punto che più conviene risolvere tramite sincronizzazione e non con la creazione di account al volo.

L’SSO serve per un gruppo con più filiali?
Sì. Un’architettura multi-tenant permette a ogni filiale di connettere il proprio identity provider in modo indipendente, mantenendo il programma unificato a livello di gruppo ma con l’autenticazione di ciascuna organizzazione risolta separatamente.

Quanto dura un’integrazione SSO?
Dipende dal fatto che il montaggio si appoggi sullo scambio di metadata e su una mappatura degli attributi definita una volta, oppure sulla configurazione manuale campo per campo. Col primo, aggiungere l’SSO è un passo di configurazione; col secondo, si allunga a causa degli errori difficili da diagnosticare.

Se stai valutando come portare il tuo programma di Cybersecurity awareness a tutta l’organizzazione senza aggiungere un’altra password né inserire account a mano, la piattaforma di SMARTFENSE risolve autenticazione e provisioning appoggiandosi all’identità che la tua organizzazione già amministra.