RBAC, ABAC, or ReBAC: Which Access Model to Use

Gateco supports three access-control models, and the most common mistake is treating them as competitors. They describe different shapes of access, and a real policy set usually uses more than one. Here is which model fits which pattern, and the templates that implement each.

RBAC: access by role or group

Role-based access control grants access by who someone is on the org chart: their role or group membership. In Gateco this reads principal.roles or principal.groups, populated from your identity provider. It is the right default when access maps cleanly to teams: engineering can read the engineering space, finance can read finance, and the templates group_rbac and department_access cover most of it. RBAC starts to strain when access does not follow the org chart, when two people in the same group need different access, or when access depends on the document rather than the person.

ABAC: access by attribute and classification

Attribute-based access control decides against attributes of the resource and the principal rather than role alone. The most useful form is a classification ceiling: a principal cannot retrieve a chunk classified above their clearance, regardless of group. ABAC reads resource.classification, resource.sensitivity, and principal.attributes.department, and is implemented by templates like classification_ceiling, label_access, and deny_sensitive. Reach for it when access follows the sensitivity of the data instead of job title, which is most regulated data.

ReBAC: access by direct relationship

Relationship-based access control grants access through a direct relationship between a principal and a specific resource: this user is the owner_of that record, or a member_of that project. In Gateco a ReBAC condition reads relation.owner_of and is checked against a stored one-hop relationship at retrieval time. Relationship lookups are cached briefly and invalidated immediately when a relationship changes, so a revoked relationship stops granting access on the next query. ReBAC is available on the Team plan and up, and it is the answer for the long tail of per-object access that neither roles nor attributes capture cleanly.

How to choose

A quick decision guide. If access maps to teams and roles, start with RBAC. If access follows the sensitivity or classification of the data, use ABAC. If access is about a specific principal's relationship to a specific object, ownership, assignment, membership of record, use ReBAC. Most organizations run RBAC and ABAC together, group rules for the broad strokes and a classification ceiling underneath, and add ReBAC for the per-record cases.

Combining models, and how deny works

Because you will mix them, precedence matters. Deny wins over allow. One sharp edge: if a deny policy's selectors match a request but none of its rules match, the policy's default deny still fires. To deny only specific conditions, add a catch-all allow rule at the lowest priority. The Access Simulator lets you dry-run a principal against a search and see exactly which policy decided, before you activate anything, which is the cheapest way to catch a precedence surprise.

Start from a template, validate it in the simulator, then activate. The template catalog and the simulator both live in the product; the features page lists what each plan includes.