困扰数学家90年的猜想

过去，我通过编写一堆Ruby自动生成相关XML来处理每个SP的唯一签名密钥，从而为Shibboleth管理了多个密钥。每当我遇到另一个错误处理断言的SP时，我都会感谢为减少这个我们不得不担心的问题而付出的努力。

在理想的情况下，我们不会使用SAML。 SAML是一种繁琐的协议，可让你创建带有身份验证内联签名的身份提供者的网状网络，其中XML中的空格确定签名是否有效。但是SAML以及OAuth 2.0和不完美的OIDC都将保留下来。鉴于SAML是事实上的企业单一登录协议，我们将忽略它。

如果你的IDP不支持此功能(请参见下文)，则应向他们打开功能请求!这是你的IDP应该支持的重要安全控制。

如果你的IDP确实支持这个功能，为你的新应用程序发出每个sp的签名密钥。使用旧的证书迁移应用程序需要做很多工作，但是如果你有特别敏感的应用程序，则值得这样做。

所有SaaS IDP都应在没有任何用户干预的情况下生成每个应用程序的签名密钥，默认情况下，每个SP密钥的使用率极高，可以悄悄地提高与这些提供商签约的每个企业的安全性。截至2020年3月，唯一获得此权限的提供商是Azure AD。

自托管的IDP应确保它们支持按SP的签名密钥，并具有启用此功能的文档。理想情况下，共享签名密钥的配置不太明显，因此管理员默认情况下选择每个SP的签名密钥。

虽然最终要由SSO管理员做出正确的SSO选择，但是我们作为安全行业的责任是使正确的选择变得容易。

IDP支持多个签名密钥

没有实施指南，最佳做法将无济于事。这是截至2020年3月我已测试的各种主要IDP(包括SaaS和自托管选项)的列表。如果你的首选IDP不在此列表中或条目不正确，请与我们联系。

1. Azure AD – SaaS

Azure AD自动为每个“企业应用程序”生成一个新密钥，并且无法在控制台中的应用程序之间共享证书。你可以手动上传自己的证书和私钥，但这并不容易，我也不鼓励这样做，Azure AD应该是所有其他SaaS IDP的模型。

2. Shibboleth - Java(自托管)

你必须编写大量的XML才能使它工作，如果你花了几个小时绞尽脑汁地研究Spring XML配置，就不会出现任何问题。我已经包括了基本的需求。要点是，你需要创建单独的签名凭据，包括安全配置中的签名凭据，然后从单独的SP引用该安全配置。

另外，我确实喜欢Shibboleth是全java的状态，即没有内存损坏!，可以在本地自己的服务器上运行，并且采用非常符合标准的方法，从而降低了被奇怪的XML问题影响的可能性。

 

核心问题是缺乏受众限制验证，换句话说，SP没有检查断言是否针对它。SAML的设计思想是你的IDP将只有一个签名密钥，你可以将它分发给与你集成的每个人。考虑到SAML的学术背景，它应该是一个合作协议，组织之间密切合作。现代企业SAML忽略了所有这些有趣的特性，因为它们是巨大的安全和配置噩梦。

当你的IDP签署一个断言时，它包含两个供SP验证的字段:SP的实体ID和断言要发送到的URL。SP可以悄悄地忽略这些字段，而你对此无能为力。

作为负责签名密钥的IDP，你如何保护自己免受不可避免的弱SP攻击?

处理一堆签名钥匙

相比依赖协议的某些部分，唯一可扩展的方法是强制你的断言仅在一个SP上有效，而且是通过具有唯一签名每个SP的密钥。

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!