Role-Based Access Control Contract Design

Wrote docs/architecture/tasks/banking-rbac-001/rbac-design/rbac-permission-matrix.md. Complete Role-Based Access Control permission matrix establishing atomic action scopes, role inheritance DAG, Static Separation of Duties constraints, and default-deny evaluation rules.

---

skill: rbac-design

Role-Based Access Control Permission Matrix: Core Treasury Administration [RBAC-BANK-001]

Summary

This specification establishes the authoritative Role-Based Access Control (RBAC) permission matrix, role inheritance Directed Acyclic Graph (DAG), and Static Separation of Duties (SSD) architecture for banking-admin-console v2.4 under run ID banking-rbac-001. It governs 850 back-office operators and treasury managers executing 45 discrete operations across Core Treasury Services at 2,200 authorization queries/second. It decisively eliminates the toxic privilege combinations demonstrated in fraud incident FRAUD-3810 (where an omnibus operator role allowed an insider to both initiate and self-approve an unauthorized $1.8M wire transfer). The contract establishes atomic action permissions on explicit object classes, enforces an acyclic role hierarchy, mandates a strict

Static Separation of Duties (SSD) rule prohibiting the simultaneous assignment of Wire Initiator and Wire Approver roles to any principal, enforces runtime maker-checker dual-custody invariants, and guarantees sub-2.0ms in-memory policy decision point (PDP) evaluation.

Detailed Description

Coarse administrative roles (such as generic "Admin", "Manager", or UI-screen-based roles) inevitably accumulate toxic permission combinations over time, violating least privilege. In financial treasury systems, conflating payment initiation with approval authority allows rogue operators to execute single-handed fraud without oversight. A formal RBAC model decomposes user duties into atomic functional roles governed by mutual exclusion rules, separating assignment eligibility from runtime activation.

Incoming Operator Request: POST /v1/wires/WR-99210/approve
                           │
                           ▼
[ RBAC Ingress Interceptor: PDP Policy Engine ]
  ├── 1. Extracts Subject Roles: ["SettlementOperator", "TreasuryReviewer"]
  ├── 2. Separation of Duties Check: Asserts NO SSD Conflict
  │      (Violates: `SSD_CONFLICT_INITIATOR_APPROVER`? -> Blocked)
  ├── 3. Graph Traversal: Resolves Effective Permissions via Role DAG
  └── 4. Evaluates Target Action: `treasury:wire:approve`
                           │
       ┌───────────────────┴───────────────────┐
       ▼ (Permission Granted & Valid Maker-Checker) ▼ (Missing Permission / SSD Clash)
HTTP 200 OK: Execute Wire Approval             HTTP 403 Forbidden: `ERR_RBAC_UNAUTHORIZED`
Log Structured Audit Trail Event                Emit High-Severity Fraud Prevention Alarm

Criteria and weights

Comparison

Result

Option C is selected. A formal role hierarchy DAG eliminates screen-level role sprawl, Static Separation of Duties (SSD) blocks maker-checker toxic role combinations at assignment time, and in-memory bitmap evaluation satisfies the sub-2.0ms p99 latency SLA.

---

Required Mechanisms

1. Asset And Actor [MC-AA-01]

• Inputs:
  • Assets: treasury:wire (wire transaction lifecycle entities), treasury:ledger_account (general ledger balance entities).
  • Actors: Authenticated back-office operators authenticated via Okta OIDC presenting verified subject claims (sub, assigned_roles, tenant_id).
• Algorithm:
  1. Map authenticated natural person sub to User Assignment (UA) set: $\text{UA}(u) \subseteq \mathcal{R}$.
  2. Define role set $\mathcal{R} = {\text{RoleWireInitiator}, \text{RoleWireApprover}, \text{RoleLedgerAuditor}, \text{RoleTreasurySupervisor}}$.
  3. Bind atomic permissions $\mathcal{P}$ to roles via Permission Assignment (PA):
     • $\text{PA}(\text{RoleWireInitiator}) = {\text{treasury:wire:create}, \text{treasury:ledger:read}}$
     • $\text{PA}(\text{RoleWireApprover}) = {\text{treasury:wire:approve}, \text{treasury:wire:cancel}, \text{treasury:ledger:read}}$
     • $\text{PA}(\text{RoleLedgerAuditor}) = {\text{treasury:ledger:read}}$
     • $\text{PA}(\text{RoleTreasurySupervisor}) = \text{Inherits}(\text{RoleLedgerAuditor}) \cup {\text{treasury:wire:cancel}}$
• Outputs: Bounded actor profile with direct and inherited permission assignment mappings.
• Owner: Elena Rostova (Head of Treasury Operations).

Failure Handling: Fail-closed. Principals without valid User Assignment records default to empty set $\emptyset$ (HTTP 403 Forbidden).

• Verification: Contract unit suite test_rbac_actor_role_mapping() asserting valid role assignment resolution.

2. Trust Boundary [MC-TB-01]

• Inputs: Incoming HTTP requests to banking-admin-console API gateway, session tokens, inter-service gRPC calls.
• Algorithm:
  1. Perimeter Gate: Ingress API Gateway terminates mTLS and validates JWT token signature against corporate JWKS.
  2. PEP/PDP Seam: Policy Enforcement Point (PEP) interceptor extracts (subject_id, requested_action, target_resource_id).
  3. Application Seam: Backend Core Treasury services never execute administrative actions based on client-asserted role claims; all requests must traverse the localized PEP authorization filter.
  4. Tenant Boundary: tenant_id of the actor must strictly match the target treasury settlement account tenant_id.
• Outputs: Verified, boundary-isolated authorization context passed to core domain services.
• Owner: David O'Reilly (CISO SecOps).

Failure Handling: Any boundary violation or unauthenticated perimeter traversal triggers immediate TCP RST and emits ERR_TRUST_BOUNDARY_VIOLATION.

Verification: Automated penetration harness test_boundary_traversal_blocked() asserting bypass attempts fail closed.

3. Control [MC-CT-01]

• Inputs: Subject assigned roles, requested operation, target entity state (wire.initiator_id, wire.amount).
• Algorithm:
  1. Static Separation of Duties (SSD) Enforcement:
     $$\forall u \in \mathcal{U}, \quad {\text{RoleWireInitiator}, \text{RoleWireApprover}} \nsubseteq \text{UA}(u)$$
     IAM provisioning directory rejects any assignment request containing both roles.
  2. Maker-Checker Dual-Custody Control:
     During evaluation of treasury:wire:approve, PEP validates:
     current_user.subject_id != wire.initiator_id
     Self-approval is unconditionally rejected regardless of role seniority.
  3. Cardinality Bounds: A maximum of 2 concurrent active sessions per operator is enforced across all console endpoints.
• Outputs: Deterministic authorization decision: ALLOW or DENY.
• Owner: David O'Reilly (Lead Security Architect) and Elena Rostova (Treasury Operations).

Failure Handling: Denied requests log security audit event with code ERR_RBAC_SSD_VIOLATION or ERR_RBAC_MAKER_CHECKER_VIOLATION.

Verification: Automated negative test suite test_ssd_assignment_blocked() verifying provisioning pipeline rejection.

4. Verification [MC-VF-01]

• Inputs: Policy configuration file policies/rbac_treasury_matrix.json, role inheritance graph.
• Algorithm:
  1. Acyclic Graph Validation: Compute topological sort of role hierarchy DAG. If in-degree dependency cycle is found, abort compilation with ERR_RBAC_HIERARCHY_CYCLE.
  2. Effective Permission Computation:
     $$\mathcal{P}{\text{effective}}(u) = \bigcup{r \in \text{UA}(u)} \left( \text{PA}(r) \cup \bigcup_{r' \prec r} \text{PA}(r') \right)$$
  3. In-Memory Evaluation: Bitmap lookup matching requested_action bit against $\mathcal{P}_{\text{effective}}$. Latency p99 <= 0.8ms.
• Outputs: Policy compilation report and sub-2ms authorization response.
• Owner: Core Banking Platform Engineering.
• Failure Handling: Any policy graph cycle or memory allocation failure causes PDP to fail-closed (DENY_ALL).
• Verification: CI pipeline test test_rbac_dag_acyclicity() verifying cycle detection.

---

Adversarial Cases and Routing

1. Reject Checkbox Security [ADV-CS-01]

Vulnerability: Treating presence of an "Admin" or "SuperUser" role in a token as sufficient authorization without verifying atomic operation permissions or Maker-Checker segregation.

Adversarial Mechanism: In incident FRAUD-3810, an operator was granted an omnibus "SuperAdmin" role intended for emergency maintenance, which silently bypassed wire initiation/approval separation and allowed embezzling $1.8M.

Enforcement & Diagnostic: PDP policy compiler rejects wildcards (*, treasury:*) and omnibus roles lacking explicit atomic permission mappings. Emits diagnostic ERR_CHECKBOX_SECURITY_OMNIBUS_ROLE_FORBIDDEN.

Forbidden Output Behavior: The authorization system is strictly forbidden from minting, assigning, or evaluating roles with wildcard permissions or bypass privileges over maker-checker controls.

2. Reject Implicit Authorization [ADV-IA-01]

Vulnerability: Assuming that senior roles (such as Treasury Supervisor) automatically inherit all operational permissions transitively, or that hiding UI buttons constitutes authorization.

Adversarial Mechanism: Operator discovers hidden REST API endpoint /v1/wires/WR-99210/approve and invokes it directly using a junior auditor session; server assumes caller is authorized because endpoint is omitted from junior navigation menus.

Enforcement & Diagnostic: PEP validates action permissions strictly at the API controller layer, independent of UI representation. Inheritance must follow explicit DAG edges ($\text{RoleTreasurySupervisor} \to \text{RoleLedgerAuditor}$). Emits diagnostic ERR_IMPLICIT_AUTHORIZATION_MISSING_EXPLICIT_PERMISSION.

Forbidden Output Behavior: Backend services are strictly forbidden from executing state mutations without direct PDP permission evaluation.

3. Reject Secret in Artifact [ADV-SA-01]

Vulnerability: Embedding administrative API tokens, signing keys, or database credentials within RBAC matrix configuration files or test manifests.

Adversarial Mechanism: Developer commits static service-account credentials to rbac_policy.json to enable automated integration testing, exposing root ledger access in version control.

Enforcement & Diagnostic: Automated static analysis scanner (Gitleaks, Semgrep) validates all policy definitions and matrix documents. Detection of key blocks or tokens fails build with ERR_SECRET_IN_ARTIFACT_DETECTED.

Forbidden Output Behavior: Specification and policy files are strictly forbidden from containing embedded secrets, passwords, or persistent bearer tokens.

---

Preserved Evidence Table

---

Invariants and Contracts

Static Separation of Duties Mandate [INV-RBAC-01]
  No single user principal may be assigned both RoleWireInitiator and RoleWireApprover simultaneously.
  The identity directory and provisioning pipelines must reject conflicting assignments at intake.

Maker-Checker Non-Self-Approval Invariant [INV-RBAC-02]
  The initiating actor of a wire transfer transaction is permanently barred from approving that transaction.
  Self-approval requests must fail closed with HTTP 403 Forbidden regardless of user role elevations.

Strict Acyclic Hierarchy Guarantee [INV-RBAC-03]
  The role inheritance graph must remain a strict Directed Acyclic Graph (DAG).
  Cycles in role inheritance definitions are strictly prohibited and fail policy compilation.

Default-Deny and Explicit Permission Binding [INV-RBAC-04]
  All operations default to DENIED in the absence of an explicit matching permission grant.
  Wildcard actions and omnibus administrator bypass roles are strictly barred from production.

Explicit Unknowns

• Cache invalidation latency across 12 distributed console pods when an operator's role assignment is revoked in Okta (G-1).
• Delegation proxy workflow rules when an authorized approver is on unplanned medical leave (G-2).

Traceability

Verification

Reviewer self-check against RBAC architecture standards:

• Separation of Duties: PASS. SSD-TREASURY-01 prevents dual initiator/approver assignment.
• Maker-Checker Safety: PASS. Dual-custody invariant blocks self-approval of wire transfers.
• Hierarchy Integrity: PASS. Role DAG validated with zero cycles; default-deny enforced.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-RBAC-01: Elena Rostova to determine whether emergency dual-approval delegation should require secondary biometric hardware verification on mobile devices (Owner: Elena Rostova).

Next steps

1. Marcus Vance implements SSD-TREASURY-01 validation checks in the Okta SCIM provisioning pipeline.
2. Platform team embeds the in-memory RBAC evaluation engine into the banking API gateway.
3. Conduct staging compliance simulation attempting to assign conflicting initiator and approver roles to verify automated rejection.