Open roaming WiFi explicado: Inicie sessão sem portais
Published
Se os seus pontos de acesso WiFi WiFi suportarem OpenRoaming, por que razão um visitante poderá continuar sem conseguir ligar-se? Porque o início de sessão automático depende de mais do que o hardware de rádio. O dispositivo necessita de um perfil utilizável, um fornecedor de identidade tem de o autenticar e o local tem de aceitar as credenciais desse fornecedor.
Para as equipas de TI e gestores de instalações, o OpenRoaming WiFi é melhor compreendido como uma forma diferente de estabelecer confiança, e não como uma promessa de que todos os visitantes se ligarão automaticamente. Pode eliminar ecrãs de início de sessão repetidos, mas não elimina a sua responsabilidade em relação à política de acesso, ligações de recurso ou privacidade.
Índice
- O que o OpenRoaming substitui e porque os portais estão a desaparecer
- Comparação lado a lado dos métodos de acesso de convidados
- Como um dispositivo se liga sem pedir autorização
- Como validar a implementação do OpenRoaming antes do lançamento
- Compromissos de privacidade por trás do acesso automático
- Confirme o seu plano piloto antes de substituir os portais de convidados
O que o OpenRoaming substitui e a razão pela qual os portais estão a desaparecer
Um viajante chega a um aeroporto, escolhe a rede de convidados e abre um navegador. Aguarda por um portal cativo, insere um endereço de e-mail ou seleciona um início de sessão social e aceita os termos. No café fora do terminal, repete o processo.
Nada nesse segundo registo ajuda o dispositivo a recordar-se de que o seu proprietário já possui uma identidade de confiança noutro local. Cada local trata o visitante como uma nova tarefa de integração.
OpenRoaming, baseado em Wi-Fi CERTIFIED Passpoint, altera essa relação. Em vez de pedir à pessoa para preencher outro formulário no navegador, a rede pode aceitar uma credencial que o dispositivo já possui.
Pense num cartão de fidelização de hotel aceite em hotéis parceiros participantes, em vez de um formulário de registo que tem de preencher em cada receção. Cada hotel continua a decidir quais as portas que esse cartão pode abrir.
O dispositivo fornece a apresentação
O acordo inclui participantes distintos:
- O dispositivo possui um perfil. Isto indica-lhe quais as redes participantes que pode utilizar e que credencial apresentar.
- O fornecedor de identidades atesta o utilizador. Essa organização autentica a credencial em vez de exigir que cada local mantenha uma conta de visitante separada.
- O local autoriza o acesso. Aceita o resultado de autenticação de confiança e decide quais os recursos de rede que o dispositivo pode alcançar.
Assim que o perfil existir, o dispositivo executa o trabalho de ligação de rotina. O visitante não tem de escolher um botão de início de sessão sempre que entra num local participante.
O contraste é mais fácil de ver como uma mudança na experiência do visitante.
Menos interação não significa menos responsabilidade
Eliminar o formulário não significa conceder acesso ilimitado a todos os visitantes autenticados. O local continua a controlar a atribuição de VLAN, a política de acesso e o registo de dados. Uma identidade de convidado reconhecida deve dar origem a permissões de convidado, e não ao acesso a aplicações de funcionários ou a sistemas de gestão do edifício.
O acesso automático também não elimina a necessidade de explicar a utilização aceitável e o tratamento de dados. Esses avisos precisam de um local adequado no registo e nas comunicações contínuas do serviço, em vez de dependerem inteiramente da interrupção por um portal.
OpenRoaming é, portanto, uma estrutura de identidade de roaming federada, e não o produto WiFi de um fornecedor específico. O seu valor prático advém da separação entre quem autentica o visitante e quem opera a rede, permitindo ao mesmo tempo que o local mantenha o controlo.
Comparação lado a lado dos métodos de acesso para convidados
| Método de acesso | Ação do visitante | Portal apresentado | Credencial mantida | Ideal para |
|---|---|---|---|---|
| Inicio de sessão de visitante no portal cativo | Abre uma página do navegador, escolhe um método de início de sessão e aceita os termos | Sim | Nenhuma, ou início de sessão social ou por SMS | Visitantes pela primeira vez sem perfil |
| Perfil Passpoint ou OpenRoaming | Instala o perfil uma vez; o dispositivo liga-se automaticamente | Não | Perfil com certificado de identidade ou credencial | Visitantes recorrentes e viajantes frequentes |
| Rede segura EAP-TLS | O dispositivo regista-se através da gestão de dispositivos móveis | Não | Certificado de dispositivo | Dispositivos geridos pelo pessoal |
| Chave pré-partilhada por dispositivo | O dispositivo liga-se com a sua própria chave exclusiva | Não | Chave exclusiva por dispositivo, utilizador ou inquilino | Residentes, caixas registadoras e frotas de IoT |
Um perfil só ajuda quando o dispositivo o suporta e o seu fornecedor de identidade é aceite pelo local. Mantenha uma rota baseada em portal disponível para visitantes que não cumpram essas condições.
Adapte o método à pessoa ou ao dispositivo
Um portal cativo continua a ser útil para alguém que chegue sem uma relação estabelecida com a sua organização. Dependendo do serviço, o início de sessão pode utilizar SSO, Google, Apple, Facebook ou um código de acesso único por SMS, com a aceitação e o consentimento registados adequadamente.
Um perfil Passpoint ou OpenRoaming adequa-se a quem regressa ou viaja entre propriedades participantes. O Passpoint gere a deteção de rede e a autenticação baseadas em perfis; o OpenRoaming adiciona a federação que permite que redes e fornecedores de identidade operados de forma independente confiem uns nos outros. Estão relacionados, mas não são nomes intermutáveis para todas as implementações.
EAP-TLS adequa-se a equipamentos de funcionários geridos porque os administradores podem aprovisionar certificados de dispositivo através de uma gestão de dispositivos móveis. Não é uma federação de roaming concorrente. É um método de autenticação que também pode estar por baixo de um acesso baseado em perfis.
Uma chave pré-partilhada por dispositivo adequa-se a equipamentos que necessitam de uma credencial prática e revogável individualmente. Uma caixa registadora ou um termóstato não devem precisar de um navegador, e a desativação de um dispositivo não deve exigir a alteração da palavra-passe em toda a infraestrutura.
Planeie a coexistência
Um local pode disponibilizar estes métodos em simultâneo. Mapeie as identidades para as VLANs adequadas e aplique regras de firewall entre elas, em vez de presumir que nomes de rede diferentes garantem isolamento por si só. Um convidado deve conseguir aceder à internet sem obter uma rota para sistemas de pagamento ou serviços de colaboradores.
Ao comparar soluções de WiFi para visitantesWiFi, avalie a jornada de adesão para cada público em vez de escolher um único método de início de sessão para todos.
O próprio perfil necessita de uma rota de inscrição. Um local ou um fornecedor de identidade participante pode oferecer a instalação, mas a elegibilidade depende da relação desse fornecedor com a rede de acesso. Teste as famílias de dispositivos que os seus visitantes utilizam, incluindo as respetivas versões de sistema operativo e restrições de instalação de perfis.
Regra de decisão: Liste primeiro os seus grupos de visitantes e dispositivos. Atribua a cada um um método de acesso principal, um responsável pela sua credencial e uma alternativa utilizável.
Esse exercício revela frequentemente que o objetivo não é abolir os portais. É deixar de solicitar o seu preenchimento desnecessário a utilizadores que já são elegíveis.
Como um dispositivo se autentica sem pedir permissão
- Detetar e corresponder. O dispositivo lê os anúncios de rede 802.11u e ANQP e, em seguida, estabelece a correspondência entre um Roaming Consortium Organization Identifier, ou RCOI, e um perfil armazenado. O visitante não seleciona manualmente um SSID.
- Iniciar a autenticação. O dispositivo inicia uma troca de 802.1X através de um método Extensible Authentication Protocol, habitualmente abreviado para EAP.
- Encaminhar o pedido. O ponto de acesso ou o respetivo controlador passa a troca de autenticação para a infraestrutura de RADIUS do fornecedor de acesso.
- Localizar o fornecedor de identidades. A infraestrutura de autenticação utiliza o domínio na identidade do utilizador para encaminhar o pedido para o fornecedor adequado.
- Verificar a credencial. O fornecedor de identidades valida o certificado, a credencial baseada em SIM ou as informações da conta e devolve um resultado de autenticação.
- Aplicar permissões locais. A infraestrutura do local aplica a VLAN autorizada e a política de acesso antes de permitir o tráfego normal do utilizador.
A visão geral da Wireless Broadband AllianceOpenRoaming sobre o descreve a combinação de Passpoint, identidade federada e política que suporta esta troca, incluindo o encaminhamento baseado em domínios (realms) e a confiança fundamentada em certificados entre fornecedores.
A ordem importa. Um portal cativo pede habitualmente ao navegador para concluir um passo de acesso após o dispositivo se ter associado à rede. Aqui, o dispositivo conclui a autenticação empresarial antes de o acesso a dados normal ser iniciado. O navegador não é a interface de autenticação.
Este diagrama mostra a mesma jornada sob a perspetiva do dispositivo.
Qual é a credencial apresentada pelo dispositivo?
Um perfil não é necessariamente um certificado. Contém a configuração que indica ao dispositivo como detetar e autenticar numa rede elegível, e a credencial subjacente segue o método EAP selecionado.
| Método EAP | Credencial que o dispositivo detém | Rede típica |
|---|---|---|
| EAP-TLS | Certificado de cliente e chave privada associada | Dispositivos empresariais e geridos por gestão de dispositivos móveis |
| EAP-SIM | Chave do cartão SIM | Assinantes de operadoras móveis |
| EAP-AKA | Chave USIM para autenticação e acordo de chaves | Redes de assinantes de operadoras |
| EAP-AKA′ | Chave USIM com derivação de chave mais forte | Assinantes de operadoras em implementações AKA mais recentes |
| EAP-TTLS | Nome de utilizador e palavra-passe num túnel TLS | Contas de colaboradores ou visitantes autenticadas através de um servidor validado por certificado |
Com o EAP-TLS, o dispositivo comprova a posse da chave privada associada ao seu certificado. Com métodos baseados em SIM, a infraestrutura de autenticação da operadora valida a credencial do assinante. Com o EAP-TTLS, o cliente deve validar o certificado do servidor de autenticação antes de enviar as credenciais internas.
Essa distinção é importante durante a aquisição. Um ponto de acesso compatível com Passpoint não garante que todos os tipos de credenciais da sua população de visitantes pretendida funcionem ao longo de todo o caminho de autenticação.
Também existe confiança entre os fornecedores
O RadSec transporta sinalização RADIUS sobre TLS entre infraestruturas participantes. O TLS mútuo permite que os pares se validem mutuamente utilizando certificados, pelo que a emissão de certificados, as raízes de confiança, a renovação e a expiração exigem a responsabilidade pela operação.
A deteção de pares RADIUS baseada em DNS ajuda um fornecedor de acesso a localizar o par de autenticação adequado para um domínio de identidade. Evita tratar cada novo fornecedor como uma razão para reconfigurar pontos de acesso individuais, embora a política de encaminhamento e federação ainda tenha de permitir a relação.
Antes de um teste em ambiente real, um engenheiro deve confirmar o perfil instalado, os RCOIs anunciados, o encaminhamento de domínios (realms) e os métodos EAP suportados como uma única cadeia. Registe simultaneamente os registos do cliente e de autenticação: um dispositivo que nunca seleciona a rede apresenta uma falha diferente daquele cuja credencial é rejeitada após a deteção bem-sucedida.
Como validar uma implementação do OpenRoaming antes da entrada em funcionamento
Num inquérito da WBA de 2025 a 170 executivos do setor, 81% planeavam implementar o OpenRoaming, enquanto 25% já o estavam a lançar, de acordo com a análise da CDG sobre o inquérito da WBA. Estas são métricas de planeamento e lançamento, não uma prova de que um visitante específico se possa ligar no seu local.
Utilize uma lista de verificação de preparação para transformar a alegação de uma infraestrutura compatível numa jornada do utilizador testada.
Testar a cadeia de autenticação completa
- Confirme a participação na federação. Identifique quem emite as credenciais e de que forma o local confia nesse fornecedor. Registe o responsável pelo suporte de ambos os lados.
- Testar perfis de clientes reais. Utilize as famílias de dispositivos a que o seu local presta serviço, incluindo um dispositivo de visitante não gerido em vez de apenas o portátil preparado de um engenheiro.
- Verifique a correspondência de RCOI e domínio. Compare os anúncios e o encaminhamento com a configuração do fornecedor para que uma divergência na deteção não seja confundida com uma palavra-passe incorreta.
- Inspecione as cadeias de certificados e a expiração. Verifique a confiança da autenticação do lado do cliente e a confiança de pares RadSec em separado.
- Valide a deteção de pares. Confirme que a deteção baseada em DNS alcança a infraestrutura de autenticação pretendida.
- Interrompa o caminho preferencial deliberadamente. Teste um fornecedor indisponível e um perfil não suportado e, em seguida, verifique se o visitante consegue encontrar e utilizar a alternativa do portal.
- Verifique as políticas e a medição. Confirme a colocação de VLAN, o isolamento e a contabilização entre operadores, incluindo o que a sua análise de visitantes consegue observar.
- Ensaiar a revogação. Desative a credencial de um dispositivo perdido e teste tanto a autenticação subsequente como o tratamento de uma sessão existente.
Uma disciplina útil de teste consiste em avaliar a relevância dos testes além dos resultados positivos, conforme abordado pela 99tests. Uma ligação bem-sucedida a partir de um telefone de teste pré-configurado não prova que a jornada de chegada funcione para os visitantes previstos.
Defina uma condição explícita de aprovação
Torne as dependências de autenticação parte do seu WiFi design de rede, e não algo pensado à última hora para a cobertura de rádio. Rastreie falhas no cliente, ponto de acesso, RADIUS e fornecedor de identidade.
Newcastle opera a primeira rede OpenRoaming em toda a cidade no Purple, e nós somos um agente de identidade certificado pela WBA. Essas credenciais não substituem os testes de aceitação ao nível do local.
Avançar ou não avançar: Exija que as verificações de deteção, confiança, autenticação e alternativa (fallback) sejam bem-sucedidas em famílias de dispositivos contrastantes antes de considerar a remoção do portal para um público definido.
Compromissos de privacidade por trás do acesso automático
A autenticação segura não é a utilização anónima. Um dispositivo pode ligar-se sem introduzir um nome num portal, enquanto continua a gerar registos que o distinguem de outros dispositivos e o associam a uma localização.
O anúncio de certificação OpenRoaming da Westermo fornece o contexto para a autenticação mediada por fornecedores de identidade e identificadores persistentes. A questão prática para um local não é se o acesso está encriptado. É quem pode ver quais identificadores, para que finalidade e por quanto tempo.
Uma ligação automática pode parecer um processo simples para o visitante, embora várias organizações participem em segundo plano.
Autenticação e anonimato respondem a perguntas diferentes
O fornecedor de identidade pode autenticar alguém sem fornecer a sua palavra-passe ao local. O local pode, contudo, receber as informações necessárias para autorizar o acesso, atribuir políticas, contabilizar uma sessão ou investigar abusos.
Dependendo do fornecedor, rede, acordo e legislação aplicável, os registos podem incluir eventos de autenticação, registos contabilísticos, identificadores de dispositivos, informações de localização ou identificadores pseudónimos. Um pseudónimo não é automaticamente anónimo: uma organização pode ser capaz de associar sessões repetidas ou ligar esse identificador a uma conta.
Considere o visitante de um estádio cujo acesso se destina apenas a um evento. O operador deve definir quais os registos de ligação que permanecem posteriormente e porquê. Não trate uma credencial útil de acesso a um evento como uma permissão para construir um histórico de presenças indeterminado.
O dispositivo gerido de um colaborador apresenta um caso diferente. A sua credencial pode permanecer ativa durante todo o período de trabalho, mas isso não justifica a retenção de todas as sessões associadas à localização pelo mesmo período. A validade das credenciais, a retenção de registos de segurança e a retenção de dados de envolvimento exigem decisões separadas.
O vídeo oferece uma forma adicional de explicar a conetividade automática aos intervenientes.
Torne o fluxo de dados auditável
Inclua estas perguntas na sua análise de segurança da rede de WiFi para visitantes:
- Divulgação do fornecedor de identidade. Identifique as organizações envolvidas e explique o que cada uma recebe, incluindo qualquer processamento transfronteiriço.
- Validação de certificados. Registe quem detém as definições de confiança e como são revistas as alterações.
- Identificadores pseudónimos. Estabeleça se estes persistem, quem os pode resolver e se conjuntos de dados distintos podem ser associados.
- Registos de contabilidade. Especifique os campos recolhidos e quem os pode aceder ou exportar.
- Períodos de conservação. Atribua uma finalidade e uma regra de eliminação a cada categoria de registos, incluindo cópias de segurança.
- Aviso e consentimento do utilizador. Identifique as funções de responsável pelo tratamento de dados, o fundamento de processamento relevante e a forma como os menores, colaboradores, residentes e visitantes são informados.
- Revogação imediata de credenciais. Ofereça aos utilizadores um canal claro para comunicação de perda de dispositivos e aos operadores uma ação testada.
O consentimento não é um substituto universal para determinar a base legal adequada, e uma página de política oculta não é um aviso significativo. Peça aos responsáveis jurídicos e de privacidade que revejam o fluxo real, em vez de uma descrição genérica de WiFi seguro WiFi.
O acesso com recolha mínima de dados é uma opção de conceção. O início de sessão automático por si só não o proporciona.
Confirme o seu plano piloto antes de substituir os portais de visitantes
Comece com um piloto delimitado após as verificações de aceitação técnica serem bem-sucedidas num ambiente controlado. Escolha um local onde possa observar tanto utilizadores recorrentes como pessoas que chegam sem qualquer perfil existente.
Defina uma decisão mensurável para o projeto-piloto
- Escolha um local representativo. Inclua o pessoal da receção ou do espaço no teste para que possam comunicar instruções de registo e de recurso confusas.
- Mantenha a rota de convidados existente. Certifique-se de que o nome da rede e as respetivas instruções são fáceis de encontrar para os visitantes fora do projeto piloto.
- Registe um grupo definido. Comece com dispositivos geridos de funcionários e convidados habituais cuja elegibilidade de perfil possa verificar.
- Meça a experiência de chegada. Registe o sucesso de ligação à primeira tentativa, as falhas de autenticação e a frequência com que os utilizadores elegíveis ainda precisam do portal. Separe as falhas de deteção da rejeição de credenciais.
- Documente os fluxos de dados. Aprove a retenção, o aviso, as permissões de acesso e a gestão de dispositivos perdidos antes de expandir o grupo.
- Expanda de acordo com os critérios de aceitação. Acorde o que constitui o sucesso antes de rever os resultados e mantenha um responsável pela reversão disponível.
Não meça o sucesso apenas pela ausência de um portal. Um dispositivo que se junta ao VLAN errado ou deixa um visitante sem conseguir encontrar um acesso alternativo não foi aprovado.
Avalie o serviço com base no mesmo teste
Se está a avaliar o nosso serviço, o Purple Access suporta Passpoint e OpenRoaming, e a nossa licença Connect gratuita inclui o portal de convidados e OpenRoaming gratuito. Os convidados recorrentes utilizam um perfil na rede Segura sem portal ao regressar, e esse perfil funciona em todas as propriedades que o executem. Teste esses comportamentos no seu conjunto de dispositivos e confirme o licenciamento e os preços de quaisquer capacidades adicionais antes de as incluir no lançamento.
A razão mais forte para prosseguir é uma melhoria demonstrada para um público específico, e não a disponibilidade de uma nova configuração no ponto de acesso. Mantenha o piloto focado nas pessoas cuja experiência de ligação pode melhorar significativamente.
Qual o grupo de visitantes que perde mais tempo no portal atualmente, e um perfil resolve o problema desse grupo?
O Purple Access oferece um portal de convidados em conjunto com o Passpoint e o OpenRoaming, para que possa testar o acesso automático sem remover a rota que os outros visitantes ainda necessitam. Visite o Purple Access para explorar a licença Connect e discutir um projeto-piloto que inclua a inscrição de perfis, políticas baseadas em identidade e suporte alternativo nos seus pontos de acesso existentes.
