SSO spiegato: Enterprise Identity e WiFi senza password

Entro il 2021, il governo del Regno Unito contava circa 121 soluzioni di Single Sign-On distinte, dimostrando perché l'SSO sia molto più di una semplice funzione di comodità. L'SSO rappresenta il consolidamento federato dell'identità: centralizza l'autenticazione tramite un provider di identità attendibile, consentendo al contempo a ciascuna applicazione di mantenere il controllo su ciò che un utente autenticato è autorizzato a fare.

Potresti riconoscere questo problema in una normale giornata lavorativa. Un dipendente ha bisogno dell'email, di un'applicazione cloud, di un sistema di gestione immobiliare, del WiFi interno e di un portale amministrativo. Ogni servizio ha i propri dati di accesso, criteri per le password e proprietario dell'account. Quando qualcuno entra in azienda, cambia ruolo o lascia l'organizzazione, gli amministratori devono aggiornare diversi sistemi e gli utenti devono ricordare quali credenziali appartengono a quale servizio.

Questo è il motivo pratico per cui le organizzazioni cercano SSO spiegato. La questione non è solo come ridurre il numero di schermate di login. Si tratta di come creare un piano di controllo dell'identità affidabile senza indebolire i permessi a livello di applicazione o introdurre un bersaglio centrale più pericoloso.

Perché un'identità frammentata crea reali problemi di accesso

L'esperienza del governo del Regno Unito offre un utile punto di partenza. Una revisione dello standard di servizio GOV.UK del 2021 ha stimato che l'amministrazione centrale disponesse di circa 121 diverse soluzioni SSO, poiché i team di servizio avevano creato sistemi di autenticazione separati invece di utilizzare un'unica piattaforma di identità condivisa a livello governativo. Le persone che utilizzavano più servizi pubblici potevano quindi possedere diversi set di credenziali di accesso e rischiavano di non sapere quale account fosse richiesto per una specifica operazione. (Revisione dell'autenticazione e dell'identità digitale del governo del Regno Unito)

L'insegnamento non è che i sistemi governativi siano unicamente complessi. Grandi aziende, organizzazioni sanitarie, gruppi dell'accoglienza, operatori immobiliari e reti del settore pubblico affrontano la stessa situazione. Ogni applicazione può creare un silo di identità, e ogni silo può sviluppare le proprie regole per le password, processi di recupero, modelli di gruppo e flussi di lavoro per la disattivazione degli utenti.

Autenticazione e autorizzazione sono attività diverse

L'autenticazione risponde alla domanda: "Chi sei?". L'autorizzazione risponde alla domanda: "A cosa puoi accedere qui?". L'SSO consolida la prima domanda attraverso un identity provider affidabile. L'applicazione di destinazione decide comunque se tale identità può visualizzare i record, amministrare un sistema, accedere a un segmento di rete o utilizzare una funzione specifica.

Un modello concettuale utile si presenta così:

Utente
  |
  | si autentica una sola volta
  v
Provider di identità
  |
  | invia informazioni di identità attendibili
  v
Applicazione o rete
  |
  | applica le autorizzazioni locali
  v
Sessione autorizzata

Questa distinzione è fondamentale durante i processi di inserimento, spostamento e uscita del personale. Un'identità centrale può essere disabilitata quando una persona lascia l'azienda, mentre ogni servizio connesso richiede comunque un modello di autorizzazione chiaro e un metodo affidabile per rimuovere i diritti di accesso.

Regola pratica: Considera l'SSO come un modo per controllare l'identità in modo centralizzato, non come un sostituto per le autorizzazioni delle applicazioni.

Lo stesso principio si applica quando si progetta la distribuzione via cavo e wireless. L'accesso alla rete fa parte dell'infrastruttura di identità, quindi i team dovrebbero decidere quali gruppi di directory possono accedere a quali ruoli di rete, anziché associare l'accesso a una password condivisa.

Per la rete WiFi aziendale e l'accesso basato sull'identità, le soluzioni per la rete basata sull'identità di Purple mostrano come le policy di rete possano essere collegate alla singola identità anziché a una credenziale condivisa. Il risultato è una relazione più chiara tra una persona, il suo stato nella directory e l'accesso che riceve.

Come funziona il Single Sign-On nella federazione aziendale

In una federazione enterprise, un identity provider, una relying party e un messaggio di identità firmato svolgono compiti distinti. L'identity provider autentica l'utente, mentre la relying party, come un'applicazione o un servizio di rete, verifica le informazioni di identità risultanti.

L'autenticazione può utilizzare una password, un'autenticazione a più fattori, condizioni del dispositivo o un altro metodo approvato. L'provider emette quindi un'asserzione o un token firmato per il servizio richiesto. Il servizio valida quel messaggio e crea la propria sessione, in modo che le credenziali rimangano presso l'identity provider.

Il flusso di federazione

1. L'utente richiede un servizio. Apre un'applicazione, un portale amministrativo o un servizio di rete protetto.
2. Il servizio verifica la presenza di una sessione esistente. In mancanza di essa, reindirizza l'utente al provider di identità.
3. Il provider di identità autentica l'utente. Applica i controlli configurati, come l'MFA o l'accesso condizionale.
4. Il provider di identità emette un messaggio firmato. L'integrazione utilizza comunemente un'asserzione SAML o un token OpenID Connect.
5. Il servizio convalida il messaggio. Verifica l'emittente, la firma, il destinatario, la scadenza e le attestazioni pertinenti.
6. L'applicazione crea la propria sessione. Mappa l'identità verificata sulle autorizzazioni locali e registra l'evento di autenticazione.

La convalida protegge il rapporto di fiducia. Il National Cyber Security Centre del Regno Unito raccomanda di verificare le asserzioni SAML ricevute su reti non attendibili rispetto all'autorità di certificazione prevista. Un'asserzione non verificata può offrire un percorso di compromissione dell'account attraverso una connessione fidata con il provider di identità. (Linee guida NCSC sulla gestione delle identità e degli accessi)

Una verifica dell'identità valida concede un'identità autenticata, non tutti i permessi all'interno del servizio di destinazione. L'applicazione dovrebbe utilizzare solo i claim richiesti per l'autorizzazione, per poi applicare le proprie regole sui ruoli e sulle risorse. Questa separazione consente inoltre allo stesso modello di federazione di supportare applicazioni per i dipendenti, portali amministrativi e servizi di rete basati sull'identità.

SAML, OIDC e OAuth in ambito enterprise

Una volta chiarito il modello di federazione, la selezione del protocollo diventa più semplice. SAML e OpenID Connect sono standard comuni per l'SSO enterprise, mentre OAuth è principalmente un framework di autorizzazione per l'accesso delegato alle API. Confondere OAuth con l'autenticazione può portare i team a creare un flusso di identità che non risponde alle proprie esigenze di sicurezza.

Standard	Ruolo pratico	Applicazione tipica
SAML	Scambia asserzioni d'identità firmate	Applicazioni enterprise consolidate e basate su browser
OpenID Connect	Aggiunge un livello d'identità utilizzando token	SaaS moderni, servizi orientati al web e al mobile
OAuth	Delega l'accesso a risorse protette	Accesso API per conto di un utente o servizio

SAML viene spesso utilizzato nei software enterprise maturi perché adotta un modello di federazione tramite browser ben consolidato. OIDC è generalmente più naturale per i servizi moderni progettati attorno a JSON, REST e interazioni basate su token. La scelta corretta dipende da ciò che l'applicazione supporta e da come il servizio valida le informazioni di identità.

Cosa deve verificare il servizio

A prescindere dallo standard, la relying party deve convalidare il materiale di identità ricevuto prima di creare una sessione. Le verifiche fondamentali includono:

• Emittente: Conferma che il messaggio provenga dal provider di identità previsto.
• Firma: Verifica che il messaggio sia stato firmato dalla chiave o dal certificato convalidato.
• Destinatario (Audience): Controlla che il messaggio sia stato predisposto per questo servizio.
• Scadenza: Rifiuta asserzioni o token obsoleti.
• Claim: Utilizza solo informazioni di gruppo e identità rilevanti e convalidate.

Il provider di identità può centralizzare i criteri come MFA, accesso condizionale, blocco delle password e appartenenza ai gruppi. L'applicazione riceve quindi i claim necessari per la propria decisione di autorizzazione, piuttosto che mantenere una copia completa del processo di autenticazione dell'utente.

Questa separazione è utile quando si integrano piattaforme come Microsoft Entra ID, Okta o Google Workspace. Il provider gestisce le policy di autenticazione, mentre l'applicazione connessa rimane responsabile del proprio modello di accesso e dei controlli di sessione. Per i gestori di rete che valutano l'integrazione con Okta per l'accesso basato su RADIUS, si applica lo stesso principio: la convalida dell'identità e l'autorizzazione di rete devono funzionare insieme, ma non costituiscono lo stesso controllo.

Il rischio di concentrazione introdotto dall'SSO

Un singolo account compromesso presso il provider di identità può aprire contemporaneamente l'accesso a diversi servizi collegati. L'SSO riduce la proliferazione delle password, ma al contempo concentra la fiducia nel provider di identità, rendendolo un piano di controllo ad alto valore. Le organizzazioni devono quindi valutare in che modo la federazione influisce sul raggio d'azione dell'impatto (blast radius) e sulle opzioni di ripristino. Le linee guida NCSC sulla scelta dei metodi di autenticazione evidenziano questa concentrazione della fiducia come un rischio che richiede una valutazione mirata.

L'SSO consolida gli eventi di accesso. La resistenza al phishing, la disponibilità dei dispositivi e l'accesso con privilegio minimo devono derivare dai controlli integrati nell'architettura di federazione. Una progettazione solida protegge il provider, le sessioni create e i processi di ripristino che possono ripristinare l'accesso.

Creare livelli di protezione attorno al provider

I controlli dovrebbero coprire l'accesso di routine e i percorsi meno visibili utilizzati durante il recupero dell'account:

• MFA solida per gli utenti con privilegi: Utilizza metodi resistenti al phishing dove l'ambiente lo supporta, in particolare per gli amministratori.
• Accesso condizionale: Valuta lo stato del dispositivo, la posizione, il rischio della sessione e altri segnali disponibili prima di concedere l'accesso.
• Identità amministrative separate: Mantieni l'amministrazione con privilegi separata dalle normali attività quotidiane.
• Monitoraggio dell'autenticazione: Indaga su spostamenti impossibili, indicatori di token replay, errori ripetuti ed escalation inaspettate dei privilegi.
• Protezione del ripristino: Tratta i reset dell'help desk e gli account di emergenza come operazioni di identità sensibili, soggette ad approvazione e monitoraggio.

Il NCSC raccomanda di combinare l'SSO enterprise con una forte autenticazione di utenti e dispositivi, inclusi MFA o accesso condizionale. Raccomanda inoltre l'SSO per il SaaS, poiché i controlli centralizzati rendono la gestione di utenti e gruppi più coerente e impediscono la sincronizzazione delle credenziali in ogni applicazione. Il suo principio di sicurezza cloud sull'identità e l'autenticazione illustra questo approccio.

L'SSO riduce il numero di credenziali da gestire. Al contempo, rende le credenziali e le sessioni che governano i servizi collegati elementi che richiedono una protezione solida.

I team di rete devono separare l'identità del personale da quella degli ospiti. Una federazione del personale può supportare l'accesso con privilegio minimo e la revoca immediata. L'autenticazione degli ospiti non deve ereditare i privilegi della directory dei dipendenti solo perché entrambi i flussi utilizzano un Captive Portal o un'infrastruttura wireless.

WiFi senza password e accesso alla rete basato su directory

Un membro del personale che si connette al WiFi non dovrebbe aver bisogno di una password condivisa che rimane valida anche dopo la sua uscita dall'azienda. Un'architettura basata su directory inizia con l'autenticazione tramite il provider di identità dell'organizzazione, per poi mappare l'identità o il gruppo verificato a un ruolo di rete. Di conseguenza, il servizio wireless applica le stesse decisioni di impiego e di accesso utilizzate altrove, anziché mantenere un elenco separato di password WiFi.

Purple supporta questo modello per il WiFi enterprise tramite integrazioni con Microsoft Entra ID, Google Workspace e Okta. Il suo approccio al WiFi passwordless evita l'uso di credenziali condivise e la gestione RADIUS on-premise. Le modifiche alla directory possono attivare il provisioning o la revoca degli accessi. L'appartenenza a un gruppo di un dipendente determina l'accesso alla rete, mentre la disattivazione dell'account di un utente uscente nella directory consente di rimuovere tale accesso senza attendere che qualcuno modifichi una password comune.

Applicare i controlli di federazione alla rete

Il provider di identità, i criteri di rete e il monitoraggio dovrebbero concordare sulla stessa decisione di accesso. Mappa i gruppi della directory su ruoli di rete distinti, in modo che personale, fornitori esterni e amministratori non ricevano gli stessi accessi per impostazione predefinita. Mantieni brevi le durate delle asserzioni o dei token, limitando l'utilità del materiale di identità obsoleto. Richiedi l'MFA presso il provider di identità, poiché lo SSO wireless non diventa MFA per il solo fatto di utilizzare lo SSO.

Registra gli eventi di autenticazione riusciti e falliti e collega ogni decisione sull'identità con la relativa autorizzazione di rete. Verifica il rinnovo dei certificati prima della scadenza, poiché i problemi nei trust di federazione possono interrompere un accesso WiFi altrimenti regolare.

Le sedi multi-tenant richiedono un perimetro separato. Gli immobili residenziali, gli alloggi universitari, gli hotel e le strutture ad uso misto possono offrire un accesso semplice a residenti o ospiti, isolando al contempo il traffico dei tenant e i sistemi del personale. L'iPSK può supportare i dispositivi legacy, mentre l'SSO aziendale fornisce un percorso di identità distinto per il personale.

Il WiFi per ospiti comporta anche decisioni in materia di consenso, conservazione e profili cliente. Questa guida ai dati degli ospiti per le strutture offre un utile riferimento da affiancare alla progettazione della rete, mentre Purple connette l'autenticazione basata sull'identità con l'esperienza di accesso wireless.

Risultati misurabili per aziende e location nel Regno Unito

Un business case pratico per l'SSO inizia con le credenziali che un'organizzazione non ha più bisogno di amministrare. Un'indagine dell'Institution of Engineering and Technology di aprile 2024 condotta su 2.000 residenti nel Regno Unito dai 16 anni in su ha rilevato che solo il 20% era in grado di identificare correttamente una password sicura. La stessa indagine ha riportato che un quinto riutilizzava una password su più siti web o dispositivi, mentre il 21% utilizzava una data significativa e il 20% il nome di un animale domestico. È emerso inoltre che il 38% riteneva che sostituire le lettere con i numeri migliorasse la sicurezza della password, il 65% riteneva che le password non dovessero mai essere scritte, e il 77% pensava che modifiche frequenti della password aumentassero la sicurezza. (Indagine IET sulla sicurezza delle password)

Questi risultati mostrano i limiti del richiedere agli utenti di creare e ricordare credenziali separate per ogni applicazione e rete. L'identità centralizzata modifica il punto in cui l'organizzazione applica i controlli e la rapidità con cui gli amministratori possono intervenire, anche se il phishing e la compromissione degli account rimangono rischi reali.

Per un operatore, i risultati sono pratici:

• Meno credenziali non gestite: Gli utenti creano, ricordano e riutilizzano un numero inferiore di password distinte per le applicazioni.
• Criteri coerenti: Il provider di identità può applicare MFA, accesso condizionale e restrizioni sulle password in tutti i servizi collegati.
• Revoca più rapida: La disabilitazione di un'identità aziendale può diventare l'azione centrale per la rimozione degli accessi, a condizione che i servizi collegati gestiscano correttamente le modifiche al ciclo di vita.
• Tracce di audit più chiare: I log possono collegare l'identità di una persona con le decisioni di autenticazione e autorizzazione di rete.
• Meno duplicazione amministrativa: I team mantengono i criteri di identità in modo centralizzato anziché ricreare controlli equivalenti in ogni servizio.

Il valore va oltre la semplice riduzione delle richieste di accesso. Un operatore sanitario può assegnare gli accessi in base al ruolo, un gruppo alberghiero può separare i servizi per il personale da quelli per gli ospiti e un gestore immobiliare può mantenere una proprietà più chiara delle credenziali di inquilini e collaboratori. In ciascun caso, il risultato misurabile è un parco credenziali più ridotto, una gestione dei dipendenti in uscita più affidabile e una prova più solida di chi ha ricevuto l'accesso a un'applicazione o a un ruolo di rete.

Implementare l'SSO senza creare nuovi rischi

Un'implementazione sicura parte dal modello di identità, non dal pulsante di login. Scegli SAML o OIDC dove si adattano all'applicazione, anziché copiare le password in un'applicazione o in una piattaforma di rete. Stabilisci il provider di identità come autorità di autenticazione, quindi fai in modo che ogni servizio connesso convalidi emittente, firma, audience, scadenza e claim prima di creare una sessione.

Utilizzare una lista di controllo operativa

• Inizia con gruppi autorevoli: Disponi l'accesso dai gruppi di directory gestiti dal team aziendale o IT di competenza.
• Definisci le regole di cambio ruolo: Una modifica di ruolo deve rimuovere i vecchi diritti oltre ad aggiungere quelli nuovi.
• Gestisci chi lascia l'azienda in modo centralizzato: Disabilita l'identità organizzativa e verifica che le applicazioni collegate e i ruoli di rete rispondano correttamente.
• Proteggi gli accessi di emergenza: Mantieni gli account di emergenza separati dalla normale amministrazione, monitorali da vicino e testa il loro processo di ripristino.
• Separa il personale dagli ospiti: L'SSO della forza lavoro può supportare l'accesso con privilegio minimo e la revoca. L'autenticazione degli ospiti non deve ereditare i permessi dei dipendenti.
• Testa le modifiche di trust: Valida il rollover dei certificati, la scadenza dei token, la terminazione delle sessioni e le interruzioni del provider prima di fare affidamento sulla produzione.
• Rivedi il monitoraggio: Conferma che gli eventi di autenticazione, le azioni amministrative e le decisioni di autorizzazione di rete siano disponibili per le indagini.

Una struttura potrebbe anche aver bisogno di supportare diversi vendor di rete anziché sostituire la propria infrastruttura wireless esistente. Purple è progettato per funzionare con Meraki, Aruba, Ruckus, Mist e UniFi, e il suo modello di implementazione dichiarato si misura in settimane anziché mesi. È bene considerare queste funzionalità come fattori di implementazione, non come sostituti di una revisione dell'architettura. Per una panoramica più ampia su come i fornitori di tecnologia descrivono le garanzie di sicurezza, la pagina trust e controlli di AdManage.ai offre un valido punto di confronto.

La decisione fondamentale è se l'organizzazione sia in grado di spiegare, per ogni servizio connesso, chi autentica l'utente, quali claim sono ritenuti affidabili, come vengono assegnati i permessi e cosa succede quando l'identità cambia. L'SSO è solo un livello all'interno di un programma di gestione delle identità e degli accessi (IAM). Non sostituisce l'MFA, l'accesso condizionale, il monitoraggio dell'autenticazione, i controlli di ripristino o la governance del ciclo di vita.

---

Purple connette l'identità aziendale con il WiFi senza password, i ruoli di rete basati su directory e l'accesso ospiti separato, supportando integrazioni con Microsoft Entra ID, Google Workspace e Okta. Visita Purple per valutare come il suo modello di rete basato sull'identità possa integrarsi nell'ambiente wireless esistente e nella distribuzione dell'SSO.