Control objective
Relationship-based access control derives permission from typed relationships in a graph. Examples include user is a member of team, team owns repository, folder contains document, or organization administers project. Policy defines which relationship paths grant each action.
Graph model
Give subjects and resources stable types and identifiers. Define relationship names, who can create or remove each edge, inheritance, traversal limits, and the permission derived from each path. Keep group membership and resource ownership distinct even when both form edges.
Decision and consistency
The decision asks whether a permitted relationship path exists for the subject, resource, and action. Distributed graphs need a consistency and freshness model. A recent grant can require stronger read consistency than an ordinary view. A revocation needs a measured propagation bound.
Failure and residual risk
Unexpected inheritance can grant broad access. Cycles and deep traversal can make behavior hard to review. Stale edges preserve authority. A user who can edit ownership or membership can indirectly grant permission. The graph can also omit application state needed for the final action.
Pomerium boundary
Pomerium can use external context in route policy, but it is not the owner of an application's resource relationship graph. Applications should evaluate object and action permission near the graph and can use Pomerium's verified identity as the subject input.
Evaluation checklist
- Are subject, resource, relationship, and permission types explicit?
- Who can create or remove each authority-bearing edge?
- Which traversal paths and inheritance rules grant the action?
- What consistency and revocation bound does the decision need?
- Can the application explain the path that produced an allow?
