Até 2021, o governo do Reino Unido tinha cerca de 121 soluções de single sign-on separadas, mostrando por que o SSO é mais do que um recurso de conveniência. O SSO é a consolidação de identidade federada: ele centraliza a autenticação por meio de um provedor de identidade confiável, enquanto cada aplicação mantém o controle do que um usuário autenticado tem autorização para fazer.
Você pode reconhecer o problema em um dia de trabalho comum. Um funcionário precisa de e-mail, uma aplicação em nuvem, um sistema de gestão imobiliária, WiFi interno e um portal administrativo. Cada serviço tem seu próprio login, política de senhas e proprietário de conta. Quando alguém entra, muda de função ou sai, os administradores precisam atualizar vários sistemas, e os usuários precisam lembrar quais credenciais pertencem a qual serviço.
Esse é o motivo prático pelo qual as organizações procuram a explicação sobre SSO. A questão não é apenas como reduzir o número de telas de login. É como criar um plano de controle de identidade confiável sem enfraquecer as permissões em nível de aplicativo ou introduzir um alvo central mais perigoso.
Por que a identidade fragmentada cria problemas reais de acesso
A experiência do governo do Reino Unido fornece um ponto de partida útil. Uma análise do padrão de serviço do GOV.UK de 2021 estimou que o governo central tinha aproximadamente 121 soluções de SSO diferentes porque as equipes de serviço criaram sistemas de autenticação separados em vez de usar uma única plataforma de identidade compartilhada em todo o governo. As pessoas que usavam vários serviços públicos podiam, portanto, possuir vários conjuntos de dados de login e podiam não saber qual conta era necessária para uma transação específica. (Análise de autenticação e identidade digital do governo do Reino Unido)
A lição não é que os sistemas governamentais são excepcionalmente complicados. Grandes empresas, organizações de saúde, grupos hoteleiros, operadoras imobiliárias e redes do setor público enfrentam o mesmo padrão. Cada aplicação pode criar um silo de identidade, e cada silo pode desenvolver suas próprias regras de senha, processo de recuperação, modelo de grupo e fluxo de trabalho de desligamento.
Autenticação e autorização são tarefas diferentes
A autenticação responde: "Quem é você?" A autorização responde: "O que você pode acessar aqui?" O SSO consolida a primeira pergunta por meio de um provedor de identidade de confiança. O aplicativo de destino ainda decide se essa identidade pode visualizar registros, administrar um sistema, ingressar em um segmento de rede ou usar um recurso específico.
Um modelo mental útil se parece com isto:
Usuário
|
| autentica uma vez
v
Provedor de identidade
|
| envia informações de identidade confiáveis
v
Aplicativo ou rede
|
| aplica permissões locais
v
Sessão autorizada
Esta distinção é importante durante os processos de entrada, movimentação e saída de funcionários. Uma identidade central pode ser desativada quando uma pessoa sai, enquanto cada serviço conectado ainda precisa de um modelo de autorização claro e de uma forma confiável de remover permissões.
Regra prática: Trate o SSO como uma forma de controlar a identidade centralmente, não como um substituto para as permissões de aplicativo.
O mesmo princípio se aplica ao projetar uma implantação de rede cabeada e sem fio. O acesso à rede faz parte do ecossistema de identidade, portanto, as equipes devem decidir quais grupos do diretório podem alcançar quais funções de rede, em vez de associar o acesso a uma senha compartilhada.
Para WiFi de funcionários e acesso baseado em identidade, as soluções de rede baseadas em identidade da Purple mostram como a política de rede pode ser conectada à identidade individual em vez de uma credencial comum. O resultado é uma relação mais clara entre uma pessoa, seu status no diretório e o acesso que ela recebe.
Como o Single Sign-On funciona na federação corporativa
Em uma federação corporativa, um provedor de identidade, uma parte confiante e uma mensagem de identidade assinada realizam tarefas separadas. O provedor de identidade autentica o usuário, enquanto a parte confiante, como um aplicativo ou serviço de rede, verifica as informações de identidade resultantes.
A autenticação pode usar uma senha, autenticação multifator, condições do dispositivo ou outro método aprovado. O provedor então emite uma asserção ou token assinado para o serviço solicitado. O serviço valida essa mensagem e cria sua própria sessão, garantindo que as credenciais permaneçam com o provedor de identidade.
O fluxo de federação
- O usuário solicita um serviço. Ele abre um aplicativo, portal administrativo ou serviço de rede protegido.
- O serviço verifica se há uma sessão existente. Se não houver, ele redireciona o usuário para o provedor de identidade.
- O provedor de identidade autentica o usuário. Ele aplica os controles configurados, como MFA ou acesso condicional.
- O provedor de identidade emite uma mensagem assinada. A integração comumente usa uma asserção SAML ou um token OpenID Connect.
- O serviço valida a mensagem. Ele verifica o emissor, a assinatura, o público, a expiração e as reivindicações relevantes.
- O aplicativo cria sua própria sessão. Ele mapeia a identidade verificada para as permissões locais e registra o evento de autenticação.
A validação protege a relação de confiança. O NCSC (UK National Cyber Security Centre) recomenda que asserções SAML recebidas em redes não confiáveis devem ser verificadas contra a autoridade certificadora esperada. Uma asserção não verificada pode fornecer um caminho para sequestro de conta por meio de uma conexão confiável com o provedor de identidade. (Orientação do NCSC sobre gestão de identidade e acesso)
Uma verificação de identidade válida concede uma identidade autenticada, não todas as permissões no serviço de destino. A aplicação deve consumir apenas as declarações necessárias para autorização e, em seguida, aplicar suas próprias regras de função e recursos. Essa separação também permite que o mesmo padrão de federação atenda a aplicações de funcionários, portais administrativos e serviços de rede baseados em identidade.
SAML, OIDC e OAuth no contexto corporativo
Assim que o modelo de federação estiver claro, a seleção do protocolo se torna mais fácil. SAML e OpenID Connect são padrões comuns para SSO corporativo, enquanto o OAuth é essencialmente uma estrutura de autorização para acesso delegado a APIs. Confundir OAuth com autenticação pode levar as equipes a criar um fluxo de identidade que não responde às exigências de segurança necessárias.
| Padrão | Função prática | Aplicações típicas |
|---|---|---|
| SAML | Troca asserções de identidade assinadas | Aplicações corporativas consolidadas e baseadas em navegador |
| OpenID Connect | Adiciona uma camada de identidade usando tokens | SaaS moderno, serviços orientados a web e dispositivos móveis |
| OAuth | Delega acesso a recursos protegidos | Acesso a API em nome de um usuário ou serviço |
O SAML geralmente aparece em softwares corporativos consolidados porque usa um modelo de federação de navegador bem estabelecido. O OIDC é geralmente mais natural para serviços modernos projetados com base em JSON, REST e interações baseadas em tokens. A escolha certa depende do que o aplicativo suporta e de como o serviço valida as informações de identidade.
O que o serviço deve verificar
Independentemente do padrão, a parte confiante deve validar o material de identidade recebido antes de criar uma sessão. As verificações principais incluem:
- Emissor: Confirme se a mensagem veio do provedor de identidade esperado.
- Assinatura: Verifique se a mensagem foi assinada pela chave ou certificado de confiança.
- Público-alvo: Verifique se a mensagem era destinada a este serviço.
- Expiração: Rejeite asserções ou tokens expirados.
- Alegações (Claims): Use apenas informações de grupo e identidade relevantes e validadas.
O provedor de identidade pode centralizar políticas como MFA, acesso condicional, proibição de senhas e associação a grupos. O aplicativo recebe as declarações necessárias para sua própria decisão de autorização, em vez de manter uma cópia completa do processo de autenticação do usuário.
Essa separação é útil ao integrar plataformas como Microsoft Entra ID, Okta ou Google Workspace. O provedor lida com a política de autenticação, enquanto a aplicação conectada permanece responsável por seu modelo de acesso e controles de sessão. Para operadores de rede que estão avaliando a integração do Okta para acesso baseado em RADIUS, o mesmo princípio se aplica: a validação de identidade e a autorização de rede devem funcionar juntas, mas não são o mesmo controle.
O risco de concentração que o SSO introduz
Uma única conta de provedor de identidade comprometida pode abrir vários serviços conectados de uma só vez. O SSO reduz a proliferação de senhas, ao mesmo tempo em que concentra a confiança no provedor de identidade, tornando-o um plano de controle de alto valor. Portanto, as organizações precisam avaliar como a federação afeta seu raio de alcance e opções de recuperação. A orientação do NCSC sobre a escolha de métodos de autenticação destaca essa concentração de confiança como um risco que exige uma avaliação deliberada.
O SSO consolida eventos de login. A resistência ao phishing, a confiança no dispositivo e o acesso com privilégios mínimos devem vir dos controles integrados à arquitetura de federação. Um projeto sólido protege o provedor, as sessões que ele cria e os processos de recuperação que podem restaurar o acesso.
Crie camadas ao redor do provedor
Os controles devem abranger o login de rotina e os caminhos menos visíveis usados durante a recuperação de conta:
- MFA forte para usuários privilegiados: Use métodos resistentes ao phishing onde o ambiente os suporte, especialmente para administradores.
- Acesso condicional: Avalie o estado do dispositivo, a localização, o risco da sessão e outros sinais disponíveis antes de conceder o acesso.
- Identidades de administrador separadas: Mantenha a administração privilegiada separada da atividade comum do dia a dia.
- Monitoramento de autenticação: Investigue viagens impossíveis, indicadores de repetição de token, falhas repetidas e escalação de privilégios inesperada.
- Proteção de recuperação: Trate redefinições de suporte técnico e contas de emergência como operações de identidade sensíveis, com aprovação e monitoramento.
O NCSC recomenda combinar o SSO corporativo com autenticação forte de usuários e dispositivos, incluindo MFA ou acesso condicional. Ele também recomenda o SSO para SaaS porque os controles centralizados tornam o gerenciamento de usuários e grupos mais consistente e evitam que as credenciais sejam sincronizadas em todas as aplicações. Seu princípio de segurança em nuvem sobre identidade e autenticação estabelece essa abordagem.
O SSO reduz o número de credenciais que você deve governar. Ele exige proteção forte para as credenciais e sessões que governam os serviços conectados.
As equipes de rede devem separar a identidade dos funcionários da identidade dos convidados. Uma federação de funcionários pode dar suporte ao acesso com privilégios mínimos e à revogação imediata. A autenticação de convidados não deve herdar os privilégios do diretório de funcionários apenas porque ambos os fluxos usam um Captive Portal ou infraestrutura sem fio.
WiFi sem senha e acesso à rede baseado em diretório
Um funcionário que se conecta ao WiFi não deve precisar de uma senha compartilhada que continue válida após a sua saída. Um projeto baseado em diretório começa com a autenticação por meio do provedor de identidade da organização e, em seguida, mapeia a identidade ou grupo verificado para uma função de rede. Portanto, o serviço sem fio aplica as mesmas decisões de emprego e acesso usadas em outros locais, em vez de manter uma lista separada de senhas de WiFi.
O Purple oferece suporte a esse modelo para WiFi corporativo por meio de integrações com Microsoft Entra ID, Google Workspace e Okta. Sua abordagem de WiFi sem senha evita credenciais compartilhadas e o gerenciamento de RADIUS local. Alterações no diretório podem disparar o provisionamento ou a revogação. A associação de um funcionário a um grupo determina o acesso à rede, enquanto a desativação da conta do diretório de quem está saindo pode remover esse acesso sem a necessidade de esperar que alguém altere uma senha comum.
Aplique controles de federação à rede
O provedor de identidade, a política de rede e o monitoramento devem concordar com a mesma decisão de acesso. Mapeie grupos de diretório para funções de rede distintas, de modo que funcionários, prestadores de serviço e administradores não recebam acessos idênticos por padrão. Mantenha os tempos de vida de asserções ou tokens curtos, limitando a utilidade de credenciais de identidade antigas. Exija MFA no provedor de identidade, pois o SSO sem fio não se torna MFA apenas pelo uso de SSO.
Registre eventos de autenticação com sucesso e com falha e conecte cada decisão de identidade com a autorização de rede resultante. Teste a renovação de certificados antes do vencimento, pois falhas na relação de confiança da federação podem interromper o acesso ao WiFi que, de outra forma, estaria funcionando perfeitamente.
Locais multilocatários exigem um limite separado. Propriedades residenciais, acomodações estudantis, hotéis e locais de uso misto podem oferecer acesso simples a residentes ou convidados, isolando o tráfego dos locatários e os sistemas da equipe. O iPSK pode dar suporte a dispositivos legados, enquanto o SSO corporativo fornece um caminho de identidade distinto para a equipe.
O WiFi para convidados também gera decisões sobre consentimento, retenção e perfis de clientes. Este guias sobre dados de convidados para estabelecimentos oferece uma referência útil junto com o projeto de rede, enquanto a Purple conecta a autenticação baseada em identidade com a experiência de acesso sem fio.
Resultados mensuráveis para empresas e locais no Reino Unido
Um case de negócios prático para SSO começa com as credenciais que uma organização não precisa mais administrar. Uma pesquisa da Institution of Engineering and Technology de abril de 2024 realizada com 2.000 residentes do Reino Unido com 16 anos ou mais descobriu que apenas 20% sabiam identificar corretamente uma senha segura. A mesma pesquisa relatou que um quinto reutilizava uma senha em vários sites ou dispositivos, enquanto 21% usavam uma data importante e 20% usavam o nome de um animal de estimação. Também descobriu que 38% acreditavam que substituir letras por números melhorava a segurança da senha, 65% acreditavam que as senhas nunca deveriam ser anotadas e 77% achavam que alterações frequentes de senha aumentavam a segurança. (Pesquisa de segurança de senha da IET)
Essas descobertas mostram os limites de pedir aos usuários que criem e meçam credenciais separadas para cada aplicativo e rede. A identidade centralizada altera onde a organização aplica os controles e a rapidez com que os administradores podem agir, embora o phishing e o comprometimento de contas continuem sendo riscos reais.
Para um operador, os resultados são práticos:
- Menos credenciais não gerenciadas: Os usuários criam, lembram e reutilizam menos senhas de aplicativos separadas.
- Política consistente: O provedor de identidade pode aplicar MFA, acesso condicional e restrições de senha em todos os serviços conectados.
- Revogação mais rápida: A desativação de uma identidade organizacional pode se tornar a ação central de remoção de acesso, desde que os serviços conectados processem as alterações do ciclo de vida corretamente.
- Trilhas de auditoria mais claras: Os logs podem vincular a identidade de uma pessoa às decisões de autenticação e autorização de rede.
- Menos administração duplicada: As equipes mantêm a política de identidade de forma centralizada em vez de recriar controles equivalentes em cada serviço.
O valor vai além de reduzir solicitações de login. Um provedor de saúde pode atribuir acesso por função, um grupo hoteleiro pode separar serviços de funcionários e hóspedes, e uma operadora imobiliária pode manter uma propriedade mais clara dos direitos de inquilinos e da equipe de trabalho. Em cada caso, o resultado mensurável é uma estrutura menor de credenciais, um processamento mais confiável de desligamentos e evidências mais sólidas de quem recebeu acesso a uma aplicação ou função de rede.
Implementando SSO sem criar novos riscos
Uma implementação segura começa com o modelo de identidade, não com o botão de login. Escolha SAML ou OIDC onde eles se adaptarem à aplicação, em vez de copiar senhas para uma aplicação ou plataforma de rede. Estabeleça o provedor de identidade como a autoridade de autenticação e faça com que cada serviço conectado valide o emissor, a assinatura, o público, a expiração e as declarações antes de criar uma sessão.
Use uma lista de verificação operacional
- Comece com grupos autoritativos: Forneça acesso a partir de grupos de diretório gerenciados pela equipe de TI ou de negócios correta.
- Defina regras de alteração de cargo: Uma mudança de função deve remover as permissões antigas, bem como adicionar novas.
- Processe desligamentos centralmente: Desative a identidade organizacional e verifique se os aplicativos conectados e as funções de rede respondem corretamente.
- Proteja o acesso de emergência: Mantenha as contas de emergência separadas da administração comum, monitore-as de perto e teste seu processo de recuperação.
- Separe funcionários e convidados: O SSO da força de trabalho pode apoiar o acesso com privilégio mínimo e a revogação. A autenticação de convidados não deve herdar as permissões dos funcionários.
- Teste alterações de confiança: Valide a renovação de certificados, expiração de tokens, encerramento de sessões e interrupções do provedor antes de depender deles em produção.
- Revise o monitoramento: Confirme se os eventos de autenticação, ações administrativas e decisões de autorização de rede estão disponíveis para investigação.
Um local também pode precisar dar suporte a vários fornecedores de rede em vez de substituir sua infraestrutura sem fio existente. O Purple foi projetado para funcionar com Meraki, Aruba, Ruckus, Mist e UniFi, e seu modelo de implantação declarado é medido em semanas, não em meses. Trate essas capacidades como considerações de implementação, não como substitutos para uma análise de arquitetura. Para uma visão mais ampla de como os provedores de tecnologia descrevem as salvaguardas de segurança, a página de confiança e controles da AdManage.ai oferece um ponto de comparação útil.
A decisão central é se a organização consegue explicar, para cada serviço conectado, quem autentica o usuário, quais declarações (claims) são confiáveis, como as permissões são atribuídas e o que acontece quando a identidade muda. O SSO é uma camada em um programa de gestão de identidade e acesso. Ele não substitui MFA, acesso condicional, monitoramento de autenticação, controles de recuperação ou governança de ciclo de vida.
A Purple conecta a identidade da força de trabalho com WiFi sem senha, funções de rede baseadas em diretório e acesso separado para convidados, oferecendo suporte a integrações com Microsoft Entra ID, Google Workspace e Okta. Visite a Purple para avaliar como seu modelo de rede baseado em identidade pode se adaptar ao seu ambiente sem fio existente e à implementação de SSO.
