无需修改源码对接多SSO提供商的配置参数及SAML格式疑问

问题1：除已知配置外还需要收集的核心信息 #

你提到的发送SAML请求的目标地址、指纹/Token属于基础配置，还需要补充收集以下信息：

• IDP实体ID（Entity ID）：身份提供商的唯一标识符，用于校验SAML响应的来源合法性，防范伪造请求攻击
• 完整IDP公钥证书：指纹只是证书的哈希值，建议直接收集PEM格式的完整公钥证书，用于校验SAML响应、断言的签名有效性，兼容性远高于仅存储指纹
• IDP单点登出服务地址（SLO Service URL）：可选配置，若需要支持全局单点登出（用户在你的应用登出后同步退出客户所有对接该IDP的系统）则需收集
• 名称ID格式（NameID Format）：指定IDP返回的用户唯一标识的格式，常见的有邮箱格式、持久化唯一ID格式，部分IDP要求必须显式指定否则会返回报错
• 用户属性映射规则：如果你的系统需要从IDP获取用户邮箱、姓名、部门等业务字段，需要让客户配置IDP侧返回的属性名和你系统字段的对应关系，比如你系统用email存储邮箱，部分IDP默认返回的属性名是mail或者带自定义命名空间的邮箱字段
• 断言加密配置：可选配置，若客户要求SAML断言不能明文传输，需要收集IDP的加密公钥，同时你需要将自身的加密公钥提供给客户配置到IDP侧

另外建议在自助配置页直接展示你方需要客户配置到IDP侧的信息，包括SP实体ID、SP回调地址（ACS URL）等，降低客户配置出错概率。 #

问题2：不同SSO提供商的SAML格式统一性说明 #

SAML 2.0的核心报文结构是OASIS定义的国际标准，主流IDP（包括Okta、Azure AD、AD FS、国内的钉钉/企业微信身份提供商等）的核心逻辑完全符合标准，包括SAML请求参数格式、响应断言结构、签名校验规则等核心部分都是统一的，不需要针对每个IDP修改核心对接源码。

但不同厂商在非核心实现上存在自定义差异，常见差异点包括：

• 支持的SAML绑定方式不同，部分小众IDP仅支持HTTP POST绑定，不支持HTTP Redirect绑定
• 用户属性的命名规则不统一，比如Azure AD的默认邮箱属性会携带微软自定义的命名空间，开源IDP Keycloak默认不带命名空间
• 对签名范围的要求不同，部分IDP要求对整个SAML响应签名，部分仅要求对断言部分签名
• 对NameID格式的要求不同，部分IDP必须指定固定的NameID格式否则会返回错误

你只要把上述差异点做成可配置项，就能在不修改核心源码的前提下适配绝大多数厂商的SSO服务。 #

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