Identity and Access

Identity and Access Management — start here. The identity lifecycle, authentication against authorisation, and the vocabulary the rest of the cluster uses. The authentication and authorisation distinction is worth slowing down on: almost every access bug is one being mistaken for the other.

Registration and Onboarding Defaults — the three questions a registration answers, the tenant a new account lands in, the party it joins and the role it receives, and who may change each. Read it before the role model below, because a default role is the first role an account ever holds.

The entry journeys — the interaction that carries the policy out: the layers, the order in which a sign-in is refused, the branch a registration takes, and the code each refusal carries. It lives with the journey documents and reads with the page above, because one decides and the other carries it out.

Role-Based Access Control — roles compose permissions, users are assigned roles. Read second, because it is the concrete model the abstract vocabulary above resolves to, and it is what the application layer actually consults.

Session modes and capabilities — how that model reaches the client: the mode a session runs in is computed by the server and delivered with the session, and the menu's authority is the permission codes the session holds. Read it with the role model above, because it is that model applied to the question "what may this person see".

Book Access and Permissions — the same model applied to the entity where it matters most. Useful as the worked example: the allowed-currency set that constrains what may be booked shows permissions doing real domain work rather than guarding a screen.

Authorised reads — how a read decides whether to answer: every read checks its read permission unless the page's allow-list names it with a reason. It also says which of the tree's two permission checks a read uses, why a self read and a privileged read are different subjects rather than one subject with a parameter, and where a refusal travels. Read it before adding a read, and especially before changing one that answers about somebody else's access.

The mechanisms are established patterns, and the identity group of the pattern language holds them: Access Token, Client Credentials, Token Relay, Token Exchange, Grant Management, and the composite Scheduled Work Acting as a Tenant. Each pattern page states its failure handling, its pitfalls and its sources. The pages below decide between them and record how ORE Studio uses them.

Service-to-Service Auth Patterns — the decision guide: which identity pattern a call needs, with the questions that decide it and the table of which layer acts as whom.

Internal Actor Impersonation — Token Exchange in its in-process form inside IAM, used by tenant provisioning to act as several parties in turn. Read it for the worked example and for the expiry failure it met.

Run grants and run tokens — IAM's implementation of Scheduled Work Acting as a Tenant: the run grant entity, the exchange and its checks, the run token's claims and the cache rules. Read it before building any work that a schedule starts in a tenant.

Report execution at scale — the first component to use run grants: the role, the audience and the moments reporting grants and revokes.

PostgreSQL Row-Level Security — the database mechanism, described before any project-specific use of it. Deliberately last: it is the backstop, and it is easier to see why the backstop is shaped as it is once the application-level model above is clear. An agent changing a query that crosses a tenant boundary should have read this page first.

User Journeys — everything above says what the system enforces. This one records what a person is trying to do, written from the goal rather than from the entity. Read it when the question is "what should this screen do" rather than "what does this entity hold". Each journey document also lists the operations and subjects its steps need, so the distance between the design and the server shows up as a table rather than as a surprise during the build.