英文:
Multiple Azure AD Enterprise Apps for Single Cognito User Pool
问题
我正在尝试使用我们的Azure AD为AWS上的内部应用提供身份验证，该应用位于ALB后面。
我正在使用Cognito用户池，将Azure AD配置为身份提供程序。
我们已经以这种方式配置了一个应用程序，任何具有Azure AD中身份的人都可以访问。我现在部署的应用程序只能由一些具有帐户管理员权限的用户访问。
我已在Azure AD管理中心创建了一个企业应用程序，但我遇到的问题是应用程序的标识符（实体ID）必须采用以下格式：urn:amazon:cognito:sp:<region>_<userpool_id>，并且必须是全局唯一的。
必须采用这种格式，因为该值用作OIDC过程中的aud声明。由于我们已经有一个使用此AD和用户池组合的应用程序，因此无法提供正确的实体ID，因为它需要在企业应用程序中全局唯一。
是否有一些解决方法，而无需更改身份验证配置（例如，我不想绕过Cognito或使ALB针对其他ALB）？
英文:
I am trying to use our Azure AD to provide auth for an internal application which is behind an ALB on AWS.
I am using a Cognito User Pool with the Azure AD configured as an identity provider.
We already have one application configured in this manner, which is accessible from anyone with an identity in Azure AD. The application I am deploying now, should only be accessible by a select few users with account admin privileges.
I have created an Enterprise Application in Azure AD Admin Center, but the issue I am having is that the application's Identifier(Entity ID) must be in the following format urn:amazon:cognito:sp:<region>_<userpool_id> and it must be globally unique.
It must be in this format because that value is used as the aud claim in the OIDC process. Since we already have an application which is uses this AD and User Pool combination, there is no way to provide the correct Entity ID because of the need for it to be globally unique across enterprise apps.
Is there some workaround for this without changing the auth config(e.g. I don't want to bypass Cognito or have ALBs targeting other ALBs)
答案1
得分: 1
这在架构上感觉有点不太对：
授权服务器
您在AS角色中使用了AWS Cognito。您的应用程序在开始登录流程时会重定向到这个服务器。您的API会接收由AS签发的访问令牌，其范围和声明应该能够正确授权API。
身份提供者
通常使用云IDP来管理员工，然后员工可以使用IDP登录应用程序。这是通过应用程序运行代码流到AS，然后AS再运行另一个代码流到IDP来实现的。但是应用程序仍然会收到由AS签发的令牌。
AS到IDP连接
连接的两端始终都有一个单一的信任条目：
- AS将IDP连接配置为一种身份验证方法
- IDP为AS配置了OAuth客户端
应用程序
应用程序不应该了解IDP的存在。相反，将许多应用程序注册为AS中的OAuth客户端。应用程序还会使用AS的OAuth端点。这使您能够控制每个应用程序的令牌。
避免使用需要在IDP中注册应用程序的技术解决方案。在那里唯一应该存在的客户端条目应该是代表组织而不是应用程序的AS。
英文:
This feels a little wrong architecturally:
AUTHORIZATION SERVER
You are using AWS Cognito in the AS role. Your apps redirect to this when beginning a login flow. Your APIs receive access tokens issued by the AS, whose scopes and claims should enable the correct API authorization.
IDENTITY PROVIDER
It is common to use a cloud IDP to manage employees, who can then use the IDP to sign into apps. This works by the app running a code flow to the AS, which in turn runs another code flow to the IDP. The app still receives tokens issued by the AS though.
AS TO IDP CONNECTIONS
There is always a single trust entry, configured in both ends of the connection:
- The AS configures an IDP connection as an authentication method
- The IDP configures an OAuth client for the AS
APPLICATIONS
The application should know nothing about the IDP. Instead, register many apps as OAuth clients in the AS. Apps also use OAuth endpoints from the AS. This is what enables you to control tokens per application.
Avoid any technology solutions that require you to register apps in the IDP. The only client entry there should be for the AS, which represents an organization, not an application.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论