Role-Based Access Control with Segregation of Duties Enforcement

Administrator defines roles (e.g., AP Clerk, AP Approver, GL Accountant, CFO) with explicit permission sets scoped to modules, actions, and data ranges. SoD ruleset prevents assigning conflicting roles to the same user (e.g., bill creator + bill approver). On every login the JWT is minted with current role claims;
the 4-layer pipeline (JWT → FGA → OPA → SQL) enforces permissions on every request. Violations are blocked with a 403 and written to the immutable audit log. Quarterly SoD conflict reports are generated for auditors.

role { role_id: string, org_id: string, name: string, permissions: string[], external_id: string };
user_role_assignment { user_id: string, role_id: string, entity_id: string, assigned_at: timestamp, assigned_by: string };
sod_conflict_rule { rule_id: string, org_id: string, role_a_id: string, role_b_id: string };
audit_event { event_id: string, actor_id: string, action: string, resource_type: string, resource_id: string, outcome: enum(ALLOWED,DENIED), timestamp: timestamp };
(reference, product may differ).

POST /v1/roles { name, permissions[], org_id } -> 201 { role_id, name };
POST /v1/users/{user_id}/roles { role_id, entity_id } -> 201 or 409 on SoD conflict;
GET /v1/roles/{role_id};
POST /v1/sod-rules { role_a_id, role_b_id } -> 201;
GET /v1/audit-events?actor_id=&outcome=DENIED;
emits security.sod_violation_blocked event;
idempotent via external_id.

DRAFT -> ACTIVE;
terminal INACTIVE;
guard: SoD conflict check blocks ACTIVE assignment;
role assignment change takes effect within one JWT refresh cycle (≤15 min);
policy engine unavailability returns 503 not pass-through.