Stratara.Outbox.RabbitMQ 4.4.5

• net10.0

  • Microsoft.Extensions.Configuration.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.DependencyInjection (>= 10.0.11)
  • Microsoft.Extensions.Hosting.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.Options.ConfigurationExtensions (>= 10.0.11)
  • RabbitMQ.Client (>= 7.2.2)
  • StackExchange.Redis (>= 3.1.31)
  • Stratara.Abstractions (>= 4.4.5)
  • Stratara.Contracts (>= 4.4.5)
  • Stratara.Mediator (>= 4.4.5)
  • Stratara.Sessions (>= 4.4.5)
  • Stratara.Shared (>= 4.4.5)

A command can now say whose data its protected fields are. Until now a command's `[EncryptData]` fields were
encrypted for the session that dispatched it, so a session with no tenant could not protect anything and a session
with another tenant protected under the wrong one. Additive and opt-in; no schema change and no migration. One
ordering rule applies once a host starts using it (see *Changed*).

### Added

- **A command can name the owner of its protected fields.** A command that implements the new `INamesDataOwner`
 (`Stratara.Abstractions.Security`: `Guid DataOwnerTenantId`, optional `Guid? DataOwnerUserId`) has its
 `[EncryptData]` fields encrypted for that owner wherever the framework serializes it — the copy the outbox, the
 bus and the Orleans record carry to its handler, and the copy the command audit records — whatever session
 dispatched it. It is to a command what `IAggregateCreationEvent` is to a stream's first event. Three cases it
 answers: a session with no tenant (an anonymous endpoint, or a saga reacting to a fact one recorded) could not
 encrypt a `TenantScoped` field at all outside development; a session with another tenant than the data's owner
 encrypted it under that tenant's key, silently, so the real owner's erasure left the audit record readable; and
 the two copies of one command were written for different users. For a command that names its owner, both copies
 are written for the same tenant and the same user.
- **The audit record of such a command is attributed to the named owner.** Its data-owner tenant and user are the
 owner the command names; its actor is the session's, as before. A tenant's view of the command log then holds the
 commands that carried its data, whoever issued them, and each record can be read back from its own columns.
- **`CommandEnvelope.DataOwnerTenantId` and `.DataOwnerUserId`** carry the owner beside the session context. They
 are set only for a command that names an owner and are omitted from the JSON otherwise; the constructor and
 `Deconstruct` are unchanged. The handling host reads the command's protected fields for the owner the envelope
 carries and runs the handler under the session it carries.
- **`CommandDataOwner`** (`Stratara.Shared.Security`) is the one resolution every writer and reader of a command
 uses, for a host that serializes commands itself.

### Changed

- **The bus-envelope signature covers a named owner.** A signed command does not verify when it is presented with
 another data owner, or with its owner removed. A command that names no owner has the canonical form it had before,
 so publishers and consumers on either side of this release verify each other's signatures for it and a fleet in
 `Strict` mode upgrades without a pass through `Permissive`.
- **Upgrade the hosts that handle commands before a host dispatches a command that names an owner.** A command
 worker or silo on an earlier release cannot read the owner. It does not run the handler with the fields emptied:
 in `Strict` mode the signature does not verify, otherwise the read fails authentication, and the message is
 retried and then kept. Two deployments are the simple order — this release first, the declarations after.
- **Nothing changes for a command that names no owner.** It is serialized, stored, published and signed as before.
 That includes a divergence this release states rather than removes: its travelling copy is written for the
 session's tenant and the *acting* user, its audit record for the session's tenant and the session's *data-owner*
 user — for an ordinary signed-in request, a user and nobody. Aligning that default would re-key every protected
 command field in transit and is left to a major version; a command that names its owner is not affected.

### Security

- **An erasure now reaches a command's protected fields where the command names its owner.** `ISubjectEraser`'s
 documentation said the command audit log and the outbox are left alone. Their rows still are; what it now also
 says is what happens to protected fields in them. A command that names its owner has them under that owner's key
 in both places, 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.
- **A command that names an empty tenant, or an empty user, as its owner is refused.** It fails with
 `ArgumentException` naming the command type where it is recorded and where it is dispatched, and nothing is
 recorded or sent. It does not fall back to the session, which would hide a caller's mistake in valid ciphertext
 under the wrong tenant's key.
- **Naming an owner authorizes nothing, and the owner is taken as stated.** Nothing compares the named owner
 against the session; the handler runs under the dispatching session, and authorization and tenant isolation decide
 as they do for any other command. Nothing checks that the named tenant exists either, and key material is created
 for it on first use — name an owner the code resolved from something it trusts, never one copied from a request.
- **A command encrypted as a whole does not outlive its owner.** With `[EncryptData]` on individual fields, a
 command still waiting when its owner is erased reaches its handler with those fields absent. With `[EncryptData]`
 on the class there is nothing left to rebuild: the command is retried and then kept, and its handler does not run.
 That is how a command whose session tenant was erased already behaved; it is now stated.