Stratara.Identity.EntityFrameworkCore 4.0.1

Prefix Reserved
There is a newer version of this package available.
See the version list below for details.
dotnet add package Stratara.Identity.EntityFrameworkCore --version 4.0.1
                    
NuGet\Install-Package Stratara.Identity.EntityFrameworkCore -Version 4.0.1
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" Version="4.0.1" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Stratara.Identity.EntityFrameworkCore" Version="4.0.1" />
                    
Directory.Packages.props
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Stratara.Identity.EntityFrameworkCore --version 4.0.1
                    
#r "nuget: Stratara.Identity.EntityFrameworkCore, 4.0.1"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Stratara.Identity.EntityFrameworkCore@4.0.1
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.0.1
                    
Install as a Cake Addin
#tool nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.0.1
                    
Install as a Cake Tool

Stratara.Identity.EntityFrameworkCore

Derived. The behaviour described here is specified under openspec/specs/. Those specifications are the source; this page explains and illustrates them.

EF Core identity-directory plane for the Stratara stack: user↔tenant membership (many-to-many with tenant-scoped roles), active-tenant selection, and membership-backed authorization.

Contents

  • IdentityDirectoryDbContext<TContext> — standalone DbContext hosting all four directory tables (tenant_membership, active_tenant, setting_entry, api_key); derive a concrete context and own its migrations. To fold these into an existing context instead, call modelBuilder.ApplyIdentityDirectoryModel() in its OnModelCreating.
  • ModelBuilder.ApplyIdentityDirectoryModel() — adds the same tables to an existing context (for example your ASP.NET Identity context) so they share one migration lineage.
  • AddTenantMembershipStore<TContext>() — EF-backed ITenantMembershipStore: forward lookup (a user's tenants), reverse lookup (a tenant's members), upsert, GDPR sweeps per user/tenant, and membership-guarded active-tenant switching.
  • MembershipAuthorizationProvider / MembershipAuthorizationProvider<TUser> — the framework's default IAuthorizationProvider: role checks pass on tenant-scoped membership roles, the TUser variant additionally on global ASP.NET Identity roles (platform roles).
  • AddMembershipCrossTenantAuthorizer(...) — membership-backed ICrossTenantAuthorizer for strict tenant isolation, with configurable cross-tenant roles for the operator-impersonation path (platform administrators without membership in the target tenant).
  • AddPermissionCatalog(...) + AddCatalogPermissionResolver[<TUser>]() — the application's code-declared permission vocabulary with role grants, resolved from membership roles (and optionally global ASP.NET Identity roles) for [RequirePermission] enforcement and HTTP permission policies.
  • AddApiKeyStore<TContext>() — API keys and personal access tokens: stk_-prefixed 256-bit keys (hash-only storage), fail-closed validation with expiry/revocation, erasure sweeps. Machine keys are materialized as tenant memberships, so they flow through the same role/permission plane as human actors; PATs act as their bound user. ImportAsync stores a machine key the caller already holds (generated with ApiKeyFormat.CreateRawKey()) for setups where the key must exist before boot — idempotent, never mutating an already-stored key.
  • AddSettingCatalog(...) + AddSettingStore<TContext>() — scoped settings plane: code-declared SettingDefinitions, row-per-key EF storage (setting_entry), a Subject-fed ISettingProvider fallback chain (user-in-tenant → user → tenant → global → configuration → default), transparent AES-GCM encryption for IsEncrypted definitions, and per-user/per-tenant erasure sweeps.
  • AddTenantMembershipStoreFromContextFactory<TContext>(), AddApiKeyStoreFromContextFactory<TContext>(), AddSettingStoreFromContextFactory<TContext>() — the same three stores, taking a fresh context per operation from IDbContextFactory<TContext> instead of sharing the request's. See below.

One context for the request, or one per operation

The plain registrations give every directory store in a request the same context instance. A database context serves one operation at a time, so directory work issued concurrently inside one request fails on whichever operation arrives second — at the call site that lost the race, not the one that introduced the concurrency. Sharing also means a store's own commit commits whatever else the consumer has left unsaved on that context.

The …FromContextFactory variants remove both: each operation creates its own context and disposes it. In exchange, a store write no longer takes part in a transaction the consumer opened on their own scoped context. That trade is why the shared registration stays the default rather than being replaced.

They require AddDbContextFactory<TContext>(); a missing registration fails at first resolution. Keep the factory's options aligned with the scoped registration — interceptors, query filters and conventions are configured per registration, not per context type. Calling both variants for the same store leaves whichever ran first in place; they do not compose.

Dependencies

  • Microsoft.EntityFrameworkCore (+ Relational)
  • Microsoft.Extensions.Identity.Core
  • Stratara.Abstractions

Used together with Stratara.Mediator (authorizing mediator, tenant isolation) and Stratara.Identity.AspNetCore (sign-in claims bridge).

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
4.2.0 46 9/18/2026
4.1.1 61 9/16/2026
4.1.0 78 9/16/2026
4.0.4 679 9/14/2026
4.0.3 112 9/3/2026
4.0.2 594 9/3/2026
4.0.1 225 9/2/2026
4.0.0 615 8/31/2026
4.0.0-preview.1 67 8/31/2026
3.4.0 135 8/28/2026
3.3.0 332 8/25/2026
3.2.3 104 8/22/2026
3.2.2 729 8/14/2026
3.2.1 360 8/2/2026
3.2.0 114 7/18/2026

### Added

- **Bundles about one aggregate are now applied one at a time within a process, a handler can say
 "not yet", and the workers' parallelism is configurable.** The projection worker and the saga
 worker open one consumer per processor on a shared queue, so two bundles published milliseconds
 apart — the fact that creates an entity and the first fact about it — landed on two consumers and
 ran at the same time, and whichever finished first won. A projection that then found no row for
 the follow-up could only warn and acknowledge a fact it never applied, or throw and have the
 bundle discarded; either way the read model lost the fact until a replay. The command worker has
 never had this problem, because it takes a per-aggregate lock before it runs a command.

 Both workers now take the same lock, keyed on the streams the bundle's events belong to. Bundles
 about different aggregates still run in parallel; bundles about one aggregate queue behind each
 other. The guarantee is per process — two replicas consuming the same subscription do not
 serialise against each other — and the delivery guarantee now says so explicitly.

 The lock serialises but does not order, so the residual case gets a second chance:
 `PrecedingFactMissingException(streamId, eventTypeName)` in `Stratara.Abstractions` is the one
 exception the workers retry — five attempts from 100 ms doubling, about three seconds in all,
 under the new named policy `ResilienceNames.PrecedingFact`, with every aggregate lock released
 between attempts so the creating fact can land in the gap. Once the retries are exhausted the
 bundle fails as any unhandled failure does, and the warning logged on each attempt
 (`104_010` for projections, `110_005` for sagas) names the stream and the event type. Any other
 exception fails the bundle on the first attempt, as before.

 `Projections:DegreeOfParallelism` and `Sagas:DegreeOfParallelism` set the number of consumers each
 worker opens; a value that is not a positive number means the processor count, and `1` gives a
 worker that applies every bundle in the order the transport delivers it.

 A consumer that changes nothing gets the serialisation and the default parallelism it had. A
 consumer that implements `IMessageBus` itself is unaffected: the retry runs inside the worker
 before the transport sees an outcome. `BucketLockPool`, previously internal to the mediator, is
 now public in `Stratara.Abstractions` so that every worker takes the same lock from the same
 place; the mediator's own copy is gone.

### Changed

- **A published version now announces itself in the repository.** The release workflow gained a
 third job that creates the GitHub release entry for the tag once the packages have reached
 nuget.org, with the changelog section for that version as its notes — the same section the
 packages already carry as their release notes. A prerelease tag is marked as one, so it does not
 displace the current stable version. Until now the release list was maintained by hand and had
 fallen behind: 4.0.0 was on nuget.org while the repository still presented 3.4.0 as current.
 Nothing about what publishes, when, or on whose approval has changed.