Blog/Artigos · Segurança
Provedor de identidade e de serviço, a asserção assinada, SSO corporativo e provisionamento com SCIM, com Okta, Ping e ADFS.
A aliança do arco-íris é um pacto entre duas partes: um lado se compromete, o outro confia, e um sinal no céu sela o acordo para que ninguém precise renegociá-lo toda vez. Federação de identidade é essa aliança entre sistemas. Sua empresa autentica você uma vez, e dezenas de aplicações de terceiros aceitam essa afirmação sem nunca ver a sua senha, porque assinaram um pacto de confiança. SAML é a língua mais antiga e ainda dominante dessa aliança no mundo corporativo, e a assinatura digital é o sinal que a sela.
Federação tem dois papéis. O provedor de identidade (IdP) é quem conhece você e sua senha, autentica e afirma quem você é: Okta, Ping Identity, Microsoft ADFS, Shibboleth no meio acadêmico. O provedor de serviço (SP) é a aplicação que você quer usar e que confia na afirmação do IdP em vez de manter a sua senha. O SP terceiriza a pergunta quem é você para o IdP, e passa a cuidar só do que você pode fazer lá dentro.
SAML 2.0, padronizado pela OASIS em 2005, é o protocolo que carrega essa afirmação entre IdP e SP. Ele venceu o mundo corporativo antes do OIDC existir, e por isso é o que praticamente todo SaaS empresarial fala: a aba de SSO de qualquer ferramenta de negócio ainda começa por SAML. Entender IdP e SP é entender por que o login corporativo funciona como funciona.
Autenticado uma vez no IdP, os outros SPs da aliança aceitam a mesma afirmação. É o single sign-on que federação destrava.
O que trafega do IdP para o SP é a asserção SAML: um documento XML que afirma quem é o usuário, quando autenticou e quais atributos ele tem, assinado digitalmente pelo IdP. A assinatura é tudo: é ela que impede que alguém forje uma afirmação de identidade. Um SP que aceita asserção sem validar a assinatura, ou que aceita assinatura de um certificado que não é o do IdP confiável, abre a porta para personificação.
É aqui que moram as vulnerabilidades clássicas de SAML, como o XML Signature Wrapping, em que o atacante envolve a asserção legítima numa estrutura que engana o validador. A defesa não é exótica: bibliotecas maduras e bem configuradas, validação estrita de assinatura, de emissor e de audiência, e certificados rotacionados antes de expirar. O pacto é forte quando o selo é verificado com rigor, e frágil quando alguém confia no envelope sem conferir o lacre.
validar_assercao_saml:
1. assinatura confere com o certificado do IdP confiavel
2. emissor (Issuer) e exatamente o IdP esperado
3. audiencia (Audience) e este SP, e nao outro
4. janela de tempo (NotBefore / NotOnOrAfter) ainda vale
5. o ID da asserção nao foi usado antes (anti-replay)
6. o certificado do IdP nao esta expirado nem revogado
qualquer item que falhar => rejeitar, nunca 'aceitar mesmo assim'Um mal-entendido comum é achar que federação resolve tudo. SAML resolve o login: a pessoa entra no SP com a identidade do IdP. Mas ele não cria nem remove a conta no SP, e sem isso o desligamento vira problema: a pessoa perde o SSO, mas a conta órfã continua no SaaS, com dados e, às vezes, com uma senha local esquecida.
Quem fecha essa lacuna é o SCIM, o padrão de provisionamento entre IdP e SP. Com SCIM, criar alguém no IdP cria a conta nos SaaS conectados, mudar de função ajusta o acesso, e desligar remove a conta em todos eles. Federação com SAML e provisionamento com SCIM são as duas metades do mesmo pacto: uma diz quem você é a cada login, a outra garante que sua existência e seu fim sejam refletidos em toda a aliança.
A pergunta prática não é qual é melhor, é qual usar onde. SAML domina o SSO empresarial: SaaS de negócio, integrações legadas e o mundo corporativo em geral falam SAML primeiro, e provavelmente falarão por muitos anos. OIDC domina o novo: aplicações mobile, SPAs, APIs e cenários onde OAuth 2.0 já resolve a autorização e o OIDC entra leve para a identidade.
Na prática, uma empresa madura opera as duas alianças ao mesmo tempo, com o IdP central falando SAML com o SaaS antigo e OIDC com o app novo. A decisão de arquitetura é escolher o IdP que fala bem as duas línguas e centraliza a política, para que o pacto de confiança seja um só, verificável num lugar, e não uma colcha de integrações que ninguém audita inteira.
| Critério | SAML 2.0 | OpenID Connect |
|---|---|---|
| Formato | XML assinado | JWT sobre OAuth 2.0 |
| Força | SSO corporativo e SaaS de negócio | mobile, SPA, API e cenário novo |
| Idade | OASIS, 2005, dominante no legado | OpenID Foundation, moderno |
| Provisionamento | complementado por SCIM | complementado por SCIM |
Federação é a aliança que faz um sistema confiar no juramento do outro: o IdP autentica e afirma, o SP confia na asserção assinada, e o SSO nasce dessa confiança. SAML sela o pacto no mundo corporativo, OIDC no mundo novo, e o SCIM garante que a existência e o fim de cada identidade se reflitam em toda a aliança. Okta, Ping e ADFS são o instrumento; validar o selo com rigor é o que mantém o pacto de pé. A IA inventaria, valida e encontra a conta órfã, mas a arquitetura da confiança continua sendo decisão de quem responde por ela.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Segurançaשָׁלִיחַ
OAuth delega acesso sem entregar a senha; OIDC prova quem é. Entenda o token como carta de autoridade, o fluxo com PKCE e os erros que viram brecha, com as plataformas do mercado.
Segurançaמִפְקָד
A pergunta que trava toda auditoria é quem tem acesso a quê e por quê. IGA responde: catálogo, recertificação, segregação de deveres e provisionamento, com as plataformas que o mercado usa.
