1

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

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

问题：

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

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

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

谢谢！

4

1 回答 1

2

随着越来越多的服务迁移到 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。

于 2018-11-10T16:43:21.980 回答