SAML 2.0 a Fundo: Asserções, Fluxos SP/IdP e Ataques de Assinatura XML

Apesar de OAuth 2.0 e OpenID Connect (OIDC) dominarem o desenvolvimento de aplicações modernas e mobile, o padrão SAML 2.0 (Security Assertion Markup Language), publicado em 2005 pela OASIS, continua sendo a espinha dorsal da federação de identidade corporativa em grandes empresas, órgãos governamentais e instituições de ensino.

sequenceDiagram
  autonumber
  participant User as Usuário (Browser)
  participant SP as Service Provider (SaaS / App)
  participant IdP as Identity Provider (Entra ID / Okta)

  User->>SP: 1. Acessa recurso protegido (/dashboard)
  SP-->>User: 2. Redireciona com AuthnRequest (SAMLRequest via Base64)
  User->>IdP: 3. Entrega SAMLRequest ao IdP
  IdP->>User: 4. Solicita credenciais + MFA
  User-->>IdP: 5. Autentica com sucesso
  IdP-->>User: 6. Emite SAMLResponse assinada (Asserção XML com certificado X.509)
  User->>SP: 7. POST HTTP contendo SAMLResponse (Assertion Consumer Service)
  SP->>SP: 8. Valida assinatura XML e chaves do IdP
  SP-->>User: 9. Estabelece cookie de sessão local

A Anatomia de uma Asserção SAML

Uma asserção SAML é um fragmento XML criptograficamente assinado emitido pelo Identity Provider (IdP) atestando a identidade do usuário para o Service Provider (SP).

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_d129a..." IssueInstant="2026-10-02T10:00:00Z" Version="2.0">
  <saml2:Issuer>https://login.microsoftonline.com/tenant-id/v2.0</saml2:Issuer>
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">engenheiro@empresa.com</saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData NotOnOrAfter="2026-10-02T10:05:00Z" Recipient="https://app.empresa.com/saml/acs"/>
    </saml2:SubjectConfirmationMethod>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2026-10-02T09:55:00Z" NotOnOrAfter="2026-10-02T10:05:00Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>https://app.empresa.com</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AttributeStatement>
    <saml2:Attribute Name="groups">
      <saml2:AttributeValue>Engenharia-Admins</saml2:AttributeValue>
    </saml2:Attribute>
  </saml2:AttributeStatement>
</saml2:Assertion>

Vulnerabilidade Clássica: XML Signature Wrapping (XSW)

A especificação XML-DSig permite assinar partes arbitrárias de um documento XML referenciando elementos por ID (URI="#_d129a..."). Isso abriu espaço histórico para ataques de XML Signature Wrapping:

• O invasor captura uma asserção legítima emitida pelo IdP para seu próprio usuário comum.
• Ele injeta uma segunda asserção forjada contendo privilégios de administrador.
• Se a biblioteca do SP validar a assinatura de um elemento, mas o parser de aplicação ler os atributos do outro elemento não-assinado devido a falha de resolução de XPath, o invasor obtém acesso administrativo pleno.

Para novos projetos, OIDC é a escolha padrão unânime. Entretanto, em contratos corporativos com grandes multinacionais, saber operar endpoints SAML 2.0 é pré-requisito indispensável para fechar contratos de integração de TI.