Como Habilitar Single Sign On

A manhã de segunda-feira começa antes da chegada dos hóspedes. Na troca de turno de um hotel, a equipe da noite sai, a equipe do dia chega e três laptops de funcionários ficam travados no Captive Portal porque alguém alterou a senha compartilhada do WiFi e esqueceu de atualizar o quadro branco do escritório. Um funcionário pesquisa um chamado antigo, outro pergunta ao supervisor e o terceiro desiste e usa um ponto de acesso pessoal.

Isso não é um problema de cobertura WiFi. É um problema de identidade. O logon único, ou SSO, permite que os funcionários se autentiquem com sua identidade de trabalho existente e obtenham acesso à rede de funcionários sem outra solicitação de senha compartilhada. Este guia explica como habilitar o logon único em um SSID de funcionários gerenciado pela Purple, escolher o provedor de identidade correto, configurar a federação, testar o resultado e manter a implantação segura quando algo der errado.

Por que as Redes de Funcionários Precisam de Single Sign-On

Chaves compartilhadas falham de maneiras previsíveis. Os funcionários as anotam em post-its, colam em sistemas de chamados, repetem pelo rádio e continuam usando depois que alguém sai da empresa. Um estabelecimento pode alterar a chave para resolver um problema de acesso, apenas para criar uma nova fila de solicitações de login na próxima troca de turno.

O custo operacional aparece em pequenas interrupções. Um recepcionista espera por uma redefinição durante o check-in, uma enfermeira perde tempo reconectando uma estação de trabalho e um supervisor de varejo liga para o suporte porque um dispositivo portátil não consegue se conectar ao SSID da equipe. Esses atrasos são difíceis de medir individualmente, mas ocorrem sempre que a rede trata toda uma força de trabalho como uma única conta.

O SSO altera a unidade de acesso da senha compartilhada para a identidade individual. Um funcionário faz login por meio do provedor de identidade da organização, e a rede aplica a política de acesso associada a essa pessoa ou ao seu grupo. Quando o funcionário muda de departamento, sua associação ao grupo pode mudar junto com ele. Quando ele sai, desativar a conta do diretório pode remover o acesso sem alterar uma senha usada por todos os outros.

Para organizações do setor público do Reino Unido, o problema da fragmentação já é visível em escala nacional. O guia de autenticação e identidade digital do GOV.UK relatou estimadas 121 soluções de single sign-on em todo o governo em 2021, juntamente com cerca de 191 métodos de configuração de conta e 44 métodos de login. O GOV.UK One Login foi criado como uma camada de autenticação comum, e a mesma atualização relatou que ele havia sido usado por mais de 1,5 milhão de pessoas para comprovar sua identidade até julho de 2023, enquanto seu aplicativo complementar havia sido baixado 2 milhões de vezes.

O que o SSID da equipe deve impor

Uma rede para funcionários gerenciada pela Purple oferece ao local um espaço prático para conectar a identidade de trabalho com o acesso wireless. A abordagem de rede baseada em identidade separa o acesso dos funcionários do acesso dos convidados e permite que a política de rede acompanhe a identidade autenticada, em vez de uma credencial impressa em um quadro de avisos.

Isso importa por razões que vão além da conveniência:

• Transição de turno: Os funcionários podem usar suas próprias credenciais de trabalho em vez de pedir uma chave ao turno anterior.
• Desligamento: A desativação no diretório pode remover o acesso sem forçar todos os colegas a se reconectarem.
• Auditabilidade: Os eventos de rede podem ser associados a pessoas ou grupos em vez de uma PSK anônima.
• Segmentação: Os grupos podem ser mapeados para SSIDs de funcionários, VLANs ou políticas de Captive Portal apropriadas ao seu cargo.
• Higiene de conformidade: É menos provável que credenciais confidenciais apareçam em chamados de suporte ou documentos compartilhados.

O SSO não elimina a necessidade de um design de rede sem fio resiliente, gerenciamento de dispositivos ou controles de acesso adequados. Ele elimina a armadilha das credenciais compartilhadas, que geralmente é o caminho mais curto para tornar o WiFi da equipe gerenciável.

Fluxos de Autenticação que Impulsionam o SSO de Funcionários

O fluxo que você escolhe depende de onde a autenticação ocorre e do que o seu equipamento de rede compreende. O provedor de identidade pode emitir a asserção, mas um ponto de acesso ainda precisa de um mecanismo para decidir se um dispositivo pode se conectar ao SSID.

O SAML 2.0 é o cavalo de batalha corporativo mais comum. O Entra ID e o Okta podem emitir uma asserção assinada contendo um identificador estável, endereço de e-mail e informações de grupo. O provedor de serviços valida essa asserção e cria a sessão autenticada. O SAML atende a organizações que já o utilizam para aplicativos SaaS e desejam que um único diretório permaneça como a fonte da verdade.

O OpenID Connect, ou OIDC, usa tokens modernos baseados em JSON. Ele se adapta particularmente bem ao Google Workspace e a aplicativos mais novos, e sua estrutura de token pode ser mais fácil de inspecionar durante a resolução de problemas. Plataformas wireless mais antigas nem sempre falam OIDC diretamente, de modo que o fluxo ainda pode precisar de um intermediário ou gateway antes que o ponto de acesso possa aplicar a decisão.

O RADIUS continua sendo a ponte entre a identidade e o WiFi corporativo. Um autenticador 802.1X, normalmente o ponto de acesso ou controlador sem fio, envia solicitações de autenticação para um serviço RADIUS. Esse serviço pode ser o Cloud RADIUS, o Microsoft NPS, um servidor RADIUS local ou um provedor gerenciado. Mesmo quando o usuário começa em um provedor de identidade SAML, o RADIUS geralmente fica entre o sistema de identidade e a infraestrutura sem fio.

A autenticação baseada em certificado usa um certificado de máquina e, às vezes, um certificado de usuário para estabelecer uma conexão de alta confiança. Hospitais, laboratórios e ambientes comerciais podem preferir essa abordagem para dispositivos gerenciados porque o certificado é emitido pela política do dispositivo, em vez de ser digitado por um funcionário. Isso exige mais preparação, especialmente em relação ao registro, renovação e revogação de certificados, mas reduz a dependência da inserção interativa de senhas.

Visão geral dos fluxos de autenticação SSO para funcionários

Fluxo	Melhor Ajuste	IdP Típico	UX do Funcionário
SAML 2.0	Federação corporativa e acesso baseado em grupo	Entra ID ou Okta	Login no navegador, seguido por uma sessão autenticada
OIDC	Aplicações modernas e integrações baseadas em JSON	Google Workspace ou um IdP compatível com OIDC	Autenticação web familiar com federação baseada em token
RADIUS	Acesso sem fio 802.1X e equipamentos de rede legados	Cloud RADIUS, NPS ou um provedor gerenciado	O dispositivo se conecta ao SSID após a autenticação de rede
Autenticação baseada em certificado	Dispositivos gerenciados e ambientes de alta confiança	PKI corporativa com integração de diretório	Geralmente silenciosa após o registro do certificado

Um SSID de funcionários da Purple pode interligar essas camadas. O IdP estabelece a identidade, o RADIUS intermedia a autenticação de rede onde for necessário, o ponto de acesso impõe o resultado e o painel do Purple oferece aos administradores uma visão operacional do evento de login. Se o MFA faz parte do seu projeto, trate-o como um controle de identidade, e não como um substituto para a segmentação de rede. A visão geral de MFA da Networking2000 é um material de apoio útil ao decidir como um segundo fator se encaixa no fluxo de SSO.

Regra prática: Use SAML quando seus aplicativos corporativos já dependerem dele, OIDC para integrações modernas baseadas na web, RADIUS para aplicação de 802.1X e certificados quando o próprio dispositivo precisar portar uma prova de identidade robusta.

Escolhendo o Provedor de Identidade Correto

O provedor de identidade correto geralmente é aquele que sua organização já opera bem. Escolher a partir de uma lista de recursos pode resultar em um design tecnicamente elegante que os gerentes do local não conseguem administrar e o suporte técnico não entende.

O Microsoft Entra ID é uma escolha natural para ambientes construídos em torno do Microsoft 365. O acesso condicional, os grupos de diretório, o contexto do dispositivo e as habilidades existentes dos administradores podem dar suporte à política de rede dos funcionários. Hospitais com endpoints gerenciados e infraestruturas regionais da Microsoft geralmente preferem manter as decisões de autenticação no mesmo plano de controle que os outros serviços de força de trabalho.

O Google Workspace funciona bem onde o diretório já reside no Google e a empresa deseja evitar a introdução de outra plataforma de identidade. Hotéis, varejistas e grupos menores de hospitalidade que se padronizaram no Google podem achar sua administração familiar e o ciclo de vida do usuário simples.

O Okta costuma ser ideal para organizações que precisam de uma camada ampla de federação entre aplicações em constante mudança, empresas adquiridas ou múltiplos diretórios. O SCIM, regras de grupo detalhadas e uma troca limpa de metadados SAML podem importar mais do que uma longa lista de recursos não utilizados quando um grupo hoteleiro está crescendo ou integrando ambientes distintos.

Um par de Active Directory local e NPS ainda tem o seu espaço. Pode ser uma escolha sensata onde o ambiente sem fio já depende de 802.1X, o diretório é local, a disponibilidade da WAN é limitada ou a organização possui fortes habilidades em infraestrutura Windows. No entanto, isso gera mais responsabilidade quanto a patches, gerenciamento de certificados, redundância e monitoramento.

Matriz de decisão de IdP para o SSO de funcionários do Purple

IdP	Ponto Forte	Atenção Com	Local Típico
Entra ID	Acesso condicional, alinhamento com Microsoft 365, administração de grupos madura	Complexidade de licenciamento e políticas pode exigir administração especializada	Hospital ou propriedade de várias regiões
Google Workspace	Diretório Google existente, administração familiar, alinhamento simples de equipe	Autenticação de rede pode precisar de uma camada RADIUS ou federação adicional	Grupo de hotel ou varejo que já utiliza o Google
Okta	Federação flexível, SCIM, grupos granulares, suporte para ambientes mistos	Estrutura de contrato e custos por usuário precisam de análise cuidadosa	Grupo de hospitalidade de rápido crescimento
Active Directory mais NPS	Excelente adequação para ambientes locais Windows e 802.1X estabelecidos	Mais infraestrutura para operar, proteger e tornar altamente disponível	Unidade com TI local madura

A política de acesso é onde a escolha se torna tangível. Verifique se o provedor consegue expor declarações de grupo confiáveis, se essas declarações podem ser mapeadas para funções de funcionários ou VLANs, como o MFA é aplicado e com que rapidez uma conta desativada deixa de autenticar. Avalie também se um gerente de local que não seja da área de TI consegue entender as telas de administração bem o suficiente para lidar com a admissão de um funcionário ou com uma transferência de departamento.

Para uma visão mais ampla de como o gerenciamento de identidade e acesso afeta os sistemas de negócios, os recursos de IAM da Kushan Business Solutions fornecem um contexto útil além da autenticação sem fio. A recomendação prática permanece simples: comece com a realidade do seu diretório, não com o folheto de recursos do provedor.

O Purple consome metadados de federação padrão, de modo que uma mudança de IdP não precisa significar uma reconstrução sem fio. A migração exata ainda precisa ser testada, mas a substituição da conexão de identidade normalmente é um exercício de configuração controlado. Mantenha a política de rede, a nomenclatura de grupos e o caminho de fallback documentados antes de mudar de provedor. Para equipes que precisam de uma camada RADIUS gerenciada, analise os provedores de Cloud RADIUS disponíveis juntamente com a plataforma de identidade, em vez de tratar o RADIUS como uma reflexão tardia.

Configurando SSO no Purple Hub e Diretório

A federação é bem-sucedida de forma mais confiável quando o provedor de identidade é preparado antes que a conexão do Purple seja criada. O erro comum é abrir ambos os consoles e copiar valores de um lado para o outro sem antes decidir qual identificador, nomes de reivindicação e certificado serão autoritativos.

Prepare o aplicativo empresarial

Crie o aplicativo no Microsoft Entra ID, Okta ou Google Workspace. Escolha SAML 2.0 quando a integração de rede da equipe exigir uma asserção e, em seguida, registre os valores do provedor de serviços fornecidos pelo Purple:

1. Copie a ACS URL, também chamada de URL do serviço de consumidor de asserção, no campo de URL de resposta ou login do IdP.
2. Copie o Entity ID no campo de identificador ou público do IdP.
3. Defina o NameID para o identificador estável de funcionário esperado pela integração. O e-mail costuma ser prático, mas não altere o formato no meio da implantação.
4. Libere os atributos obrigatórios, normalmente e-mail, nome de exibição e grupo.
5. Atribua um grupo piloto em vez de toda a força de trabalho.
6. Baixe os metadados de federação e o certificado de assinatura do IdP.

Para OIDC, registre o emissor, o identificador do cliente, o endpoint de autorização, o endpoint do token e o segredo do cliente conforme fornecidos pela integração. Mantenha os segredos no gerenciador de senhas aprovado, não em um ticket ou planilha compartilhada.

Adicione o provedor no Purple

Abra o portal Purple e siga Authentication > Identity Providers > Add. Selecione SAML 2.0 ou OIDC, dependendo do design, depois importe os metadados do IdP ou insira os endpoints solicitados manualmente. Vincule o novo provedor de identidade ao realm RADIUS de funcionários ou ao perfil do Captive Portal, e selecione os mapeamentos de grupo para política antes de salvar.

Use a tolerância de dessincronização de relógio (clock-skew) padrão documentada do console, a menos que sua política de segurança exija um valor mais rígido. Não invente uma tolerância local para fazer uma asserção com falha passar. Em vez disso, corrija a fonte de hora no IdP, no serviço RADIUS e nos equipamentos de rede.

Ordem de configuração: Crie e atribua o aplicativo IdP, mapeie as reivindicações (claims), exporte os metadados, importe-os para o Purple, vincule o perfil de equipe, teste com uma conta piloto e depois ative a política de produção.

Dois erros representam grande parte das primeiras tentativas fracassadas. O primeiro é uma incompatibilidade entre o URI do identificador no IdP e o Entity ID esperado pela Purple. O segundo é a importação de metadados que não estão assinados ou cuja assinatura não pode ser validada após uma atualização. Verifique a string exata, incluindo maiúsculas e minúsculas e caracteres finais, e estabeleça como a rotação do certificado será aprovada antes da produção.

Se o site ainda depender da infraestrutura de domínio do Windows, separe o design do diretório do design da federação. Um guia como a explicação da Monro Cloud sobre como promover um controlador de domínio pode ajudar a esclarecer a tarefa subjacente do Active Directory, mas não substitui a configuração de SSO ou os testes de rede.

Por fim, verifique as opções de integração relevantes na biblioteca de conectores do Purple. Mantenha a primeira alteração em escopo reduzido. Um grupo de funcionários, uma política de SSID, um local de teste designado e um plano de fallback documentado tornam a resolução de problemas muito mais fácil do que uma transição simultânea em toda a empresa.

Testando e Verificando o Fluxo de Login da Equipe

Não teste apenas a partir do navegador já autenticado de um administrador. Sessões de IdP em cache podem fazer com que uma federação quebrada pareça funcional. Use uma janela de navegação anônima, uma conta de teste limpa e uma sequência que verifique a asserção, a decisão de rede e a experiência final do usuário.

Comece com a validação de metadados. Use um rastreador SAML ou um depurador OIDC para inspecionar a resposta e confirmar o formato NameID esperado, URI de audiência, emissor, assinatura e declarações de grupo. Para um fluxo baseado em RADIUS, confirme se o broker recebe a identidade e retorna uma decisão de aceitação ou rejeição com os atributos necessários para o mapeamento de políticas.

Teste por dispositivo e contexto de rede

Execute o fluxo em diferentes tipos de dispositivos em vez de presumir que um único teste bem-sucedido no navegador cobre todo o ambiente:

• Notebook gerenciado: Use um dispositivo associado ao domínio na VLAN corporativa e confirme se a política de equipe esperada é aplicada.
• Telefone BYOD: Conecte-se a partir do SSID de convidados e verifique se as credenciais da equipe não concedem acidentalmente um acesso mais amplo à rede.
• Quiosque compartilhado: Teste o Captive Portal com uma sessão de navegador limpa, depois saia e repita o processo com outra conta de equipe.
• Caminho de revogação: Altere ou desative a conta de teste e confirme se uma nova tentativa de autenticação falha e se as sessões existentes seguem o tempo de vida configurado.

Verifique a duração da sessão e a reautenticação forçada após uma alteração de senha ou de status da conta. Para o 802.1X, inspecione os pacotes de contabilização RADIUS e confirme se o ponto de acesso registra os eventos esperados de início, parada e identidade.

Correlacione ambos os lados da transação

Leia os logs do provedor de identidade e o fluxo de eventos do Purple juntos. Os logs de login do Entra, o Okta System Log e os dados de auditoria do Google Admin devem mostrar a solicitação de autenticação, o resultado da política e a identidade do usuário. O Purple deve mostrar a solicitação correspondente e o resultado da rede.

Registre o ID de correlação de ambos os sistemas sempre que disponível. Apenas um registro de data e hora costuma ser muito vago durante um turno movimentado, enquanto um identificador compartilhado permite distinguir uma declaração de grupo rejeitada de um problema de associação sem fio. Capture o rastreamento bem-sucedido antes de alterar a configuração, para que a central de atendimento tenha um exemplo em bom estado para comparação.

Planos de Rollback e Solução de Falhas Comuns

Às 09:00 de uma terça-feira, um hotel de 220 quartos ativa o SSO para um grupo piloto. O primeiro administrador faz login com sucesso. Dez minutos depois, chegam chamados no suporte vindos da governança, recepção e serviço de alimentação. Alguns usuários enfrentam um redirecionamento infinito, outros chegam ao IdP mas caem na política de equipe errada, e um notebook mais antigo recusa totalmente a conexão.

A resposta não deve ser desativar todos os controles de uma vez. Mantenha o domínio RADIUS local ativado como contingência, reverta o perfil do Captive Portal para autenticação por senha em dois cliques e, somente então, desative a conexão SAML se o piloto ainda não conseguir autenticar. Essa ordem mantém a equipe trabalhando enquanto a federação é isolada.

Falhas comuns de SSO e correções

Sintoma	Causa Provável	Solução
Asserção rejeitada imediatamente	Desvio de relógio entre sistemas	Verifique a sincronização de tempo no IdP, serviço RADIUS, controladora e ponto de acesso. Use a tolerância documentada do Purple em vez de aumentá-la sem critério.
Login retorna em loop para o portal	Cookie do Captive Portal colide com a sessão do IdP	Limpe a sessão do portal, teste em uma janela privada e revise o comportamento de redirecionamento e cookies no perfil do Captive Portal.
Usuário se autentica mas não recebe acesso de funcionário	Declaração de grupo ausente ou nomeada incorretamente	Compare a asserção com o mapeamento de grupo do Purple, corrija a declaração do IdP e teste novamente com a conta piloto.
Conexão SAML falha após alteração de certificado	Certificado de assinatura expirado, não confiável ou importado incorretamente	Exporte os metadados atuais do IdP, valide o certificado de assinatura e importe os metadados atualizados no registro do provedor de identidade do Purple.
Assinatura da asserção é rejeitada	Algoritmo de assinatura não suportado ou incompatível	Alinhe o algoritmo de assinatura do IdP com os requisitos de integração e importe novamente os metadados verificados.
Falha apenas para alguns usuários	Atribuição de aplicativo ou associação de grupo incorreta	Verifique a atribuição de aplicativo do usuário no IdP, a associação de grupo e o mapeamento de políticas antes de alterar a rede.

Não exclua o domínio antigo até que o novo caminho tenha passado pelas verificações de dispositivos e a equipe de suporte saiba como identificar uma falha. Um rollback não é um projeto fracassado. É um controle normal que evita que o trabalho de autenticação se transforme em uma interrupção no local.

A expiração de certificados merece atenção especial porque pode ocorrer sem qualquer alteração no ambiente sem fio. Registre o proprietário do certificado, o processo de renovação e o local de importação. Para atualizações de metadados, valide o arquivo e sua assinatura antes de substituir a conexão ativa e, em seguida, teste o fluxo iniciado pelo provedor de serviços (SP) a partir de uma sessão limpa.

Melhores Práticas de Segurança Após a Ativação

O SSO é tão forte quanto o ciclo de vida de identidade por trás dele. Um login centralizado pode melhorar o controle, mas também pode concentrar riscos se os administradores deixarem contas inativas, liberarem atributos de diretório em excesso ou permitirem que uma identidade de serviço compartilhado ignore a política normal.

Realize uma revisão trimestral com as equipes de identidade e de rede. Confirme se os novos funcionários, os que mudaram de função e os que saíram aparecem nos grupos de equipe corretos, se as contas inativas não recebem mais acesso à rede e se as alterações de grupo chegam à política de equipe sem a necessidade de cópia manual. As diretrizes do NCSC sobre o uso seguro de SaaS recomendam a federação de identidade completa em contextos de nuvem em vez de sincronizar senhas na nuvem, o que é um princípio de design útil para integrações de rede de equipe.

Controles que devem ser verificados a cada trimestre

• Use MFA resistente a phishing: Exija chaves de segurança FIDO2 ou passkeys de plataforma para contas IdP onde a plataforma e os dispositivos as suportem. Trate o acesso por SMS ou apenas por senha como uma exceção de compatibilidade, não como o estado desejado.
• Limite a persistência da sessão: Defina o tempo de vida da sessão do IdP para que a reautenticação do Purple siga a política corporativa. Teste o que ocorre após o logout, fechamento do navegador, alteração de senha e desativação de conta.
• Revise o acesso just-in-time: Audite atribuições obsoletas de funcionários temporários e funções de convidados. Remova o acesso no diretório de origem em vez de depender de uma lista manual dentro do console de rede.
• Acompanhe o fluxo de eventos: Monitore erros de federação e padrões de login incomuns no painel do Purple, correlacionando-os com os logs do IdP.
• Libere o mínimo de declarações (claims): Envie apenas os atributos necessários para a política de funcionários, geralmente e-mail, nome de exibição e grupo. Dados de diretório desnecessários não devem fazer parte de uma asserção sem fio.
• Rotacione credenciais de confiança: Renove certificados de assinatura e segredos de API antes do vencimento, teste a substituição e mantenha o certificado anterior disponível apenas durante a janela de transição aprovada.
• Remova identidades compartilhadas: Desative contas de serviço compartilhadas sempre que um dispositivo gerenciado ou usuário nominal puder realizar a tarefa. Se houver alguma exceção, documente o proprietário e a data de revisão.

Os programas de identidade do Reino Unido mostram por que a adoção e o reuso são importantes junto com a autenticação. A análise setorial de identidade digital do GOV.UK de 2026 relatou que 77% dos entrevistados haviam concluído pelo menos um caso de uso de identidade digital, enquanto 20% das pessoas que usaram um serviço de identidade digital relataram apresentar uma identidade reutilizável. A lição para a TI do local é prática: um login é útil, mas o reuso consistente, a garantia, a acessibilidade e o controle do ciclo de vida determinam se o SSO funciona em serviços reais.

As diretrizes de gerenciamento de identidade e acesso do NCSC também destacam a importância de desativar contas e propagar essa decisão para os serviços conectados. Mantenha essa propagação em teste. O SSO não é uma configuração única. Seu valor aparece quando as alterações no diretório e as políticas de rede dos funcionários permanecem em sincronia.

---

A Purple oferece autenticação de WiFi para funcionários que conecta provedores de identidade como Entra ID, Google Workspace, Okta e SAML 2.0 ao acesso de rede gerenciado, com políticas e eventos de autenticação tratados por meio de sua plataforma. Visite a Purple para avaliar um SSID de funcionários com federação de identidade para seus hotéis, hospitais, locais de varejo ou outros estabelecimentos, e planeje um piloto com um caminho de reversão testado.