上下文：我们有一个无法控制的OIDC IdP，但我们需要支持服务提供商(SP(对SSO的SAML请求。
想法：构建一个位于SP和OIDC身份提供程序之间的代理(应用程序(。来自SP的请求被发送到代理应用程序(充当SP的SAML IdP(，代理应用程序将请求转换为OIDC请求并将其转发给OIDC提供商。OIDC提供商的结果返回到代理应用程序，代理应用程序将其转换为SAML响应并转发给SP。
问题：
我对SAML-IdP(实现方面(的了解非常有限。这种方法对我来说似乎很粗糙：(感觉我错过了很多事情需要考虑。所以，我想得到一些帮助和指导，看看我哪里做错了。我想问的几件事是：
- 这种方法有意义吗
- 这种方法会对安全产生什么影响
- 是否有其他更简单/更好的解决方案或类似的用例
如有任何帮助，我们将不胜感激。
谢谢！
随着越来越多的服务转移到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。