英文:
Is there any OpenID Connect Identity Provider that can delegate autentication to other OpenID Connect IdPs?
问题
我面临以下情景：
有若干家公司，每家公司都有自己的OpenID Connect身份提供者（IdP），这些提供者从它们各自的LDAP服务器中联合用户。这些提供者用于在每家公司的上下文中执行SSO。
存在一个要求，即创建一个应用程序，为所有这些公司的用户提供共同的登录。
想法是提供或使用现有的云解决方案（如AWS Cognito、Google Cloud Identity等），提供一个共享的登录界面，但将实际登录委托给每家公司的IdP。
是否有任何允许这样做的解决方案？
您能指出任何实施的文档/指南吗？
英文:
I'm facing the following scenario:
There are several companies each one with its own OpenID Connect Identity Provider (IdP) which federates users from their respetive LDAP servers. These providers are used to perform SSO in the context of each company.
There's a requirement to create an application that offers a common login for all the users of those companies.
The idea is to provision or use an existing cloud solution (AWS Cognito, Google Cloud Identity, etc., ...) that offers a shared login screen but delegates/federates the actual login to each of the company IdPs.
Are there any solutions that allows this?
Could you point at any documentation/guide to implement it?
答案1
得分: 0
有一个名为cloudpods的解决方案，可以用它来管理本地和公共云资源。Cloudpods支持与多个云提供商集成，如aws、GCP、azure、阿里巴巴等。
英文:
There is a solution called cloudpods using which you can manage both on-prem and public cloud resources. Cloudpods supports integration with multiple cloud providers like aws, GCP, azure, alibaba and etc.,
答案2
得分: 0
是的。https://github.com/apereo/cas 是其中之一。您可以将其设置为一个OIDC身份提供者，然后让它委托给您想要的任意数量的OIDC身份提供者。
英文:
> Is there any OpenID Connect Identity Provider that can delegate autentication to other OpenID Connect IdPs?
Yes. https://github.com/apereo/cas is one. You can set it up as an OIDC identity provider and have it then delegate to as many OIDC Identity providers as you want.
答案3
得分: 0
这只是标准的OAuth和OpenID Connect行为，涉及到这3个角色：
- 应用程序，使用OIDC进行重定向到...
- 授权服务器，由您拥有，然后重定向到...
- 身份提供者
因此，您需要一个基于标准的授权服务器，并将您的应用程序配置为OAuth客户端。然后包括openid范围，以便使用OpenID Connect。基于SAML的身份提供者也可以在此流程中得到支持，即使您的应用程序只使用OIDC。
以最佳可用性来管理这一点的方法是，授权服务器应呈现一个用户名认证器，首先捕获用户标识符，例如电子邮件。然后运行一些自定义逻辑，如用户查找，以确定将用户路由到哪个IDP。用户然后在IDP进行身份验证。
身份验证后，IDP向授权服务器发放令牌，授权服务器验证这些令牌，然后向应用程序发放自己的令牌。特别是应用程序会获得一个访问令牌，您可以控制其范围和声明。然后，您的应用程序可以将这些令牌发送到您的API，以正确授权对业务数据的访问。
目标是实现类似上述的行为，或根据您的偏好进行调整。然后进行试验，例如使用基于云或Docker的授权服务器，并确保选择一个具有足够可扩展性以满足您的需求的授权服务器。
还要注意，Stack Overflow的答案不应推荐特定的供应商，因此我没有这样做。
英文:
This is just standard OAuth and OpenID Connect behaviour, with these 3 roles:
- Application, uses OIDC to redirect to ...
- An Authorization Server, which you own, and which redirects to ...
- An Identity Provider
So you need a standards based authorization server and to configure your app as an OAuth Client. Then include the openid scope so that OpenID Connect is used. SAML based identity providers can also be supported in this flow, even though your app only uses OIDC.
The way to manage this with best usability, is for the authorization server to present a usernane authenticator, which captures a user identifier first, such as an email. It then runs some custom logic, such as a user lookup, to determine which IDP to route the user to. The user then authenticates at the IDP.
After authentication, the IDP issues tokens to the authorization server, which validates them, then issues its own tokens to the application. In particular the app gets an access token whose scopes and claims you can control. Your app can then send these to your APIs, which can authorize access to business data correctly.
Aim for behaviour similar to that above, or adjust it based on your preferences. Then trial it, eg with a cloud or Docker based authorization server, and ensure that you select one with sufficient extensibility to meet your requirements.
Note also that Stack Overflow answers should not recommend particular vendors, so I have not done so.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论