Bindings 与流程

当前支持的 Binding

登录流程

• redirect
• post
• simpleSign
• artifact

注销流程

• redirect
• post

SOAP 后信道

• ArtifactResolve
• ArtifactResponse

一条登录链路里谁负责什么

SP 负责

• createLoginRequest(idp, binding)
• parseLoginResponse(idp, binding, request)

IdP 负责

• parseLoginRequest(sp, binding, request)
• createLoginResponse({ sp, binding, ... })

这是当前最核心、最推荐的高层 API 组合。

createLoginRequest() 的返回形式

const context = sp.createLoginRequest(idp, 'redirect');

根据 binding 不同，返回上下文会有一些差异：

Binding	主要特征
redirect	返回适合拼接跳转或 query 的上下文
post	返回 Base64 编码后的消息上下文
simpleSign	返回 Base64 消息，同时带 sigAlg、signature
artifact	返回前信道 artifact，以及后续解析所需上下文

createLoginResponse() 的返回形式

const response = await idp.createLoginResponse({
  sp,
  binding: 'post',
  user: {
    NameID: 'user@example.com'
  }
});

它会返回：

• context
• entityEndpoint
• type
• 某些 binding 下的 relayState
• Artifact 下需要继续后信道解析的上下文

解析入口

IdP 解析登录请求

await idp.parseLoginRequest(sp, 'redirect', request);

SP 解析登录响应

await sp.parseLoginResponse(idp, 'post', request);

普通 redirect / post / simpleSign 流程会进入统一 flow() 逻辑。artifact 则会先走 Artifact 专用流程，再把 resolved SAML 消息继续交给常规解析逻辑。

注销流程

公共父类 Entity 上还提供：

• createLogoutRequest()
• createLogoutResponse()
• parseLogoutRequest()
• parseLogoutResponse()

当前主文档建议把注销流程主要理解为 redirect / post 场景。Artifact 在登录链路上的支持更完整。

不同 Binding 的推荐使用场景

Redirect

适合：

• 浏览器前端跳转式发起登录
• 请求体较小的 AuthnRequest

注意：

• 会涉及 DEFLATE 和 query 级签名
• 参数顺序、编码和解码细节更敏感

POST

适合：

• 最常见的浏览器 SSO 回传
• 不希望受 URL 长度限制影响

这是绝大多数系统最先应该跑通的 binding。

SimpleSign

适合：

• 对接明确要求 HTTP-POST-SimpleSign 的系统

注意：

• 它不是内层 XML Signature
• 它是对 POST 载荷外层做签名

Artifact

适合：

• 不希望前信道暴露完整 SAML 消息
• 需要服务端之间后信道拉取真实消息
• 想把主要验签和解析集中在后端之间完成

当前实现里的几个关键约束

• SP 在 strictSecurity 开启时，会检查本地 authnRequestsSigned 与对端 metadata 的 WantAuthnRequestsSigned 是否冲突
• Artifact 解析链路会继续进入普通登录请求 / 响应解析，而不是单独停在 SOAP 层
• 普通登录响应默认要求走签名验证路径

选择 Binding 的简单建议

• 大多数应用先用 redirect + post
• 只有对端明确要求时再上 simpleSign
• 需要后信道或想减小前信道消息时再上 artifact