ABAC vs. RBAC

Role-based access control, or RBAC, assigns permissions through roles. Attribute-based access control, or ABAC, evaluates facts about the subject, resource, operation, and relevant context. Relationship-based access control, or ReBAC, uses relationships between actors and objects, such as membership or ownership.

These approaches can be combined. The choice depends on the access conditions you need to express. NIST's RBAC reference and ABAC guide establish the core role and attribute concepts.

Explore Dome: Authorization · Docs: Authorization model.

Match the model to the restriction

Suppose a support organization has three requirements: support staff can view the queue, on-call leads can close incidents for their team, and collaborators can read a particular case.

AuthZed's ReBAC explanation describes relationships as an authorization model. Implementations differ in how they store and evaluate those relationships.

For the on-call lead, the role identifies what they can do, while team attributes limit which incidents they can close. Some systems also express relationships through trusted attributes. In each case, check how membership and ownership stay up to date.

If every new customer or project requires a new role, it may be worth representing membership or ownership directly. If a role assignment already expresses the requirement clearly, adding more attributes may make the system harder to maintain.

Explore Dome: Authorization · Docs: Author rules.

Know where each fact comes from

To authorize incident closure, the system needs the person's verified role and team, plus the incident's owning team and current state. An outdated team assignment can lead to the wrong decision even when the policy is correct.

Review who can change each fact. Does a role come from an identity directory? Does incident ownership come from the ticket service? Could the agent supply an unverified value that the policy mistakes for a trusted fact?

Decide what happens when information is missing. A missing team claim should not accidentally count as a match. When someone's team changes, specify how soon access decisions must reflect that change.

For relationship-based access, ask who can add a collaborator, how quickly removal takes effect, and whether access through inherited membership is intended.

Explore Dome: Access · Docs: Govern per end user.

Test the conditions separately

For incident closure, change one fact at a time:

• A lead from the correct team attempts closure.
• A lead from another team attempts the same operation.
• A non-lead from the correct team attempts it.
• The role is present but the team fact is missing.
• The incident changes state between selection and execution.

These cases show whether the policy expresses the intended restriction. They also reveal which checks must remain in the backend because they depend on current business state.

Dome's rules can evaluate supported identity, resource, and request attributes. That does not imply a general relationship-graph service or automatic verification of arbitrary request fields. Choose the smallest model that expresses the needed restriction, then use policy testing and simulation to examine it. The agent authorization entry explains which facts an action decision requires.

Explore Dome: Authorization · Docs: Simulate rules.