Aeion RBAC vs Standard Role Frameworks
Why simple `isAdmin` boolean checks and custom middleware layers are catastrophic liabilities for large enterprises. Discover why Aeion OS enforces a mathematically strict, 3-Stage, kernel-level access control pipeline.
Decisive Architectural Advantages
The End of Controller Fragmentation
In standard Node.js applications, security logic is scattered across hundreds of individual REST controllers. An engineer must remember to write `if (!user.isAdmin) throw 403;` on every new endpoint. Aeion OS centralizes security. RBAC is defined precisely *once* on the centralized Collection Schema. The database access layer intercepts every request uniformly, mathematically preventing a developer from forgetting to secure an endpoint.
Dynamic Pre-Query Security
Standard security frameworks only verify *if* a user can perform an action, not *what* data they are allowed to act upon. Implementing Row-Level Security normally requires writing brittle, highly-custom SQL strings. Aeion utilizes a Declarative AST. The RBAC engine returns a typed `Filter` object, and the kernel securely injects this directly into the Drizzle ORM layer, guaranteeing the database only returns authorized records.
Automated Field-Level Defense
Trying to hide a user's `socialSecurityNumber` in a standard Express app requires the developer to remember to run `delete response.user.ssn` before calling `res.send()`. If missed once, the data leaks. Aeion OS employs a Post-Read Masking engine. The kernel automatically strips sensitive fields from the payload directly at the network boundary based on the schema's field-level access functions.
The Visual Airlock
Hiding a button via CSS is not security. Aeion's architecture purges unauthorized UIs at boot. By reading the strict `<module-id>:<action>` permissions, the OS removes unauthorized `ViewDefinitions` directly from the React Router. A malicious user cannot interact with a restricted UI because the UI component was never even downloaded to their browser.
Frequently Asked Questions
Postgres RLS is policy expressions written in SQL — powerful but spread across the schema in DDL. Aeion's RBAC lives in TS schemas with the rest of your model, evaluates to a typed Filter AST that compiles to SQL, and supports field-level masking which native RLS doesn't. You can still use Postgres RLS underneath if you want defense-in-depth.
Compose. Roles are sets of permissions (`module:action` tuples); a user can hold multiple roles; permissions are unioned. Define a `support-agent` role, a `billing-viewer` role, layer them on a person, they get both surfaces. Permissions can also be granted directly without a role wrapper if you need precision.
No — tenant isolation comes first. An admin in tenant A is omniscient within tenant A and invisible to tenant B. Cross-tenant access (super-admin, support, platform-engineer) is a separate privilege class with its own audit trail and explicit acknowledgment of cross-tenant action.
Yes — Admin UI has a role / permission manager that surfaces all `module:action` permissions with friendly labels, role templates by industry, and a 'who can do X' inspector. No code change to add a permission to an existing role; instant evaluation on the next request.
Sub-millisecond — the role check happens once per request, returns a Filter AST, and gets composed into the query at AST level (not as a post-fetch filter). The DB only ever returns authorized rows, and the query planner uses indexes as if the filter were hand-written. No N+1 problem, no full-table scans.
When a Standard Role Framework Is the Right Call
Kernel-level RBAC earns its complexity at scale. It is not free, and it is not always the answer. Passport.js and a handful of Express middleware checks remain the correct choice in real situations, and pretending otherwise would be dishonest.