SAML SSO工作原理及四大技术疑问解析

刚好我对SAML这块接触得比较多，来逐个帮你理清这些问题：

1. 重定向绑定与POST绑定的适用场景 #

这两种绑定的核心差异在于数据传递的方式和容量限制，适用场景区分很明确：

• 重定向绑定：
  最适合传递SAML认证请求（AuthnRequest）。因为认证请求的内容通常比较简洁，能轻松塞进URL的查询参数里。流程上也更直接——SP直接把浏览器重定向到IdP，不需要额外的页面渲染。但它受限于URL长度限制（不同浏览器和服务器的上限不同，一般在几千字符左右），没法传递体积大的内容；而且参数会暴露在地址栏和服务器日志里，敏感信息的暴露风险相对高一些。
• POST绑定：
  主要用来传递SAML响应（Response）。因为响应里包含用户断言、签名、属性等大量内容，体积往往远超URL的承载能力。它通过IdP返回一个自动提交的XHTML表单，把SAML数据放在请求体里传递，既没有长度限制，也不会把敏感数据暴露在地址栏里，安全性更好。唯一的小缺点是多了一步表单渲染自动提交的过程，不过用户几乎感知不到。

2. 服务提供商（SP）的边界定义 #

这个问题关键要搞清楚：SP是指拥有独立SAML配置、能独立提供服务的实体，而不是“托管服务的主体”。举几个实际例子：

• Office 365是一个独立的SP，它有自己专属的SAML元数据、断言消费端点，用户通过SAML认证后直接访问Office 365的服务；
• Salesforce也是完全独立的SP，和Office 365没有共享任何SAML配置；
• 如果是企业内部的多个应用，比如公司的OA系统和CRM系统，如果它们共用同一套SAML配置（比如同一个实体ID、同一个断言消费端点），那可以归为同一个SP实体；但如果各自有独立的SAML信任配置，那就是两个独立的SP。

之前视频里提到的“托管服务的主体”，可能是指像微软、Salesforce这类同时提供多个服务的厂商，但这些服务如果是独立的SAML实体，那每个都是独立SP；如果共享SAML配置，才属于同一个SP。

3. 客户端令牌存储与SSO实现逻辑 #

SSO的核心其实在IdP的会话管理，客户端存储的内容更多是会话标识，而非完整令牌：

• SSO的实现逻辑：当用户第一次在IdP完成认证后，IdP会在用户浏览器上设置一个属于IdP域名的会话Cookie（比如idp.example.com下的Cookie），这个Cookie记录了用户的已认证状态。当用户访问SP B时，SP B发现用户未认证，就会把用户重定向到IdP。此时浏览器会自动带上IdP的会话Cookie，IdP检查后确认用户已有活跃的认证会话，就直接生成SAML响应发给SP B，不需要用户再输入凭证。
• 客户端令牌存储：SP通常不会直接把SAML令牌存在客户端（毕竟令牌里有敏感的用户信息），而是会提取SAML断言中的用户数据（比如用户名、角色），在服务器端创建自己的会话（比如Tomcat的HttpSession），然后给客户端返回一个JSESSIONID Cookie。客户端后续访问SP时，用这个Cookie关联服务器端的会话即可。少数场景下SP会把加密后的令牌存在客户端的Cookie或localStorage，但服务器端会话是更安全的主流做法。

4. SSO是否要求SP部署在同一Tomcat实例？ #

完全不需要！SSO的实现和SP的部署环境没有任何绑定关系，只要两个SP都和同一个IdP建立了信任关系（交换了SAML元数据、配置了正确的断言消费端点等），不管它们部署在不同的Tomcat、不同的服务器甚至不同的域名下，都能实现SSO。

举个例子：SP A部署在tomcat1.company.com，SP B部署在tomcat2.company.com，只要它们都信任同一个IdP（idp.company.com），用户在SP A认证后，访问SP B就能直接实现单点登录，不需要重复输入凭证。

内容的提问来源于stack exchange，提问作者PDStat