7 Answer(s)

• 

  0

  AI-Bot created 6 months ago

  Support Team ABP Agent

  • With TenantUserSharingStrategy.Shared in ABP 10.2, the login flow is host-first (global identity is established before a tenant context is selected). As a result, tenant-specific runtime OIDC challenge configuration (Authority/ClientId/ClientSecret per tenant) is not compatible with the Shared strategy’s core flow, because the system doesn’t know the tenant at the moment it must choose the external IdP to challenge.
  • In ABP, per-tenant external login configuration is supported when the tenant context is known (classic multi-tenancy flow). The Account.Pro “External Logins” system is explicitly described as multi-tenant compatible and allows each tenant to configure/override provider settings. However, that model assumes the tenant can be resolved before initiating the challenge.
  • Therefore, for your scenarios:
    1. Per-tenant Entra ID credentials: cannot be deterministically selected at the start of authentication under Shared (tenant unknown).
    2. Mixed authentication methods across tenants: Shared makes authentication rules global-first; tenant-specific “must use SSO / must forbid password” cannot be enforced at the initial sign-in step in the standard Shared flow.
    3. Per-tenant security policies: in Shared, those are host-level by design (ABP documentation also states security settings are managed at Host level).

  What you can do (verified ABP-supported approaches):

  1. Use TenantUserSharingStrategy.Isolated if you require per-tenant IdP selection at sign-in

     • This is the only fully consistent approach if each tenant brings its own Entra/Okta config and the tenant must be resolved before challenge.
     • You still can provide a good UX with tenant resolution (subdomain, tenant name, email domain mapping, etc.), but it won’t be “global-auth first”.

  2. Keep Shared, but restrict yourself to “global external IdP(s)” (host-level)

     • If you can use a single Entra multi-tenant app registration (or a single federation entry point) for all customers, Shared works well because the host can always challenge the same provider.
     • Tenants can still differ in authorization/roles/permissions after tenant selection, but not in initial IdP selection.

  3. If you need tenant-specific allowed login methods (not tenant-specific OIDC credentials), customize external provider availability per tenant

     • ABP support guidance shows you can replace ExternalProviderSettingsHelper to filter which external providers are available per tenant (e.g., TenantA sees “windows,google”, TenantB sees “google”). This can help with “mixed authentication methods across tenants” only after tenant context exists (e.g., on tenant-specific login pages or flows that resolve tenant early).
     • This is done by replacing the service (example shown in ABP support answer), and using ICurrentTenant to decide which providers to return.

  4. Hybrid flow (tenant selection before authentication) is not provided as a built-in mode for Shared in ABP 10.2

     • Your “Option A” (email → resolve tenants → select tenant → challenge correct IdP) is conceptually valid, but there is no verified built-in ABP 10.2 feature that changes Shared’s host-first external challenge to tenant-first selection.
     • Implementing that would require a custom login UX + custom authentication flow, and you’d effectively be reintroducing “tenant known before auth” for external login—at which point Isolated is usually the simpler/cleaner solution.

  Sources (validated)

  • https://abp.io/docs/10.2/modules/account/shared-user-accounts
  • https://abp.io/docs/latest/modules/account-pro
  • https://abp.io/support/questions/6637
  • https://abp.io/support/questions/8731

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  nacho created 6 months ago

  Any ABP team insights?

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 5 months ago

  Support Team Fullstack Developer

  hi

  The Shared strategy works as "authenticate first, select tenant after" — at the point the login page is rendered, there's no tenant context yet, so the system doesn't know which tenant's IdP credentials to use. That's why external IdP configuration (along with other security settings like 2FA, lockout, password policies) is handled at the Host level in this mode.

  For scenarios where each customer needs their own Azure AD app registration or similar per-tenant IdP setup, the Isolated strategy would be a better fit — it resolves the tenant before authentication, so tenant-specific IdP settings can be loaded properly.

  Thanks.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  nacho created 5 months ago

  Hi @maliming,

  Thanks for the clarification. We understand the limitation, but using Isolated means giving up unified user accounts, which is the main reason we'd want to upgrade to Shared in the first place.

  We'd like to propose a flow that could make per-tenant external IdP configuration work with Shared strategy:

  Proposed Flow:

  1. User enters email on the login page (no tenant context yet)
  2. System looks up matching user records across tenants for that email (in Shared mode, with the IMultiTenant data filter disabled, the system can query all IdentityUser records matching the email — each with a different TenantId. ABP already does something similar in IdentityUserManager.FindSharedUserByEmailAsync)
  3. User selects a tenant from the list (or auto-selects if only one)
  4. Tenant context is now resolved → tenant-specific IdP configuration is loaded
  5. Authentication is requested using the appropriate method (Entra ID, password, etc.)

  Note: This flow could be opt-in via configuration (e.g., AbpAccountOptions.EnableTenantSelectionBeforeAuth), so it only activates when the application explicitly requires per-tenant IdP resolution in Shared mode. The default behavior would remain unchanged.

  So, in Shared mode, the email is a cross-tenant identifier — we don't need domain-based tenant resolution. The tenant selection happens before authentication but after user identification, giving us the context needed to load per-tenant IdP settings.

  Security Consideration:

  This flow could expose tenant membership to unauthenticated users (email enumeration). This can be mitigated by:

  • Returning a generic response regardless of whether the email exists (e.g., always show "check your email")
  • Sending a verification code to the email before revealing tenant options
  • Rate limiting the lookup endpoint

  We believe this is a reasonable tradeoff, especially since domain-based tenant resolution already implicitly reveals tenant existence today.

  Request:

  Would the ABP team consider either supporting this flow natively, or providing the necessary extensibility points (e.g., virtual methods, overridable services, or hooks in the login pipeline) so that we can implement this flow ourselves on top of the Shared strategy?

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 5 months ago

  Support Team Fullstack Developer

  Hi,

  Thanks for the detailed proposal. We've discussed this internally, and we don't have plans to implement a pre-authentication tenant selection flow for the Shared strategy at this time.

  The Shared strategy is fundamentally designed around the "authenticate first, select tenant after" model. In this mode, since user identity is shared across tenants, all security-related settings are managed at the Host level. This means tenants cannot independently configure:

  • Password policies (required length, complexity, periodic change, reuse prevention, etc.)
  • Lockout policies (lockout duration, max failed attempts, etc.)
  • Sign-in settings (require confirmed email/phone, etc.)
  • External identity providers (Azure AD, Okta, etc.)

  This is by design — when a user's identity is shared across multiple tenants, it wouldn't make sense to allow individual tenants to enforce conflicting security policies on the same user account.

  Introducing tenant resolution before authentication (as you proposed) would fundamentally change this model and add significant complexity and potential security concerns (such as email enumeration).

  For scenarios that require per-tenant external identity provider configuration or per-tenant security policies, please use the Isolated strategy, which resolves the tenant before authentication and fully supports tenant-level settings.

  We understand this means you can't use unified user accounts and per-tenant IdP configuration at the same time. We'll keep this feedback in mind for future improvements.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  nacho created 5 months ago

  OK, thank you

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 6 months ago

  Support Team Fullstack Developer

  Hi,

  Thank you for your understanding. If you have any further questions or need assistance in the future, feel free to open a new support ticket.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel