我有一个网络应用程序，我想允许我的用户通过 SAML 登录。我想允许他们通过提供 IdP 登录 URL、注销 URL、证书等或仅提供元数据 URL 来配置其身份提供者。
另外，我的一些客户想要设置和使用他们自己的内部身份提供者。
我的问题是，一旦交换了密钥、验证了签名等，我怎么能相信身份提供者是安全的？当 SAMLResponse 进入时（特别是通过 IdP 发起的 SSO），我如何知道 NameID 元素中的电子邮件地址与想要登录的合法用户相关？是什么阻止他们发送我自己的电子邮件地址以站点管理员身份登录？
我已经阅读了很多 SAML 2.0 规范、此处的答案和博客文章，但我还没有看到这个问题的具体解决方案。
【问题讨论】：
在回答您的问题之前，我认为明确 SSO 身份验证流程很重要。
对于 SAML 2.0，涉及两方，即身份提供者 (IdP) 和服务提供者 (SP)。他们使用协议端点和证书来进行反向通道（服务器到服务器）通信。
话虽如此，你有各种网络层进程来确保通信过程是安全的，不会发生man-in-the-middle 攻击。
然后回到你原来的问题，如果正确的话，我认为它包含以下两个主题：
通过提供 IdP 登录 URL、注销 URL、证书等或仅提供元数据 URL 来配置其身份提供者。
这些都是 SAML 2.0 所需的元数据，因此您可以自己配置，或者信任您的合作伙伴按照您的方式进行操作（in your way 我的意思是不同的 SAML 2.0 联合服务器有自己的一组元数据，但通常它们应该是一样的）。
一旦交换了密钥、验证了签名等，我如何才能相信身份提供者是安全的？当 SAMLResponse 进入时（特别是通过 IdP 发起的 SSO），我如何知道 NameID 元素中的电子邮件地址与想要登录的合法用户相关？是什么阻止他们发送我自己的电子邮件地址以站点管理员身份登录？
IdP 必须是安全的，就像他们被黑客入侵（社会工程）一样，他们可以登录到您的应用。
SAML 属性映射，除了 SAML_SUBJECT，您还可以使用其他属性来确定 SAML_SUBJECT 的角色（如果我们可以谈论 provisioning），或者您可以将预定义角色映射到该用户 (SAML_SUBJECT) 来确定角色。
由于SAML只是为用户认证和交换可信信息，如何使用双方约定的SAML有效载荷中的信息需要SP应用程序实现。
关于@nzpcmad 评论的代币操作，我认为这是可能的，当 PingFederate 通过 OpenToken 适配器与 SP 应用程序对话时，这就是 PingFederate 中所谓的合同履行。 Okta、OAuth0 都有类似的概念。
希望这能回答你的问题。
【讨论】：
您无法更改 SAML 令牌，因为它已签名。
最终，由您来检查所有这些 IDP。
因此，联合是一个手动过程。
如果你联合，你就会信任。
【讨论】：