SAML v2.0中IDP与SP之间的信任机制是如何实现的？

1. 元数据的核心信任锚作用 #

SAML协议采用点对点信任模型，不存在默认的公共信任根，双方交换Metadata文件的本质就是主动注入可信对方的信任锚。Metadata文件中封装的x509证书不需要经过CA体系验证有效性，只要你确认这份Metadata来自你要对接的合法IDP/SP，证书就会被系统默认信任。

2. 信任建立的完整技术流程 #

• 前置准备：密钥对与元数据生成
  IDP和SP各自独立生成非对称密钥对（行业通用RSA 2048/4096位），私钥本地加密存储绝不对外泄露，公钥封装为x509证书后，和自身的唯一标识EntityID、SSO/ACS端点地址、支持的绑定协议、签名加密算法列表等信息一起，组装为标准SAML Metadata XML文件。
• 可信元数据交换
  你看到的图形化界面上传元数据就是这个步骤的产品化实现：管理员通过可信带外通道（比如企业内部配置平台、对接双方管理员线下同步）拿到对方的Metadata文件后，上传到自身系统，系统会自动提取文件中的EntityID、x509证书、端点地址三类核心信息，持久化到本地可信存储中，完成信任关系的静态配置。

  安全提示：这个交换环节是整个信任链的风险点，如果Metadata被篡改注入恶意证书，后续所有SAML交互的校验都会失效，所以必须保证交换通道的可信度。

• 运行时交互的信任校验
  实际SSO流程中的校验逻辑就是信任机制的落地：
  1. IDP生成SAML断言后，会用自身私钥对断言做数字签名，部分高安全场景下还会用SP的公钥加密整个断言或敏感字段
  2. SP拿到SAML响应后，首先匹配发送方的EntityID是否在本地可信列表中，匹配通过后取出对应IDP的预存公钥证书，验证断言的数字签名是否合法：签名验证通过即可证明断言确实由信任的IDP签发，且传输过程中没有被篡改
  3. 如果收到的是加密断言，SP会先用自身私钥解密后再做签名校验
  4. 若SP开启了请求签名配置，IDP收到AuthnRequest后也会用预存的SP公钥验证请求签名，确认请求来自可信SP，而非第三方伪造

3. Golang实现核心注意点 #

• 元数据解析：可直接用标准库encoding/xml解析SAML Metadata XML结构，重点提取EntityDescriptor节点下的EntityID属性、IDPSSODescriptor/SPSSODescriptor节点下KeyDescriptor中的x509证书内容，以及各端点的Location属性
• 签名校验逻辑：用标准库crypto/x509解析提取到的证书得到公钥，再根据签名算法选用crypto/rsa/crypto/ecdsa等包完成签名校验，注意要禁用SHA1等不安全的摘要算法
• 必做校验项：所有SAML交互必须校验对方EntityID与预存值一致，同时校验请求/响应的接收端点和预存的自身端点一致，避免跨租户伪造、重定向攻击

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