Attribute-based authorization

Let an organization decide who may see and do what in which part of its inventory. Today every member holds one of four fixed roles (owner, admin, member, viewer), and each context checks a hard-coded list of them. That cannot express common arrangements: a network team that edits switches but not power, facilities staff who place hardware at one site, or a contractor who may only see and operate a few hosts for two weeks.

This RFD replaces the role lists with one model. A role is a named combination of permissions. Attributes of the person decide which roles they hold, and attributes of the resource decide where each role applies. RFDs 12, 13, and 14 already need scoped grants that can expire, and RFDs 15 and 16 grant access from an identity provider; all of them become instances of this model instead of separate grant tables.

Authorization stays where it is today: in context functions, inside the transaction that performs the change. Hiding a control in the UI remains a hint, never the boundary.

A permission names one kind of action, such as inventory.edit or topology.edit. The catalogue is defined in code, not by organizations, and every public context function that changes data declares and checks one or more permissions or is an explicit system path.

The first release derives the catalogue from today’s checks:

A setting controlled or locked by the deployment stays read-only even for holders of organization.manage. No organization permission can change deployment configuration or secrets.

Relationship checks such as "only the person who made a request may withdraw it" and "a personal view belongs to its owner" stay in context code; they are not permissions.

RFDs 12, 13, and 14 add queries.run, queries.run_sensitive, terminal.open, vm.power, and vm.approve when they are implemented. Those are explicit permissions: no built-in role includes them and nobody holds them by default, including owners. Their grant and disclosure contracts are:

This deliberately replaces RFD 12's owner/admin and member-query role checks with permissions while preserving its sensitivity split. It preserves RFD 13's 30-day terminal limit, owner/admin-only replay restriction and replay audit, and RFD 14's expiring grants and distinct second operator. Replay is a hard eligibility rule, not a delegable permission. A deployment or organization may set a shorter maximum, never a longer one. Explicit permissions are kept in roles that contain no non-explicit permissions, so a routine role never quietly acquires operational access.

A role is a named set of permissions within an organization.

The four built-in roles keep today’s behavior exactly and cannot be edited:

The fifth built-in role, support, is viewer’s permissions for a deployment’s support identities (RFD 22). Nobody assigns it: Renga grants it to every support identity while the organization’s Allow support access setting (RFD 19) is on and removes it when the setting goes off, and `members.manage can neither grant nor revoke it. A support identity can hold no other role and no explicit permission, and the role itself cannot be edited or carry a condition. It is listed here so that the members list, Activity, and the grant ceilings below account for it.

members.manage and roles.manage are new; Renga has no member management UI today. Permission to administer a grant is separate from permission to perform the granted action, so an owner or admin can still assign the built-in member role without gaining requests.create. The grant ceilings and explicit permission bootstrap rules are in Administration.

Owners and admins can define custom roles from any non-explicit permissions, for example a network engineer role with inventory.reconcile, findings.act, ipam.edit, and topology.edit. Explicit permissions live in their own roles as described above.

An assignment gives one role to a subject, optionally limited by a condition and an expiry:

Authority selection happens before assignments are combined. An independently created manual membership is authoritative for that person and organization, even when it has no base role, and suppresses every claim- or SCIM-derived assignment. An individually issued supplemental manual assignment, such as a terminal grant to an externally governed member, does not change membership authority and remains additive.

External sources continue reconciling their candidate assignments while a manual membership suppresses them. Removing the manual membership activates only candidates that are valid at that moment; it never resurrects one the provider expired or SCIM revoked while it was suppressed.

Each eligible membership keeps one base role, as today, which acts as an assignment without a condition. It may instead have no base role, so that it holds only what its other eligible assignments grant (see Reads). Further eligible assignments add access; the result is their union. There are no deny rules, so the answer to "why can this person do this" is always a list of eligible assignments. An external source never changes or removes a manual assignment, and an externally sourced assignment becomes ineligible when its source no longer grants it.

Teams gain members. A team is already the owner of resources (RFD 8); adding people to it lets one assignment say "people on a team may operate what their team owns". Team membership is managed with teams.manage. RFD 16 SCIM groups are assignment subjects and never silently add people to Renga teams.

A condition is a set of clauses over resource attributes. A resource matches when it satisfies every clause, and a clause is satisfied by any of its values:

This reads as "servers and switches at this site that are owned by one of the person’s teams", and the UI renders it that way.

The first release supports these attributes:

The API rejects unknown condition attributes, operators, resource kinds, and IDs from another organization. It never accepts an inert policy that only appears to grant access.

Conditions are deliberately a small structured language rather than a general policy language such as Cedar or Rego. Lists, search, and bulk actions must find what a person may act on in the database, so every condition compiles to an SQL predicate over indexed columns. A richer language would either leak into per-row checks in Elixir or need its own partial evaluator.

Every capability declares how the server derives its complete authorization target set. A permission is checked against every resource in that set; a caller-supplied association or presentation resource_id never selects or narrows the boundary. Placement, cables, and other actions that involve several resources must be covered for each of them. An action whose target is organization-wide, such as defining a catalog type, a VRF, a site, a team, or a triage rule, requires the permission from an assignment without a condition. Source- or agent-wide actions, unmatched observations, and reconciliation that may create a resource also require an unconditioned permission unless the capability can derive every affected resource before it changes data. Resource creation authorizes its server-derived parent or container first and the complete resulting target set before commit.

Conditions never read agent-reported data such as resource labels. An organization configures its agents but does not fully control them, and anyone holding its intake key can report any label. Boundaries that cut across sites and teams, such as environment, customer, or compliance scope, are left to RFD 18’s resource groups.

inventory.read is a permission like any other, and conditions limit it. A person sees a resource only when one of their assignments grants inventory.read with a condition the resource matches. Every built-in role includes it, so a member whose base role is built-in still reads the whole organization, as today. A contractor can instead be a member with no base role and a viewer assignment for servers at one site, and sees nothing else.

Resource visibility and payload disclosure are separate decisions:

Human mutations require inventory.read over every target in addition to their action permissions. Renga does not support blind writes, so a successful mutation may return the ordinary resource representation without becoming a read side channel. Internal machine paths return only the payload their fixed principal needs.

Every read path applies the same rule in its query:

Losing read access takes effect like any other assignment change: connected LiveViews refresh their scope and stop showing the resource, and an open page for it returns to the list.

Machine scopes are not read-filtered; agents and reconcilers see what their organization-scoped work needs.

Renga.Authorization becomes the only place that answers authorization:

Renga keeps one access row per resource with the attributes conditions read: its kind, owner team and whether a person set it, and current and confirmed site. The transaction that changes placement or ownership updates that row too. Inherited containers, mixed-resource records and redacted aggregates still use query-specific joins or projections; the access row does not make an opaque payload safe to disclose.

Every public context function that reads organization data declares the permission it filters by. A test enumerates the contexts' public functions and fails on any that declare none, and a scoped-member suite checks each list, fetch, search, count, and export with a member who can see one site.

The scope carries the person’s resolved assignments and the organization’s authorization version, loaded once per request or LiveView mount. Every change to a role definition, membership status or base role, assignment, team membership, external source validity, resource ownership or placement, or relevant container hierarchy increments that version and broadcasts on the organization’s authorization topic. Connected LiveViews refresh before protected data delivery or events when the version changes. They also check the earliest assignment or provider deadline before delivery; a timer is only a wake-up mechanism, never enforcement. The transaction check, current version, and current deadlines, not the cached scope, are authoritative.

Every authorization-changing transaction locks the organization’s authorization-version row before its dependencies. Protected mutations take the same lock before authorization. Role, membership, assignment, team and source changes therefore serialize with decisions they can affect. A resource access-row change locks that row and evaluates the old and new target under the same transaction, so neither a stale policy nor stale placement can authorize a commit.

Machine scopes are unchanged in shape: agents, the reconcilers, and triage rule application run as fixed internal principals with fixed permission sets, which cannot be assigned to people.

Some requirements stay outside the policy model as hard guards, checked after a permission is granted: an active organization, deployment entitlements and locks, organization enablement such as allowed job capabilities, agent-local policy, step-up authentication (RFD 13), second-operator approval (RFD 14), and query result classification (RFD 12). The operation table defines the additional permissions for approval and sensitive disclosure. Policy can only narrow who reaches these guards; no assignment bypasses them.

An access view answers both directions: on a member’s page, what they can do and through which assignments; on a resource page, who holds each permission over it. A refused action names the missing permission, not just "forbidden".

Implementation checklist