Skip to main content

Access Paths

When you call the evaluate endpoint, Vengtoo checks access through multiple paths. If any path grants access (and no DENY policy blocks it), the request is allowed.

The three paths​

1. Direct access​

A policy is assigned directly to the subject.

Subject → Policy → Resource

Use this for one-off grants or exceptions. Example: Give contractor Frank read-only access to a specific report.

2. Role-based access (RBAC)​

The subject has a role, and the role has policies.

Subject → Role → Policy → Resource

Use this for standard permission patterns. Example: All editors can read and write documents.

3. Group-based access​

The subject belongs to a group (directly, or via nested group hierarchy), and the group has policies or roles attached.

Subject → Group (→ parent Group...) → Policy → Resource

Use this for org-structure-shaped permissions. Example: Everyone in the engineering group inherits access granted to that group, including through any parent groups it belongs to.

Attribute-based conditions (ABAC), not a fourth path​

ABAC conditions are not a separate path: they're a gate you can attach to a policy on any of the three paths above (direct, role, or group). A policy with conditions only grants access when its path matches and its conditions pass; it doesn't introduce a new way to be granted access. Example: a role-based policy for editors that additionally requires resource.department == subject.department is still evaluated via the role path: access_path reports "role", not a separate ABAC value.

See ABAC Conditions for full syntax.

Delegation: a different axis​

The three paths above decide how a subject is granted access. Delegation decides whose access is evaluated in the first place.

When a request carries a delegation, the caller (the actor) is not the identity whose permissions are checked. Vengtoo evaluates the principal's access (through the same three paths, direct, role, or group) and applies the result to the actor, narrowed by the delegation scope. The actor's own policies are not consulted while the delegation is active.

So delegation is not a fourth value of access_path; it sits orthogonal to the three. A delegated request still reports direct, role, or group (the path by which the principal holds the access being borrowed) and additionally carries the delegation chain that authorized it. See Delegated authority for the model, chains, and revocation.

DENY policies and access paths​

DENY policies work through the same three paths: a DENY can be assigned directly to a subject, via a role, or via a group, optionally gated by ABAC conditions same as ALLOW policies.

DENY does not automatically win

A DENY blocks access only when its priority is equal to or higher than any matching ALLOW, meaning a high-priority ALLOW can override a low-priority DENY.

Evaluation order​

  1. Vengtoo collects all applicable policies from all paths.
  2. If a DENY policy matches and has equal or higher priority than any matching ALLOW → access is denied.
  3. If any ALLOW policy matches → access is allowed.
  4. If no policy matches → access is denied (default deny).

When multiple ALLOW policies match, the one with the highest priority is reported in the response.

The three paths resolve into a single decision like this:

Access path in the response​

The evaluate response includes which path was used:

{
  "decision": true,
  "context": {
    "reason": "Policy 'editors-can-read-write' grants access",
    "policy_id": "pol-789",
    "access_path": "role"
  }
}

Possible values for context.access_path:

ValueMeaning
"direct"Access granted via a policy assigned directly to the subject
"role"Access granted via a role the subject holds
"group"Access granted via a group the subject belongs to (directly or via a parent group)
"none"No ALLOW policy matched, or a DENY overrode the match: decision is false

Combining paths​

A subject can have access through multiple paths simultaneously. Vengtoo evaluates all paths and the highest-priority match wins.

Example: Frank has the viewer role (read-only on all documents via RBAC) and a direct policy granting write on one specific document.

  • (Frank, read, any document) → allowed via role path
  • (Frank, write, doc-123) → allowed via direct path
  • (Frank, write, doc-456) → denied: no matching ALLOW for write on that document

The access_path field in the response tells you which path produced the decision.

  • Policies: Policy structure, assignment, and conditions.
  • ABAC Conditions: Condition syntax for attribute-based access.
  • Decisions: What happens after evaluation.
Last updated on