问题描述
我有两项服务，并且希望允许用户从另一项登录到一项服务。但是，作为IdP最有意义的服务仅允许OIDC，而我的其他服务（在此充当SP）仅接受SAML。我没有任何一项服务，因此无法在这些服务中添加对SAML / OIDC的支持。我们也没有通过SAML或类似方式进行任何自动配置，因此不必担心。
我目前的想法是使用某种中介。诸如Ping或OneLogin之类的IdP解决方案是否可以做到这一点，还有待观察，但是定制Web服务器可以做到。
- 客户端请求访问SP
- SP通过SAML配置中的适当URL重定向到中介
- SAML中介将用户重定向到IdP OIDC登录
- 用户登录IdP，中介机构使用代码来检索令牌并验证用户登录
- 中介机构基于成功的OIDC身份验证生成SAML声明，并允许用户登录SP
我已经确信自己可以使用，但是应该吗？有更好的选择吗？除了告诉我的用户，这样做可能没有任何意义，还有其他方法吗？
是什么使这客观上可以还是不可以？
解决方法
理想情况下，人们喜欢在任何地方添加额外的移动部件来避免复杂性，尤其是在像身份验证这样敏感的事物中。但是，大多数软件开发的现实是，您必须将各种预先存在的组件集成到新的解决方案中，并且通常包括合并现有的身份提供程序。 （迁移大量的身份和凭证会引入其自身的复杂性和风险！）因此，您一定会在实际系统中看到这些“身份验证适配器”模式。并且已经有经过测试的工具，因此您不必冒险自行开发。
一种常用的工具是Keycloak（或商业支持的版本，RedHat SSO）。 Keycloak允许您使用外部OIDC IdPs并让用户与SAML clients连接以提供您所描述的桥接。其他解决方案也可能存在。
,据我所知，没有任何解决方案可以让您“即时”更改协议。
您必须自己动手，很快就会陷入困境，例如令牌签名，将OIDC属性映射到SAML属性（没有一对一关系），退出等。
最简单的方法是使用同时允许OIDC和SAML的外部IDP，这将为您提供跨应用程序的SSO。
如果必须使用当前的IDP，则将其与可以同时提供两种协议的IDP联合。
例如周围有一个数字Azure AD，Auth0，Okta等。