Open Roaming WiFi spiegato: come accedere senza portali
Published
Se i Suoi punti di accesso WiFi supportano OpenRoaming, per quale motivo un visitatore potrebbe non riuscire a connettersi? Perché il login automatico non dipende solo dall'hardware radio. Il dispositivo necessita di un profilo utilizzabile, un identity provider deve autenticarlo e la sede deve accettare le credenziali di tale provider.
Per i team IT e i responsabili delle sedi, OpenRoaming WiFi deve essere inteso principalmente come una modalità diversa per stabilire un rapporto di fiducia, non come la garanzia che ogni visitatore si connetterà automaticamente. Può eliminare le schermate di login ripetute, ma non solleva dalle responsabilità relative alle politiche di accesso, alle connessioni di riserva o alla privacy.
Sommario
- Cosa sostituisce OpenRoaming e perché i portali stanno scomparendo
- Confronto affiancato dei metodi di accesso ospiti
- Come un dispositivo si connette senza chiedere
- Come convalidare un'implementazione di OpenRoaming prima del Go-Live
- Compromessi sulla privacy dietro l'accesso automatico
- Confermare il piano pilota prima di sostituire i portali ospiti
Cosa sostituisce OpenRoaming e perché i portali stanno per scomparire
Un viaggiatore arriva in aeroporto, sceglie la rete ospiti e apre un browser. Attende un portale captive, inserisce un indirizzo e-mail o seleziona un login social, quindi accetta i termini. Al bar fuori dal terminal, ripete la procedura.
Nulla di quella seconda registrazione aiuta il dispositivo a ricordare che il suo proprietario dispone già di un'identità affidabile altrove. Ogni struttura tratta il visitatore come una nuova procedura di onboarding.
OpenRoaming, basato su WiFi CERTIFIED Passpoint, modifica tale relazione. Invece di chiedere all'utente di compilare un altro modulo nel browser, la rete può accettare una credenziale già presente sul dispositivo.
Si pensi a una tessera fedeltà di un hotel accettata negli hotel partner aderenti, piuttosto che a un modulo di registrazione da compilare a ogni reception. Ogni hotel decide comunque quali porte quella tessera può aprire.
Il dispositivo trasmette la presentazione
L'accordo prevede partecipanti distinti:
- Il dispositivo possiede un profilo. Questo gli indica quali reti partecipanti può utilizzare e quale credenziale presentare.
- L'identity provider garantisce per l'utente. Tale organizzazione autentica la credenziale anziché richiedere a ogni struttura di mantenere un account ospite separato.
- La struttura autorizza l'accesso. Accetta il risultato dell'autenticazione attendibile e decide quali risorse di rete il dispositivo può raggiungere.
Una volta creato il profilo, il dispositivo gestisce la connessione di routine. Il visitatore non deve selezionare un pulsante di accesso ogni volta che entra in una sede aderente.
Il contrasto è più facile da notare come un cambiamento nell'esperienza del visitatore.
Meno interazione non significa meno responsabilità
Rimuovere il modulo non significa garantire a ogni visitatore autenticato un accesso senza restrizioni. La sede mantiene comunque il controllo sull'assegnazione delle VLAN, sulle politiche di accesso e sulla registrazione dei log. Un'identità ospite riconosciuta deve comportare l'assegnazione di autorizzazioni per ospiti, non l'accesso alle applicazioni del personale o ai sistemi di gestione dell'edificio.
L'onboarding automatico non elimina l'esigenza di illustrare l'uso consentito e il trattamento dei dati. Tali informative necessitano di una collocazione adeguata nell'ambito della registrazione e delle comunicazioni continue sul servizio, anziché fare affidamento esclusivo sull'interruzione mediante portale.
OpenRoaming è quindi un framework di identità di roaming federato, non il prodotto WiFi di un singolo fornitore. Il suo valore pratico deriva dal separare chi autentica il visitatore da chi gestisce la rete, consentendo al tempo stesso alla struttura di mantenerne il controllo.
Confronto affiancato dei metodi di accesso ospiti
| Metodo di accesso | Azione del visitatore | Portale mostrato | Credenziale posseduta | Caso d'uso ideale |
|---|---|---|---|---|
| Accesso ospiti tramite portale captive | Apre una pagina del browser, sceglie un metodo di accesso, accetta i termini | Sì | Nessuna, oppure un accesso social o via SMS | Visitatori che accedono per la prima volta senza profilo |
| Profilo Passpoint o OpenRoaming | Installa il profilo una volta; il dispositivo si connette automaticamente | No | Profilo con certificato di identità o credenziale | Ospiti abituali e viaggiatori frequenti |
| Rete sicura EAP-TLS | Il dispositivo viene registrato tramite la gestione dei dispositivi mobili | No | Certificato del dispositivo | Dispositivi gestiti dal personale |
| Chiave pre-condivisa per singolo dispositivo | Il dispositivo si connette con la propria chiave univoca | No | Chiave univoca per dispositivo, utente o tenant | Residenti, casse e dispositivi IoT |
Un profilo è utile solo se il dispositivo lo supporta e il suo provider di identità è accettato dalla struttura. Mantenga disponibile una modalità basata su portale per i visitatori che non soddisfano tali condizioni.
Associare il metodo alla persona o al dispositivo
Un portale captive rimane utile per chi arriva senza una relazione consolidata con la Sua organizzazione. A seconda del servizio, l'accesso potrebbe utilizzare SSO, Google, Apple, Facebook o un codice monouso via SMS, con l'accettazione e il consenso debitamente registrati.
Un profilo Passpoint o OpenRoaming è ideale per chi ritorna o si sposta tra strutture aderenti. Passpoint gestisce l'individuazione della rete e l'autenticazione basate su profilo; OpenRoaming aggiunge la federazione che consente a reti gestite in modo indipendente e a provider di identità di fidarsi reciprocamente. Sono concetti correlati, ma i nomi non sono intercambiabili per qualsiasi tipo di implementazione.
EAP-TLS è adatto alle apparecchiature del personale gestite poiché gli amministratori possono distribuire i certificati dei dispositivi tramite la gestione dei dispositivi mobili (MDM). Non si tratta di una federazione di roaming concorrente. È un metodo di autenticazione che può anche essere integrato all'interno di un accesso basato su profili.
Una chiave pre-condivisa per singolo dispositivo è adatta alle apparecchiature che necessitano di una credenziale pratica e revocabile individualmente. Una cassa o un termostato non dovrebbero richiedere un browser e la dismissione di un singolo dispositivo non dovrebbe comportare la modifica della password sull'intera infrastruttura.
Pianificare la coesistenza
Una sede può offrire questi metodi affiancandoli l'uno all'altro. Mappi le identità sulle VLAN appropriate e applichi le regole del firewall tra di esse, anziché presupporre che nomi di rete diversi garantiscano da soli l'isolamento. Un ospite dovrebbe poter raggiungere Internet senza ottenere un instradamento verso i sistemi di pagamento o i servizi per i dipendenti.
Quando si confrontano le soluzioni di WiFi WiFiper ospiti, è opportuno valutare il percorso di onboarding per ciascun tipo di utenza, anziché scegliere un unico metodo di accesso per tutti.
Il profilo stesso richiede un percorso di registrazione. Una sede o un identity provider partecipante possono offrirne l'installazione, ma l'idoneità dipende dal rapporto che tale provider intrattiene con la rete di accesso. Testi le famiglie di dispositivi utilizzate dai Suoi visitatori, inclusi i sistemi operativi e le relative versioni, oltre alle restrizioni per l'installazione dei profili.
Regola decisionale: elenchi innanzitutto i gruppi di visitatori e di dispositivi. Assegni a ciascuno un metodo di accesso primario, un responsabile delle credenziali e una soluzione alternativa utilizzabile.
Questa verifica dimostra spesso che l'obiettivo non è eliminare i portali, bensì smettere di richiedere inutilmente la compilazione agli utenti già idonei.
Come si autentica un dispositivo senza fare domande
- Individuare e associare. Il dispositivo legge gli annunci di rete 802.11u e ANQP, quindi associa un Roaming Consortium Organization Identifier (RCOI) a un profilo memorizzato. Il visitatore non seleziona manualmente un SSID.
- Avviare l'autenticazione. Il dispositivo avvia uno scambio 802.1X utilizzando un metodo EAP (Extensible Authentication Protocol).
- Inoltrare la richiesta. Il punto di accesso o il relativo controller trasmette lo scambio di autenticazione all'infrastruttura RADIUS del provider di accesso.
- Trovare l'identity provider. L'infrastruttura di autenticazione utilizza il realm nell'identità dell'utente per instradare la richiesta verso il provider appropriato.
- Verificare la credenziale. L'identity provider convalida il certificato, la credenziale basata su SIM o le informazioni dell'account e restituisce un risultato di autenticazione.
- Applicare le autorizzazioni locali. L'infrastruttura della struttura applica la policy di accesso e VLAN autorizzata prima di consentire il normale traffico utente.
La panoramica su OpenRoaming della Wireless Broadband Alliance descrive la combinazione di Passpoint, identità federata e politiche di accesso a supporto di questo scambio, compresi l'instradamento basato su realm e la fiducia basata su certificati tra i provider.
L'ordine è importante. Un portale captive richiede solitamente al browser di completare un passaggio di accesso dopo che il dispositivo si è connesso alla rete. In questo caso, il dispositivo completa l'autenticazione enterprise prima dell'inizio dell'ordinario accesso ai dati. Il browser non è l'interfaccia di autenticazione.
Questo diagramma mostra lo stesso percorso dal punto di vista del dispositivo.
Quale credenziale presenta il dispositivo?
Un profilo non è necessariamente un certificato. Contiene la configurazione che indica al dispositivo come individuare una rete idonea e autenticarsi ad essa, mentre le credenziali sottostanti seguono il metodo EAP selezionato.
| Metodo EAP | Credenziale posseduta dal dispositivo | Rete tipica |
|---|---|---|
| EAP-TLS | Certificato client e relativa chiave privata associata | Dispositivi enterprise e gestiti tramite Mobile Device Management |
| EAP-SIM | Chiave della scheda SIM | Abbonati a un operatore mobile |
| EAP-AKA | Chiave USIM per autenticazione e accordo sulla chiave (AKA) | Reti di abbonati a un operatore |
| EAP-AKA′ | Chiave USIM con derivazione della chiave più forte | Abbonati a un operatore su distribuzioni AKA più recenti |
| EAP-TTLS | Nome utente e password all'interno di un tunnel TLS | Account del personale o degli ospiti autenticati tramite un server con certificato convalidato |
Con EAP-TLS, il dispositivo dimostra il possesso della chiave privata associata al proprio certificato. Con i metodi basati su SIM, l'infrastruttura di autenticazione dell'operatore convalida le credenziali dell'abbonato. Con EAP-TTLS, il client deve convalidare il certificato del server di autenticazione prima di inviare le credenziali interne.
Tale distinzione è fondamentale in fase di approvvigionamento. Un access point che supporta Passpoint non garantisce che ogni tipo di credenziale presente nella popolazione di visitatori prevista funzioni lungo l'intero percorso di autenticazione.
La fiducia esiste anche tra i provider
RadSec veicola la segnalazione RADIUS su TLS tra le infrastrutture partecipanti. Il TLS reciproco consente ai peer di convalidarsi a vicenda tramite certificati, pertanto l'emissione, le root attendibili, il rinnovo e la scadenza dei certificati richiedono tutti una gestione operativa.
L'individuazione dei peer RADIUS basata su DNS aiuta un provider di accesso a localizzare il peer di autenticazione appropriato per un realm di identità. Ciò evita di dover riconfigurare i singoli punti di accesso per ogni nuovo provider, sebbene l'instradamento e le politiche di federazione debbano comunque consentire tale relazione.
Prima di una prova sul campo, un tecnico dovrebbe verificare il profilo installato, gli RCOI annunciati, l'instradamento del realm e i metodi EAP supportati all'interno di un'unica catena. Aquisisca contestualmente i log del client e di autenticazione: un dispositivo che non seleziona mai la rete presenta un errore diverso da uno le cui credenziali vengono rifiutate dopo una ricerca riuscita.
Come convalidare un'implementazione OpenRoaming prima della messa in funzione
In una indagine WBA del 2025 condotta su 170 dirigenti del settore, l'81% pianificava di distribuire OpenRoaming, mentre il 25% lo stava già implementando, secondo il resoconto di CDG sull'indagine WBA. Si tratta di metriche di pianificazione e implementazione, non della prova che un determinato visitatore possa connettersi presso la Sua struttura.
Utilizzi una checklist di conformità per trasformare una dichiarazione di infrastruttura compatibile in un percorso utente testato.
Testare la catena di autenticazione completa
- Confermare la partecipazione alla federazione. Identificare chi rilascia le credenziali e in che modo la struttura si fida di tale provider. Registrare il responsabile del supporto su ciascun lato.
- Testare profili client reali. Utilizzare le famiglie di dispositivi servite dalla struttura, incluso un dispositivo visitatore non gestito anziché solo il laptop preparato da un tecnico.
- Verificare la corrispondenza di RCOI e realm. Confrontare annunci e instradamento con la configurazione del provider, in modo da non scambiare un errore di individuazione per una password errata.
- Ispezionare le catene di certificati e le relative scadenze. Verificare separatamente l'affidabilità dell'autenticazione rivolta ai client e quella dei peer RadSec.
- Convalidare l'individuazione dei peer. Confermare che l'individuazione basata su DNS raggiunga l'infrastruttura di autenticazione prevista.
- Interrompere deliberatamente il percorso preferito. Testare un provider non disponibile e un profilo non supportato, quindi verificare che il visitatore possa trovare e utilizzare l'alternativa del portale.
- Verificare le policy e la misurazione. Confermare il posizionamento, l'isolamento e la rendicontazione di VLAN tra gli operatori, compreso ciò che le analytics sui visitatori possono osservare.
- Provare la revoca. Disabilitare la credenziale di un dispositivo smarrito e testare sia la successiva autenticazione sia la gestione di una sessione esistente.
Un'utile disciplina di test consiste nel valutare la pertinenza dei test oltre i risultati positivi, come discusso da 99tests. Una connessione riuscita da un telefono di prova preconfigurato non dimostra che il percorso di arrivo funzioni per i visitatori previsti.
Impostare un gate di rilascio esplicito
Renda le dipendenze di autenticazione parte integrante della progettazione della rete WiFi, non un elemento secondario rispetto alla copertura radio. Tracci i guasti tra client, punto di accesso, RADIUS e provider di identità.
Newcastle gestisce la prima rete dell'intera città OpenRoaming su Purple e Purple è un broker di identità certificato WBA. Tali credenziali non sostituiscono i test di accettazione a livello di struttura.
Go o no-go: Richiedere che i controlli di individuazione, affidabilità, autenticazione e fallback vengano superati su famiglie di dispositivi differenti prima di considerare la rimozione del portale per un pubblico definito.
Compromessi in materia di privacy alla base dell'accesso automatico
L'autenticazione sicura non equivale a un uso anonimo. Un dispositivo può connettersi senza inserire un nome in un portale, generando comunque registri che lo distinguono da altri dispositivi e lo associano a una posizione.
L'annuncio della certificazione OpenRoaming di Westermo fornisce il contesto per l'autenticazione gestita dal provider di identità e per gli identificatori persistenti. La questione pratica per una struttura non è se l'accesso sia crittografato, ma chi possa vedere quali identificatori, per quale scopo e per quanto tempo.
Una connessione automatica può sembrare impercettibile per il visitatore, anche se dietro di essa intervengono diverse organizzazioni.
Autenticazione e anonimato rispondono a esigenze diverse
Il provider di identità può autenticare un utente senza fornire la relativa password alla struttura. La struttura può comunque ricevere le informazioni necessarie per autorizzare l'accesso, assegnare criteri, contabilizzare una sessione o verificare eventuali abusi.
A seconda del provider, della rete, dell'accordo e della legge applicabile, i registri possono includere eventi di autenticazione, record contabili, identificatori del dispositivo, informazioni sulla posizione o identificatori pseudonimi. Uno pseudonimo non è automaticamente anonimo: un'organizzazione potrebbe essere in grado di collegare sessioni ripetute o di associare quell'identificatore a un account.
Si consideri un visitatore di uno stadio il cui accesso è previsto unicamente per un evento. L'operatore dovrebbe definire quali registri di connessione conservare successivamente e per quale motivo. Non consideri una credenziale di accesso valida per un evento come l'autorizzazione a creare una cronologia delle presenze a tempo indeterminato.
Il dispositivo gestito di un dipendente rappresenta un caso differente. Le sue credenziali possono rimanere attive per tutta la durata del rapporto di lavoro, ma questo non giustifica la conservazione di ogni sessione legata alla posizione per il medesimo periodo. La validità delle credenziali, la conservazione dei log di sicurezza e quella dei dati di coinvolgimento richiedono decisioni distinte.
Il video offre un modo ulteriore per spiegare la connettività automatica agli stakeholder.
Rendere il flusso di dati verificabile
Includa queste domande nella revisione della sicurezza della rete WiFi per ospiti:
- Informativa sull'Identity Provider. Indicare le organizzazioni coinvolte e spiegare cosa riceve ciascuna di esse, inclusi eventuali trattamenti transfrontalieri.
- Validazione dei certificati. Registrare chi detiene la titolarità delle impostazioni di attendibilità e le modalità di revisione delle modifiche.
- Identificatori pseudonimi. Stabilire se rimangono persistenti, chi può risalirvi e se è possibile collegare dataset distinti.
- Registri di contabilità e calcolo. Specificare i campi raccolti e chi vi può accedere o esportarli.
- Periodi di conservazione. Assegnare una finalità e una regola di eliminazione a ciascuna categoria di registri, inclusi i backup.
- Informativa all'utente e consenso. Individuare i ruoli dei titolari del trattamento, la base giuridica del trattamento pertinente e le modalità di informazione di minori, dipendenti, residenti e visitatori.
- Revoca immediata delle credenziali. Fornire agli utenti un percorso chiaro per la segnalazione dei dispositivi smarriti e agli operatori una procedura d'intervento verificata.
Il consenso non è un sostituto universale per la determinazione della base giuridica appropriata e una pagina di informativa nascosta non costituisce un'informativa valida. Richieda ai responsabili legali e della privacy di esaminare il flusso effettivo anziché una descrizione generica del WiFi sicuro WiFi.
L'accesso con dati minimi è una scelta di progettazione. L'accesso automatico da solo non basta a garantirlo.
Confermare il piano pilota prima di sostituire i portali per ospiti
Avvii un progetto pilota circoscritto dopo che i controlli di accettazione tecnica hanno avuto esito positivo in un ambiente controllato. Scelga una sede in cui sia possibile osservare sia gli utenti abituali sia le persone che arrivano senza un profilo esistente.
Fornire al progetto pilota una decisione misurabile
- Scegliere una sede rappresentativa. Includere il personale della reception o della struttura nella prova, affinché possa segnalare eventuali istruzioni di registrazione e fallback poco chiare.
- Mantenere il percorso per ospiti esistente. Rendere il nome della rete e le relative istruzioni facili da trovare per i visitatori non coinvolti nel progetto pilota.
- Iscrivere un gruppo definito. Iniziare con i dispositivi del personale gestiti e con gli ospiti abituali di cui è possibile verificare l'idoneità del profilo.
- Misurare l'esperienza all'arrivo. Registrare il successo della connessione al primo tentativo, i problemi di autenticazione e la frequenza con cui gli utenti idonei necessitano ancora del portale. Separare i problemi di rilevamento dal rifiuto delle credenziali.
- Documentare i flussi di dati. Approvatore la conservazione, l'informativa, le autorizzazioni di accesso e la gestione dei dispositivi smarriti prima di ampliare il gruppo.
- Espandere in base ai criteri di accettazione. Concordare gli elementi che costituiscono il successo prima di esaminare i risultati e tenere a disposizione un responsabile del ripristino.
Non valuti il successo unicamente in base all'assenza di un portale. Un dispositivo che si connette alla rete VLAN errata o che impedisce a un visitatore di trovare un accesso alternativo non ha superato il test.
Valutare il servizio rispetto al medesimo test
Se sta valutando il nostro servizio, Purple Access supporta Passpoint e OpenRoaming, e la nostra licenza gratuita Connect include il portale ospiti e OpenRoaming gratuito. Gli ospiti che ritornano utilizzano un profilo sulla rete Sicura senza passare dal portale al loro rientro, e tale profilo funziona in ogni struttura in cui è attivo. La invitiamo a verificare questi comportamenti in base ai dispositivi utilizzati e a confermare le licenze e i prezzi di eventuali funzionalità aggiuntive prima di includerle nel piano di rilascio.
Il motivo più valido per procedere è un miglioramento comprovato per un pubblico specifico, non la disponibilità di una nuova impostazione dell'access point. Mantenere il progetto pilota incentrato sulle persone la cui esperienza di connessione può essere migliorata in modo significativo.
Quale gruppo di visitatori perde più tempo sul portale allo stato attuale e il profilo risolve il problema per tale gruppo?
Purple Access offre un portale ospiti insieme a Passpoint e OpenRoaming, consentendo di testare l'accesso automatico senza rimuovere la modalità ancora necessaria agli altri visitatori. Visiti la pagina Purple Access per esplorare la licenza Connect e discutere un progetto pilota che comprenda la registrazione del profilo, i criteri basati sull'identità e le opzioni di fallback sui Suoi access point esistenti.
