Activities of "franciscosl"

[maliming] said: hi

I'm not familiar with Azure.

Let’s make it clear:

1. Can you use a different subdomain in Azure for tenants?

eg: https://tenant1.myazure.com https://tenant2.myazure.com

2. For each tenant, I need to configure several URLs for login and logout. Even if it is only one per customer, there are more than one of those customers.

Where do you need to confiture URL? In the database or Azure?

Because you can use a wildcard redirect URL and a post-redirect URL in the database.

Thanks.

1. Yes, I can, in the app registration, but I have a maximum limit of 100/256 URLs.
2. I must register those redirect URLs in the app registration, as mentioned above. Azure does not allow me to use a wildcard, as it is not recommended practice.

[maliming] said: hi

If you use a path as a tenant name, you don't need to use sub-domains. Path or subdomain you can only select one. I recommend to use sub-domain.

100 or 256 tenants are not enough for you?

Thanks.

For each tenant, I need to configure several URLs for login and logout. Even if it is only one per customer, there are more than one of those customers.

I know that this should be resolved with subdomains or paths, but not with both. That is not the question. The question is how to resolve it using Azure as an external provider.

[maliming] said: hi

Do you mean Azure doesn't support https://abp.io/community/articles/resolving-tenant-from-route-in-abp-framework-ah7oru97

Thanks.

No, sorry, what I mean is that with this way of resolving the tenant, using the path, should I also configure the URLs with the wildcard in Azure App Registration, the original problem in this thread (with subdomains).

In Azure App Registrations, I have to configure the return URLs. I cannot add one URL per client due to a limitation in Azure itself, nor does it allow me to add wildcards, which is the recommended practice.

https://learn.microsoft.com/en-us/entra/identity-platform/reply-url#maximum-number-of-redirect-uris-and-uri-length https://learn.microsoft.com/en-us/entra/identity-platform/reply-url#restrictions-on-wildcards-in-redirect-uris

[maliming] said: hi

You can see : https://abp.io/community/articles/resolving-tenant-from-route-in-abp-framework-ah7oru97

But using sub-domains will be easy.

Thanks.

Even so, the URL limitation in Azure remains; I cannot use wildcards. Does it support this?

[maliming] said: hi

Wildcard Support: Azure AD B2C does support wildcards in redirect URIs (e.g., https://*.app-app1-qa.commondomain.com/authentication/login), but Microsoft does not recommend this practice for security reasons.

I think you have to use wildcard domains for your apps.

Correlation cookie

You can configure this cookie share across wildcard domains.

See https://abp.io/community/articles/how-to-share-the-cookies-between-subdomains-jfrzggc2#gsc.tab=0

Thanks.

After several attempts, it has not worked.

Would it be possible to resolve the tenant in another way, similar to how Azure DevOps does it?

Something like: http:app.commondomain.com/tenant1/entity

Description

Hello ABP Team,

Following the successful resolution of ticket #10222 regarding Domain/Subdomain Tenant Resolver implementation, we have encountered a critical issue when integrating this functionality with Azure AD B2C as an external authentication provider.

The domain/subdomain tenant resolution works perfectly in local development environments using OpenIddict, but fails when Azure AD B2C is enabled as the external provider, which is required for our QA, Preproduction, and Production environments in Azure.

Environment

• ABP Framework: 9.1.3
• UI: Blazor Interactive (WebAssembly only)
• Multi-tenancy: Enabled
• Authentication:
  • Local development: OpenIddict ✅ (Working)
  • Azure environments: Azure AD B2C ❌ (Not working)

URL Structure / Scenario

Our application is deployed with environment-based subdomains and tenant resolution:

QA: https://tenant1.app-app1-qa.commondomain.com Preproduction: https://tenant2.app-app1-pre.commondomain.com Production: https://tenant3.app-app1.commondomain.com

The tenant (e.g., tenant1, tenant2) is resolved from the first subdomain label, following the implementation described in ticket #10222.

What We Have Tried

1. Successful Implementation with OpenIddict

Following the solution provided by @maliming in ticket #10222, we successfully implemented:

• AbpOpenIddictWildcardDomainOptions configuration with wildcard domain formats
• AbpTenantResolveOptions with domain-based tenant resolvers
• TokenWildcardIssuerValidator for JWT validation with wildcard issuers
• Custom MyWebAssemblyMultiTenantUrlProvider in Blazor WASM client to extract tenant from subdomain

Result: ✅ Works perfectly in local development with OpenIddict.

2. Azure AD B2C Integration Attempt

When attempting to replicate this behavior in Azure environments using Azure AD B2C as the external provider, we encounter authentication flow failures.

3. Azure AD B2C App Registration Redirect URIs Limitation

We identified a fundamental conflict between Azure AD B2C requirements and the subdomain-based tenant resolution strategy:

Current Redirect URIs registered in Azure AD B2C "App1 QA" app:

• https://app-app1server-qa-qa-we-001.azurewebsites.net/signin-azuread-oidc
• https://server-app1-qa.commondomain.com/signin-azuread-oidc
• https://localhost:44329/signin-azuread-oidc
• https://app-app1-qa.commondomain.com/authentication/login
• https://app-app1-qa.commondomain.com/authentication/logout
• https://app-app1-qa.commondomain.com/signout/B2C_1_signupsignin01
• https://app-app1-qa.commondomain.com/signin-azuread-oidc
• https://localhost:44385/signin-azuread-oidc
• https://localhost:44385/authentication/logout
• https://localhost:44385/authentication/login
• https://localhost:44385/signout/B2C_1_signupsignin01

The Problem: To support subdomain-based tenant resolution, we would need to register one redirect URI per tenant, for example:

• https://tenant1.app-app1-qa.commondomain.com/authentication/login
• https://tenant2.app-app1-qa.commondomain.com/authentication/login
• https://tenant3.app-app1-qa.commondomain.com/authentication/login
• ... (one per tenant and endpoint)

Azure AD B2C Limitation: According to Microsoft documentation, there is a hard limit on the number of redirect URIs that can be registered per App Registration.

This makes the manual registration approach not scalable for multi-tenant scenarios with subdomain resolution.

Wildcard Support: Azure AD B2C does support wildcards in redirect URIs (e.g., https://*.app-app1-qa.commondomain.com/authentication/login), but Microsoft does not recommend this practice for security reasons.

4. Latest Attempt and Current Error

After researching and implementing various solutions found in documentation and forums, we have advanced in the authentication flow but now encounter a correlation cookie error:

'.AspNetCore.Correlation.Kh3ihYshY6FPVHu7SpFA9Uka76CC_IBMV0yO8yMcZxQ' cookie not found.

This error indicates that the correlation cookie used by ASP.NET Core during the OAuth/OpenID Connect authentication flow is not found or is not available when Azure AD B2C attempts to redirect back to the application.

Potential causes:

• Cookie domain configuration issues when using subdomains
• SameSite cookie policy conflicts in the authentication flow
• Incompatibilities between the cookie domain and the subdomain used in redirection
• Tenant resolution interfering with the authentication middleware pipeline

Expected Behavior

1. User accesses https://tenant1.app-app1-qa.commondomain.com
2. Tenant tenant1 is automatically resolved from the subdomain
3. User is redirected to Azure AD B2C for authentication
4. After successful authentication, user is redirected back to the application
5. The tenant context (tenant1) remains correctly applied throughout the session
6. API requests include the correct tenant context
7. The authentication flow works seamlessly with Azure AD B2C just as it does with OpenIddict

Actual Behavior

1. ✅ User accesses https://tenant1.app-app1-qa.commondomain.com
2. ✅ Tenant tenant1 is correctly resolved from the subdomain
3. ✅ User is redirected to Azure AD B2C for authentication
4. ❌ Correlation cookie error occurs during redirect back to application
5. ❌ Authentication flow fails
6. ❌ User cannot access the application with the tenant context

Use Case: Direct Links with Automatic Tenant Resolution

The primary use case for this functionality is to facilitate direct links to specific entities without requiring manual tenant specification.

Previous URL (without automatic resolution):

https://app-app1-qa.commondomain.com/Entity/36512651

Users had to manually select their tenant before accessing the patient record.

Implemented Solution (Working with OpenIddict)

With subdomain-based tenant resolution, the tenant is automatically resolved from the URL:

Improved URL (with automatic resolution):

https://tenantCliente.app-app1-qa.commondomain.com/Entity/36512651

The system automatically detects tenantCliente from the subdomain, configures the appropriate context, and allows direct access to the record without intermediate steps.

This works perfectly in local development with OpenIddict, but fails when Azure AD B2C is enabled.

Questions

1. Is the Domain/Subdomain Tenant Resolver compatible with Azure AD B2C external authentication providers?

2. Are there additional configurations or workarounds required to make subdomain-based tenant resolution work with Azure AD B2C?

3. How can we resolve the correlation cookie error when using subdomains with Azure AD B2C authentication?

4. Is there a recommended approach for handling redirect URI configuration in Azure AD B2C for multi-tenant applications with subdomain resolution?

   • Should we use wildcards despite security concerns?
   • Is there a proxy/middleware pattern recommended by ABP?
   • Should we implement a different tenant resolution strategy for Azure environments?

5. Are there known limitations or incompatibilities between:

   • ABP's domain-based tenant resolver
   • Azure AD B2C authentication flow
   • Cookie-based authentication state management
   • Subdomain-based tenant isolation

6. Has ABP team tested or validated the Domain/Subdomain Tenant Resolver with Azure AD B2C in production scenarios?

Azure AD B2C Configuration Attempts

We have tried various approaches to integrate Azure AD B2C, including:

1. Cookie domain configuration for subdomain sharing
2. SameSite cookie policies adjustments
3. Custom authentication handlers for tenant-aware redirects
4. Middleware ordering adjustments
5. Correlation cookie storage modifications

None of these attempts have successfully resolved the correlation cookie error when using subdomain-based tenant resolution with Azure AD B2C.

Request for Guidance

We would greatly appreciate:

1. Official guidance or documentation on integrating Domain/Subdomain Tenant Resolver with external authentication providers like Azure AD B2C

2. Sample implementation or reference project demonstrating this integration

3. Clarification on whether this scenario is supported in the current ABP Framework version

4. Recommended architectural patterns for handling this use case in production Azure environments

5. Any known workarounds or alternative approaches that maintain the automatic tenant resolution functionality while working with Azure AD B2C

Additional Context

• This functionality is critical for our production deployment in Azure
• We have successfully implemented the base functionality with OpenIddict (local development)
• The solution works as expected when Azure AD B2C is disabled
• Our application requires external authentication via Azure AD B2C for all Azure environments (QA, Pre, Prod)
• We need to maintain the direct link functionality with automatic tenant resolution

Thank you in advance for any guidance or assistance you can provide.

Related Issues:

• #10222 - Domain/Subdomain Tenant Resolver not working (Resolved for OpenIddict)

[maliming] said: hi

Can you share the debug logs of 44393 website?

Thanks

If you wish, I can give you access to the source code where I am implementing it, so you can run the application yourself and see what happens. Please contact me by email, francisco.sierra@semicrol.com

Hi,

I have uploaded the log to the repository. You can find it here https://github.com/franciscosl-fnet/abp-app-domain-based/blob/main/Logs20251217.txt

I followed those steps and fixed the error. Ultimately, it was because one of the methods that configures the application was overridden in a module, which was our fault.

Now I am getting a different error when making the request: https://localhost:44393/connect/token

When I take it to the production application, I am getting an error in this call: https://{0}.localhost:44393/.well-known/openid-configuration

The ports are different because it is another solution. What could be the reason for this?