O Active Directory que eu gerenciava na Oi e o que isso tem a ver com SSO
Passei anos criando usuários e aplicando GPO no Active Directory de clientes. Só entendi o que estava fazendo quando precisei integrar SAML com Azure AD — e percebi que era a mesma coisa, com nome diferente.
Na Oi eu criava usuário no Active Directory como tarefa rotineira.
Empresa contratava novo funcionário: eu abria o AD, criava a conta, colocava no grupo correto, aplicava a GPO do departamento. Funcionário chegava, logava, tinha acesso ao que precisava.
Fazia isso sem pensar muito. Era operação mecânica.
Só entendi o que estava fazendo de verdade quando, anos depois na POA Software, precisei integrar uma aplicação com Azure AD via SAML e percebi: é a mesma coisa.
Active Directory é um serviço de diretório. Guarda informação sobre objetos numa rede: usuários, computadores, grupos, políticas. O "banco de dados" de identidade de uma organização Windows.
Quando um funcionário loga, o Windows autentica contra o AD: esse usuário existe? Senha correta? Quais grupos pertence? Quais políticas se aplicam? Grupos determinam acesso — se está no grupo TI-Suporte, tem acesso às pastas de suporte. Simples e poderoso.
GPO (Group Policy Object) é como você aplica configuração em massa: bloquear USB no financeiro, wallpaper da empresa para todos, acesso ao sistema de tickets para suporte. Você define a política uma vez, aplica ao grupo, e todos herdam na próxima vez que fazem login. Isso é infraestrutura como configuração. Antes de eu conhecer esse nome, eu já fazia isso no AD.
Azure AD é a versão cloud. Mesmo conceito: diretório de usuários, grupos, políticas — só que roda nos servidores da Microsoft e usa SAML/OIDC/OAuth em vez de Kerberos/NTLM.
Quando um cliente disse "integramos com Azure AD via SAML", meu modelo mental do AD ajudou muito. Eu sabia o que era usuário, grupo, atributos de usuário, como funcionava hierarquia de permissão. O protocolo (SAML) era novo. O conceito era familiar.
Muitas empresas enterprise usam Active Directory, Azure AD (Microsoft Entra hoje), Google Workspace ou Okta — todos Identity Providers: a fonte de verdade sobre quem são os usuários e o que podem acessar.
Quando você faz integração SSO, está se conectando ao sistema de identidade da empresa. Usuários são criados e gerenciados no IdP, não na sua aplicação. Permissões podem vir via grupos do IdP. Quando usuário é desligado, a conta é desativada no IdP e seu sistema deixa de autenticá-lo automaticamente — sem precisar lembrar de desativar em cada sistema individualmente.
Quando eu gerenciava AD na Oi, estava aprendendo o modelo mental de identity and access management sem saber. Usuários, grupos, atributos, políticas, hierarquia de permissão — esses conceitos aparecem no IAM da AWS, no RBAC do Kubernetes, no sistema de permissões de qualquer SaaS enterprise. A implementação muda. O modelo mental é o mesmo.
Essa semana: descobre qual Identity Provider sua empresa usa. No próximo sistema que você construir que precisar de login, pesquisa se esse IdP tem suporte a SSO. A integração pode ser mais simples do que você imagina.