ekklesiaandClaude Opus 5
80189c8ae2
ADR 0033 gave Ekklesia a display host and ADR 0034 gave it a login page. Together, the only way to light a television in a foyer was to sign a human being into it and leave that session running on a screen anyone can walk up to: a person's credentials on a wall, a person's session as the thing signage depends on, and the display going dark when they are revoked or their session simply expires. A screen is not a person. Ekklesia now recognizes three principal classes — anonymous, authenticated human, and managed device — and a device is a first-class principal with its own credential and its own explicit permissions. It has no email, no password, and no row in the identity tables, and it satisfies the `authenticated` baseline never, so every route that settles for "somebody is signed in" stays closed to it. Device permissions live in their own table because ekklesia_core_grant.user_id is a non-null foreign key into the user table and making it polymorphic would rewrite the platform's central authorization record to serve one narrow case. That is a schema decision, not a second decision point: the evaluator gained one branch, so a device is allowed or denied by the same function, with the same deny-by-default, as anyone else — with no owner path it could reach and no baseline that stands in for a grant. The six-digit code is not the credential. It is printed across a screen in a public hallway, so it is treated as public: it identifies a request to an administrator and is worth nothing alone. Collecting the credential also requires a 256-bit claim secret held only in the requesting browser's HttpOnly cookie, and approving requires the restricted core.devices.manage permission. Without that split, reading a code off a wall would hand over the screen's identity. The permission a pairing asks for is read from the module's validated display declaration, never from the request, so a browser cannot ask to be granted core.devices.manage or another module's permission. Approval grants exactly that one permission. Credentials are stored only as SHA-256; the raw value exists in the Set-Cookie that issues it and the device's own cookie jar, and is never logged, returned in JSON, or placed in a URL. The cookie is HttpOnly, so the module display code running in that same page cannot read it. Revocation is a server-side column checked on every principal resolution, and re-pairing mints a new identity so an old credential can never come back. State transitions are conditional updates, so one code cannot be approved twice or claimed into two credentials under a race. /api/v1/principal still reports a device as anonymous: it is what the Dashboard uses to decide whether a person is signed in. Displays read their viewer from the descriptor instead, which already performed the authorization — so displays are descriptor-first while the Dashboard stays principal-first, and neither infers an identity by elimination. Proven end to end against real PostgreSQL and real HTTP: an unpaired screen shows a code, an owner approves it, the device opens the display descriptor and a realtime stream, and revocation closes both while the device still holds its cookie. An already-open SSE stream is bounded by realtime's existing five-minute reconnect rather than closed instantly, and that bound is documented rather than called immediate. Co-Authored-By: Claude Opus 5 <[email protected]>
48 lines
2.0 KiB
TypeScript
48 lines
2.0 KiB
TypeScript
import type {
|
|
AuthorizationScope,
|
|
EkklesiaDeviceId,
|
|
EkklesiaUserId,
|
|
PermissionId,
|
|
} from "@ekklesia/contracts";
|
|
|
|
export interface ActiveGrantQuery {
|
|
readonly userId: EkklesiaUserId;
|
|
readonly permission: PermissionId;
|
|
/** Absent means an unscoped check. An unscoped grant satisfies either an unscoped or scoped
|
|
* check for the same permission; a scoped grant satisfies only the exact matching scope and
|
|
* never satisfies an unscoped check. */
|
|
readonly scope?: AuthorizationScope;
|
|
/** The instant to evaluate expiration against — injected so evaluation is deterministic and
|
|
* testable rather than reading the wall clock inside the lookup itself. */
|
|
readonly now: Date;
|
|
}
|
|
|
|
/**
|
|
* The only read dependency `createAuthorizationEvaluator` has for grant state. Narrow and
|
|
* Postgres-independent by design: a test can supply a fake implementation, and the evaluator
|
|
* itself never knows whether it is backed by `core/src/authorization/store.ts` or a test double.
|
|
*/
|
|
export interface AuthorizationGrantPort {
|
|
hasActiveGrant(query: ActiveGrantQuery): Promise<boolean>;
|
|
}
|
|
|
|
/** The only read dependency the evaluator has for platform-owner authority — deliberately a
|
|
* separate, narrower port from grants, since owner authority is not represented as a grant. */
|
|
export interface AuthorizationPlatformOwnerPort {
|
|
isPlatformOwner(userId: EkklesiaUserId): Promise<boolean>;
|
|
}
|
|
|
|
/**
|
|
* The evaluator's only read dependency for **device** authority.
|
|
*
|
|
* Separate from `AuthorizationGrantPort` because the two answer questions about different kinds of
|
|
* subject, not because devices are a special case in the decision: `authorize` consults exactly one
|
|
* of them per call, by principal kind, and neither can be reached without going through it.
|
|
*
|
|
* There is deliberately no device counterpart to `AuthorizationPlatformOwnerPort`. A device is
|
|
* never a platform owner, so there is no port that could accidentally say it was.
|
|
*/
|
|
export interface AuthorizationDevicePort {
|
|
hasActivePermission(deviceId: EkklesiaDeviceId, permission: PermissionId): Promise<boolean>;
|
|
}
|