SAML断言是由IdP签发、SP验证的声明凭证，包含AuthnStatement（身份验证）和AttributeStatement（属性）两类核心声明，必须签名、有时效、绑定正确主体，且需经Base64编码+DEFLATE压缩后通过HTTP POST传输。
什么是 SAML 断言（SAML Assertion）
SAML Assertion 是 SAML 协议中承载身份验证、属性和授权决策的核心 XML 结构。它不是“登录动作”，而是由身份提供者（IdP）签发的、可被服务提供者（SP）验证的**声明凭证**——类似一张带防伪印章的电子身份证。
一个 SAML Assertion 通常包含三类声明（<saml:AuthnStatement>、<saml:AttributeStatement>、<saml:AuthzDecisionStatement>），但实际生产中绝大多数只用前两者：前者证明“用户刚通过某种方式登录了”，后者传递“这个用户的邮箱是 xxx@domain.com”这类属性。
如何构造一个最小可用的 SAML 断言 XML
手动写完整断言不现实，但理解结构能帮你快速排查错误。关键点在于：必须有签名、必须有时效、必须绑定正确主体。以下是一个简化但可被主流 SP（如 Okta、Azure AD 测试端点）接受的 AuthnStatement-only 断言片段：
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_1234567890abcdef"
IssueInstant="2024-04-05T10:00:00Z"
Version="2.0">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<!-- 真实场景此处为 IdP 私钥签名生成的 <ds:SignatureValue> 和 <ds:KeyInfo> -->
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2024-04-05T10:05:00Z"
Recipient="https://sp.example.com/acs">
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:AuthnStatement AuthnInstant="2024-04-05T09:59:30Z"
SessionIndex="_session_abc123">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>注意这些硬性要求：
基于5000余部现行法律法规进行的高质量专业合同审查，一键输出审查意见书，并附有参考法条原文，满足专业溯源核查要求。由accurLex知法提供技术支持。 Use when users ask for 合同审查, 审查意见书, 合同风险分析, 条款审查,知法,accurLex or 站在甲方/乙方角度审查合同 through accurLex direct API. China law only, plaintext only, review mode limited to 审查意见书.
-
ID必须以_开头，且全局唯一（不能重复使用） -
IssueInstant和NotOnOrAfter时间必须在 SP 接收时处于有效窗口（常见容忍 ±3 分钟） -
Recipient必须与 SP 的AssertionConsumerServiceURL完全一致（含协议、大小写、尾部斜杠） - 没有
<ds:Signature>的断言会被所有合规 SP 拒绝 —— 即使内容合法
为什么直接 POST 这个 XML 到 SP 不会成功
你不能把上面那段 XML 直接 curl -X POST 给 SP 的 /acs 地址。SAML 身份验证依赖严格的消息封装机制：
- SP 期望收到的是一个
SAMLResponse参数，其值是上述Assertion的 **base64 编码 + DEFLATE 压缩**（不是纯 base64） - 整个请求必须是
application/x-www-form-urlencoded，且通常还需附带RelayState参数（用于跳转回原始请求页面） - IdP 必须用 SP 提供的 X.509 证书公钥对
<ds:Signature>内容进行签名，SP 用同一证书验签 - 部分 SP（如 AWS SSO）还强制要求
<saml:Conditions>中包含NotBefore和AudienceRestriction
换句话说：手写 XML 只是“填空”，真正跑通需要 IdP 侧完成编码、压缩、签名、HTTP 封装整套流程。调试时建议用浏览器开发者工具抓取真实 IdP 返回的 SAMLResponse 值，再 base64 解码查看原始 XML —— 这比自己拼更可靠。
常见失败原因和验证要点
当 SP 返回 InvalidRequest、RequestDenied 或静默失败时，优先检查：
- XML 命名空间是否完整且拼写正确：
urn:oasis:names:tc:SAML:2.0:assertion不能少字母或换行截断 -
<saml:Issuer>的值是否与 SP 配置的 IdP 实体 ID **逐字符一致**（包括末尾斜杠） - 签名是否覆盖整个
<saml:Assertion>元素（而非仅子节点）；很多库默认签名范围错误 - 系统时间偏差：IdP 和 SP 服务器时间差超过 5 分钟会导致
NotOnOrAfter验证失败 - SP 是否启用宽松模式？例如某些测试 SP（如 samltest.id）允许无签名断言，但生产环境一律禁用
最易被忽略的一点：SAML 断言本身不包含密码或令牌，它只是“我证明这个人已登录”的声明。验证成败完全取决于签名有效性、时间窗口、URI 匹配度这三项 —— 和用户密码无关，也和 SP 是否存了该用户账号无关。
