Parser SAML

SAML (Security Assertion Markup Language) e um padrao baseado em XML para troca de dados de autenticacao e autorizacao entre provedores de identidade (IdPs) e provedores de servico (SPs). Esta ferramenta decodifica mensagens SAML de URLs, trata codificacao Base64 e DEFLATE, e formata o XML para inspecao.

Especificacoes

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Casos de Uso Comuns

• Depurar fluxos de autenticacao Enterprise Single Sign-On (SSO)
• Inspecionar assertions SAML de provedores de identidade (Okta, Azure AD, ADFS)
• Solucionar problemas de integracao SAML entre servicos
• Verificar atributos de assertion e valores de NameID
• Analisar AuthnContext e parametros de sessao
• Auditar configuracoes SAML para revisao de seguranca

Funcionalidades

• Analisar mensagens SAML AuthnRequest (SP para IdP)
• Decodificar SAML Response e Assertions (IdP para SP)
• Extrair SAMLRequest e SAMLResponse de parametros de consulta URL
• Tratar codificacao Base64 e compressao DEFLATE (binding HTTP-Redirect)
• Formatar estrutura XML com destaque de sintaxe
• Exibir visao geral da mensagem (tipo, ID, IssueInstant, Destination, Status)
• Extrair Issuer, Subject/NameID e Conditions
• Exibir atributos de assertion do AttributeStatement
• Indicador de presenca de assinatura

Exemplos

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Dicas

• SAML usa dois bindings principais: HTTP-Redirect (GET com deflate+base64) e HTTP-POST (POST com base64).
• O parametro RelayState preserva a URL originalmente solicitada durante o fluxo SSO.
• Assertions SAML podem ser assinadas, criptografadas ou ambos. Esta ferramenta mostra o conteudo decodificado.
• Verifique as condicoes NotBefore e NotOnOrAfter para validar o timing da assertion.

Entendendo Parser SAML

SAML (Security Assertion Markup Language) e um padrao aberto baseado em XML para troca de dados de autenticacao e autorizacao entre um Identity Provider (IdP) e um Service Provider (SP). SAML 2.0, publicado pela OASIS em 2005, permanece o protocolo dominante para Enterprise Single Sign-On (SSO), permitindo que funcionarios se autentiquem uma vez e acessem multiplas aplicacoes.

Um fluxo SAML SSO funciona da seguinte forma: um usuario tenta acessar um service provider, o SP gera um AuthnRequest e redireciona o navegador para o IdP, o IdP autentica o usuario e cria uma SAML Response contendo Assertions, e o navegador envia essa Response via POST de volta ao SP. A assertion contem a identidade do usuario (NameID), atributos (email, grupos, funcoes) e condicoes (janela de validade, restricao de audience).

Mensagens SAML sao transportadas usando bindings. O binding HTTP-Redirect codifica XML usando compressao DEFLATE e codificacao Base64 em um parametro de consulta URL. O binding HTTP-POST usa apenas Base64 e envia via formulario de auto-submissao. Depurar SAML requer decodificar essas camadas para inspecionar o XML subjacente.

Assertions SAML podem ser assinadas (para provar que vieram do IdP), criptografadas (para impedir que intermediarios leiam o conteudo) ou ambos. Ao solucionar problemas de SSO, o primeiro passo e sempre decodificar a SAML Response e verificar as condicoes, audience, timestamps e valores de atributos da assertion.

SAML e OAuth 2.0/OpenID Connect servem propositos diferentes. SAML e projetado para SSO corporativo usando assertions baseadas em XML transportadas via redirecionamentos de navegador, e e mais comum em ambientes corporativos com provedores de identidade como ADFS e Okta. OAuth 2.0 e um framework de autorizacao para acesso a APIs usando tokens JSON, e OpenID Connect adiciona uma camada de autenticacao sobre OAuth usando JWTs. OIDC e mais comum em aplicacoes web e moveis modernas, enquanto SAML permanece dominante em ambientes de TI corporativa.

Mensagens SAML frequentemente aparecem como strings ininteligiveis porque sao codificadas para transporte. No binding HTTP-POST, o XML e codificado em Base64. No binding HTTP-Redirect, o XML e primeiro comprimido com DEFLATE, depois codificado em Base64, e entao codificado para URL. Ler o XML original requer reverter essas camadas na ordem correta. Esta ferramenta trata todas as etapas de decodificacao automaticamente, independentemente de qual binding foi usado.

Ao solucionar erros SAML, verifique varias causas comuns: diferenca de relogio entre IdP e SP pode fazer com que timestamps de assertions falhem na validacao; o elemento Audience deve corresponder exatamente ao entity ID configurado do SP; assertions podem ter expirado alem do tempo NotOnOrAfter; o atributo Destination deve corresponder a URL do Assertion Consumer Service (ACS) do SP; e o SP pode nao ter o certificado de assinatura atual do IdP se foi recentemente rotacionado. O parametro RelayState tambem desempenha um papel importante no fluxo SSO — ele preserva a URL originalmente solicitada pelo usuario durante o redirecionamento de autenticacao, para que apos a autenticacao bem-sucedida, o SP possa redirecionar de volta a pagina que o usuario tentou acessar inicialmente.