Decodificador de SAMLResponse e SAMLRequest

Como decodificar uma mensagem SAML

1. Cole o que você tiver. Tudo isto funciona:
   • o valor puro de SAMLResponse ou SAMLRequest, com ou sem codificação de URL
   • SAMLRequest=… com ou sem RelayState, SigAlg e Signature
   • uma URL Redirect inteira copiada da barra de endereços
   • o formulário HTML de envio automático com o campo oculto SAMLResponse
   • XML bruto
2. O decodificador detecta o binding: Base64 puro significa HTTP-POST, dados com deflate significam HTTP-Redirect.
3. Leia primeiro o resumo e depois o XML formatado logo abaixo. O XML é exibido como texto e nunca é renderizado.

A direção Codificar faz o caminho inverso: cole um AuthnRequest e obtenha um valor Redirect, um parâmetro SAMLRequest= ou uma URL completa montada a partir do atributo Destination. Isso ajuda a repetir uma requisição enquanto você testa um service provider.

Binding Redirect vs binding POST

O Redirect usa compactação porque as URLs têm limites práticos de comprimento. No exemplo usado nesta página, um AuthnRequest de 464 caracteres vira 273 bytes com deflate e viaja como 364 caracteres Base64. As respostas carregam assinaturas e certificados, então são grandes demais para uma URL e vão por POST. O decodificador também aceita dados com envelope zlib, que alguns service providers enviam no Redirect em vez de raw deflate.

O que conferir quando o SSO falha

O resumo destaca os campos que causam a maioria das falhas de login:

• Status: qualquer coisa diferente de urn:oasis:names:tc:SAML:2.0:status:Success. Um subcódigo como AuthnFailed, InvalidNameIDPolicy ou RequestDenied indica o motivo, e o StatusMessage costuma acrescentar detalhes.
• Destination e URL de ACS: precisam bater exatamente com o endpoint configurado no service provider, incluindo https e a barra final.
• Audience: precisa ser igual ao entity ID do SP. Uma divergência aqui é um erro de configuração comum depois de renomear uma aplicação.
• Conditions: NotBefore e NotOnOrAfter são comparados com o seu relógio. “Expirado” ou “ainda não válido” em um login recém-feito aponta para diferença de relógio entre o IdP e o SP.
• InResponseTo: deve ser igual ao ID do AuthnRequest. Uma divergência sugere uma resposta antiga ou reenviada. O atributo não existe em logins iniciados pelo IdP, que alguns service providers rejeitam.
• NameID e Format: o identificador que o SP vai comparar com seus usuários, por exemplo emailAddress versus persistent.
• Attributes: cada atributo com todos os seus valores, para confirmar se o IdP envia os grupos ou o e-mail que o SP mapeia.

Decodificar SAML em Python

import base64, zlib
from urllib.parse import unquote

def decode_post(value):
    return base64.b64decode(value).decode()

def decode_redirect(value):
    raw = base64.b64decode(unquote(value))
    return zlib.decompress(raw, -15).decode()

O -15 diz ao zlib para esperar raw deflate sem cabeçalho. Chame unquote só em valores copiados de uma URL; um valor de formulário POST já é Base64 puro, e decodificá-lo como URL pode transformar + em espaço. Mais em Base64 em Python, e o lado da compactação está explicado na página de raw deflate e zlib.

Privacidade das assertions SAML

Uma assertion contém nomes, endereços de e-mail, grupos e às vezes mais dados pessoais, e uma assertion válida e não expirada pode servir como token de login. Esta página a decodifica localmente e não consegue enviá-la para lugar nenhum. Mesmo assim, oculte os dados das assertions antes de colá-las em tickets ou chats, e trate uma resposta capturada como um cookie de sessão até o NotOnOrAfter passar.

Perguntas frequentes