Stratara.Identity.EntityFrameworkCore
4.0.1
Prefix Reserved
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
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" Version="4.0.1" />
<PackageVersion Include="Stratara.Identity.EntityFrameworkCore" Version="4.0.1" />
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" />
paket add Stratara.Identity.EntityFrameworkCore --version 4.0.1
#r "nuget: Stratara.Identity.EntityFrameworkCore, 4.0.1"
#:package Stratara.Identity.EntityFrameworkCore@4.0.1
#addin nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.0.1
#tool nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.0.1
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, callmodelBuilder.ApplyIdentityDirectoryModel()in itsOnModelCreating.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-backedITenantMembershipStore: 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 defaultIAuthorizationProvider: role checks pass on tenant-scoped membership roles, theTUservariant additionally on global ASP.NET Identity roles (platform roles).AddMembershipCrossTenantAuthorizer(...)— membership-backedICrossTenantAuthorizerfor 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.ImportAsyncstores a machine key the caller already holds (generated withApiKeyFormat.CreateRawKey()) for setups where the key must exist before boot — idempotent, never mutating an already-stored key.AddSettingCatalog(...)+AddSettingStore<TContext>()— scoped settings plane: code-declaredSettingDefinitions, row-per-key EF storage (setting_entry), a Subject-fedISettingProviderfallback chain (user-in-tenant → user → tenant → global → configuration → default), transparent AES-GCM encryption forIsEncrypteddefinitions, and per-user/per-tenant erasure sweeps.AddTenantMembershipStoreFromContextFactory<TContext>(),AddApiKeyStoreFromContextFactory<TContext>(),AddSettingStoreFromContextFactory<TContext>()— the same three stores, taking a fresh context per operation fromIDbContextFactory<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.CoreStratara.Abstractions
Used together with Stratara.Mediator (authorizing mediator, tenant isolation) and
Stratara.Identity.AspNetCore (sign-in claims bridge).
| Product | Versions 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. |
-
net10.0
- Microsoft.EntityFrameworkCore (>= 10.0.11)
- Microsoft.EntityFrameworkCore.Relational (>= 10.0.11)
- Microsoft.Extensions.Configuration.Abstractions (>= 10.0.11)
- Microsoft.Extensions.Identity.Core (>= 10.0.11)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
- Stratara.Abstractions (>= 4.0.1)
- Stratara.Diagnostics (>= 4.0.1)
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.