[REVIEW] rbac-design: add relationship authorization evidence

[mlodygbelmondo]

Skill Being Reviewed

Skill name: rbac-design
Skill path: skills/identity/rbac-design/

False Positive Analysis

Benign authorization model that can be over-reported as role explosion if relationship-based access is not recognized:

document:roadmap#viewer@user:alice
document:roadmap#editor@group:product#member
folder:planning#viewer@organization:acme#member
document:roadmap#parent@folder:planning

Why this is a false positive risk:

The skill correctly warns against role explosion and recommends ABAC for tenant, owner, and contextual decisions. But many collaborative SaaS and data-sharing systems do not fit cleanly into RBAC roles or ABAC attribute comparisons. They use relationship-based authorization: users can access resources because of direct sharing, group membership, parent-folder inheritance, organization membership, resource ownership, or delegated administration. If reviewers only see many per-resource grants, they may call it role explosion instead of recognizing a deliberate ReBAC model that needs different evidence.

Coverage Gaps

Missed variant 1: Shared-resource authorization is modeled as roles or attributes, but the real control is graph relationships

User alice can view document:roadmap if:
  alice is directly viewer on document:roadmap, OR
  alice is member of a group that is editor on document:roadmap, OR
  document:roadmap is inside a folder alice can view, OR
  alice is an organization admin for the document's organization.

Why it should be caught:

This is not merely RBAC or ABAC. It is a relationship graph with inheritance and userset rewrites. The skill should ask reviewers whether a target system needs ReBAC evidence: object types, relation definitions, allowed subject types, inheritance rules, tuple sources, consistency model, and delete/revocation propagation.

Missed variant 2: Tenant isolation is bypassed by parent or group relationships

folder:tenant-a-root#viewer@group:contractors#member
group:contractors#member@user:bob
document:tenant-b-plan#parent@folder:tenant-a-root

Why it should be caught:

Tenant isolation can fail when relationship tuples cross tenant boundaries or when a parent relation grants access to children in another tenant. The current ABAC recommendation subject.tenant_id == resource.tenant_id is useful, but a ReBAC system also needs tuple-write validation, allowed subject/object types, tenant-scoped namespaces, and invariant tests that prove relationships cannot bridge isolation boundaries.

Missed variant 3: Contextual relationships outlive the source-of-truth change

JWT claim: groups = ["finance-approvers"]
Contextual tuple: invoice:123#approver@group:finance-approvers#member
HR event: user removed from finance-approvers
Token expiry: 8 hours later
Access continues until token expiry

Why it should be caught:

Relationship engines can combine stored tuples with contextual tuples, token claims, caveats, or request-time attributes. If contextual relationship data is stale, authorization can continue after group removal, tenant transfer, or risk-state changes. Reviews should record contextual tuple source, TTL, revocation behavior, precedence over stored tuples, and cache invalidation rules.

Missed variant 4: Authorization schema changes are not versioned or tested against existing tuples

Old schema:
  document.viewer = user | group#member
New schema:
  document.viewer = user | folder#viewer
Existing tuple:
  document:roadmap#viewer@group:product#member
Migration result:
  group-based sharing silently stops working, or fallback code grants broader access.

Why it should be caught:

Relationship-based authorization has both policy/schema and tuple data. Schema migrations can orphan tuples, change inheritance semantics, or create fallback behavior. The skill should require schema versioning, tuple migration plans, backward-compatibility tests, and authorization decision replay before promoting a new model.

Edge Cases

• A user can have multiple relationship paths to the same object; evidence should show which path authorized the decision.
• Deny, caveat, or condition semantics vary between authorization engines; reviewers should not assume all ReBAC systems resolve conflicts the same way.
• Cached authorization checks can be correct under bounded staleness for read-heavy systems, but high-risk revocations need freshness or explicit invalidation evidence.
• Relationship tuples may be written by application services, admin tools, imports, sync jobs, or user sharing flows; each tuple writer needs validation and audit logging.
• Public or type-bound access such as user:* / <type>:* should be treated as a high-risk relationship, not just a broad role.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add relationship-based access control assessment to the RBAC/ABAC skill. Require reviewers to identify when ReBAC is the correct model, capture relationship schema/tuple evidence, test tenant-boundary invariants, and record contextual tuple freshness, tuple writer controls, and schema migration safety.

Comparison to Other Tools

Tool / Framework	Catches this?	Notes
NIST RBAC	Partial	Useful for roles, hierarchies, and constraints, but does not model object-to-object relationship inheritance well.
NIST SP 800-162 ABAC	Partial	Includes attributes and policy architecture; relationship-driven sharing still needs graph/tuple evidence.
Google Zanzibar model	Yes conceptually	Provides a relationship graph model for global authorization across shared resources.
OpenFGA	Partial	Implements relationship tuples, models, contextual tuples, and conditions; reviewers must still assess tenant invariants and tuple writer controls.
Cedar	Partial	Supports entity hierarchies and policy evaluation, but schema, entity hierarchy, and context freshness still need review evidence.

Overall Assessment

Strengths:

• Strong RBAC0-RBAC3 structure with hierarchy, constraints, permission boundaries, ABAC policy architecture, and role mining.
• Good guidance on role explosion, SoD, centralized PDP, and authoritative ABAC attributes.
• Useful warning that hybrid RBAC/ABAC is common and that role mining needs business validation.

Needs improvement:

• Modern collaborative systems often need ReBAC, not only RBAC plus ABAC.
• The skill lacks relationship schema evidence: object types, relations, allowed subject types, inheritance, caveats/conditions, and conflict semantics.
• The skill does not require tuple writer validation, tenant-boundary invariant tests, relationship revocation freshness, or schema migration/replay tests.
• Contextual tuples and token-derived relationships can become stale and should be assessed separately from stored relationship tuples.

Priority recommendations:

1. Add a When to use ReBAC decision branch for shared resources, nested folders/projects, organization membership, delegated admin, group membership, and user-to-resource relationships.
2. Add a Relationship Authorization Evidence table with object type, relation, allowed subject types, inheritance rule, tuple source, tuple writer, tenant boundary, caveat/condition, cache TTL, revocation path, decision log, and evidence confidence.
3. Add invariant tests for tenant isolation, public/type-bound relationships, parent-child inheritance, group membership revocation, and multi-path authorization.
4. Add schema/version migration guidance: model versioning, tuple migration, compatibility checks, decision replay, rollback plan, and orphaned-tuple detection.

Sources Checked

• NIST SP 800-162 ABAC definition and considerations: https://csrc.nist.gov/pubs/sp/800/162/upd2/final
• Google Zanzibar paper: https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/
• OpenFGA concepts and relationship tuples: https://openfga.dev/docs/concepts
• OpenFGA contextual tuples: https://openfga.dev/docs/interacting/contextual-tuples
• OpenFGA modeling ABAC with contextual and conditional relationships: https://openfga.dev/docs/best-practices/modeling-abac
• Cedar entity hierarchy documentation: https://docs.cedarpolicy.com/policies/syntax-entity.html

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: to be provided privately after acceptance

[JamesJi79]

Review: rbac-design — Add Relationship Authorization Evidence (#194)

Skill: skills/identity/rbac-design/SKILL.md
Proposed commit: 7a3a44a ("Improve RBAC tenant and ReBAC guidance")
Base: f4f3374 (current HEAD on main)
Reviewer: Hermes Agent
Date: 2026-06-03

---

Summary

This PR adds relationship-based access control (ReBAC) evidence to the RBAC design skill. ReBAC — where access is derived from relationship tuples (e.g., user -> group -> folder -> document) rather than roles or attributes alone — is a significant blind spot in the current skill, which only covers RBAC0-3, ABAC, and runtime assurance. The proposed changes fill that gap with a dedicated Step 6 (ReBAC / Tuple Graph Design), 7 finding codes (RBAC-REBAC-01 through -07), and supporting infrastructure.

Overall verdict: APPROVED with minor corrections. The content is high-quality, well-structured, and addresses a real coverage gap. The issues below are blocking only if they would ship incorrect metadata or lose valuable content.

---

What the PR Adds

Step 0: Classify the Authorization Model Before Scoring

A new preliminary step that forces the reviewer to classify each system as workforce RBAC, tenant/customer RBAC, emergency/break-glass, service/workload identity, ABAC, ReBAC/tuple graph, or hybrid before applying role-health metrics. This prevents false positives where tenant-scoped or emergency roles are flagged for high role counts or single-user assignments.

Step 6: ReBAC / Tuple Graph Design

A new step covering:

• Relation definitions — subject/object typing and scoped inheritance
• Tuple write authorization — who can create/update/delete tuples
• Tenant-boundary invariants — preventing cross-tenant inheritance
• Traversal limits — depth, cycle handling, expansion bounds
• Lifecycle cleanup — tuple invalidation on offboarding, moves, deletions
• Model tests — positive and negative path testing

New Finding Codes

Code	Description
RBAC-ASSESS-09	Tenant roles reviewed with workforce metrics
RBAC-ASSESS-10	Service/workload identities evaluated as humans
RBAC-ABAC-07	Clarified "documented combining algorithm"
RBAC-ABAC-09	Deny/forbid must precede broad permit
RBAC-ABAC-10	Attribute freshness/cache/revocation latency
RBAC-ABAC-11	Negative tests for stale attributes/offboarding
RBAC-REBAC-01..07	Full ReBAC finding set

Test File

tests/tenant-rebac-edge-cases.md — 5 test cases covering tenant-scoped roles, break-glass activation, cross-tenant inheritance, permit/deny conflict semantics, and stale attribute/offboarding paths.

---

Issues Found

1. FRAMEWORKS field does not include ReBAC references

The frontmatter frameworks: [NIST-RBAC, NIST-SP-800-162] is not updated to include Zanzibar or OpenFGA, even though the References section now lists them and the skill now covers ReBAC.

Fix: Add frameworks reference, e.g., frameworks: [NIST-RBAC, NIST-SP-800-162, Zanzibar-ReBAC, OpenFGA]

2. Frontmatter allowed-tools may be too restrictive

allowed-tools: Read, Grep, Glob — The skill prescribes producing findings tables, summary reports, and remediation roadmaps, but cannot write any output file without Write access.

Fix: Consider adding Write to allowed-tools since the Output Format section expects report generation.

3. Version history update is correct but version field is odd

The version: field in the frontmatter stays at "1.0.0" in the original and should be bumped. The version history table correctly records "1.0.1" — but the frontmatter version field needs to match.

Fix: Update the version field to "1.0.1" to match the version history table entry.

4. Release date inconsistency

The version history entry says 2026-06-02 but the current HEAD commit f4f3374 is dated from the initial repo structure. Ensure the date matches the PR merge date or uses a consistent convention.

Suggestion: Use the PR merge date or YYYY-MM-DD convention with TBD if not yet merged.

---

Recommendations

1. Strong addition — keep Step 0

The model classification step is the most valuable addition. It prevents the skill from generating false positives on tenant-scoped roles, emergency access, and workload identities — a real problem in multi-tenant cloud environments. This should be retained.

2. ReBAC content quality is high

The ReBAC checks correctly identify the key failure modes: cross-tenant inheritance, tuple write authorization bypass, unbounded traversal, and lifecycle cleanup. The test cases (especially #3: cross-tenant parent inheritance) are excellent concrete examples.

3. ABAC-07 clarification is good

Changing "without resolution order" to "without documented combining algorithm" is a meaningful precision improvement — it recognizes that different engines use different combining strategies (first-applicable, deny-overrides, permit-overrides) and the important thing is that the algorithm is documented and tested.

4. Consider combining with runtime assurance

There is an orthogonal commit (d588751 on another branch) that adds Step 5A (Authorization Decision Assurance) with runtime evidence for PDP outages, cache freshness, revocation, and migration testing. The proposed PR removes that content. Ideally, both should coexist: Step 0 for classification, Step 5A for runtime assurance (PDP coverage, fail-closed, cache TTL, decision logging, migration diff tests), and Step 6 for ReBAC checks. They address different failure modes and neither subsumes the other.

---

Coverage Gap Assessment

Area	Coverage Before	Coverage After	Verdict
Core RBAC (RBAC0)	Full	Full	OK
Hierarchical RBAC (RBAC1)	Full	Full	OK
Constrained RBAC (RBAC2)	Full	Full	OK
Symmetric RBAC (RBAC3)	Full	Full	OK
ABAC (NIST SP 800-162)	Good	Improved (09-11)	OK
Permission boundaries	Good	Good	OK
Role mining	Good	Good	OK
Relationship/ReBAC	None	Full	Gap closed
Model classification	None	Full	Gap closed
Workload identity	None	Partial (ASSESS-10)	OK for now
Runtime assurance	None	None*	Gap remains
PDP fail-closed testing	None	None	Gap remains

*Runtime assurance was added in an orthogonal commit (d588751) on a different branch. Consider merging both.

---

Final Assessment

Bounty tier: Moderate ($100) — New coverage area (ReBAC) with evidence, test cases, and documentation.

Verdict: APPROVED with minor corrections (framework metadata needs updating). The ReBAC content fills a genuine gap, the model classification step prevents false positives, and the test fixtures are concrete and actionable. The PR would benefit from also incorporating the orthogonal runtime assurance work to avoid losing that content, but the ReBAC additions themselves are well-executed.

Action items before merge:

1. Add ReBAC references to the frontmatter frameworks field
2. Bump the frontmatter version to match the version history
3. Evaluate whether to also merge the runtime assurance gates from d588751 to avoid regression

[modelsbridgeaicom-ship-it]

Submitted implementation PR: #960

Bounty requested: Improver moderate / if accepted.

Summary:

• Added Step 0 authorization model classification for workforce RBAC, tenant/customer RBAC, workload identities, break-glass access, ABAC, ReBAC, and hybrid models.
• Added ReBAC / tuple graph evidence gates for relation definitions, tuples, tuple write authorization, tenant-boundary invariants, traversal limits, consistency/staleness, lifecycle cleanup, model tests, and decision logging.
• Added RBAC-REBAC-01 through RBAC-REBAC-09 plus ReBAC test matrix and output fields.
• Tightened ABAC conflict/deny precedence and attribute freshness evidence.
• Refreshed the stale NIST SP 800-162 reference URL.

Validation performed:

• git diff --check
• required-string assertions
• markdown fence balance check
• official NIST/Zanzibar/OpenFGA source URLs returned HTTP 200