所有的编程语言知识，都包含在这100张思维导图里了

5. Okta—SaaS

是的，但是需要在API中进行修改。Okta为每个SP使用不同的实体ID，但是默认情况下，使用完全相同的凭据对声明进行签名。无法在Okta控制台中上传自定义私钥或旋转签名凭证。

但是，你可以创建一个新的签名密钥，并通过两个API调用将密钥与应用程序关联。

6. GSuite SAML - SaaS

GSuite的SAML配置允许你在给定的时间内拥有两个签名证书，这样你就可以旋转过期的签名证书。很明显，GSuite可以支持其他证书，但它不支持。

7. Auth0——SaaS

尽管支持唯一的OAuth 2.0客户端机密，但Auth0在所有SAML“应用程序”之间共享一个签名证书!也没有选择旋转你的SAML签名凭据。鉴于你正在动态配置每个SP，因此没有理由不生成每个SP的签名凭据。

8. ADFS - Microsoft Windows Server(自托管)

Windows Server 2019版的ADFS不支持每个“依赖方”(我们称之为SP)的唯一“签名令牌”。在运行一些PowerShell以禁用自动旋转之后，你可以手动添加一个用于旋转的备用证书，但它对其他任何东西都没有用处。

在每个SP上运行一个ADFS服务器并在每个服务器上使用单独的签名令牌在技术上是可行的。这将是痛苦的管理，更不用说Windows许可成本，所以我不认为这是一个好的建议。

9. Gluu——自托管

Gluu的用户界面未提供任何将特定签名身份与SAML SP相关联的方法，也无法创建新的签名身份。

10. Duo Access Gateway –自托管

根据通用SP配置的文档，整个DAG服务器只有一个证书。你可以重新创建证书，但这似乎会影响到没有唯一密钥选项的每个SP。

11. SimpleSAMLphp—自托管

SimpleSAMLphp的IDP支持单个服务提供者的唯一密钥，一旦你知道要查找什么，它就很简单了。在“SP远程元数据”参考中，通过signature.certificate和signature.privatekey可以为每个SP指定一个单独的密钥。

虽然它确实很好地支持惟一秘钥，但如果可以的话，你最好不要使用这个软件。该项目有一个经典的PHP webapp漏洞。

总结

• 有一些深奥的功能，例如动态ACS(断言消费者服务)URL，还有可能会被误用的功能，例如通过未加密的HTTP提供元数据，但是同样，在现代公司SAML中，TLS至关重要。
• 我不相信libxmlsec1库，尤其是libxml2库。这两个C库都非常常用，没有真正的替代方法。如果你认为使用Ruby，PHP或Python SAML库是安全的，那么你就错了，它们都依赖于libxmlsec1。
• 尽管C库为我们服务了很多年，但到2020年，由于内存损坏问题严重，它将成为安全负担。libxml2的漏洞历史可以追溯到2004年(16年前!)。虽然libxmlsec1没有相同的记录历史，但我怀疑只是由于缺少必要的报告，而不是真的没有内存安全问题。通过对已知漏洞进行相对快速的修补来积极地维护这些库，可以在一定程度上缓解这种危险，但是如果可以的话，我不会使用这些库。
• 就我个人而言，我认为对于安全界的外行来说，进入的门槛是相当高的!你必须与第三方进行有效的SSO集成，并且必须能够访问私钥(我们已经不太可能使用它了)或能够更改部分断言(如用户名)。大多数IDP都不愿意让你更改字段，因为它们是从你无权访问的中央目录中提取的。即使确实满足所有这些条件，这些漏洞通常也只能让你在现有组织中横向移动，而不能完全以其他帐户身份登录。
• 接受不同组织的断言实际上是一件非常可怕的事情，因为作为IDP，你几乎无能为力。保护自己不受攻击的最好方法是测试SP是否有这种行为。不过，我在本文中没有深入探讨这个问题，
• Gluu是基于Shibboleth的，因此你可以手动设置一个工作配置，这可能会破坏UI。

 

（编辑：平顶山站长网）

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