Skip to content
ironflow
Ironflow is pre-1.0: APIs can change between releases. Pin a version. What is ready →

Auth & RBAC

Every API request passes through a single authentication and authorization path. The server extracts credentials (API key or JWT), loads the associated roles, derives the requested action from the HTTP method and route, builds an IRN for the target resource, and evaluates the request. Authorization has two layers. Layer 1 system RBAC (built-in roles and verbs) is authoritative for ALLOW. Layer 2, the Rego policy set of the organization, is subtractive and only denies. See ADR 0015, ADR 0016 and ADR 0121.

Layer 2 enforcement is opt-in (spec.auth.policyEnforcement, off by default). With it off, a policy set is stored, versioned and shown in the dashboard, and it does not change live access decisions. A new set starts in monitor mode, which records would_deny audit rows and blocks nothing. The diagram shows the contract that enforcement applies. See Authorization policy sets for the model.

Ironflow auth and RBAC

Layer 1 decides first. If it denies, Layer 2 does not run. Layer 2 cannot grant access that Layer 1 denied. Every denied decision is written to the auth audit log, and a monitor-mode deny is written as authz.decision.would_deny.