Open Roaming WiFi Explicado: Faça login sem portais
Published
Se os seus pontos de acesso WiFi suportam OpenRoaming, por que um visitante ainda poderia ser incapaz de se conectar? Porque o login automático depende de mais do que o hardware de rádio. O dispositivo precisa de um perfil utilizável, um provedor de identidade deve autenticá-lo e o local deve aceitar as credenciais desse provedor.
Para equipes de TI e gerentes de locais, o OpenRoaming WiFi é mais bem compreendido como uma forma diferente de estabelecer confiança, não como uma promessa de que todos os visitantes se conectarão automaticamente. Ele pode eliminar telas de login repetidas, mas não remove sua responsabilidade pelas políticas de acesso, conexões de fallback ou privacidade.
Sumário
- O que o OpenRoaming substitui e por que os portais estão desaparecendo
- Comparação detalhada dos métodos de acesso para visitantes
- Como um dispositivo faz login sem solicitar
- Como validar uma implantação do OpenRoaming antes do lançamento oficial
- Relação entre privacidade e acesso automático
- Confirme seu plano piloto antes de substituir os portais de visitantes
O que o OpenRoaming substitui e por que os portais estão acabando
Um passageiro chega a um aeroporto, escolhe a rede de convidados e abre um navegador. Ele aguarda um portal cativo, insere um endereço de e-mail ou seleciona um login social e aceita os termos. No café fora do terminal, ele repete o processo.
Nada nesse segundo registro ajuda o dispositivo a lembrar que seu proprietário já possui uma identidade confiável em outro lugar. Cada local trata o visitante como uma nova tarefa de integração.
OpenRoaming, desenvolvido com base no WiFi CERTIFIED Passpoint, muda essa relação. Em vez de pedir que a pessoa preencha outro formulário no navegador, a rede pode aceitar uma credencial que o dispositivo já possui.
Pense em um cartão de fidelidade de hotel aceito em hotéis parceiros participantes, em vez de um formulário de cadastro que você precisa preencher em cada recepção. Cada hotel ainda decide quais portas esse cartão pode abrir.
O dispositivo porta a apresentação
O acordo possui participantes distintos:
- O dispositivo possui um perfil. Isso informa a ele quais redes participantes pode usar e qual credencial apresentar.
- O provedor de identidade atesta o usuário. Essa organização autentica a credencial em vez de exigir que cada local mantenha uma conta de visitante separada.
- O local autoriza o acesso. Ele aceita o resultado de autenticação confiável e decide quais recursos de rede o dispositivo pode alcançar.
Assim que o perfil existir, o dispositivo faz o trabalho de conexão de rotina. O visitante não precisa escolher um botão de login toda vez que entrar em um local participante.
O contraste é mais fácil de ver como uma mudança na jornada do visitante.
Menos interação não significa menos responsabilidade
Remover o formulário não significa conceder a cada visitante autenticado acesso ilimitado. O local ainda controla a atribuição de VLAN, a política de acesso e o registro de logs. Uma identidade de convidado reconhecida deve levar a permissões de convidado, não ao acesso a aplicativos de funcionários ou sistemas de gestão predial.
O onboarding automático também não elimina a necessidade de explicar o uso aceitável e o tratamento de dados. Esses avisos precisam de um local adequado na integração e nas comunicações contínuas do serviço, em vez de depender totalmente de uma interrupção por portal.
OpenRoaming é, portanto, uma estrutura de identidade de roaming federada, e não um produto de um único fornecedor WiFi. Seu valor prático vem da separação entre quem autentica o visitante e quem opera a rede, permitindo ao mesmo tempo que o local mantenha o controle.
Comparação direta dos métodos de acesso para convidados
| Método de acesso | O que o visitante faz | Portal exibido | Credencial mantida | Ideal para |
|---|---|---|---|---|
| Login de convidado no portal cativo | Abre uma página no navegador, escolhe um método de login e aceita os termos | Sim | Nenhuma, ou login por rede social ou SMS | Visitantes de primeira viagem sem perfil |
| Perfil do Passpoint ou do OpenRoaming | Instala o perfil uma vez; o dispositivo conecta-se automaticamente | Não | Perfil com certificado de identidade ou credencial | Visitantes recorrentes e viajantes frequentes |
| Rede segura de EAP-TLS | O dispositivo é registrado por meio do gerenciamento de dispositivos móveis | Não | Certificado do dispositivo | Dispositivos gerenciados pela equipe |
| Chave pré-compartilhada por dispositivo | O dispositivo conecta-se com sua própria chave exclusiva | Não | Chave exclusiva por dispositivo, usuário ou locatário | Residentes, caixas registradoras e frotas de IoT |
Um perfil só ajuda quando o dispositivo o suporta e seu provedor de identidade é aceito pelo local. Mantenha uma rota baseada em portal disponível para visitantes que não atendem a essas condições.
Associe o método à pessoa ou ao dispositivo
Um portal cativo continua sendo útil para quem chega sem uma relação estabelecida com a sua organização. Dependendo do serviço, o login pode utilizar SSO, Google, Apple, Facebook ou um código de acesso único via SMS, com a aceitação e o consentimento registrados adequadamente.
Um perfil Passpoint ou OpenRoaming é ideal para quem retorna ou viaja entre propriedades participantes. O Passpoint lida com a descoberta de rede baseada em perfil e a autenticação; o OpenRoaming adiciona a federação que permite que redes operadas de forma independente e provedores de identidade confiem uns nos outros. Eles estão relacionados, mas não são nomes intercambiáveis para todas as implantações.
EAP-TLS é adequado para equipamentos gerenciados da equipe, pois os administradores podem provisionar certificados de dispositivos por meio do gerenciamento de dispositivos móveis. Não se trata de uma federação de roaming concorrente. É um método de autenticação que também pode estar sob o acesso baseado em perfis.
Uma chave pré-compartilhada por dispositivo é adequada para equipamentos que precisam de uma credencial prática e individualmente revogável. Um caixa ou termostato não deve precisar de um navegador, e a desativação de um dispositivo não deve exigir a alteração de uma senha em toda a infraestrutura.
Planeje para a coexistência
Um local pode oferecer esses métodos lado a lado. Mapeie identidades para as VLANs apropriadas e aplique regras de firewall entre elas, em vez de presumir que apenas nomes de rede diferentes fornecem isolamento. Um convidado deve acessar a internet sem obter uma rota para sistemas de pagamento ou serviços de funcionários.
Ao comparar soluções de WiFi para WiFi visitantes, avalie a jornada de integração para cada público em vez de escolher um único método de login para todos.
O próprio perfil precisa de uma rota de inscrição. Um local ou provedor de identidade participante pode oferecer a instalação, mas a elegibilidade depende do relacionamento desse provedor com a rede de acesso. Teste as famílias de dispositivos que seus visitantes carregam, incluindo suas versões de sistema operacional e restrições de instalação de perfil.
Regra de decisão: Liste seus grupos de visitantes e dispositivos primeiro. Atribua a cada um um método de acesso principal, um proprietário para sua credencial e uma alternativa utilizável.
Esse exercício geralmente revela que o objetivo não é abolir os portais. É parar de pedir que usuários já elegíveis os preencham desnecessariamente.
Como um dispositivo faz login sem solicitar
- Descubra e coincida. O dispositivo lê os anúncios de rede 802.11u e ANQP e, em seguida, faz a correspondência de um Roaming Consortium Organization Identifier, ou RCOI, com um perfil armazenado. O visitante não seleciona manualmente um SSID.
- Inicie a autenticação. O dispositivo inicia uma troca de 802.1X usando um método Extensible Authentication Protocol, geralmente abreviado como EAP.
- Encaminhe a solicitação. O ponto de acesso ou seu controlador repassa a troca de autenticação para a infraestrutura de RADIUS do provedor de acesso.
- Localize o provedor de identidade. A infraestrutura de autenticação usa o realm na identidade do usuário para rotear a solicitação ao provedor apropriado.
- Verifique a credencial. O provedor de identidade valida o certificado, a credencial baseada em SIM ou as informações da conta e retorna um resultado de autenticação.
- Aplique permissões locais. A infraestrutura do local aplica a política de acesso e de VLAN autorizada antes de permitir o tráfego normal do usuário.
A visão geral da Wireless Broadband AllianceOpenRoaming descreve a combinação de Passpoint, identidade federada e política que suporta essa troca, incluindo roteamento baseado em domínio e confiança respaldada por certificados entre provedores.
A ordem é importante. Um portal cativo geralmente solicita que o navegador conclua uma etapa de acesso após o dispositivo ter se conectado à rede. Aqui, o dispositivo conclui a autenticação empresarial antes que o acesso a dados comum seja iniciado. O navegador não é a interface de autenticação.
Este diagrama mostra a mesma jornada a partir da perspectiva do dispositivo.
Qual credencial o dispositivo apresenta?
Um perfil não é necessariamente um certificado. Ele contém configurações que dizem ao dispositivo como descobrir e se autenticar em uma rede qualificada, e a credencial subjacente segue o método EAP selecionado.
| Método EAP | Credencial mantida pelo dispositivo | Rede típica |
|---|---|---|
| EAP-TLS | Certificado do cliente e chave privada associada | Dispositivos corporativos e gerenciados por gerenciamento 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 chave | Redes de assinantes de operadoras |
| EAP-AKA′ | Chave USIM com derivação de chave mais forte | Assinantes de operadoras em implantações AKA mais recentes |
| EAP-TTLS | Nome de usuário e senha dentro de um túnel TLS | Contas de funcionários ou convidados autenticadas por meio de um servidor com certificado validado |
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 as credenciais 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 importa durante o processo de aquisição. Um ponto de acesso compatível com Passpoint não garante que todos os tipos de credencial da sua população de visitantes pretendida funcionarão em todo o caminho de autenticação.
A confiança também existe entre provedores
O RadSec transporta sinalização RADIUS sobre TLS entre as infraestruturas participantes. O TLS mútuo permite que os pares se validem utilizando certificados, de modo que a emissão de certificados, raízes confiáveis, renovação e expiração exijam responsabilidade operacional.
A descoberta de pares de RADIUS baseada em DNS ajuda um provedor de acesso a localizar o par de autenticação apropriado para um domínio de identidade. Isso evita tratar cada novo provedor como um motivo para reconfigurar pontos de acesso individuais, embora a política de roteamento e federação ainda precise permitir o relacionamento.
Antes de um teste ao vivo, um engenheiro deve confirmar o perfil instalado, os RCOIs anunciados, o roteamento de domínio e os métodos EAP suportados como uma única cadeia. Capture os logs do cliente e de autenticação juntos: um dispositivo que nunca seleciona a rede tem uma falha diferente daquele cujas credenciais são rejeitadas após uma descoberta bem-sucedida.
Como validar uma implantação de OpenRoaming antes do lançamento oficial
Em uma pesquisa da WBA de 2025 com 170 executivos do setor, 81% planejavam implantar o OpenRoaming, enquanto 25% já o estavam implementando, de acordo com a análise da pesquisa da WBA feita pela CDG. Essas são métricas de planejamento e implantação, não uma prova de que um visitante específico possa se conectar no seu local.
Use uma lista de verificação de preparação para transformar uma alegação de infraestrutura compatível em uma jornada do usuário testada.
Teste a cadeia de autenticação completa
- Confirme a participação na federação. Identifique quem emite as credenciais e como o local confia nesse provedor. Registre o responsável pelo suporte de cada lado.
- Testes perfis de clientes reais. Utilize as famílias de dispositivos que seu local atende, incluindo um dispositivo de visitante não gerenciado, em vez de apenas o laptop preparado de um engenheiro.
- Verifique a correspondência de RCOI e realm. Compare os anúncios e o roteamento com a configuração do provedor para que uma falha de identificação não seja confundida com uma senha incorreta.
- Inspecione as cadeias de certificados e a expiração. Verifique a confiança da autenticação voltada ao cliente e a confiança entre pares RadSec separadamente.
- Valide a descoberta de pares. Confirme se a descoberta baseada em DNS atinge a infraestrutura de autenticação pretendida.
- Interrompa o caminho preferencial deliberadamente. Teste um provedor indisponível e um perfil não suportado e, em seguida, verifique se o visitante consegue encontrar e usar a alternativa do portal.
- Verifique as políticas e a medição. Confirme o posicionamento, o isolamento e a contabilização do VLAN entre os operadores, incluindo o que sua análise de visitantes pode observar.
- Ensaiador a revogação. Desative a credencial de um dispositivo perdido e teste tanto a autenticação subsequente quanto o tratamento de uma sessão existente.
Uma disciplina útil de testes é avaliar a relevância do teste além dos resultados positivos, conforme abordado pela 99tests. Uma conexão bem-sucedida a partir de um telefone de teste pré-configurado não prova que a jornada de chegada funcione para os visitantes pretendidos.
Defina uma etapa de liberação explícita
Faça das dependências de autenticação parte do seu WiFi design de rede, e não algo pensado após a cobertura de rádio. Rastreie falhas no cliente, ponto de acesso, RADIUS e provedor de identidade.
Newcastle opera a primeira rede de OpenRoaming em toda a cidade no Purple, e somos um provedor de identidade certificado pela WBA. Essas credenciais não substituem os testes de aceitação em nível de local.
Aprovação ou reprovação: Exija que as verificações de descoberta, confiança, autenticação e alternância sejam aprovadas 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
Autenticação segura não é uso anônimo. Um dispositivo pode se conectar sem digitar um nome em um portal e, ao mesmo tempo, gerar registros que o diferenciam de outros dispositivos e o associam a um local.
O anúncio de certificação OpenRoaming da Westermo oferece um contexto para a autenticação intermediada por provedor de identidade e identificadores persistentes. A questão prática para um local não é se o acesso é criptografado. É quem pode ver quais identificadores, para qual finalidade e por quanto tempo.
Uma conexão automática pode parecer imperceptível para o visitante, mesmo que várias organizações participem nos bastidores.
Autenticação e anonimato respondem a perguntas diferentes
O provedor de identidade pode autenticar alguém sem fornecer a senha dessa pessoa ao local. O local pode, no entanto, receber as informações necessárias para autorizar o acesso, atribuir políticas, contabilizar uma sessão ou investigar abusos.
Dependendo do provedor, da rede, do contrato e da legislação aplicável, os registros podem incluir eventos de autenticação, registros de auditoria/contabilidade, identificadores de dispositivo, informações de localização ou identificadores pseudônimos. Um pseudônimo não é automaticamente anônimo: uma organização pode ser capaz de vincular sessões repetidas ou conectar esse identificador a uma conta.
Considere um visitante de um estádio cujo acesso destina-se apenas a um evento. O operador deve definir quais registros de conexão permanecem depois e o motivo. Não trate uma credencial de acesso a eventos útil como uma permissão para criar um histórico de frequência por tempo indeterminado.
O dispositivo gerenciado de um funcionário apresenta um caso diferente. Suas credenciais podem permanecer ativas durante todo o período de emprego, mas isso não justifica reter todas as sessões vinculadas à localização pelo mesmo período. A validade da credencial, a retenção de logs de segurança e a retenção de dados de engajamento precisam de decisões separadas.
O vídeo oferece uma maneira adicional de explicar a conectividade automática aos stakeholders.
Torne o fluxo de dados auditável
Inclua estas perguntas em sua análise de segurança da rede de WiFi para visitantes:
- Divulgação do provedor de identidade. Nomeie as organizações envolvidas e explique o que cada uma recebe, incluindo qualquer processamento transfronteiriço.
- Validação de certificado. Registre quem possui as configurações de confiança e como as alterações são revisadas.
- Identificadores pseudônimos. Estabeleça se eles persistem, quem pode resolvê-los e se conjuntos de dados separados podem ser vinculados.
- Registros contábeis. Especifique os campos coletados e quem pode acessá-los ou exportá-los.
- Prazos de retenção. Atribua uma finalidade e uma regra de exclusão para cada categoria de registro, incluindo backups.
- Aviso ao usuário e consentimento. Identifique as funções dos controladores de dados, a base de processamento relevante e como menores, funcionários, residentes e visitantes são informados.
- Revogação imediata de credenciais. Ofereça aos usuários um canal claro para relatar dispositivos perdidos e aos operadores uma ação testada.
O consentimento não é um substituto universal para determinar a base legal apropriada, e uma página de política oculta não é um aviso significativo. Peça que os responsáveis jurídicos e de privacidade analisem o fluxo real, em vez de uma descrição genérica de WiFi seguro.
O acesso com dados mínimos é uma escolha de design. O login automático por si só não o proporciona.
Confirme 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 em um ambiente controlado. Escolha um local onde você possa observar tanto usuários recorrentes quanto pessoas que chegam sem nenhum perfil existente.
Forneça ao piloto uma decisão mensurável
- Escolha um local representativo. Inclua a equipe da recepção ou do local no teste para que possam relatar instruções confusas de cadastro e de contingência.
- Mantenha a rota de visitantes existente. Facilite a localização do nome da rede e das instruções para os visitantes fora do piloto.
- Cadastre um grupo definido. Comece com dispositivos gerenciados da equipe e visitantes recorrentes cujas elegibilidades de perfil você possa verificar.
- Meça a experiência de chegada. Registre o sucesso da conexão na primeira tentativa, falhas de autenticação e a frequência com que usuários elegíveis ainda precisam do portal. Separe falhas de descoberta de rejeições de credenciais.
- Documente os fluxos de dados. Aprove a retenção, os avisos, as permissões de acesso e o tratamento de dispositivos perdidos antes de expandir o grupo.
- Expanda com base em critérios de aceitação. Acorde o que constitui o sucesso antes de revisar os resultados e mantenha um responsável pela reversão (rollback) disponível.
Não meça o sucesso unicamente pela ausência de um portal. Um dispositivo que se conecta à rede VLAN errada ou deixa um visitante impossibilitado de encontrar um acesso alternativo não foi aprovado.
Avalie o serviço sob o mesmo teste
Se você estiver avaliando nosso serviço, o Purple Access dá suporte ao Passpoint e ao OpenRoaming, e nossa licença Connect gratuita inclui o portal de convidados e o OpenRoaming gratuito. Convidados recorrentes usam um perfil na rede Secure sem precisar passar por um portal ao retornar, e esse perfil funciona em todas as propriedades que o executam. Teste esses comportamentos com seu mix de dispositivos e confirme o licenciamento e os preços de quaisquer recursos adicionais antes de incluí-los na implantação.
O motivo mais forte para prosseguir é uma melhoria comprovada para um público específico, e não a disponibilidade de uma nova configuração de ponto de acesso. Mantenha o piloto focado nas pessoas cuja jornada de conexão você pode melhorar de forma significativa.
Qual grupo de visitantes perde mais tempo no portal hoje, e um perfil resolve o problema desse grupo?
O Purple Access oferece um portal de convidados junto com o Passpoint e o OpenRoaming, para que você possa testar o acesso automático sem remover a rota de que outros visitantes ainda precisam. Visite o Purple Access para explorar a licença Connect e discutir um piloto que cubra a inscrição de perfil, políticas baseadas em identidade e fallback em seus pontos de acesso existentes.
