嘶吼RoarTalk|SAML IDP 签名密钥？，为什么我们需要多个( 二 )
当你的IDP签署一个断言时 ， 它包含两个供SP验证的字段:SP的实体ID和断言要发送到的URL 。 SP可以悄悄地忽略这些字段 ， 而你对此无能为力 。
作为负责签名密钥的IDP ， 你如何保护自己免受不可避免的弱SP攻击？
处理一堆签名钥匙
相比依赖协议的某些部分 ， 唯一可扩展的方法是强制你的断言仅在一个SP上有效 ， 而且是通过具有唯一签名每个SP的密钥 。
文章图片
之所以可行 ， 是因为几乎每个SAMLSP实现都包含三个部分 。 他们将从请求中提取用户名 ， 在断言中验证签名 ， 并拒绝无效的断言签名 ， 其他所有内容都应视为可选内容 。
虽然SP可以忽略你的签名 ， 但是它的测试超级简单 ， 而且这种事情很容易被漏洞赏金报告人员发现 。 与更深奥的受众限制测试不同 ， 这里不涉及任何复杂性 。
如何管理这么多密钥？
文章图片
过去 ， 我通过编写一堆Ruby自动生成相关XML来处理每个SP的唯一签名密钥 ， 从而为Shibboleth管理了多个密钥 。 每当我遇到另一个错误处理断言的SP时 ， 我都会感谢为减少这个我们不得不担心的问题而付出的努力 。
在理想的情况下 ， 我们不会使用SAML 。 SAML是一种繁琐的协议 ， 可让你创建带有身份验证内联签名的身份提供者的网状网络 ， 其中XML中的空格确定签名是否有效 。 但是SAML以及OAuth2.0和不完美的OIDC都将保留下来 。 鉴于SAML是事实上的企业单一登录协议 ， 我们将忽略它 。
如果你的IDP不支持此功能（请参见下文） ， 则应向他们打开功能请求！这是你的IDP应该支持的重要安全控制 。
如果你的IDP确实支持这个功能 ， 为你的新应用程序发出每个sp的签名密钥 。 使用旧的证书迁移应用程序需要做很多工作 ， 但是如果你有特别敏感的应用程序 ， 则值得这样做 。
所有SaaSIDP都应在没有任何用户干预的情况下生成每个应用程序的签名密钥 ， 默认情况下 ， 每个SP密钥的使用率极高 ， 可以悄悄地提高与这些提供商签约的每个企业的安全性 。 截至2020年3月 ， 唯一获得此权限的提供商是AzureAD 。
自托管的IDP应确保它们支持按SP的签名密钥 ， 并具有启用此功能的文档 。 理想情况下 ， 共享签名密钥的配置不太明显 ， 因此管理员默认情况下选择每个SP的签名密钥 。
【嘶吼RoarTalk|SAML IDP 签名密钥？，为什么我们需要多个】虽然最终要由SSO管理员做出正确的SSO选择 ， 但是我们作为安全行业的责任是使正确的选择变得容易 。
IDP支持多个签名密钥
没有实施指南 ， 最佳做法将无济于事 。 这是截至2020年3月我已测试的各种主要IDP（包括SaaS和自托管选项）的列表 。 如果你的首选IDP不在此列表中或条目不正确 ， 请与我们联系 。
AzureAD–SaaS
AzureAD自动为每个"企业应用程序"生成一个新密钥 ， 并且无法在控制台中的应用程序之间共享证书 。 你可以手动上传自己的证书和私钥 ， 但这并不容易 ， 我也不鼓励这样做 ， AzureAD应该是所有其他SaaSIDP的模型 。
Shibboleth-Java(自托管)
你必须编写大量的XML才能使它工作 ， 如果你花了几个小时绞尽脑汁地研究SpringXML配置 ， 就不会出现任何问题 。 我已经包括了基本的需求 。 要点是 ， 你需要创建单独的签名凭据 ， 包括安全配置中的签名凭据 ， 然后从单独的SP引用该安全配置 。
另外 ， 我确实喜欢Shibboleth是全java的状态 ， 即没有内存损坏! ， 可以在本地自己的服务器上运行 ， 并且采用非常符合标准的方法 ， 从而降低了被奇怪的XML问题影响的可能性 。
conf/relying-party.xml的示例配置（Shibboleth文档）：