Interface ISubjectEraser
- Namespace
- Stratara.Abstractions.Erasure
- Assembly
- Stratara.Abstractions.dll
Erases a subject across every plane the framework holds its data in, in an order that leaves nothing unreachable before it has been removed.
public interface ISubjectEraser- Extension Methods
Remarks
What it covers. API keys, scoped settings, directory memberships and their active-tenant selections, and key material — the last of these making any data encrypted under the subject's keys unrecoverable. A key is named by level, tenant and user together, and the level decides whose erasure a value dies with. A tenant's erasure shreds every key naming the tenant, at every level, alone or together with each of its members. A user's erasure shreds the user-level keys naming the user, alone or together with each tenant it belongs to. It also asks the key store for every such key naming the subject, which reaches keys shared with someone no longer in the directory; a key store that cannot list its keys leaves that to the directory, and the erasure logs a warning.
What it does not cover, and why it matters. Read models a consumer's own
projections built are unknown to the framework and remain the consumer's responsibility. Data in
the event stream that is not protected by a scoped key is not shredded by removing a key,
because there is no key to remove. The command audit log and the outbox both carry a session
context naming the subject and are deliberately left alone: the audit log is the evidence that
the erasure happened, and retaining it is a decision only the consumer can take. Their rows
stay; what an erasure reaches in them is the fields a command marked for encryption, which are
written for a key and die with it. For a command that names its data owner through
INamesDataOwner that key is the named owner's, in the audit record and in the copy
waiting in the outbox alike, so the owner's erasure leaves the record of the command with those
fields unreadable, and a command still waiting reaches its handler with them absent. For a
command that names none the key is the dispatching session's — the session's tenant with its
data-owner user in the audit record, with the acting user in the outbox — whichever tenant the
data in fact belongs to. A command field that is not marked is not reached at all.
Tenant-level and confidential values written for a user belong to the tenant and survive that
user's erasure. Confidential values written with an empty tenant share one system-wide key that
no erasure shreds. A key store that cannot list its scopes leaves an erasure with the keys the
directory names; a key shared with a former member, or with an operator acting in a tenant from
outside it, is then not found. A snapshot written before 4.4.0 records no user and stays under its
tenant alone, so a user's erasure does not reach it unless the host removed such snapshots on
upgrading.
Methods
EraseTenantAsync(Guid, CancellationToken)
Erases one tenant across every plane, including its members' tenant-scoped data.
Task<ErasureReport> EraseTenantAsync(Guid tenantId, CancellationToken cancellationToken = default)Parameters
tenantIdGuidThe tenant to erase.
cancellationTokenCancellationTokenA token to cancel the operation.
Returns
- Task<ErasureReport>
What each plane covered, once every plane has succeeded.
Exceptions
- ErasureIncompleteException
Thrown when one plane's sweep fails; the erasure stops there.
- ArgumentException
tenantIdis empty, which names no subject.
EraseUserAsync(Guid, CancellationToken)
Erases one user across every plane, in every tenant it is a member of.
Task<ErasureReport> EraseUserAsync(Guid userId, CancellationToken cancellationToken = default)Parameters
userIdGuidThe user to erase.
cancellationTokenCancellationTokenA token to cancel the operation.
Returns
- Task<ErasureReport>
What each plane covered, once every plane has succeeded.
Exceptions
- ErasureIncompleteException
Thrown when one plane's sweep fails; the erasure stops there.
- ArgumentException
userIdis empty, which names no subject.