# Relationship-based access control: relationships, rules, and enforcement > Learn how ReBAC derives permissions from relationships, with a document-sharing example and practical guidance for inheritance, enforcement, and testing. Canonical URL: https://www.devobs.io/articles/relationship-based-access-control/ By: Jonah Reed Published: 2026-10-06T11:35:13.465Z Updated: 2026-10-06T11:35:13.465Z Section: Authorization Relationship-based access control (ReBAC) determines whether a subject may act on a resource by applying permission rules to relationships among users, groups, and resources. Rather than relying only on a broad role such as “editor,” it evaluates which relationships grant a particular permission on a particular object. Ory’s Keto documentation illustrates this approach with “User:x is in readers of Document:y” and documents permission inheritance through groups, roles, and hierarchies. [Ory Keto documentation](https://www.ory.com/docs/network/keto) The important distinction is that a relationship supplies a fact; a permission rule decides what that fact allows. ## Separate relationship facts from permission rules Consider a hypothetical document-sharing application. Its relationship data might say: - Alice is an editor of the design document. - Bob is a viewer of the design document. Those facts do not, by themselves, define every action Alice or Bob may perform. The application also needs rules mapping relationships to permissions. The documented Ory Permission Language example makes this separation explicit. A `Document` declares `editors` and `viewers` relationships, then defines `write` and `read` permissions using those relationships. Ory defines OPL as a configuration language that is a subset of TypeScript. [Ory Keto documentation](https://www.ory.com/docs/network/keto) This separation gives engineers two things to review independently: 1. **Relationship data:** Who is connected to which resource, and how? 2. **Permission policy:** Which of those connections authorize the requested action? An editor relationship on one document should not be confused with a global editor role. In this example, the rule evaluates the requesting subject against the relationships of the particular document. ## Work through a document-sharing model Ory’s example defines two rules: document editors can write; anyone who can write, or who belongs to the document’s viewers, can read. Expressed as language-neutral pseudocode, rather than executable OPL, the model is: ```text can_write(subject, document) = subject is in document.editors can_read(subject, document) = can_write(subject, document) OR subject is in document.viewers ``` These rules reproduce the permission logic in the [documented OPL example](https://www.ory.com/docs/network/keto). For a particular document, the resulting decisions are: | Subject’s relationships to the document | Read | Write | | --- | --- | --- | | Editor only | Allow | Allow | | Viewer only | Allow | Deny | | Both editor and viewer | Allow | Allow | | Neither | Deny | Deny | The table follows from these two rules alone; it is not a report of implementation testing. It does not assume an administrator override, public sharing, ownership privileges, or inherited access. Notice why an editor can read: the `read` rule explicitly invokes the `write` rule. “Write implies read” is a policy choice in this example, not an assumption to carry into every ReBAC model. Likewise, adding an `owner` relationship to this example would not change its read or write decisions unless the rules used that relationship. ## Make inherited access explicit Direct document sharing is only one use of relationship modeling. Ory also documents permission inheritance through groups, roles, and hierarchies. Role-based and relationship-based modeling therefore need not be competing choices: a role or group can participate in a relationship-based permission model. [Ory Keto documentation](https://www.ory.com/docs/network/keto) For an illustrative team-sharing design, suppose: ```text Alice is a member of the Platform team. The Platform team is a reader team for the design document. ``` The application could define a rule allowing document reads by members of its reader teams. These relationship names and this rule are illustrative, not a ready-to-deploy Keto configuration. The critical step is defining that inheritance rule. Merely connecting a user, team, and document does not mean every connection should authorize access. Specify which relationship paths count for each permission. Also consider overlapping grants. If Alice can read through both team membership and a direct viewer relationship, removing her team membership leaves the direct viewer grant intact under a rule that accepts either path. For reviews and tests, ask not just “Was this relationship removed?” but “Does another permitted path remain?” This is a consequence of the illustrative policy, not a guarantee about how quickly a deployed system observes relationship changes. ## Keep identity and resource authorization distinct A useful architecture separates identifying the requester from deciding what that requester may do to a particular resource. Ory’s documentation describes separate Ory Network services for these responsibilities: - **Identities, built on Kratos:** Identity and user management, including self-service login and registration. [Kratos documentation](https://www.ory.com/docs/network/kratos/intro) - **OAuth2 and OpenID Connect, built on Hydra:** OAuth 2.0 and OpenID Connect capabilities through a headless API that does not require a particular user-management system. [Hydra documentation](https://www.ory.com/docs/network/hydra) - **Permissions, based on Keto:** Fine-grained permissions, relationship-based rules, and permission inheritance. [Keto documentation](https://www.ory.com/docs/network/keto) For the document example, keep the resource-level question explicit: “May this subject write this document?” Do not substitute “The requester signed in” for that permission decision. ## Design enforcement and relationship changes together Ory documents using Keto to centralize authorization logic in one service. Treat that as a place to evaluate permission rules, not as a substitute for reviewing application enforcement. [Ory Keto documentation](https://www.ory.com/docs/network/keto) For an implementation review, use these recommendations: - **Check the specific action and resource.** A read decision should not stand in for a write decision, and permission on one document should not stand in for permission on another. - **Protect relationship mutations.** Define who may add editors, share documents, or change group membership. The example’s `read` and `write` rules do not specify who may perform those operations; do not silently equate writing document content with changing its access rules. - **Define failure handling.** Decide how protected operations behave when a permission check cannot complete; do not silently convert uncertainty into permission. - **Verify operational behavior separately.** Establish revocation timing, cache behavior, and consistency requirements for the chosen implementation rather than inferring them from the ReBAC model. These are application-design recommendations, not guarantees supplied by choosing a relationship-based permissions service. ## Test allowed paths and missing paths Start with the four direct-sharing cases above. Then extend tests to the inheritance and boundary rules your application actually defines: - A team member receives the intended inherited permission. - A nonmember does not receive that permission through the team. - Once a membership removal is visible to the permission evaluator, that membership no longer supplies an access path; any remaining direct grant is evaluated separately. - A subject related to one document does not gain access to an unrelated document. - For a multi-tenant application, tenant isolation holds except where the policy deliberately permits cross-tenant access. - Unauthorized attempts to create or delete relationships are rejected by the application’s relationship-management interface. Test relationship-change visibility and revocation timing separately from these policy cases. The central engineering habit is to keep relationship facts, permission rules, and enforcement visible as separate concerns. Define which paths grant access, test overlapping and missing paths, and ensure protected operations enforce the resulting decisions. ## Source references - - -