Stratara.Identity.EntityFrameworkCore
4.7.0
Prefix Reserved
dotnet add package Stratara.Identity.EntityFrameworkCore --version 4.7.0
NuGet\Install-Package Stratara.Identity.EntityFrameworkCore -Version 4.7.0
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" Version="4.7.0" />
<PackageVersion Include="Stratara.Identity.EntityFrameworkCore" Version="4.7.0" />
<PackageReference Include="Stratara.Identity.EntityFrameworkCore" />
paket add Stratara.Identity.EntityFrameworkCore --version 4.7.0
#r "nuget: Stratara.Identity.EntityFrameworkCore, 4.7.0"
#:package Stratara.Identity.EntityFrameworkCore@4.7.0
#addin nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.7.0
#tool nuget:?package=Stratara.Identity.EntityFrameworkCore&version=4.7.0
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.13)
- Microsoft.EntityFrameworkCore.Relational (>= 10.0.13)
- Microsoft.Extensions.Configuration.Abstractions (>= 10.0.13)
- Microsoft.Extensions.Identity.Core (>= 10.0.13)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.13)
- Stratara.Abstractions (>= 4.7.0)
- Stratara.Diagnostics (>= 4.7.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on Stratara.Identity.EntityFrameworkCore:
| Package | Downloads |
|---|---|
|
Stratara.EventSourcing.EntityFrameworkCore
EF Core persistence for the Stratara event-sourced stack on PostgreSQL — write-store, read-store, ASP.NET Identity store — including a shared identity store with its migrations — shared conventions, value generators, and UnitOfWork primitives. Targets Npgsql; maps pgvector types for a model that uses them, and needs no database extension otherwise. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 4.7.0 | 328 | 10/30/2026 |
| 4.6.1 | 67 | 10/29/2026 |
| 4.6.0 | 169 | 10/28/2026 |
| 4.5.0 | 250 | 10/28/2026 |
| 4.4.10 | 195 | 10/26/2026 |
| 4.4.9 | 100 | 10/26/2026 |
| 4.4.8 | 239 | 10/24/2026 |
| 4.4.7 | 109 | 10/23/2026 |
| 4.4.6 | 205 | 10/22/2026 |
| 4.4.5 | 641 | 10/14/2026 |
| 4.4.4 | 377 | 10/10/2026 |
| 4.4.3 | 111 | 10/10/2026 |
| 4.4.2 | 461 | 10/2/2026 |
| 4.4.1 | 420 | 9/29/2026 |
| 4.4.0 | 152 | 9/27/2026 |
| 4.3.1 | 128 | 9/25/2026 |
| 4.3.0 | 396 | 9/23/2026 |
| 4.2.0 | 158 | 9/18/2026 |
| 4.1.1 | 94 | 9/16/2026 |
| 4.1.0 | 108 | 9/16/2026 |
A release for one person who belongs to several tenants — and, sharing one identity store, to several applications.
### Added
- **`MembershipStatus.Former`** records a member who has left. It confers nothing — no role, permission or
cross-tenant access, never the tenant at sign-in, never a selection — and stays listed until the user's or the
tenant's erasure removes it.
- **`AddCheckedMembershipTenantClaim<TUser>()`**, a third tenant-claim mode: the claim is stamped at sign-in, kept when
the security-stamp validator refreshes a cookie sign-in, and checked on every request. A request whose user is no
longer an active member of the carried tenant loses the claim and resolves to the reserved default tenant, without
another tenant substituted. Only principals ASP.NET Identity issued are checked; an API key or a token the host
mints keeps its tenant. The tenant changes only when the host re-issues the sign-in. Combining it with
`AddMembershipTenantClaimsTransformation()` throws, and a claims transformation of the host's own registered
beside it is refused at start. Use it where several applications share one identity store:
`active_tenant` holds one selection per account, so live resolution moves every open session when any of them
switches.
- **`EventSubject.ForUser(userId)`** and **`EventSubject.NamesAnOwner`**: a stream can be created for a user alone,
for data that belongs to a person rather than to any of their tenants. It is recorded under the reserved default
tenant, keeps that owner for every later event whatever tenant the session names, and its encrypted fields — at
every level — are keyed to the person: shredded by the person's erasure, untouched by any tenant's.
`KeySubject.User` covers those keys too, so nothing is encrypted for the person again after the erasure.
- **`StrataraIdentityStore`, an identity store several hosts can share on PostgreSQL**, with its migrations shipped
in `Stratara.EventSourcing.EntityFrameworkCore`. It holds ASP.NET Identity's tables, passkeys included, and the
tenant directory in the fixed schema `stratara_identity`, with the history in
`stratara_identity.__stratara_identity_migrations`. `AddStrataraIdentityStore()` registers it on the connection
string `identitydb` (falling back to `defaultdb`, never through a tenant-routing `IDbResolver`) with the
directory's stores over it, and refuses a host that turns on `Stores.ProtectPersonalData`;
`MigrateStrataraIdentityStoreAsync()` creates the database where needed and applies the migrations — hosts that
migrate at once take turns. The account type is `IdentityUser` and cannot be extended, and the store fixes the
ASP.NET Identity schema version and key lengths, so every host's model matches the shipped migrations. Within a
major version the schema changes only additively. Moving an existing identity store onto it means replacing it and
seeding with the same user and tenant ids; the new guide *Shared Identity Store* describes it.
### Changed
- **Setting a membership to a status other than `Active` clears a selection that pointed at it**, as removing it
already did.
- **An explicit subject that names a user and no tenant is accepted** by `AppendOnBehalfOfAsync` and
`CreateOnBehalfOfAsync`; one that names neither is refused as before. A session whose tenant resolved to the
reserved default still gives an event no owner.
- **BREAKING (behaviour): an event or aggregate type marked `[EncryptData]` as a whole stops the host from starting.**
`EncryptionMetadataDriftGuard` refuses every registered aggregate, and every event type a registered aggregate
applies, that carries the attribute on the type; an event type no aggregate applies is refused when it is appended,
before anything is written. Once its subject was erased such a payload had nothing left to deliver, and a replay or
rebuild stopped there for good. Mark the properties instead; payloads already written as a whole are still read.
Commands and other types may still be marked as a whole.
### Fixed
- **A user's erasure shreds their own data through a key store that cannot list its scopes.** The eraser names the
user's keys under the reserved default tenant itself, at every level; until now only a listing reached the
user-level one.