Skip to main content

#security

Log entries with this tag, newest first.

  1. Decision recordDevices at the edge

    Panel passwords are sealed to the host that uses them

    A secret that one process uses should be readable by that process alone. The decision record for the administrator passwords of access-control panels: write-only entry, a fresh AES-GCM key per secret wrapped with RSA-OAEP under the connector host's key, opened in memory only, one escrow export and then a key nobody can export, a TPM tier that excludes escrow, and why machine-scope DPAPI and the web runtime's key ring were the wrong tools.

    8 min read

  2. Decision recordRealtime transports

    SignalR between a cloud and its sites

    A hub that pushes changes from a cloud to on-premises sites is a security boundary and a lifecycle problem: who may connect, what each connection hears, how long an admission holds, and how a client comes back after the server closes it. The design note: a service-client policy, a group per tenant, a fifteen-second sweep with the same check requests get, and a client that starts itself again because automatic reconnect does not follow a server-side Abort.

    8 min read

  3. Decision recordMulti-tenant platforms

    A schema per tenant: the database owns the name

    When every tenant's rows live in a PostgreSQL schema of their own, the mapping from identifier to schema name is a security boundary. So the mapping moved into the database: a stored generated column, a unique index, COLLATE "C", and a plain CREATE SCHEMA as the claim on a new name. With the two error codes that mean 'taken', the one-at-a-time gate, and an EF Core pooling detail that only production-shaped tests found.

    10 min read

  4. Decision recordMulti-tenant platforms

    The tenant comes from the token, not from the header

    In a multi-tenant API the tenant a request acts in is decided from who is calling. A header may name one; the token says whether the caller may act there. The decision record: one middleware owns the header, the status code follows the caller, and authority that arrives through a replicated directory is trusted for one token lifetime.

    9 min read

  5. Decision recordIdentity and access

    Mutual TLS and certificate-bound tokens for the links that matter

    Client credentials alone let a token travel. For the links between a site and its cloud, and between an assistant's tool servers and the API, every token is bound to the client's certificate (RFC 8705), tokens are exchanged instead of forwarded (RFC 8693), and resources announce their issuer (RFC 9728). The decision record, with the parts that only building it revealed.

    8 min read

  6. Decision recordIdentity and access

    A Content Security Policy for an identity server

    The strictest policy a sign-in page can carry, which directive is left out and why, what base-uri 'none' does to a Blazor page, and why the policy is chosen from the endpoint. A design note from building Hexavera's identity host.

    6 min read

  7. Decision recordIdentity and access

    When the token store is down, the honest answer is 503

    A resource server that cannot check a token must refuse it, and a 401 is the wrong refusal: it tells the client its token is bad and signs the user out. The design: fail closed, classify the fault by what the data provider says, answer 503 with a Retry-After drawn per response, and let anonymous routes ask before they say 'not signed in'.

    7 min read

  8. Decision recordIdentity and access

    Decide from the endpoint, not from the path

    Rate limits, security headers and access gates are per-endpoint decisions. ASP.NET Core accepts several spellings of one path, so a decision made by comparing the path is a decision made on incomplete information. Put it on the endpoint, and test that every endpoint is covered.

    6 min read