Implementing multi-tenancy in EF Core with global filters

The C# Corner Annual Conference 2020 program brings C#, Azure, data and DevOps specialists together, yet many production applications still have a deceptively small requirement: keep each customer’s records separate. In a multi-tenant system, one account may represent a law firm in Brisbane and another a retailer in Melbourne, while both use the same application, schema and operational pipeline.

EF Core global query filters can make tenant isolation the default by adding a tenant discriminator to ordinary LINQ queries. They are valuable, but a filter alone is not a security boundary: tenant identity, entity keys, authorisation, migrations and tests must reinforce it. The practical goal is a design where ordinary application code asks for “accounts” and receives only the accounts owned by the current tenant.

Define the tenancy boundary

Begin with the isolation promise rather than the number of tenants. Decide whether customers share a database schema, use separate schemas in one database, or receive dedicated databases. Global filters fit the first model naturally, but they can also protect accidental access in carefully controlled hybrids. A tenant means a contractual customer organisation, not an individual user or subscription plan.

A shared schema usually offers the best economics for Australian SaaS businesses serving many small and medium-sized customers. Melbourne and Sydney firms often operate lean engineering teams, so pooling resources can control database and administration costs. It also suits usage patterns built around cloud APIs, where customers expect fast, always-available access without maintaining separate estates.

Regulated or larger customers may request a dedicated database for contractual, risk or capacity reasons. That choice is separate from Australian privacy law: the Privacy Act 1988 and the Australian Privacy Principles govern how personal information is handled, but they do not generally prescribe one tenant per database. Document the chosen boundary, customer entitlements and migration path before writing filters.

Resolve tenant identity for each request

EF Core evaluates a query filter as part of each LINQ expression. The context therefore needs a reliable tenant identifier before any tenant-owned query runs. Resolve it from a validated membership claim after authentication, place it in a scoped tenant context, and bind it to the DbContext for that request. Never trust a tenant ID supplied only in JSON, a query string or an unsigned header.

public interface ITenantContext
{
    Guid TenantId { get; }
}

public sealed class AppDbContext : DbContext
{
    private readonly ITenantContext _tenant;

    public AppDbContext(DbContextOptions<AppDbContext> options,
        ITenantContext tenant) : base(options)
    {
        _tenant = tenant;
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Account>()
            .HasQueryFilter(x => x.TenantId == _tenant.TenantId);
    }
}

Scoped registration prevents one user’s tenant from leaking into another request through a singleton context. In ASP.NET Core, complete authentication and tenant selection before the first database call. If a user can belong to several organisations, make tenant selection explicit and verify that the chosen tenant appears in the signed membership claim. Cache tenant metadata, not the tenant decision itself.

Workers need deliberate tenant boundaries too. A queue message can carry a tenant ID, but the consumer should validate it against the target record before creating the scoped context. Use a separate, audited administrative path for support access, and record who switched context and why. Calling IgnoreQueryFilters is appropriate for that path, not as a convenient way to repair an incorrect normal request.

Encode ownership in the EF model

Filtering reads is only part of ownership. Model tenant-owned entities with the tenant key in their primary key and relevant unique indexes. A bare integer primary key can remain unique, while a compound key expresses that the same local identifier may exist in several tenants. Unique business fields, such as an email address or ABN, must be unique within a tenant rather than across the entire platform.

modelBuilder.Entity<Account>()
    .HasKey(x => new { x.TenantId, x.Id });

modelBuilder.Entity<Account>()
    .HasIndex(x => new { x.TenantId, x.Email })
    .IsUnique();

Global filters scope query roots, but they are application-side filtering rather than database row-level security, and they do not decide whether the current user may perform an operation. Add authorisation policies for roles and tenant membership, and validate newly attached or modified entities during SaveChanges. An interceptor can reject tracked changes whose TenantId differs from the active context. This protects against code that retrieves an entity through an unfiltered path and then saves it.

Navigation properties deserve specific tests. Global query filters apply to the top-level entity in a LINQ query; they do not automatically apply a navigation entity’s own filter when that navigation is included. Validate required relationships in memory or query them with an explicit tenant predicate. If soft deletion also matters, compose both conditions in the filter, and test a deleted record that is reached through an active parent.

Test isolation and meet local obligations

Tenant isolation needs a test matrix that deliberately crosses boundaries. Create two tenants with identical local identifiers, then verify reads, updates, deletes, Include operations, aggregates and background jobs cannot cross them. Seed each test database deterministically and run the matrix in CI. Add a test that creates a scoped context without a tenant, because an empty or default GUID should fail loudly rather than widen a query.

For Australian deployments, personal information requires more than row separation. The Privacy Act 1988, Australian Privacy Principles and applicable state instruments such as NSW’s Privacy and Personal Information Protection Act 1988 or Victoria’s Privacy and Personal Information Protection Act 2016 can shape collection, purpose, access correction and retention decisions. The Notifiable Data Breaches scheme also makes containment and evidence important. Global filters can reduce accidental disclosure, while access controls, audit trails and incident procedures address the wider legal obligations.

Local infrastructure choices matter as well. Australian organisations commonly mix Microsoft Azure with AWS and Google Cloud, with Sydney, Melbourne and Brisbane hosting requirements influencing latency and resilience. The Privacy Act does not create a blanket Australian data-residency rule, but contracts and regulator expectations may still require specific storage locations. Keep the tenancy model independent of the database vendor so dedicated or regional deployments remain possible.

Everyday expectations are equally concrete: commuters checking mobile banking, retail loyalty and booking apps assume a signed-in account cannot expose another household’s data. The Australian Signals Directorate’s Essential Eight adds a useful security baseline through application allow-listing, patching, MFA, logging and privileged-access controls. These measures limit the blast radius of a compromised account when support staff operate across shared infrastructure.

Design for cloud operations

Runtime correctness must extend into cloud operations. Give cached values, queued commands and idempotency keys tenant-qualified identities, and use an outbox or equivalent mechanism to publish events only after the transaction commits. Retries must not create a second tenant-owned record. Distributed tracing should include a pseudonymous tenant identifier, enough to diagnose failures without copying personal information into logs.

A resilient Azure architecture can guide health checks, retry policies, service communication and failure isolation when tenant-aware workloads become microservices. Multi-tenancy does not replace those patterns; it adds an ownership dimension to them. A retrying service needs the same tenant context and idempotency controls as its first attempt.

Database changes require a deployment plan. For a shared-schema move, add and backfill tenant columns before enforcing keys, then introduce filters and compatibility code in stages. EF Core migrations should create the new shape safely for live traffic, while blue-green deployment can keep old and new application versions operating against the same transition schema. Dedicated databases need an orchestration process for provisioning, migration and tenant movement.

Roll out with measurable safeguards

Treat the implementation as a staged change with observable outcomes. Establish the ownership model and threat cases first, prove isolation in an integration environment, and release with dashboards that track query volume, denied cross-tenant attempts, migration errors and tenant-specific latency. A rollback must preserve data boundaries; restoring a backup needs the same tenant mapping and access checks as the original system.

• Define tenant ownership, key strategy and dedicated-instance criteria before changing the schema.
• Derive tenant context from validated identity and membership claims, with an explicit elevated-access path.
• Exercise every query, navigation, write path and worker against at least two tenants in automated tests.
• Roll out migrations with backfill checks, tenant-level telemetry and rehearsed rollback procedures.

Used this way, global query filters become a consistent default rather than a stand-alone safeguard. The C# Corner Annual Conference 2020 mix of C#, Azure, data, DevOps and AI sessions reflects the same reality: tenant isolation spans application code, cloud operations and governance. A design that combines deterministic context, enforced model rules, Australian privacy controls and continuous verification can scale from a shared Australian SaaS deployment to customers with dedicated infrastructure.