Come abilitare il Single Sign On

Il lunedì mattina inizia prima dell'arrivo degli ospiti. Al cambio turno di un hotel, il team notturno esce, arriva il team diurno e tre laptop del personale rimangono bloccati sul Captive Portal perché qualcuno ha cambiato la password del WiFi condiviso e ha dimenticato di aggiornare la lavagna del retroufficio. Un dipendente cerca un vecchio ticket, un altro chiede a un supervisore e il terzo si arrende e utilizza un hotspot personale.

Questo non è un problema di copertura WiFi. È un problema di identità. Il Single sign-on, o SSO, consente al personale di autenticarsi con la propria identità aziendale esistente e accedere alla rete del personale senza che venga richiesta un'altra password condivisa. Questa guida spiega come abilitare il single sign-on su un SSID per il personale gestito da Purple, scegliere l'identity provider corretto, configurare la federazione, testare il risultato e proteggere il rollout in caso di problemi.

Perché le reti del personale hanno bisogno del Single Sign-On

Le chiavi pre-condivise falliscono in modi prevedibili. Lo staff le scrive sui post-it, le incolla nei sistemi di ticketing, le ripete via radio e continua a usarle anche dopo aver lasciato l'azienda. Una sede potrebbe cambiare la chiave per risolvere un singolo problema di accesso, solo per creare una nuova coda di richieste di login al cambio di turno successivo.

Il costo operativo si manifesta in piccole interruzioni. Un addetto alla reception attende un ripristino durante il check-in, un infermiere perde tempo a riconnettere una workstation e un supervisore del punto vendita chiama l'helpdesk perché un dispositivo palmare non si connette allo SSID del personale. Questi ritardi sono difficili da misurare singolarmente, ma si ripresentano ogni volta che la rete tratta un'intera forza lavoro come un unico account.

Il Single Sign-On (SSO) cambia l'unità di accesso dalla password condivisa all'identità individuale. Un dipendente accede tramite l'identity provider dell'organizzazione e la rete applica la policy di accesso associata a quella persona o al suo gruppo. Quando il dipendente cambia reparto, la sua appartenenza al gruppo può cambiare con lui. Quando lascia l'azienda, la disattivazione dell'account di directory può rimuovere l'accesso senza dover modificare una password utilizzata da tutti gli altri.

Per le organizzazioni del settore pubblico del Regno Unito, il problema della frammentazione è già visibile su scala nazionale. Le linee guida sull'autenticazione e l'identità digitale di GOV.UK hanno registrato circa 121 soluzioni di single sign-on in tutto il governo nel 2021, insieme a circa 191 metodi di configurazione dell'account e 44 metodi di accesso. GOV.UK One Login è stato creato come livello di autenticazione comune e lo stesso aggiornamento ha riportato che è stato utilizzato da oltre 1,5 milioni di persone per dimostrare la propria identità entro luglio 2023, mentre l'app associata è stata scaricata 2 milioni di volte.

Cosa dovrebbe imporre l'SSID del personale

Una rete per il personale gestita da Purple offre alla sede un luogo pratico per collegare l'identità di lavoro con l'accesso wireless. L'approccio al networking basato sull'identità separa l'accesso del personale da quello degli ospiti e consente alla policy di rete di seguire l'identità autenticata anziché una credenziale stampata su una bacheca.

Questo è importante per ragioni che vanno ben oltre la semplice comodità:

• Passaggio di consegne: I dipendenti possono utilizzare le proprie credenziali di lavoro invece di chiedere una chiave al turno precedente.
• Offboarding: La disattivazione nella directory può rimuovere l'accesso senza costringere ogni collega a riconnettersi.
• Verificabilità: Gli eventi di rete possono essere associati a persone o gruppi anziché a una PSK anonima.
• Segmentazione: I gruppi possono essere mappati su SSID del personale, VLAN o policy del Captive Portal appropriate al loro ruolo.
• Igiene di conformità: È meno probabile che credenziali sensibili appaiano nei ticket dell'helpdesk o nei documenti condivisi.

L'SSO non elimina la necessità di un design wireless resiliente, della gestione dei dispositivi o di controlli di accesso sensati. Elimina la trappola delle credenziali condivise, che di solito è la via più rapida per rendere gestibile il WiFi del personale.

Flussi di autenticazione che alimentano l'SSO del personale

Il flusso scelto dipende dal luogo in cui avviene l'autenticazione e da ciò che l'apparecchiatura di rete è in grado di comprendere. L'identity provider può emettere l'asserzione, ma un access point ha comunque bisogno di un meccanismo per decidere se un dispositivo può connettersi all'SSID.

SAML 2.0 è il cavallo di battaglia aziendale più comune. Entra ID e Okta possono emettere un'asserzione firmata contenente un identificatore stabile, un indirizzo email e informazioni sul gruppo. Il fornitore di servizi convalida tale asserzione e crea la sessione autenticata. SAML si adatta alle organizzazioni che già lo utilizzano per le applicazioni SaaS e desiderano che un'unica directory rimanga l'unica fonte di verità.

OpenID Connect, o OIDC, utilizza moderni token basati su JSON. Si adatta particolarmente bene a Google Workspace e alle applicazioni più recenti, e la sua struttura di token può essere più facile da ispezionare durante la risoluzione dei problemi. Le piattaforme wireless più vecchie non sempre supportano direttamente OIDC, quindi il flusso potrebbe richiedere comunque un broker o un gateway prima che l'access point possa applicare la decisione.

RADIUS rimane il ponte tra l'identità e il WiFi aziendale. Un autenticatore 802.1X, normalmente l'access point o il controller wireless, invia richieste di autenticazione a un servizio RADIUS. Tale servizio può essere Cloud RADIUS, Microsoft NPS, un server RADIUS on-premises o un provider gestito. Anche quando l'utente parte da un identity provider SAML, RADIUS si colloca comunemente tra il sistema di identità e l'infrastruttura wireless.

L'autenticazione basata su certificato utilizza un certificato della macchina, e talvolta un certificato utente, per stabilire una connessione ad alta affidabilità. Ospedali, laboratori e ambienti di trading potrebbero preferire questo approccio per i dispositivi gestiti perché il certificato viene emesso dalla policy del dispositivo anziché essere digitato da un dipendente. Richiede una maggiore preparazione, in particolare per quanto riguarda la registrazione, il rinnovo e la revoca del certificato, ma riduce la dipendenza dall'inserimento interattivo della password.

I flussi di autenticazione SSO del personale a colpo d'occhio

Flusso	Ideale per	IdP tipico	UX del Personale
SAML 2.0	Federazione aziendale e accesso basato sui gruppi	Microsoft Entra ID o Okta	Accesso tramite browser, seguito da una sessione autenticata
OIDC	Applicazioni moderne e integrazioni basate su JSON	Google Workspace o un IdP compatibile con OIDC	Autenticazione web familiare con federazione basata su token
RADIUS	Accesso wireless 802.1X e apparecchiature di rete legacy	Cloud RADIUS, NPS o un provider gestito	Il dispositivo si connette al SSID dopo l'autenticazione di rete
Autenticazione basata su certificati	Dispositivi gestiti e ambienti ad alta affidabilità	PKI aziendale con integrazione di directory	In genere invisibile all'utente dopo la registrazione del certificato

Un SSID Purple per il personale può unire questi livelli. L'IdP stabilisce l'identità, RADIUS gestisce l'autenticazione di rete laddove richiesto, l'access point applica il risultato e la dashboard di Purple offre agli amministratori una vista operativa dell'evento di accesso. Se la MFA fa parte della progettazione, consideratela come un controllo dell'identità piuttosto che come un sostituto della segmentazione della rete. La panoramica sulla MFA di Networking2000 rappresenta un utile punto di partenza per decidere come inserire un secondo fattore nel flusso SSO.

Regola pratica: Utilizzate SAML quando le vostre applicazioni aziendali dipendono già da esso, OIDC per le moderne integrazioni basate sul web, RADIUS per l'applicazione dello standard 802.1X e i certificati quando il dispositivo stesso deve fornire una prova forte di identità.

Scegliere l'Identity Provider corretto

L'identity provider giusto è solitamente quello che la vostra organizzazione gestisce già con successo. Scegliere da un elenco di funzionalità può produrre un design tecnicamente elegante che i gestori delle sedi non sono in grado di amministrare e che il service desk non comprende.

Microsoft Entra ID si adatta perfettamente agli ambienti basati su Microsoft 365. L'accesso condizionale, i gruppi di directory, il contesto del dispositivo e le competenze amministrative esistenti possono supportare la policy della rete aziendale. Gli ospedali con endpoint gestiti e infrastrutture Microsoft regionali preferiscono spesso mantenere le decisioni di autenticazione all'interno dello stesso piano di controllo dei loro altri servizi per la forza lavoro.

Google Workspace funziona bene quando la directory risiede già in Google e l'azienda desidera evitare l'introduzione di un'ulteriore piattaforma di identità. Hotel, rivenditori e gruppi di hospitality più piccoli che si sono standardizzati su Google troveranno la sua amministrazione familiare e il ciclo di vita degli utenti lineare.

Okta tende a essere ideale per le organizzazioni che necessitano di un ampio livello di federazione tra applicazioni in continua evoluzione, aziende acquisite o directory multiple. Il protocollo SCIM, le regole di gruppo dettagliate e uno scambio pulito di metadati SAML possono contare più di un lungo elenco di funzionalità inutilizzate quando un gruppo alberghiero è in crescita o sta integrando proprietà separate.

Una combinazione Active Directory on-premises e NPS ha ancora il suo scopo. Può essere una scelta sensata dove l'infrastruttura wireless dipende già da 802.1X, la directory è locale, la disponibilità WAN è limitata o l'organizzazione dispone di solide competenze sull'infrastruttura Windows. Questo comporta tuttavia maggiori responsabilità in termini di patching, gestione dei certificati, ridondanza e monitoraggio.

Matrice decisionale dell'IdP per l'SSO del personale Purple

IdP	Punto di forza	A cosa prestare attenzione	Sede tipica
Entra ID	Accesso condizionale, allineamento con Microsoft 365, gestione avanzata dei gruppi	La complessità delle licenze e dei criteri può richiedere un'amministrazione specializzata	Ospedale o struttura multi-regione
Google Workspace	Directory Google esistente, amministrazione familiare, semplice allineamento della forza lavoro	L'autenticazione di rete potrebbe richiedere un livello RADIUS o di federazione aggiuntivo	Hotel o gruppo retail che già utilizza Google
Okta	Federazione flessibile, SCIM, gruppi granulari, supporto per ambienti misti	La struttura del contratto e i costi per utente richiedono un'attenta revisione	Gruppo alberghiero in rapida crescita
Active Directory più NPS	Ideale per ambienti 802.1X consolidati e Windows locali	Maggiore infrastruttura da gestire, proteggere e rendere altamente disponibile	Sito con IT on-premises consolidato

La policy di accesso è il punto in cui la scelta diventa tangibile. Verificate se il provider è in grado di esporre attestazioni di gruppo affidabili, se tali attestazioni possono essere mappate sui ruoli del personale o sulle VLAN, come viene imposta la MFA e con quale rapidità un account disabilitato smette di autenticarsi. Valutate anche se un direttore di sede non IT sia in grado di comprendere le schermate di amministrazione abbastanza bene da gestire un nuovo assunto o un trasferimento di reparto.

Per una panoramica più ampia di come la gestione delle identità e degli accessi influisca sui sistemi aziendali, le risorse IAM di Kushan Business Solutions offrono un contesto utile al di là dell'autenticazione wireless. La raccomandazione pratica rimane semplice: parti dalla realtà della tua directory, non dal catalogo delle funzionalità del provider.

Purple consuma metadati di federazione standard, quindi una modifica dell'IdP non comporta necessariamente il rifacimento della rete wireless. La migrazione esatta richiede comunque dei test, ma la sostituzione della connessione di identità è normalmente un'attività di configurazione controllata. Mantieni documentati la policy di rete, la denominazione dei gruppi e il percorso di fallback prima di cambiare provider. Per i team che necessitano di un livello RADIUS gestito, esamina i provider Cloud RADIUS disponibili insieme alla piattaforma di identità anziché considerare il RADIUS come un aspetto secondario.

Configurazione dell'SSO sulla console Purple e sulla Directory

La federazione ha successo in modo più affidabile quando il provider di identità viene preparato prima che venga creata la connessione con Purple. L'errore comune è aprire entrambe le console e copiare i valori avanti e indietro senza aver prima deciso quale identificativo, nomi di claim e certificato saranno autorevoli.

Preparare l'applicazione enterprise

Creare l'applicazione in Microsoft Entra ID, Okta o Google Workspace. Scegliere SAML 2.0 quando l'integrazione della rete del personale richiede un'asserzione, quindi registrare i valori del fornitore di servizi (service provider) forniti da Purple:

1. Copiare l'URL ACS, chiamato anche URL del servizio consumatore di asserzioni, nel campo dell'URL di risposta o di accesso dell'IdP.
2. Copiare l'Entity ID nel campo dell'identificatore o del destinatario dell'IdP.
3. Impostare NameID sull'identificatore dipendente stabile previsto dall'integrazione. L'e-mail è spesso pratica, ma non bisogna cambiare il formato a metà del rollout.
4. Rilasciare gli attributi richiesti, normalmente e-mail, nome visualizzato e gruppo.
5. Assegnare un gruppo pilota anziché l'intera forza lavoro.
6. Scaricare i metadati di federazione e il certificato di firma dall'IdP.

Per OIDC, registrare l'emittente (issuer), l'identificativo client, l'endpoint di autorizzazione, l'endpoint token e il client secret come forniti dall'integrazione. Conservare i secret nel gestore di password approvato, non in un ticket o in un foglio di calcolo condiviso.

Aggiungere il provider in Purple

Apri il portale Purple e segui Authentication > Identity Providers > Add. Seleziona SAML 2.0 o OIDC, a seconda del progetto, quindi importa i metadati dell'IdP o inserisci manualmente gli endpoint richiesti. Associa il nuovo identity provider al realm RADIUS del personale o al profilo del Captive Portal, e seleziona le mappature da gruppo a policy prima di salvare.

Utilizza la tolleranza predefinita per la sfasatura temporale (clock skew) documentata nella console, a meno che la tua politica di sicurezza non richieda un valore più restrittivo. Non inventare una tolleranza locale solo per far passare un'asserzione fallita. Correggi invece la sorgente oraria sull'IdP, sul servizio RADIUS e sui dispositivi di rete.

Ordine di configurazione: Creare e assegnare l'applicazione IdP, mappare le attestazioni (claims), esportare i metadati, importarli in Purple, associare il profilo del personale, testare con un account pilota, quindi abilitare la policy di produzione.

Due errori rappresentano gran parte dei primi tentativi falliti. Il primo è una discrepanza tra l'URI dell'identificatore nell'IdP e l'Entity ID previsto da Purple. Il secondo è l'importazione di metadati non firmati o la cui firma non può essere convalidata dopo un aggiornamento. Verifica la stringa esatta, inclusi maiuscole/minuscole e caratteri finali, e stabilisci come verrà approvata la rotazione dei certificati prima della messa in produzione.

Se il sito dipende ancora dall'infrastruttura di dominio Windows, separa la progettazione della directory da quella della federazione. Una guida come la spiegazione di Monro Cloud sulla promozione di un domain controller può aiutare a chiarire l'attività sottostante di Active Directory, ma non sostituisce la configurazione SSO o i test di rete.

Infine, verifica le opzioni di integrazione rilevanti nella libreria dei connettori di Purple. Mantieni limitata la portata del primo cambiamento. Un singolo gruppo di dipendenti, una sola policy SSID, una sede di test designata e un piano di fallback documentato rendono la risoluzione dei problemi molto più semplice rispetto a una migrazione simultanea sull'intera flotta.

Testare e verificare il flusso di accesso del personale

Non limitarti a testare da un browser amministratore già autenticato. Le sessioni IdP memorizzate nella cache possono far apparire funzionante una federazione che in realtà è compromessa. Utilizza una finestra di navigazione privata, un account di test pulito e una sequenza che verifichi l'asserzione, la decisione di rete e l'esperienza finale dell'utente.

Inizia con la convalida dei metadati. Utilizza un tracciatore SAML o un debugger OIDC per ispezionare la risposta e confermare il NameID format atteso, l'URI del destinatario, l'emittente, la firma e i claim del gruppo. Per un flusso supportato da RADIUS, conferma che il broker riceva l'identità e restituisca una decisione di accettazione o rifiuto con gli attributi necessari per la mappatura dei criteri.

Testare in base al contesto del dispositivo e della rete

Esegui il flusso su diversi tipi di endpoint anziché presumere che un singolo test del browser andato a buon fine copra l'intera infrastruttura:

• Laptop aziendale gestito: utilizza un dispositivo associato al dominio sulla VLAN aziendale e conferma che venga applicata la policy prevista per il personale.
• Telefono BYOD: connettiti dall'SSID guest e verifica che le credenziali del personale non concedano accidentalmente un accesso alla rete più ampio.
• Kiosk condiviso: testa il Captive Portal con una sessione del browser pulita, quindi esegui la disconnessione e ripeti l'operazione con un altro account del personale.
• Percorso di revoca: modifica o disabilita l'account di test e conferma che un nuovo tentativo di autenticazione fallisca e che le sessioni esistenti rispettino la durata configurata.

Verificare la durata della sessione e la riautenticazione forzata dopo una modifica della password o dello stato dell'account. Per 802.1X, ispezionare i pacchetti di accounting RADIUS e confermare che l'access point registri gli eventi previsti di start, stop e identity.

Correlare entrambi i lati della transazione

Esamina contemporaneamente i log del provider di identità e il flusso di eventi di Purple. I log di accesso di Entra, l'Okta System Log e i dati di audit di Google Admin devono mostrare la richiesta di autenticazione, il risultato della policy e l'identità dell'utente. Purple deve mostrare la richiesta corrispondente e l'esito di rete.

Registra l'ID di correlazione di entrambi i sistemi ovunque sia disponibile. Spesso un semplice timestamp è troppo vago durante un turno di lavoro intenso, mentre un identificatore condiviso consente di distinguere un claim di gruppo rifiutato da un problema di associazione wireless. Cattura una traccia riuscita prima di modificare la configurazione, in modo che l'assistenza clienti disponga di un esempio di funzionamento corretto come riferimento.

Piani di rollback e risoluzione dei problemi comuni

Alle 09:00 di un martedì, un hotel da 220 camere abilita l'SSO per un gruppo pilota. Il primo amministratore accede con successo. Dieci minuti dopo, arrivano i ticket di assistenza da parte del personale delle pulizie, della reception e della ristorazione. Alcuni utenti visualizzano un reindirizzamento continuo, altri raggiungono l'IdP ma atterrano sui criteri del personale errati e un computer portatile più vecchio rifiuta completamente la connessione.

La risposta non dovrebbe consistere nel disabilitare tutti i controlli contemporaneamente. Mantieni abilitato il realm RADIUS locale come sistema di fallback, riporta il profilo del Captive Portal all'autenticazione tramite password in due clic e solo allora disabilita la connessione SAML se il gruppo pilota non riesce ancora a autenticarsi. Questo ordine consente al personale di continuare a lavorare mentre la federazione viene isolata.

Modalità di errore SSO comuni e relative soluzioni

Sintomo	Causa probabile	Risoluzione
Asserzione rifiutata immediatamente	Disallineamento dell'orologio tra i sistemi	Verificare la sincronizzazione dell'ora su IdP, servizio RADIUS, controller e access point. Utilizzare la tolleranza documentata da Purple anziché ampliarla casualmente.
Il login reindirizza continuamente al portale	Il cookie del Captive Portal va in conflitto con la sessione IdP	Cancellare la sessione del portale, testare in una finestra di navigazione privata e verificare il comportamento dei reindirizzamenti e dei cookie sul profilo del Captive Portal.
L'utente si autentica ma non riceve l'accesso per lo staff	Claim di gruppo mancante o con nome errato	Confrontare l'asserzione con la mappatura dei gruppi di Purple, quindi correggere il claim dell'IdP e testare nuovamente con l'account pilota.
La connessione SAML non riesce dopo la modifica di un certificato	Certificato di firma scaduto, non attendibile o importato in modo errato	Esportare i metadati IdP correnti, convalidare il certificato di firma e importare i metadati aggiornati nel record dell'identity provider di Purple.
La firma dell'asserzione viene rifiutata	Algoritmo di firma non supportato o non corrispondente	Allineare l'algoritmo di firma dell'IdP con i requisiti di integrazione e importare nuovamente i metadati verificati.
Solo alcuni utenti riscontrano problemi	Assegnazione dell'applicazione o appartenenza al gruppo errata	Verificare l'assegnazione dell'applicazione IdP dell'utente, l'appartenenza al gruppo e la mappatura dei criteri prima di modificare la rete.

Non eliminare il vecchio realm fino a quando il nuovo percorso non ha superato i controlli dei dispositivi e il team di supporto non è in grado di identificare un errore. Un rollback non è un progetto fallito. Si tratta di un controllo standard che impedisce alle attività di autenticazione di trasformarsi in un disservizio per la sede.

La scadenza dei certificati merita una particolare attenzione perché può verificarsi senza alcuna modifica all'infrastruttura wireless. Registra il proprietario del certificato, il processo di rinnovo e la posizione di importazione. Per l'aggiornamento dei metadati, convalida il file e la relativa firma prima di sostituire la connessione attiva, quindi testa il flusso avviato dal Service Provider da una sessione pulita.

Best practice di sicurezza dopo il go-live

L'SSO è forte tanto quanto lo è il ciclo di vida delle identità che lo supporta. Un accesso centralizzato può migliorare il controllo, ma può anche concentrare i rischi se gli amministratori lasciano account inattivi, rilasciano un numero eccessivo di attributi della directory o consentono a un'identità di servizio condivisa di aggirare le normali policy.

Esegui una revisione trimestrale con i team dedicati all'identità e alla rete. Conferma che i nuovi assunti, i dipendenti che cambiano ruolo e quelli che lasciano l'azienda compaiano nei gruppi del personale corretti, che gli account inattivi non ricevano più l'accesso alla rete e che le modifiche ai gruppi raggiungano la policy del personale senza copia manuale. Le linee guida dell'NCSC sull'uso sicuro del SaaS raccomandano la federazione completa delle identità nei contesti cloud anziché la sincronizzazione delle password nel cloud, il che rappresenta un utile principio di progettazione per le integrazioni di rete del personale.

Controlli da verificare ogni trimestre

• Utilizzare una MFA resistente al phishing: Richiedere chiavi di sicurezza FIDO2 o passkey di piattaforma per gli account IdP laddove la piattaforma e i dispositivi aziendali li supportino. Considerare l'accesso tramite SMS o solo password come un'eccezione di compatibilità, non come lo stato finale desiderato.
• Limitare la persistenza della sessione: Impostare la durata delle sessioni IdP in modo che la riautenticazione a Purple segua la policy aziendale. Verificare cosa accade dopo la disconnessione, la chiusura del browser, il cambio della password e la disattivazione dell'account.
• Rivedere l'accesso just-in-time: Monitorare i ruoli del personale temporaneo e degli ospiti per evitare assegnazioni obsolete. Rimuovere l'accesso direttamente nella directory di origine invece di affidarsi a un elenco manuale all'interno della console di rete.
• Monitorare il flusso di eventi: Monitorare gli errori di federazione e i pattern di accesso insoliti nella dashboard di Purple, mettendoli poi in correlazione con i log dell'IdP.
• Rilasciare il minimo dei claim: Inviare solo gli attributi richiesti dalla policy del personale, in genere l'email, il nome visualizzato e il gruppo. I dati della directory non necessari non devono trovare posto in un'asserzione wireless.
• Ruotare il materiale di attendibilità: Rinnovare i certificati di firma e i segreti delle API prima della scadenza, testare la sostituzione e mantenere disponibile il certificato precedente solo per la finestra temporale di transizione approvata.
• Rimuovere le identità condivise: Disattivare gli account di servizio condivisi ovunque un dispositivo gestito o un utente nominativo possa eseguire l'attività. Se permane un'eccezione, documentarne il proprietario e la data di revisione.

I programmi di identità del Regno Unito mostrano perché l'adozione e il riutilizzo siano importanti tanto quanto l'autenticazione. L'analisti di settore sull'identità digitale GOV.UK del 2026 ha rilevato che il 77% dei rispondenti ha completato almeno un caso d'uso di identità digitale, mentre il 20% delle persone che hanno utilizzato un servizio di identità digitale ha riferito di aver presentato un'identità riutilizzabile. La lezione per l'IT delle sedi è pratica: un login è utile, ma il riutilizzo costante, la garanzia, l'accessibilità e il controllo del ciclo di vita determinano se l'SSO funziona davvero nei servizi reali.

La guida NCSC sulla gestione delle identità e degli accessi evidenzia anche l'importanza di disabilitare gli account e propagare tale decisione ai servizi connessi. Mantieni sotto test questa propagazione. L'SSO non è una configurazione una tantum. Il suo valore emerge quando le modifiche alla directory e le policy della rete del personale rimangono perfettamente sincronizzate.

---

Purple fornisce un'autenticazione WiFi per il personale che collega identity provider come Entra ID, Google Workspace, Okta e SAML 2.0 all'accesso di rete gestito, con policy ed eventi di autenticazione gestiti tramite la sua piattaforma. Visita Purple per valutare un SSID per il personale federato con l'identità per i tuoi hotel, ospedali, punti vendita o altre sedi, e pianifica un progetto pilota con un percorso di ripristino testato.