OIDC IdP 提供商之上的代理，用于接受来自服务提供商的 SSO SAML 请求

Question

上下文： 我们有一个无法控制的 OIDC IdP，但我们需要支持来自服务提供商 (SP) 的 SSO 的 SAML 请求。

想法： 构建位于 SP 和 OIDC 身份提供商之间的代理（应用程序）。来自 SP 的请求将发送到代理应用程序（充当 SP 的 SAML IdP），代理应用程序将请求转换为 OIDC 请求并将其转发到 OIDC 提供商。来自 OIDC 提供商的结果返回到代理应用程序，代理应用程序将其转换为 SAML 响应并将其转发到 SP。

问题：

我对 SAML IdP（实施方面）的了解非常有限。这种方法对我来说似乎很黑客:)感觉有很多事情我需要考虑。因此，对于我做错的地方需要一些帮助和指导。我想问的几件事是：

• 这种方法有任何意义吗？
• 这种方法的安全影响是什么？
• 是否还有其他更简单/更好的解决方案或类似的用例？

任何形式的帮助将不胜感激。

谢谢！

Answer 1

随着越来越多的服务迁移到 OpenIdConnect，例如与 Office365 OIDC 身份验证并行运行的 SAML 工作流程，这已成为一个非常常见的问题。你的方法非常有道理。

正如您所说，IdP 应该将 OIDC JWT 声明转换为 SAML 属性以供 SP 使用，并且有多种选项可用于在 SAML 和 OIDC 之间桥接。

如果您想走付费路线，Overt 有一个带有基于云的 IdP 的Shibboleth/ADFS 桥接器。

或者您可以安装“标准”IdP并开发您自己的网桥。基本上，它将身份验证委托给 OIDC 提供商，并将声明转为 SAML，或许还可以通过 LDAP 查找来增强以获得更多属性。

或者您可以使用“标准”IdP 并在其前面安装 apache 和mod_auth_openidc来管理 OIDC 身份验证和声明处理。

至于安全性，只要您可以相信 OIDC 的声明，就应该没问题。SAML 信任已由 IdP/SP 的 SAML 元数据处理。身份验证将由 OIDC 处理，JWT 声明将发送到您的 SAML IdP，因此只要您确保 IdP 和 OIDC 之间的路由安全，它就应该与 SAML 路由一样安全。

如果 Office365 作为 OIDC 提供商，则 IdP 需要注册为租户应用程序，并且声明将发送到其replyUrl。