Assertions, bindings, metadata, assinatura XML, SSO e federação de identidade em ambientes corporativos
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Federação : identidade autenticada em um domínio e consumida em outro
Figura de abertura - O conecta domínios de identidade por meio de mensagens e relações explícitas de confiança.
Princípio central
transporta declarações de segurança entre entidades que já estabeleceram metadados, chaves e regras de confiança.
Edição aprofundada - material de estudo e consulta profissional
Apresentação do capítulo
Os capítulos anteriores estudaram 2.0, OpenID Connect e a família . Esses padrões dominam aplicações modernas e , mas não substituíram completamente os mecanismos de federação empresarial construídos antes deles. 2.0 permanece amplamente presente em portais corporativos, sistemas SaaS, ambientes acadêmicos, governos, bancos e integrações entre organizações que precisam de Single Sign-On baseado em navegador e troca padronizada de atributos.
, abreviação de Security Markup Language, é um para comunicar declarações de autenticação, atributos e decisões de autorização. Seu uso mais conhecido é o Web Browser , no qual um Identity Provider autentica o usuário e envia ao Service Provider uma assinada. Porém, compreender apenas o fluxo visual de redirecionamento é insuficiente. A segurança depende de bindings, , certificados, validação de assinatura , condições temporais, audience, recipient, correlation e proteção contra .
Diferentemente de um simples transportado diretamente para uma , a resposta normalmente é consumida por um específico do Service Provider, chamado Consumer Service. O valida a mensagem e cria sua própria sessão local. Essa separação explica por que é especialmente adequado ao login federado de aplicações web, mas menos natural para autorização delegada de e chamadas service-to-service.
Este capítulo constrói um modelo mental completo do 2.0: atores, assertions, protocol messages, bindings, profiles, , , atributos, assinatura, criptografia, Single Logout, federação e integração com . O foco é permitir projeto, revisão e seguros, sem reduzir o padrão a copiar certificados entre dois consoles administrativos.
Como estudar este capítulo
Separe sempre quatro camadas: , protocol message, e . Depois, acompanhe a relação de confiança descrita em e valide cada restrição de segurança. Essa decomposição torna o muito menos confuso e evita misturar transporte, identidade e sessão.
Objetivos de aprendizagem
Explicar as responsabilidades de principal, Identity Provider, Service Provider e autoridades .
Distinguir , protocol message, , e .
Descrever statements de autenticação, atributos e decisão de autorização.
Detalhar o Web Browser nos modos -initiated e -initiated.
Interpretar , , , Subject, Conditions e .
Comparar -Redirect, - , -Artifact e bindings.
Entender , , Service, Service, KeyDescriptor e rotação de certificados.
Aplicar validação segura de Signature e reconhecer signature wrapping e .
Compreender , atributos, mapeamento de identidade, e discovery.
Comparar 2.0 com OpenID Connect e reconhecer o papel de e brokers de identidade.
Estrutura do capítulo
19.1 Fundamentos e componentes do 2.0
19.2 Assertions e statements
19.3 Protocol messages
19.4 Web Browser
19.5 -initiated e -initiated
19.6 em profundidade
19.7 e em profundidade
19.8 Conditions, e correlação
19.9 Bindings
19.10 e confiança
19.11 Signature e criptografia
19.12 , atributos e mapeamento
19.13 Sessões, e discovery
19.14 x , , segurança e
Resumo, checklist, exercícios, glossário e referências
19.1 Fundamentos e componentes do 2.0
organiza a federação em entidades com papéis bem definidos. O principal é normalmente o usuário. O Identity Provider, ou , autentica esse principal e emite declarações. O Service Provider, ou , oferece a aplicação e confia nas assertions produzidas pelo conforme uma relação previamente configurada. Em cenários mais amplos, também podem existir Attribute Authorities, Authentication Authorities e Policy Decision Points.
O padrão é composto por peças complementares. Core define assertions e mensagens de protocolo. Bindings descrevem como essas mensagens são transportadas por protocolos como ou . Profiles combinam assertions, mensagens e bindings para resolver casos de uso concretos, como browser ou Single Logout. descreve entidades, , bindings suportados, identificadores, certificados e outras informações necessárias para interoperabilidade.
A relação de confiança não nasce porque uma mensagem contém um certificado. O deve conhecer previamente o do e as chaves aceitas para assinatura. Da mesma forma, o precisa conhecer o do , seus e, dependendo da política, as chaves usadas pelo . é o mecanismo padrão para distribuir essas informações, mas sua obtenção e atualização também precisam ser autenticadas e governadas.
Tabela 1 - As camadas do SAML devem ser analisadas separadamente.
Conceito
Responsabilidade
Exemplo
Assertion
Contém declarações sobre um subject.
Usuário autenticado com MFA e atributos corporativos.
Protocol
Coordena requisições e respostas SAML.
AuthnRequest e Response.
Binding
Define o transporte da mensagem.
HTTP-Redirect ou HTTP-POST.
Profile
Combina regras para um caso de uso.
Web Browser SSO Profile.
Metadata
Publica identidade, endpoints e chaves.
EntityDescriptor do IdP ou SP.
19.2 Assertions e statements
Uma é uma estrutura emitida por uma autoridade e relacionada a um subject. Ela possui identificador, versão, instante de emissão, issuer e zero ou mais statements. Também pode conter assinatura, condições e informações sobre como o subject deve confirmar sua identidade perante o destinatário.
O Authentication Statement registra que uma autoridade autenticou o subject em determinado instante e contexto. Pode incluir SessionIndex, SessionNotOnOrAfter e AuthnContextClassRef, elementos usados por aplicações que precisam distinguir senha, , certificado ou outros métodos. O Attribute Statement transporta pares de nome e valor, como identificador interno, e-mail, unidade organizacional ou grupos.
O Authorization Decision Statement representa uma decisão de autorização sobre um recurso, mas é menos frequente no Web moderno. Na prática, muitos SPs usam atributos e contexto de autenticação para alimentar suas próprias políticas locais. Essa escolha preserva autonomia de domínio, mas exige acordos claros sobre semântica, cardinalidade, namespaces e tratamento de atributos ausentes.
Figura 1 - Uma segura combina origem, subject, restrições, statements e proteção criptográfica.
Tabela 2 - Statements carregam semânticas distintas dentro da assertion.
Statement
Declaração principal
Uso recorrente
AuthnStatement
Como e quando o usuário foi autenticado.
SSO, step-up e auditoria.
AttributeStatement
Atributos associados ao subject.
Provisionamento lógico e autorização local.
AuthzDecisionStatement
Decisão sobre ação em recurso.
Integrações específicas e legadas.
19.3 Protocol messages
As mensagens de protocolo coordenam interações entre entidades. pede autenticação; carrega uma ou mais assertions ou um status de erro; LogoutRequest e LogoutResponse participam de Single Logout; ArtifactResolve e ArtifactResponse recuperam mensagens por referência; AttributeQuery e AuthnQuery consultam autoridades especializadas.
Cada mensagem possui ID, Version, IssueInstant e, conforme o tipo, Destination, Consent, e outros atributos. Esses campos não são decorativos. O ID permite correlação e proteção contra . Destination restringe o esperado. vincula uma resposta a uma solicitação previamente emitida. IssueInstant auxilia na validação temporal e na investigação de relógios desalinhados.
O status da precisa ser interpretado antes da . Success indica que o processamento principal foi concluído, mas não substitui todas as validações. Outros códigos podem representar requester error, responder error, autenticação falhou, método não suportado, usuário desconhecido ou ausência de consentimento.
O Web Browser é o uso mais conhecido do 2.0. O navegador atua como intermediário entre e . Quando o usuário acessa um recurso protegido, o cria uma e redireciona ou envia o navegador ao . O autentica o usuário, cria a , assina a ou a própria conforme o acordo e devolve o resultado ao Consumer Service do .
O recebe a mensagem, realiza validações estruturais, criptográficas e semânticas e, se tudo estiver correto, cria uma sessão local da aplicação. O não define como essa sessão local deve ser implementada. Ela pode usar seguro, sessão server-side ou outro mecanismo. Isso significa que a segurança pós-login depende também de controles clássicos como Secure, HttpOnly, SameSite, expiração, rotação e proteção contra fixation.
preserva estado da aplicação, como o recurso originalmente solicitado. Ele não deve ser tratado como canal confiável de autorização e precisa ser protegido contra open redirect e adulteração. A implementação deve aceitar apenas destinos previstos ou valores opacos armazenados server-side.
Figura 2 - No -initiated , a deve ser correlacionada à original.
19.5 -initiated e -initiated
No -initiated , o fluxo começa no Service Provider. O cria uma , registra seu ID e espera uma resposta correlacionada. Esse modelo permite melhor controle de contexto, destination e retorno ao recurso solicitado. A validação de reduz ataques de resposta não solicitada e ajuda a associar a autenticação à transação correta.
No -initiated , o fluxo começa em um portal do ou catálogo de aplicações. O envia uma não solicitada ao do . Esse modo é conveniente para portais corporativos, porém perde a correlação com uma . A implementação precisa compensar essa redução de contexto com controles estritos de issuer, audience, recipient, tempo, e destinos permitidos.
Algumas aplicações aceitam os dois modos. Nessa situação, o código de validação deve distinguir claramente respostas solicitadas e não solicitadas. Não é seguro simplesmente tornar opcional em todos os casos. A política precisa definir quando -initiated é aceito, para quais IdPs, ACSs e fluxos de negócio.
Tabela 3 - Os dois modos exigem políticas de validação distintas.
Aspecto
SP-initiated
IdP-initiated
Início
Usuário acessa o SP.
Usuário parte do portal do IdP.
AuthnRequest
Existe e deve ser rastreada.
Normalmente ausente.
Correlação
InResponseTo e estado local.
Não há requisição original.
Risco adicional
Open redirect e request tampering.
Replay e resposta não solicitada.
Tabela 3 - Os dois modos exigem políticas de validação distintas.
19.6 em profundidade
A comunica ao qual solicita autenticação e, opcionalmente, quais características deseja. Issuer identifica o . Destination aponta o do . AssertionConsumerServiceURL ou AssertionConsumerServiceIndex seleciona o . ProtocolBinding pode indicar como a deve retornar. NameIDPolicy pede formato de identificador e pode permitir criação de um novo pseudônimo.
ForceAuthn solicita que o reautentique o usuário mesmo que exista uma sessão . IsPassive pede que o não interaja com o usuário; se não for possível autenticar silenciosamente, a resposta deve indicar falha apropriada. RequestedAuthnContext expressa requisitos sobre método ou força de autenticação, mas sua interpretação precisa ser alinhada entre as partes.
Assinar pode ser obrigatório por política, especialmente quando o envia dinâmico, solicita ForceAuthn ou opera em federações com exigências fortes. No Redirect , a assinatura ocorre sobre parâmetros da e não sobre um elemento ds:Signature dentro do . No , a mensagem pode carregar Signature. Confundir essas duas formas é causa comum de falha.
Tabela 4 - A AuthnRequest controla mais do que um simples redirecionamento.
Campo
Função
Validação ou política
Issuer
Identifica o SP solicitante.
Deve corresponder a metadata confiável.
Destination
Endpoint do IdP.
Comparação exata com o endpoint recebido.
ACS URL / Index
Destino da Response.
Somente valores registrados em metadata.
ForceAuthn
Solicita nova autenticação.
Aplicar apenas conforme política.
RequestedAuthnContext
Requisito de autenticação.
Mapear classes e comparação corretamente.
19.7 e em profundidade
A é a mensagem de protocolo entregue ao . Ela possui Issuer, Status, Destination, e pode conter assertions. Em muitos perfis, a e a podem ser assinadas em combinações diferentes. A política do deve definir exatamente qual assinatura é necessária e em qual elemento, evitando aceitar mensagens parcialmente protegidas de forma inconsistente.
A contém as declarações consumidas pela aplicação. O deve localizar a autenticada por uma assinatura validada, e não simplesmente a primeira com determinado XPath. Essa regra é central contra , ataque em que um elemento assinado válido é deslocado e outro elemento malicioso é colocado no local que a aplicação processa.
Uma validação completa também verifica Issuer, Version, IssueInstant, Conditions, AudienceRestriction, SubjectConfirmationData, Recipient, NotOnOrAfter, , AuthnStatement e contexto exigido. Depois da validação, os atributos devem ser mapeados por regras explícitas. O fato de um ter sido assinado não torna todos os valores adequados à aplicação.
Estrutura simplificada de Response e Assertion
<samlp:Response Destination="https://app.example/saml/acs"
InResponseTo="_a12f...">
<saml:Issuer>https://idp.example/metadata</saml:Issuer>
<samlp:Status>...</samlp:Status>
<saml:Assertion ID="_assertion123">
<saml:Subject>...</saml:Subject>
<saml:Conditions>...</saml:Conditions>
<saml:AuthnStatement>...</saml:AuthnStatement>
<saml:AttributeStatement>...</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
19.8 Conditions, e correlação
Conditions restringe quando e onde a pode ser usada. NotBefore define o instante inicial, e NotOnOrAfter define um limite exclusivo. AudienceRestriction indica as entidades para as quais a foi emitida. A aplicação deve comparar a audience com seu identificador esperado e usar tolerância de relógio pequena e controlada, sem transformar clock skew em janela ampla de .
normalmente usa o método no Web Browser . SubjectConfirmationData carrega Recipient, NotOnOrAfter e . Recipient precisa corresponder ao efetivamente utilizado. deve apontar para uma pendente quando o fluxo foi iniciado pelo . Uma resposta já processada deve ser marcada como consumida para impedir .
A correlação também envolve , temporários e estado local. Esses elementos não substituem uns aos outros. relaciona a à ; devolve contexto da aplicação; a sessão temporária do armazena informações sobre a transação. Um desenho robusto mantém todos os vínculos e remove o estado após uso.
Figura 3 - A assinatura é uma etapa do , não a validação completa.
19.9 Bindings
define como uma mensagem é mapeada para outro protocolo. No -Redirect , a mensagem é normalmente comprimida com DEFLATE, codificada em e colocada na . É adequado para pequenas, mas possui limites de e regras específicas de assinatura sobre SAMLRequest, e SigAlg.
No - , a mensagem é enviada em um formulário , geralmente por auto-submit. É o mais comum para transportar SAMLResponse ao . Como o navegador entrega conteúdo de um domínio a outro, o precisa aceitar , proteger sessão local e validar integralmente a mensagem antes de qualquer redirecionamento.
-Artifact envia apenas uma referência curta pelo navegador. O troca o artifact pela mensagem real em um canal back-channel, normalmente com . Isso reduz exposição da ao user agent, mas adiciona disponibilidade, autenticação e latência ao artifact resolution service. também aparece em consultas e Single Logout back-channel.
Figura 4 - é transporte; o define como esse transporte participa do caso de uso.
Tabela 5 - Cada binding possui formato e riscos operacionais próprios.
Binding
Uso típico
Ponto técnico
HTTP-Redirect
AuthnRequest no navegador.
DEFLATE, URL encoding e assinatura de parâmetros.
HTTP-POST
SAMLResponse para o ACS.
Formulário HTML com mensagem Base64.
HTTP-Artifact
Referência no front-channel.
Resolução da mensagem por back-channel.
SOAP
Consultas e troca direta.
Canal servidor-servidor com XML SOAP.
19.10 e confiança
descreve entidades por meio de EntityDescriptor. Um é um identificador estável, frequentemente uma , mas não precisa ser uma acessível. Role descriptors informam se a entidade atua como , ou outra autoridade. incluem , location, índice e preferência. KeyDescriptor publica certificados associados a assinatura ou criptografia.
do costuma conter , formats e certificados. do contém SingleSignOnService, SingleLogoutService, certificados e outros recursos. O consumidor deve aceitar somente e chaves provenientes de fontes confiáveis. Permitir arbitrário vindo apenas da pode transformar o em transmissor de assertions para um atacante.
Rotação de certificado exige sobreposição. O novo certificado deve ser publicado antes de ser usado; o antigo permanece enquanto mensagens e ainda podem depender dele. Certificado expirado em não deve ser tratado de forma simplista: o uso de em é frequentemente como contêiner de chave, mas políticas corporativas podem exigir validações adicionais. O importante é possuir regra explícita e auditável.
Figura 5 - reduz configuração manual, mas precisa de cadeia de distribuição confiável.
Exemplo simplificado de metadata de SP
<md:EntityDescriptor entityID="https://app.example/saml">
<md:SPSSODescriptor AuthnRequestsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">...</md:KeyDescriptor>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://app.example/saml/acs"
index="0" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
19.11 Signature e criptografia
Signature protege integridade e autenticidade de elementos . Ela referencia um elemento por ID, aplica transforms, canonicalização e digest e produz SignatureValue. Canonicalização existe porque semanticamente equivalente pode ter diferenças de whitespace, namespaces e ordenação de atributos. A implementação deve usar bibliotecas maduras e uma política restrita de algoritmos, transforms e referências.
O ataque explora divergência entre o elemento verificado e o elemento consumido. A defesa central é resolver a referência assinada de forma segura, exigir IDs únicos, rejeitar estruturas inesperadas e processar exatamente o nó autenticado. Consultas XPath genéricas como procurar a primeira no documento são perigosas quando não estão vinculadas à verificação criptográfica.
Encryption permite criptografar a , o ou atributos. O usa a chave pública de criptografia do , e o descriptografa com sua chave privada. Assinar e criptografar resolvem problemas diferentes: criptografia protege confidencialidade no caminho e em intermediários; assinatura protege integridade e origem. Mesmo uma criptografada precisa ser validada após a decriptação.
Tabela 6 - Controles criptográficos são complementares.
Controle criptográfico
Protege
Não substitui
Assinatura da Response
Mensagem de protocolo e destino.
Validação da assertion e conditions.
Assinatura da Assertion
Declarações e restrições.
Correlação e proteção de sessão.
EncryptedAssertion
Confidencialidade do conteúdo.
Autenticidade e audience.
TLS
Canal entre participantes.
Assinatura fim a fim da mensagem.
Regra de implementação
Nunca implemente Signature manualmente com concatenação de strings ou XPath improvisado. Use biblioteca especializada, mantenha parser endurecido, desabilite entidades externas e valide estrutura, IDs e referências antes de consumir atributos.
19.12 , atributos e mapeamento de identidade
identifica o subject em formatos padronizados. Persistent produz um identificador estável e geralmente opaco. Transient cria um valor temporário. EmailAddress usa e-mail, mas pode ser inadequado como chave imutável. Unspecified depende de acordo bilateral. A escolha deve considerar privacidade, correlação entre SPs, mudanças de dados e ciclo de vida de contas.
Atributos são identificados por Name e, opcionalmente, NameFormat e FriendlyName. O não deve confiar apenas em nomes informais como role ou group sem contrato. É necessário definir namespace, tipo, cardinalidade, origem autoritativa e significado. Um grupo do diretório pode não equivaler a uma permissão de negócio, e mapeamentos automáticos podem elevar privilégios indevidamente.
Account linking merece cuidado. Quando o recebe um subject federado, precisa vinculá-lo a uma conta local. Vincular apenas por e-mail pode permitir takeover se provedores diferentes emitirem o mesmo endereço ou se a verificação de e-mail não for equivalente. A chave recomendada normalmente combina issuer e identificador estável do subject, com processos controlados para migração.
Tabela 7 - Identificadores e atributos precisam de contrato, não apenas de XML válido.
Formato / elemento
Característica
Cuidado
persistent NameID
Estável e opaco por relação.
Preservar vínculo durante migração.
transient NameID
Temporário e não correlacionável.
Não usar como chave permanente.
emailAddress
Legível e familiar.
Pode mudar e não ser globalmente único.
Attribute
Valor adicional sobre o subject.
Definir semântica, origem e cardinalidade.
19.13 Sessões, Single Logout e discovery
Existem pelo menos duas sessões distintas: a sessão do usuário no e a sessão local no . O AuthnStatement pode conter SessionIndex e SessionNotOnOrAfter, mas o decide como criar e expirar seu . Encerrar a sessão do não encerra automaticamente todas as sessões locais, a menos que Single Logout seja suportado e funcione em toda a cadeia.
Single Logout coordena LogoutRequest e LogoutResponse entre participantes. Pode usar front-channel pelo navegador ou back-channel. Na prática, falhas parciais são comuns: um indisponível, bloqueado ou pode deixar sessões ativas. Por isso, não deve ser tratado como substituto de sessões curtas, revogação local e controles próprios de risco.
Discovery aparece quando um aceita múltiplos provedores. A escolha pode ocorrer por domínio do usuário, portal, de descoberta ou serviço dedicado. A interface deve evitar phishing e seleção confusa. Em federações amplas, agregada e discovery service precisam ser operados com assinatura, expiração, filtros e governança.
19.14 2.0 x OpenID Connect
2.0 e OpenID Connect resolvem autenticação federada, mas possuem modelos e ecossistemas diferentes. usa , assertions, bindings e browser profiles. usa 2.0, , , e Discovery/ . tende a se encaixar melhor em aplicações móveis, SPAs, e arquiteturas modernas; permanece muito forte em SaaS empresarial e integrações B2B legadas.
A comparação não deve ser reduzida a antigo versus novo. possui rica, federações maduras e interoperabilidade consolidada em muitos produtos corporativos. oferece melhor alinhamento com , bibliotecas modernas e . Uma organização pode operar ambos por muitos anos, usando um identity broker para traduzir protocolos e centralizar políticas.
Tradução entre e não é mera conversão sintática. , subject, atributos, , acr, amr, sessão e logout possuem semânticas diferentes. O broker precisa de mapeamentos explícitos, política de confiança e observabilidade para que a garantia de autenticação não seja degradada durante a transformação.
Tabela 8 - Os padrões se sobrepõem em objetivo, mas não em todos os detalhes.
Aspecto
SAML 2.0
OpenID Connect
Formato
XML e XML Signature.
JSON, JWT e JOSE.
Uso dominante
Web SSO corporativo e federação B2B.
Apps web, mobile, APIs e identidade moderna.
Descoberta
Metadata SAML.
Discovery metadata e JWKS.
Identificador
NameID e atributos.
sub e claims.
Sessão e logout
SLO por mensagens SAML.
RP-Initiated e canais de logout OIDC.
19.15 em e brokers de identidade
normalmente protegem com , , ou credenciais técnicas. pode aparecer na autenticação do portal de desenvolvedores, no login de consoles administrativos ou como protocolo de entrada de um identity broker. Quando uma aplicação precisa chamar , o padrão comum é trocar a sessão federada por um apropriado, e não enviar a diretamente a todos os .
Alguns conseguem validar assertions , extrair atributos e transformá-los em contexto ou internos. Essa capacidade deve ser usada com cuidado: o precisa validar assinatura, issuer, audience, recipient, tempo e com o mesmo rigor de um . Também deve evitar transformar atributos genéricos em privilégios amplos sem política explícita.
Em arquiteturas híbridas, um broker pode receber de parceiros e emitir / para aplicações modernas. Essa ponte reduz a necessidade de cada compreender Signature, mas concentra confiança no broker. devem registrar issuer externo, subject federado, método de autenticação, mapeamentos e emitido, preservando rastreabilidade fim a fim.
19.16 Ameaças e hardening
As principais ameaças incluem , assinatura inválida ou em elemento errado, acceptance de issuer inesperado, audience inadequada, aberto, , parser vulnerável a entidades externas, algoritmos fracos, adulterada, roubo de sessão, open redirect por e mapeamento inseguro de atributos.
Hardening começa com allowlists de e , autenticada, algoritmos modernos, validação exata de , IDs únicos, de , tolerância de relógio curta e fail closed. O parser deve desabilitar DTD e external entities. A aplicação deve processar apenas elementos assinados e rejeitar mensagens com estrutura ambígua, assinaturas duplicadas ou referências inesperadas.
A operação também importa. Certificados precisam de inventário, alertas e rotação com sobreposição. Relógios devem usar sincronização confiável. Mudanças de atributos e exigem testes de regressão. não devem armazenar assertions completas sem necessidade, porque elas podem conter dados pessoais e informações de autenticação.
Tabela 9 - A maioria das falhas ocorre na validação e integração, não no conceito de SAML.
Ameaça
Falha explorada
Controle
Replay
Assertion válida reutilizada.
Cache de IDs e janelas temporais curtas.
Signature wrapping
Elemento verificado difere do consumido.
Processar exatamente o nó referenciado e assinado.
ACS injection
Destino controlado pelo atacante.
Somente endpoints registrados em metadata.
XXE
Parser resolve entidade externa.
DTD e entidades externas desabilitadas.
Privilege mapping
Atributo vira permissão excessiva.
Mapeamento explícito e menor privilégio.
19.17 orientado por evidências
deve identificar o ponto exato do fluxo: criação da , redirecionamento, autenticação no , emissão da , entrega ao , validação criptográfica, mapeamento de atributos ou criação da sessão. Erros de browser, e aplicação podem parecer semelhantes, por isso IDs de , timestamps, entityIDs e são essenciais.
Mensagens como invalid signature podem resultar de certificado incorreto, canonicalização, alterado, algoritmo não permitido ou verificação do elemento errado. Audience invalid aponta para divergente. Recipient mismatch indica diferente. expired pode ser relógio desalinhado, fila longa ou janela pequena. unknown aponta para estado perdido, múltiplos nós sem compartilhamento de sessão ou resposta não solicitada.
Ferramentas de captura devem ser usadas em ambientes autorizados e com cuidado para não expor assertions. O diagnóstico ideal compara ativa, emitida, recebida, certificado selecionado e configuração da aplicação. Em , verifique afinidade, armazenamento do ID e relógio de todos os nós.
Tabela 10 - Diagnóstico SAML exige correlação entre mensagem, metadata e estado local.
Sintoma
Hipóteses
Evidências
Invalid signature
Chave errada, XML alterado, algoritmo ou referência.
Certificado, SignedInfo, Reference URI e logs da biblioteca.
Audience mismatch
entityID diferente do esperado.
AudienceRestriction e configuração do SP.
InResponseTo desconhecido
Estado perdido ou resposta não solicitada.
Request ID, cookie temporário e nó do cluster.
Assertion expirada
Clock skew ou atraso excessivo.
NotBefore, NotOnOrAfter e horário dos hosts.
Usuário sem permissão
Atributo ausente ou mapping incorreto.
AttributeStatement e política local.
19.18 Estudos de caso e laboratórios
Estudo de caso 1: uma empresa integra seu corporativo a um SaaS externo. O exige persistent e grupos específicos. A equipe define bilateral, certificados de assinatura, mapeamento de atributos, janela de rotação e testes de usuários com múltiplas unidades. O projeto falha inicialmente porque o e-mail era usado como chave imutável; a correção adota identificador estável e migração controlada.
Estudo de caso 2: um portal bancário aceita parceiros por e converte a identidade em internos para . O broker valida a , aplica política de issuer e , mapeia o subject externo a uma aplicação parceira e emite com audience restrita. O nunca recebe a original nos , reduzindo exposição do e centralizando a federação.
Estudo de caso 3: um de apresenta falhas intermitentes de . A causa é o armazenamento local da em cada nó sem afinidade ou sessão compartilhada. O navegador inicia em um nó e retorna a outro. A correção utiliza armazenamento distribuído de pendentes e mantém de por toda a janela de validade.
Laboratórios sugeridos
1) Examine de e e identifique , , , e certificados. 2) Decodifique uma e uma de ambiente de laboratório. 3) Liste todas as validações além da assinatura. 4) Simule rotação de certificado com período de sobreposição. 5) Compare um fluxo com Authorization Code + .
Resumo do capítulo
2.0 é um de federação baseado em assertions, protocol messages, bindings, profiles e . Seu caso de uso mais comum é Web Browser entre um Identity Provider e um Service Provider. O autentica o principal, emite declarações e o valida a mensagem antes de criar sua própria sessão local.
A segurança depende de muito mais que uma assinatura válida. Issuer, audience, recipient, destination, , tempo, , , estrutura e precisam ser validados de forma coerente. e parsing inseguro demonstram por que bibliotecas maduras e processamento do elemento efetivamente assinado são indispensáveis.
continua relevante em federações corporativas e B2B, enquanto OpenID Connect se encaixa melhor em aplicações e modernas. Brokers de identidade permitem coexistência e tradução, mas precisam preservar semântica e rastreabilidade. Em plataformas de , normalmente autentica usuários em portais ou entra no broker, que então emite apropriados para as .
Próximo passo do curso
O Capítulo 20 aprofundará Identity Federation e Single Sign-On como arquitetura, comparando domínios de confiança, brokers, home realm discovery, provisionamento, ciclo de vida e coexistência entre , OpenID Connect e outros mecanismos.
Checklist de implementação e revisão
EntityIDs, e bindings vêm de confiável e versionada.
IDs são únicos e armazenados até a correlação da .
O aceita somente destinos registrados e rejeita mensagens para outro recipient.
A biblioteca valida Signature e a aplicação consome exatamente o elemento assinado.
Issuer, audience, destination, recipient, e condições temporais são verificados.
Assertions processadas são registradas em de durante a janela necessária.
Parser desabilita DTD, external entities e construções perigosas.
e atributos possuem contrato de semântica, cardinalidade e origem.
Mapeamentos de grupos para permissões seguem menor privilégio e possuem testes.
Certificados têm inventário, monitoramento, sobreposição e plano de .
Sessão local usa seguros e não depende exclusivamente de Single Logout.
preservam correlação sem armazenar dados pessoais desnecessários.
Exercícios
Diferencie , protocol message, , e .
Descreva o fluxo -initiated e indique onde é validado.
Explique por que assinatura válida não é suficiente para aceitar uma .
Compare -Redirect, - , -Artifact e bindings.
Explique o papel de AudienceRestriction, Recipient e SubjectConfirmationData.
Diferencie assinatura da e assinatura da .
Descreva e a principal regra de defesa.
Proponha rotação de certificado sem indisponibilidade.
Compare persistent, transient e emailAddress .
Explique por que pode falhar parcialmente.
Compare 2.0 e OpenID Connect em uma arquitetura corporativa.
Desenhe uma ponte para / usando um identity broker.
Glossário
Tabela 11 - Vocabulário essencial do capítulo.
Termo
Definição
ACS
Assertion Consumer Service; endpoint do SP que recebe a Response.
Assertion
Estrutura XML com declarações sobre um subject.
AttributeStatement
Statement que transporta atributos do subject.
AuthnContext
Informação sobre o método ou força de autenticação.
AuthnRequest
Mensagem do SP que solicita autenticação ao IdP.
Binding
Mapeamento de mensagens SAML para outro protocolo.
EntityID
Identificador estável de uma entidade SAML.
IdP
Identity Provider que autentica e emite declarações.
InResponseTo
Correlação entre Response e request anterior.
Metadata
Descrição de entidade, roles, endpoints, bindings e chaves.
NameID
Identificador do subject em formato definido.
Profile
Conjunto de regras para um caso de uso SAML.
RelayState
Estado da aplicação transportado pelo fluxo de navegador.
SLO
Single Logout coordenado entre participantes.
SP
Service Provider que consome assertions e oferece a aplicação.
SubjectConfirmation
Regras pelas quais o subject apresenta a assertion.
XML Signature Wrapping
Ataque que separa elemento verificado do elemento consumido.
Referências técnicas
OASIS. Assertions and Protocols for the OASIS Security Markup Language ( ) V2.0.
OASIS. Bindings for the OASIS Security Markup Language ( ) V2.0.
OASIS. Profiles for the OASIS Security Markup Language ( ) V2.0.
OASIS. for the OASIS Security Markup Language ( ) V2.0.
OASIS. Security Markup Language ( ) V2.0 Technical Overview.
OASIS. V2.0 Interoperability Version 1.0.
. Signature Syntax and Processing.
. Encryption Syntax and Processing.
. Security Cheat Sheet.
. Digital Identity Guidelines, quando aplicável ao contexto de autenticação e federação.
Nota de atualização
2.0 é um padrão estável, mas produtos, algoritmos permitidos, perfis de interoperabilidade e práticas de hardening continuam evoluindo. Antes de implantar, valide documentação oficial do , , e biblioteca utilizados, incluindo comportamento de assinatura, e rotação.
