Probabilmente hai già a che fare con tutto questo. Il personale accede a Microsoft 365, poi a uno strumento di prenotazione, poi alle risorse umane, poi a un'app aziendale e infine al WiFi aziendale, spesso con un metodo diverso per ciascuno di essi. Un gruppo alberghiero ha un set di sistemi presso la sede centrale e un altro all'interno delle proprietà. Un ospedale dispone di app cliniche, postazioni di lavoro condivise e accesso wireless segmentato. Un operatore retail ha personale che si sposta tra negozi, tablet, POS e dashboard di back-office.
Questo mix genera rapidamente attriti. Gli utenti dimenticano le password, i team IT reimpostano gli account e le credenziali WiFi condivise rimangono attive molto più a lungo di quanto dovrebbero. Il risultato non è solo fastidioso. Si traduce in un controllo più debole su chi può accedere a cosa, da quale dispositivo e per quanto tempo.
È qui che il single sign-on, o SSO, diventa utile. Se stai cercando che cos'è il single sign-on, la risposta breve è semplice: consente a un utente di autenticarsi una sola volta e poi accedere a più sistemi approvati senza dover inserire continuamente le credenziali. La risposta più utile è di tipo operativo. L'SSO fornisce all'IT un unico livello di identità per l'accesso alle app e, con la giusta progettazione, può anche supportare il modo in cui le persone e i dispositivi si connettono a reti sicure.
La fine del caos delle password
La maggior parte degli ambienti aziendali non è diventata complessa intenzionalmente. È cresciuta in questo modo. Un'applicazione cloud è diventata cinque. Un ufficio è diventato un insieme di molte sedi. Una rete wireless per l'IT si è trasformata in SSID separati per personale, ospiti, appaltatori e dispositivi.
È così che inizia la proliferazione delle password. Un dipendente potrebbe aver bisogno di e-mail, risorse umane, pianificazione, accesso ai file, dashboard interne e accesso alla rete, il tutto prima di poter svolgere qualsiasi lavoro effettivo. IBM descrive l'SSO come uno schema in cui gli utenti accedono una sola volta con un unico set di credenziali e accedono a più applicazioni durante la stessa sessione, reso possibile da una relazione di fiducia tra i fornitori di servizi e un fornitore di identità. La panoramica di IBM sul single sign-on rispecchia da vicino ciò di cui le organizzazioni del Regno Unito hanno avuto bisogno con l'accelerazione dell'adozione del cloud e del lavoro a distanza.
L'impatto della proliferazione delle password sulle attività operative
Quando ogni applicazione richiede un proprio login, gli utenti iniziano a prendere scorciatoie. Riutilizzano le password. Le salvano nei browser. Chiedono ai colleghi la "password del WiFi del personale" perché è più veloce rispetto ad attendere il reparto IT.
Per un IT manager aziendale, il controllo è la preoccupazione principale. Login separati creano isole di accesso separate, e queste isole sono più difficili da gestire quando le persone cambiano ruolo, lasciano l'azienda o lavorano in più sedi.
Il caos delle password raramente è un unico grande fallimento. Di solito è la somma di cento piccole decisioni di accesso che nessuno riesce a gestire in modo coerente.
Perché l'SSO cambia lo scenario
L'SSO riduce il numero di password che gli utenti devono gestire, migliorando l'esperienza di accesso e supportando una sicurezza più robusta se abbinato a una policy centrale e MFA. Si adatta inoltre alla realtà delle organizzazioni distribuite in cui il personale ha bisogno di un unico accesso per e-mail, risorse umane, strumenti di prenotazione, POS, app interne e servizi del sito.
Questa stessa logica sta ora plasmando l'accesso alla rete. Se ti stai già muovendo verso un accesso alle applicazioni basato sull'identità, ha senso considerare il WiFi senza password come parte dello stesso approccio di progettazione, non come un problema a sé stante.
Comprendere il concetto fondamentale dell'SSO
Il single sign-on sposta l'autenticazione dalle singole applicazioni a un unico sistema di identità attendibile. L'utente accede una sola volta, l'identità viene verificata e i servizi connessi accettano quel risultato invece di richiedere un'altra password.
Sembra semplice, ma il valore è architetturale. Si sta cambiando il luogo in cui risiede la fiducia.
Le tre parti coinvolte in ogni flusso SSO
Ogni architettura SSO prevede tre partecipanti, ognuno con un compito diverso:
- L'utente desidera accedere a un'applicazione, a un servizio o a una risorsa di rete.
- L'Identity Provider o IdP verifica l'identità e applica la policy di accesso. Esempi comuni nelle organizzazioni del Regno Unito includono Microsoft Entra ID e Okta.
- Il Service Provider o SP è il sistema che l'utente sta cercando di raggiungere, come Salesforce, una piattaforma di prenotazione, una intranet o un altro sistema aziendale.
Il punto che spesso genera confusione è la fiducia. L'applicazione non ha bisogno di raccogliere e verificare la password stessa. Si affida all'IdP per svolgere correttamente questo compito, accettando poi il risultato.
Cosa significa realmente la relazione di fiducia
Auth0 spiega l'SSO in modo chiaro in termini aziendali: l'IdP autentica l'utente una volta, quindi emette un artefatto di sessione o un token che i fornitori di servizi attendibili convalidano per l'accesso successivo. In pratica, l'utente viene reindirizzato all'IdP, autenticato lì e reindirizzato a ciascuna app senza ripetute richieste di credenziali. La guida di Auth0 su come funziona il single sign-on è particolarmente pertinente negli ambienti del Regno Unito che utilizzano Entra ID su sistemi SaaS e interni.
Un modo pratico per interpretare questo concetto è il seguente:
- Un utente apre un'applicazione.
- L'applicazione verifica se un IdP attendibile ha già autenticato quell'utente.
- Se non esiste una sessione attiva, l'utente esegue l'accesso con l'IdP.
- L'IdP conferma l'identità e restituisce una prova che l'applicazione può convalidare.
- Altri sistemi collegati possono accettare la stessa prova durante la sessione.
Regola pratica: l'SSO non trasforma ogni sistema in un'unica piattaforma. Fornisce a più sistemi un unico punto per verificare l'identità.
Perché questo è importante al di fuori delle app web
Questo è anche il punto in cui il SSO diventa più di una semplice comodità SaaS. Una volta centralizzata l'identità, lo stesso modello può essere utilizzato per scopi che vanno oltre le semplici sessioni browser. Può anche definire il modo in cui controlli l'accesso ai servizi interni e, con il design appropriato, il modo in cui gli utenti accedono alla rete wireless aziendale.
Questo è importante per le operazioni IT. Un'applicazione finanziaria, una sessione VPN e una connessione WiFi per i dipendenti possono essere servizi diversi, ma iniziano tutti con la stessa domanda: chi è questo utente e deve essere autorizzato ad accedere? Quando Microsoft Entra ID o Okta rispondono a questa domanda in modo coerente, la politica di accesso diventa più facile da gestire sia per le applicazioni che per i punti di accesso alla rete.
Per i team che gestiscono ancora il WiFi del personale con una password condivisa, si tratta di una svolta importante. Invece di autenticare un dispositivo con una password che tutti conoscono, si autentica una persona o un dispositivo gestito a partire da una fonte di identità attendibile. Ciò garantisce un controllo più stretto, registri di controllo più chiari e un modo più lineare per revocare l'accesso quando i ruoli cambiano o il rapporto di lavoro termina.
Come funziona l'SSO: i protocolli principali
L'esperienza utente appare semplice. Dietro le quinte, l'SSO si basa su protocolli standard che consentono a un'applicazione di fidarsi di una decisione di identità presa altrove.
Per un responsabile IT aziendale, la domanda pratica non è solo "cos'è l'SSO?" È "in che modo un sistema accetta la prova da un altro sistema senza chiedere all'utente di accedere nuovamente?" La risposta dipende da un ristretto insieme di protocolli che spostano i dati di identità tra l'applicazione, l'identity provider e, a volte, il dispositivo stesso.
Questo è importante anche oltre i login del browser. Lo stesso modello di attendibilità utilizzato per aprire un'app SaaS può influenzare anche il modo in cui gli utenti si connettono alle VPN, alle reti cablate e al WiFi aziendale quando queste decisioni di accesso sono collegate a Microsoft Entra ID, Okta o a un'altra sorgente di identità centrale.
SAML in parole semplici
SAML 2.0 è ancora comune nell'SSO aziendale, in particolare per le piattaforme SaaS consolidate e i sistemi line-of-business.
SAML funziona trasmettendo dichiarazioni di identità affidabili tra l'applicazione e l'identity provider. Un utente tenta di aprire un'applicazione. L'applicazione lo reindirizza all'IdP. L'IdP autentica l'utente e rimanda un'asserzione firmata digitalmente. L'applicazione controlla la firma, accetta la richiesta di identità e crea una sessione.
Questo flusso è adatto ad ambienti in cui il browser svolge la maggior parte del lavoro e l'applicazione si aspetta uno scambio formale basato su standard.
SAML è spesso un'ottima scelta per:
- SaaS aziendali come HR, finanza o applicazioni aziendali legacy
- Flussi di lavoro basati su browser in cui gli utenti accedono ai sistemi tramite una sessione web
- Applicazione centralizzata delle policy quando l'IT desidera un unico punto per gestire l'autenticazione
OAuth e OIDC in parole semplici
OAuth 2.0 è nato come un modo per concedere un accesso limitato a una risorsa senza condividere un set completo di credenziali. Di per sé, riguarda l'autorizzazione.
OpenID Connect, o OIDC, aggiunge l'identità a OAuth 2.0. Questo offre alle applicazioni moderne un modo standard per confermare l'identità dell'utente continuando a utilizzare modelli di accesso basati su token. Se SAML si adatta spesso al SaaS tradizionale incentrato sul browser, OIDC si adatta solitamente alle app web più recenti, alle app mobili e ai servizi basati su API.
In pratica, OIDC tende a risultare più leggero per i team di sviluppo moderni perché i token funzionano bene tra app front-end, servizi back-end e client mobili. Per l'IT, questo significa meno soluzioni di ripiego complesse quando l'applicazione non è una sessione browser tradizionale.
OIDC tende ad essere ideale per:
- Moderne applicazioni cloud
- App mobili e single-page
- Ambienti ricchi di API dove i token fanno già parte del design
Una breve nota su Kerberos
Potresti anche sentir parlare di Kerberos nelle discussioni relative al SSO. Kerberos è strettamente legato ai tradizionali ambienti Active Directory e all'autenticazione Windows on-premise. Rimane rilevante nelle infrastrutture aziendali interne, in particolare dove i dispositivi associati a un dominio e le applicazioni legacy sono ancora comuni.
Ciò premesso, molti progetti SSO attuali si concentrano sull'identità federata attraverso servizi cloud e ibridi. In questi casi, SAML e OIDC ricevono solitamente maggiore attenzione perché si collegano più naturalmente alle piattaforme SaaS e ai servizi accessibili esternamente.
SAML vs OIDC in sintesi
| Funzionalità | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| Ruolo primario | Autenticazione per applicazioni web aziendali | Autorizzazione con identità aggiunta tramite OIDC |
| Caso d'uso comune | Applicazioni SaaS consolidate e app aziendali basate su browser | Applicazioni web moderne, app mobili, API |
| Formato | Asserzioni basate su XML | Flussi basati su token |
| Flusso tipico | Reindirizzamento all'IdP, autenticazione, restituzione dell'asserzione firmata | Reindirizzamento o flusso di token, quindi l'app utilizza i token per identità e accesso |
| Adattamento ideale | Integrazioni SSO aziendali tradizionali | Architetture più recenti cloud-native e incentrate sulle app |
Ciò che conta per un responsabile IT
I nomi dei protocolli contano meno delle scelte di progettazione. Servono risposte chiare a quattro domande operative:
- Quali app supportano SAML o OIDC
- Quale IdP fungerà da pannello di controllo centralizzato
- In che modo verranno applicati il timeout di sessione, la MFA e l'accesso condizionale
- Se l'accesso alla rete, incluso il WiFi per il personale, debba anch'esso convalidare l'identità rispetto a quella stessa fonte
Quest'ultimo punto è il motivo per cui l'SSO diventa particolarmente utile per i team responsabili dell'infrastruttura. Se la tua piattaforma wireless può utilizzare lo stesso livello di identità del tuo parco SaaS, la policy di accesso diventa più coerente dalla pagina di login fino al perimetro della rete. Questo è uno dei motivi per cui molti team che esaminano i vantaggi del single sign-on per il controllo degli accessi e le operazioni iniziano a considerare anche l'autenticazione WiFi basata sull'identità, e non solo i login alle app web.
Valutare i vantaggi e i compromessi in termini di sicurezza
L'SSO viene spesso venduto come una funzionalità per la comodità dell'utente. Questo è riduttivo. Se implementato correttamente, è un modello di controllo degli accessi in grado di migliorare l'esperienza utente e, allo stesso tempo, rafforzare la sicurezza operativa.
Okta sottolinea che il vantaggio tecnico dell'SSO non risiede solo nella comodità. Riduce la proliferazione delle password e i ripetuti accessi che aumentano il carico del supporto tecnico e l'attrito per l'utente. La panoramica di Okta sulla sicurezza del single sign-on evidenzia inoltre un punto a cui i progettisti tengono molto: se la sessione dell'IdP viene invalidata, le applicazioni collegate possono negare l'accesso al successivo controllo del token.
Dove si manifesta il valore aziendale
Il primo vantaggio è un accesso più semplice. Gli utenti effettuano l'accesso una sola volta, iniziano a lavorare prima e smettono di considerare l'autenticazione come un ostacolo quotidiano.
Il secondo vantaggio è un controllo centrale più forte. L'IT può applicare MFA, accesso condizionale, policy di sessione e revoche da un unico livello di identità, invece di rincorrere le impostazioni all'interno di ciascuna applicazione.
Un terzo vantaggio è una gestione più pulita di assunzioni, trasferimenti e dimissioni. Quando l'identità è centralizzata, l'onboarding e l'offboarding diventano più coerenti. Questo è uno dei motivi per cui i team che esplorano i vantaggi del single sign-on spesso collegano i progetti di SSO a un più ampio lavoro di governance dell'identità.
I compromessi da prendere sul serio
Esiste una reale preoccupazione legata alle "chiavi del regno". Se un utente malintenzionato compromette l'accesso principale dell'utente, il raggio d'azione dell'attacco può essere più ampio perché un singolo account può fornire l'accesso a molti sistemi.
Esiste anche un rischio di resilienza. Se l'IdP non è disponibile, l'accesso ai servizi collegati potrebbe essere interrotto. E l'integrazione non è sempre fluida. Le app legacy, i sistemi di nicchia e i servizi di rete locali non sempre si adattano perfettamente a un modello moderno di single sign-on.
La domanda giusta non è se l'SSO comporti dei compromessi. È se preferisci gestire tali compromessi a livello centrale o continuare a gestirne dozzine scollegati tra loro.
Mitigazioni comuni
Utilizzate un approccio multilivello:
- Proteggi fortemente l'IdP con MFA, accesso condizionale, attendibilità dei dispositivi e solidi controlli amministrativi.
- Pianifica la resilienza in modo che un problema dell'IdP non causi un blocco a livello di intera organizzazione.
- Implementa in modo graduale partendo dalle app ad alto valore e da gruppi di utenti ben definiti.
- Verifica l'accesso regolarmente in modo che le autorizzazioni obsolete non rimangano attive oltre il necessario.
Un'implementazione SSO debole può centralizzare i problemi. Una forte centralizza il controllo.
SSO oltre le applicazioni web: accesso alla rete e al WiFi
La maggior parte degli articoli si ferma al SaaS. Questo è utile, ma incompleto. Nei contesti reali, il personale non ha bisogno solo dell'accesso alle app. Hanno bisogno di un accesso sicuro alla rete quando arrivano in sede, collegano un laptop gestito, aprono un tablet in una filiale o si spostano tra diverse sedi.
Ed è qui che la discussione sull'SSO si fa più interessante. Lo stesso identity provider che gestisce l'accesso a Microsoft 365, ai sistemi HR o alle dashboard interne può diventare anche la fonte di verità per i criteri di autenticazione wireless.
Optimal IdM segnala che il 52% dei professionisti IT in Nord America utilizza l'SSO per la gestione delle identità nella sua analisi sull'adozione del single sign-on. Per le organizzazioni del Regno Unito con più sedi o proprietà, tale maturità è fondamentale perché il personale ha spesso bisogno di un accesso sicuro ai sistemi condivisi senza dover effettuare continui accessi.
SSO delle app e identità di rete sono correlati, non identici
Un comune punto di confusione per i lettori è che l'SSO per le applicazioni e l'accesso di rete basato sull'identità sono concetti collegati, ma non rappresentano lo stesso meccanismo.
Il SSO per le app significa solitamente che l'utente si autentica una volta con un IdP e riceve un token o una sessione accettata dalle applicazioni connesse. L'accesso alla rete utilizza spesso controlli diversi, come certificati di dispositivo, metodi di autenticazione wireless, policy basate su directory e controlli di stato o di conformità del dispositivo.
Ciò che li unisce è la sorgente di identità. Se Microsoft Entra ID o Okta sanno già chi è l'utente, a quale gruppo appartiene e se il suo dispositivo è gestito, è possibile utilizzare questo contesto di identità per decidere se consentirgli l'accesso alla rete del personale.
Come si presenta questa situazione sul WiFi aziendale
In un design maturo, il personale non inserisce affatto una password WiFi condivisa. Il loro dispositivo gestito dall'organizzazione viene registrato, considerato attendibile e associato alla loro identità. Quando entrano nell'edificio, il dispositivo si connette all'SSID protetto appropriato utilizzando l'autenticazione aziendale basata su certificati o equivalente.
Questo cambia notevolmente le cose dal punto di vista operativo:
- Le password condivise scompaiono, quindi una singola credenziale compromessa non influisce sull'intera rete aziendale.
- L'accesso diventa sensibile al ruolo, perché la policy può seguire i gruppi di identità.
- La revoca diventa più rapida, perché quando cambiano i permessi nella directory, anche l'accesso alla rete può variare di conseguenza.
- Il roaming diventa più semplice, specialmente in proprietà multi-sito dove gli utenti si aspettano la stessa esperienza ovunque.
Perché questo è importante nei settori hospitality, retail e healthcare
Questi settori sono pieni di casi limite. Vi sono lavoratori su turni, dispositivi condivisi, personale interinale, team in mobilità e un mix costante di esigenze di accesso aziendali, semi-aziendali e guest.
Un gruppo alberghiero potrebbe desiderare che un'unica identità del personale gestisca l'accesso al PMS, alle app di back-office e al WiFi interno sicuro in tutte le strutture. Una catena di negozi potrebbe volere che i palmari gestiti si connettano automaticamente al WiFi del negozio, mantenendo isolato il traffico degli ospiti. Un fornitore di servizi sanitari potrebbe desiderare una separazione più netta tra utenti clinici, visitatori e dispositivi connessi.
Questo è anche il punto in cui entrano in gioco le soluzioni di controllo dell'accesso alla rete. Aiutano a estendere i criteri di identità dal livello applicativo al livello di rete.
Il ruolo di Purple
Un'opzione pratica è Purple, che supporta il networking basato sull'identità per il personale e gli ambienti multi-tenant, incluse le integrazioni con Microsoft Entra ID, Google Workspace e Okta per un accesso sicuro senza dipendere da password condivise. Questo tipo di approccio è utile quando si desidera che l'identità dell'applicazione e l'identità di rete operino a partire dalla stessa unica fonte di verità.
SSO nel vostro settore: casi d'uso pratici
Il modo più semplice per comprendere il valore dell'SSO è osservare il lavoro quotidiano, non i diagrammi dell'architettura.
Hospitality
Un responsabile delle operazioni alberghiere inizia la giornata in una struttura e la finisce in un'altra. Ha bisogno di accedere alla pianificazione, a un sistema di gestione della proprietà, ai documenti condivisi e al WiFi interno in entrambe le sedi.
Con il single sign-on, quell'identità li segue. Effettuano l'accesso una sola volta e i sistemi approvati riconoscono la sessione. Se l'organizzazione collega anche l'accesso alla rete alla stessa sorgente di identità, il loro dispositivo gestito si connette alla rete WiFi del personale senza che nessuno debba inviare l'ultima password via SMS al responsabile di turno.
Retail
Un responsabile regionale entra in un negozio con un tablet. Ha bisogno immediato di dashboard di vendita, strumenti di magazzino e app di comunicazione interna.
In una configurazione frammentata, ogni passaggio può significare un'altra richiesta di login, un'altra password scaduta o un'altra chiamata al supporto. In un modello basato sull'identità, il tablet si autentica in modo pulito, l'accesso riflette il ruolo dell'utente e il personale del negozio non deve condividere credenziali locali per svolgere il proprio lavoro.
Un buon SSO non rende l'accesso invisibile. Rende l'accesso legittimo prevedibile.
Sanità
Un medico inizia il turno e ha bisogno di un accesso rapido e controllato ai sistemi principali. Durante la giornata può spostarsi tra postazioni di lavoro, dispositivi condivisi e segmenti di rete protetti.
In questo caso, il SSO aiuta a ridurre i continui accessi alle applicazioni approvate, mentre i controlli di rete basati sull'identità aiutano a garantire che gli utenti e i dispositivi corretti si connettano agli ambienti wireless appropriati. Questa separazione è importante. L'accesso clinico, l'accesso ospiti e l'accesso ai dispositivi non dovrebbero essere tutti gestiti allo stesso modo.
Proprietà multi-tenant e campus
Negli alloggi per studenti, nei centri direzionali e negli immobili a uso misto, il personale e i residenti spesso coesistono sulla stessa infrastruttura fisica, ma non dovrebbero mai condividere lo stesso modello di accesso.
Il personale potrebbe aver bisogno di sistemi di gestione dell'edificio, strumenti di supporto e app di amministrazione interna. I residenti o gli inquilini hanno bisogno di una connettività affidabile, ma non dell'accesso alle piattaforme operative. In questo contesto, la progettazione dell'identità è fondamentale. L'SSO può supportare l'accesso della forza lavoro, mentre policy di identità di rete separate mantengono isolato il traffico degli inquilini e degli ospiti.
Implementazione dell'SSO e best practice
Un progetto SSO di successo inizia con una decisione: scegliere l'identity provider che fungerà da piano di controllo. Per molte organizzazioni si tratta di Microsoft Entra ID o Okta, perché queste piattaforme sono già strettamente integrate con il ciclo di vita degli utenti, la MFA e le policy dei dispositivi.
L'implementazione dovrebbe essere graduale. Inizia con le applicazioni più importanti e con i gruppi di utenti che hanno maggiori probabilità di trarne vantaggio. Ripulisci gli account duplicati, definisci correttamente i gruppi di ruoli e testa il comportamento delle sessioni prima di estendere l'ambito.
I controlli che contano di più
Alcune pratiche fanno la differenza tra una demo ben riuscita e un'implementazione duratura:
- Richiedi l'MFA al punto di accesso primario. Se un singolo accesso può fornire l'accesso a molte risorse, tale accesso necessita di una protezione più forte.
- Crea processi di disattivazione basati sulla revoca immediata. L'identità centrale è utile solo se le modifiche all'account vengono trasmesse rapidamente.
- Verifica l'accesso per ruolo. L'SSO può rendere più facile trascurare un eccesso di autorizzazioni se nessuno controlla chi ha ancora accesso.
- Pianifica l'interruzione dell'IdP. Scopri cosa succede se il tuo servizio di identità non è disponibile e quali sistemi richiedono una gestione di emergenza.
Sapere quando l'SSO non è lo strumento giusto
Questo punto viene spesso trascurato in molte spiegazioni generiche. OneLogin rileva una crescente distinzione tra l'SSO per il personale aziendale e l'accesso per ospiti o dispositivi nelle implementazioni reali, e pone una domanda utile per gli acquirenti nella sua spiegazione di come funziona il single sign-on: quando l'SSO è lo strumento sbagliato e quando invece l'identità dovrebbe essere applicata all'accesso alla rete piuttosto che al login dell'applicazione?
Questo è un aspetto cruciale nella progettazione WiFi. Il personale dovrebbe spesso utilizzare un accesso basato sull'identità e guidato dalle policy. Gli ospiti di solito hanno bisogno di qualcosa di più leggero, semplice e separato. Cercare di forzare ogni problema di accesso attraverso il single sign-on aziendale crea inutili attriti.
Se stai valutando l'SSO come parte di una strategia di accesso più ampia, includi nella stessa discussione app, WiFi del personale, onboarding degli ospiti, dispositivi condivisi e flussi di lavoro di revoca. È proprio lì che di solito si registrano i maggiori guadagni operativi.
Se stai ripensando l'accesso tra app, WiFi del personale, onboarding degli ospiti o reti multi-tenant, vale la pena dare un'occhiata a Purple. Offre un sistema di networking basato sull'identità in grado di integrarsi con piattaforme come Microsoft Entra ID, Okta e Google Workspace, aiutando i team a sostituire le password condivise e i Captive Portal complessi con un accesso controllato per personale, ospiti e residenti.
