SAML

SAML (Security Assertion Markup Language) é um padrão aberto para autenticação e autorização de usuários. Ele permite que um sistema (geralmente um site ou aplicação) delegue o login para outro sistema confiável (como o login corporativo da empresa).

LDAP e SAML parecem cobrir o mesmo terreno, mas eles resolvem problemas diferentes e complementares.

LDAP (Lightweight Directory Access Protocol) é um protocolo de consulta de diretórios. Usado para autenticar usuários (ex: login com usuário/senha) e buscar informações (ex: grupos, permissões), mas é de mais baixo nível, ou seja, um app que usa LDAP precisa saber como se conectar, como autenticar, como lidar com sessões e senhas, etc.

Característica	LDAP	SAML
Tipo	Protocolo de diretório	Protocolo de federação de identidade
Transporte	TCP (cliente → servidor)	Browser (redirects via HTTP)
Autenticação	Direta (usuário/senha)	Indireta (via assertion do IdP)
Integração	Cada app precisa falar LDAP	Apps só precisam aceitar SAML
SSO (Single Sign-On)	Não nativo	Sim, projetado pra isso
Senha	Aplicação vê e manipula a senha	Senha nunca chega na aplicação

O que o SAML resolve que o LDAP não resolve?

• SSO (Single Sign-On): LDAP não tem conceito de login único. Cada app que usa LDAP precisa pedir usuário e senha toda vez. Com SAML, um único login serve para várias apps.
• Menos exposição de senha: Com LDAP, o app precisa da senha para autenticar o usuário. Com SAML, nenhuma senha é enviada para o app — só uma assertion assinada.
• Federar identidade entre domínios: Com SAML, você pode logar em apps de terceiros (ex: Salesforce, AWS, etc.) usando seu login corporativo. LDAP não escala bem pra isso.
• Baseado em navegador: SAML é feito para rodar 100% via browser. Ideal pra apps web modernas. LDAP precisa de bibliotecas, binds, conexões TCP, etc.

LDAP é tipo um banco de dados de usuários que você mesmo consulta e autentica.

SAML é tipo uma "declaração de confiança" que vem de um órgão confiável (o IdP), dizendo "esse cara tá autenticado".

Redirecionamentos HTTP

Essa é a ideia base de como funciona o SAML.

Imaginemos que temos uma aplicação Web 1 que precisa se comunicar com outra aplicação web 2, porém a aplicação web 1 fica dentro da intranet da empresa enquanto a 2 fica fora e não tem acesso a aplicação web 1.

Podemos aproveitar o navegador para fazer isso se ele tem acesso a ambos. A máquina do usuário está na VPN da empresa e consegue acesso à aplicação. Caso a aplicação web 2 precise se comunicar com a 1, ela pode mandar uma requisição para que o browser faça a requisição por ela. O mesmo pode acontecer com a aplicação web 1 tentando se comunicar com a 2.

Todo esse redirecionamento acontece via HTTP request com encaminhamentos no cabeçalho da requisição.

Fluxo de Autenticação

A seguir o fluxo de como acontece a prova de identidade usando SAML.

No processo 4, caso o usuário já esteja logado então ele reaproveita o login ao invés de pedir uma nova autenticação, melhorando o fluxo e diminuindo o número de chamadas. Se o navegador já tem um cookie de sessão ativo e válido não pedirá login de novo. Gera a resposta SAML (SAMLResponse) e te redireciona de volta ao SP.

Mesmo se o cookie de sessão for válido o login ainda acontece, mas de forma transparente e muito mais rápido. O IdP chega a fazer a requisição pro IdP no passo 3. O IdP confere o cookie na requisição e com o cookie válido não mostra a tela de login mas gera o SAMLResponse no passo 4 redirecionando de volta pro SP.

O SAMLResponse é o coração do SAML SSO — é onde o IdP prova para o SP que você está autenticado. É um XML assinado digitalmente, contendo algo desse tipo.

<samlp:Response>
  <saml:Issuer>https://idp.exemplo.com</saml:Issuer>
  <samlp:Status>...</samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID>[email protected]</saml:NameID>
      ...
    </saml:Subject>
    <saml:Conditions>...</saml:Conditions>
    <saml:AuthnStatement>...</saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="email">...</saml:Attribute>
      <saml:Attribute Name="role">...</saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Campo	O que faz
Issuer	Quem gerou a resposta (o IdP)
Status	Se a autenticação deu certo
Assertion	A prova de que o usuário está autenticado
NameID	Identificador do usuário (geralmente e-mail ou username)
AuthnStatement	Quando e como o usuário se autenticou
AttributeStatement	Info adicional (ex: nome, e-mail, grupos, cargo, etc)
Conditions	Validade da resposta, SP autorizado, etc
Signature	Assinatura digital que garante a integridade e autenticidade

O que o SP faz com isso?

• Verifica a assinatura.
• Confere se o Issuer é confiável.
• Lê o NameID e os atributos.
• Cria uma sessão local pro usuário.

SAMLResponse = resposta completa do IdP.

SAML Assertion = a parte da resposta que contém a identidade e os atributos do usuário.

“SAML token” = outro nome pra esse Assertion (às vezes chamado de “token SAML” porque é o que “prova” a identidade).

<samlp:Response>
  ...
  <saml:Assertion>  ← ISSO é o "SAML token"
    <saml:Subject>...</saml:Subject>
    <saml:AuthnStatement>...</saml:AuthnStatement>
    <saml:AttributeStatement>...</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Como podemos ter certeza de que o SAMLResponse veio realmente do IdP e não foi forjado?

Para isso, usamos assinatura digital + troca prévia de certificados.

Ao configurar a aplicação, é necessário estabelecer uma relação de confiança com o IdP.

O IdP possui um certificado X.509 (contendo sua chave pública), que deve ser conhecido pelo SP. Esse certificado pode ser fornecido manualmente ou via metadata XML. Normalmente, o IdP disponibiliza esses metadados (incluindo o certificado) em um endpoint público, permitindo que o SP atualize as informações automaticamente caso ocorram mudanças. Esses dados não são sensíveis, por isso podem ser expostos publicamente.

Quando o SAMLResponse chega ao SP, ele usa a chave pública do IdP para verificar a assinatura digital contida na resposta. Isso garante que o conteúdo não foi alterado nem forjado durante o trajeto.

Se necessário leia mais sobre isso em TLS.

Com tudo isso, conseguimos centralizar os usuários em um único lugar e trabalhar com Single Sign-On (SSO).

Esses usuários passam a ser considerados federados, ou seja, suas identidades são gerenciadas por um provedor central (IdP) e podem ser usadas por vários aplicativos dentro da organização. Isso permite que todos os sistemas compartilhem a mesma identidade de forma segura e padronizada.

Quais São As Limitações do SAML?

Apesar de ser um padrão muito usado, especialmente em empresas, o SAML tem algumas limitações importantes:

1. Complexidade: O protocolo é verboso (XML pesado, namespaces, assinatura digital, etc). Implementar corretamente exige muita atenção a detalhes técnicos.

2. Performance: Baseado em XML e troca de dados via redirects HTTP + base64, o que pode ser mais lento comparado com soluções modernas como OAuth2/OIDC.

3. Limitado a Web: Foi criado para navegadores e aplicações web. Não funciona bem em APIs ou apps mobile. Não lida bem com tokens bearer como o JWT.

4. Sessão gerenciada pelo IdP: O SP depende do IdP pra tudo relacionado à sessão. Isso limita o controle que o SP tem sobre logout, expiração, etc.

5. Integrações mais difíceis: Configurar SAML entre SP e IdP costuma ser manual e chato (troca de metadata, certificados, endpoints). Poucos serviços oferecem um SDK simples como OAuth2/OIDC.

6. Falhas comuns de implementação: Por ser complexo, muitos devs erram na verificação de assinatura, replay attacks, ou aceitam assertions vencidas.

SAML ainda é útil, especialmente em ambientes corporativos legados, mas está sendo gradualmente substituído por OIDC/OAuth2, que são mais leves, modernos e versáteis.