AWS ALB supports integration with an Open ID Connect (OIDC) providers such as Azure AD (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#oidc-requirements ). Same for AWS Cognito (https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html )
Azure AD supports single tenant as well as multi-tenant Identity apps. Multi-tenant apps permit authentication of Azure IDs across multiple tenants. For single-tenant apps, the end points needed for OIDC integration hardcode the Azure Tenant ID in the path. However for multi-tenant apps, Azure AD provides a "/common" alias instead of an enumerated tenant ID. (https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#update-your-code-to-send-requests-to-common)
However the token issuer in the case of Azure multi-tenant apps does include the actual tenant ID of the authenticated user. It is this step that trips up AWS OIDC integration.
For example, the Issuer field in the ALB configuration for OIDC auth does not permit regex or wildcards. As a result only one Issuer URL can be provided which can then reference the tenant ID of exactly one Azure AD tenant. This limits the auth to one tenant of Azure only, vs. the expected multi-tenant support. Although the example below is for ALB, similar concerns raised about Cognito here: https://www.thelambdablog.com/azure-ad-multi-tenancy-issue-in-aws-cognito
Currently we have to move the authentication into our target application itself but the goal is to offload this to the ALB.
Questions
- Any work around in AWS that will allow us to specify more than 1 issuer URL (Setting up multiple ALB rules one for each Azure AD tenant would not scale). Either from the UI or via CLI?
- Any work arounds in Azure AD that will use a predictable issuer URL for multi-tenant apps which would then be configured in AWS
- Any other suggestions?
