The Zero-Trust Enterprise Firewall.
Basic admin/user toggles are insufficient for global organizations with thousands of employees, external vendors, and franchises. Aeion OS employs a "Defense-in-Depth" architecture. It enforces granular, string-based access control from the deepest PostgreSQL database row, all the way up to the complete removal of unauthorized UI components from the interface.
The 4-Layer Defense-in-Depth
The Visual Airlock
If a user lacks permission to use a module, they shouldn't even know it exists. At load time, the platform cross-references each user's permissions against every screen and menu item in the product. Anything they're not authorized for is stripped out of the interface entirely — not hidden with CSS, but genuinely removed — so even a curious (or malicious) user hits a hard 404 instead of finding a grayed-out button to poke at.
Pre-Query Row-Level Security
Users should only see data relevant to their assignment. When a Regional Manager pulls up the warehouse list, the platform dynamically adds filtering conditions to the database query before it ever runs. They automatically see only their 2 warehouses — the other 500 are filtered out at the database level, before the data is fetched, not stripped out afterward.
Post-Read Field Masking
Sometimes a user is allowed to view a record, but specific fields on it are classified. If a junior employee loads a product, sensitive fields like supplier margin or wholesale cost are stripped from the response before it ever leaves the server — not hidden in the UI, actually removed from the payload. Even a user inspecting raw network traffic never sees the field.
Automated Audit Provenance
Every enterprise needs an immutable ledger of who changed what. Aeion OS intercepts every create and update, stamping the authenticated user's real identity onto the record automatically — overwriting anything a malicious client tries to spoof. You never have to trust client-submitted attribution again.
Granular Permission Strings
Move beyond simple "editor" roles. Permissions follow a strict module:action format — finance:payroll, hr:compensation — so every grant is precise and auditable. Wildcards are supported too: grant commerce:* and an admin instantly gets every permission the Commerce module emits, without hand-picking each one.
Dual-Approach Architecture
Content needs flexibility; security needs speed and guarantees. Your content lives in flexible, schema-driven storage — but roles, members, and teams run on fixed, strictly-typed database tables with hard constraints, accessed through a dedicated fast path. That separation keeps permission checks fast even as your content model grows, and means a malformed request can never corrupt your security model.
The Visual Role Manager
No-Code Matrices
While the database enforces the rules, administrators never have to write permission matrices by hand. A built-in visual role manager in the Admin UI lets security officers configure custom roles and toggle precise module access with a few clicks — no code, no ticket to engineering.
Team-Based Access Control (TBAC)
Users are mapped into teams — say, the Warehouse A crew, with a given member holding the "lead" role on that team — and permissions are granted dynamically based on that org-hierarchy context, not just a flat global role.
How RBAC Composes
Permission Resolver
Combines every user's roles, team memberships, resource grants, and active delegations into one effective permission set — computed fresh per request, so a role change takes effect immediately.
Access Control Helpers
Evaluates your collection's access rules and merges them with the user's row-level filter at query time, so every read and write is checked at the same layer the data comes from.
Invitations
Team and tenant invitations with email verification and a full acceptance flow, so onboarding a new hire or vendor never requires manual account provisioning.
Delegations
Temporary authority handoff — "act as user X for the next 4 hours" — fully audited, with automatic expiry so nobody has to remember to revoke it.
Resource Grants
Per-document access — grant one user visibility into one specific contract without opening up the whole collection to them.
Sessions + Step-Up
Session creation, token validation, and mandatory re-authentication before your most sensitive operations.
Teams
Team membership and team-role assignment that maps directly onto your real org hierarchy.
Cleanup Jobs
Expired sessions, delegations, invites, and resource grants are swept nightly — nothing lingers past its intended lifetime.
Role Assignment
Grant roles with automatic conflict detection and cascading revocation, so removing a role cleanly removes everything it implied.
Field Guards
Per-field read/write rules for sensitive data — an SSN field, for instance, can be scoped to HR only, independent of who can see the rest of the record.
Permission Registry
A live catalog of every permission string your modules emit, with wildcard expansion (commerce:\*) so admins can grant broad access without hand-picking each one.
Step-Up Tokens
Short-lived, single-purpose re-auth tokens required before high-impact operations like deleting a tenant or rotating keys.
Collection Access Gate
Runs your access rules and checks extension entitlements before any query is even built — unauthorized requests never reach the database.
The Permission Resolution Algorithm
.
When the platform asks "can this user read this collection?", it computes the effective permission set by merging multiple grant sources in a deterministic order:
- Direct user permissions. Permissions assigned straight to the user. Rarely used — reserved for break-glass admins.
- Role memberships. The user holds one or more roles, each with its own permission list (e.g., commerce:orders.read, commerce:orders.write, finance:invoices.read). Wildcards expand automatically: commerce:\* covers every permission the Commerce module emits.
- Team-based grants. The user belongs to a team with a specific team role — say, lead on the Warehouse A team. The team grants permissions to every member holding that role, built for organizational hierarchy rather than flat lists.
- Resource grants. Per-document access to a specific record without opening the whole collection. "User X can view THIS contract" without "user X can read all contracts." These can be time-limited.
- Active delegations. If user A is currently delegating authority to user B for a bounded time window, B inherits A's permissions during that window — and every action B takes is logged as "B acting as A."
- Extension entitlements. Tenant-level entitlements gate feature access — e.g., "this tenant has Aegis Pro, so the Aegis Hub is visible" — and are resolved before role checks even run.
The final permission set is the union of all sources, with the most-specific deny winning if a deny rule exists. The result is computed once per request and reused for the rest of that request, so a single API call never re-evaluates the same user's permissions twice.
Step-Up Authentication for Sensitive Operations
.
For high-impact operations, basic password + MFA isn't enough. Step-up requires re-authentication immediately before the action — "you may have logged in 8 hours ago, but you need to prove it's you RIGHT NOW to do this."
Operations that auto-trigger step-up:
- Delete a tenant (irreversible without Aegis recovery)
- Rotate or revoke API keys at the platform level
- Modify role definitions that grant break-glass permissions
- Run a destructive database migration that would drop or truncate live data
- Export PII data at scale (>1000 records)
- Approve a delegation spanning >24 hours or to an external email
Step-up tokens are short-lived (5 min default), scoped to one operation, and fully audited — every step-up event is written to the audit trail alongside a timestamped record of exactly what it authorized. The same flow re-uses the user's configured MFA factor (TOTP, WebAuthn, SMS) — no separate enrollment.
Identity Foundation — Beyond RBAC
Multi-Factor Authentication
TOTP (Google Authenticator, 1Password, Authy compatible), WebAuthn / FIDO2 (hardware security keys, Touch ID, Face ID, Windows Hello), SMS fallback. Per-tenant policy enforcement: "all users with `admin` role MUST have MFA enrolled."
SAML 2.0 + OAuth + OIDC SSO
Native SAML 2.0 (Okta, Microsoft Entra ID, OneLogin, Ping) plus 10 OAuth 2.0 + OIDC providers with PKCE: Google · GitHub · Microsoft · Apple · Facebook · Twitter/X · LinkedIn · Discord · Slack · generic OIDC. JIT user provisioning with attribute mapping from SAML assertions or OIDC claims.
SCIM 2.0 Directory Sync
Continuous user lifecycle from your IdP — auto-provision on join, auto-revoke on offboard, group → role mapping. SCIM 2.0 Users + Groups + Bulk (RFC 7643/7644). The ex-employee account can't linger past the moment IT disables them in the directory.
API Keys
Per-service tokens with scoped permission grants, rate-limit policies, IP allowlists, and expiry. Keys are stored as bcrypt hashes — the full key value is shown exactly once at creation. Rotation flow built-in (overlap window prevents downtime).
Magic Link
Passwordless email-based auth. One-time signed token, 15-min default expiry, single-use. Reduces account-takeover surface for low-frequency users (customer portal logins, vendor access).
Password Reset
Industry-standard reset flow with rate-limiting, timing-attack-safe token comparison, and notification on completion. Old sessions invalidated on password change.
Login History
Every auth event logged — successful login, failed attempt, IP address, user agent, device fingerprint, geolocation. Anomaly detection flags "logged in from Country A 10 min ago, now Country B" — emits `auth.anomaly.detected` event for security review.
Bridge Auth
Hardware-backed auth on the Bridge desktop daemon. YubiKey / FIDO2 PIV / smart-card readers paired through the Bridge layer. The cloud requests a signed assertion; Bridge verifies the hardware token; signature returns. Cloud never sees the private key.
Invitations
Email-based team/tenant invitations with custom welcome flows. Optional self-serve role selection for B2B onboarding. Audit log captures who invited whom.
Audit Trail — Every Auth Event, Forever
Every authentication-adjacent event writes to a structured audit log that's tenant-scoped, immutable, and flows through the Aegis backup pipeline:
- Login attempts — successful + failed (with failure reason), IP, UA, device fingerprint
- MFA challenges — issued, verified, failed, bypassed (via recovery code)
- Step-up events — requested, completed, expired
- Permission resolution — for high-impact operations, the full chain (which role granted which permission) is recorded
- Role assignments — who assigned what to whom, when, with optional expiry
- Delegations — start, end, every action taken under delegation (with the action's audit row linked to the delegation row)
- API key usage — every request authenticated with an API key logs the key ID (not the secret) + the request path
- Anomaly detection — geo-velocity violations, brute-force patterns, credential-stuffing detection
Audit writes are queued asynchronously so logging never adds latency to your login path. Delivery is guaranteed — even through transient failures, the queue retries until every event is durably recorded. Nothing is dropped.
Retention: 90 days hot in Postgres, then offloaded to S3 via the Aegis archive tier (same pattern as temporal events).
Frequently Asked Questions
Both. The `access` config on a `CollectionConfig` accepts either a role-match (`access.read: requireRole('admin')`) or a custom function (`access.read: ({ user, doc }) => doc.ownerId === user.id`). Custom functions get the full user + the document (for update/delete) and return a boolean OR a Filter object. The Filter object pattern is powerful: returning `{ ownerId: { equals: user.id } }` is intersected with the developer's query — it acts as Row-Level Security without writing SQL.
The resolver computes the union of all granted permissions, with explicit-deny rules winning over implicit-allow. For example, if a user is in a role that grants `commerce:*` but also has a specific `deny:commerce.orders.delete` grant on their user record, they cannot delete commerce orders. Deny rules are rare in practice — they exist for break-glass scenarios (e.g., "temporary lockout after suspected breach").
**Roles** are organization-wide labels with permission lists (`admin`, `editor`, `support_agent`). **Teams** are organizational groupings (`team_warehouse_a`, `team_west_region`) with their own permissions that all members inherit. **Resource Grants** are per-document grants — "this specific user can view THIS specific contract" without granting access to the whole collection. Most enterprise deployments use all three: roles for job function, teams for organizational hierarchy, resource grants for sensitive one-off access.
For most deployments, yes. The UI handles role creation, permission assignment with wildcard support, team management, and audit log review. For deployments with thousands of fine-grained permissions or programmatic role generation (e.g., per-customer-tier roles in a multi-customer SaaS), the API-driven path is recommended. The visual role manager covers operator workflows; the API covers programmatic workflows.
Two-way integration. (1) Authentication: SAML 2.0 or OAuth 2.0 + OIDC routes login through your IdP (Okta, Entra ID, OneLogin, Ping, Auth0, JumpCloud, custom). JIT provisioning creates the user on first login with role mapping from SAML attributes / OIDC claims. (2) Continuous sync: SCIM 2.0 keeps it in lock-step — when you remove someone from `eng-leads` in Okta, they lose the Aeion `eng-lead` role in near-real-time (group → role/team mapping), and a disabled user is deprovisioned immediately. Without SCIM, OIDC claim refresh on token expiry catches most changes within hours. Audit log captures the source of every role change.
Permission resolution runs once per request and the result is cached for the rest of that request — typically under 2 ms for the full user → role → team → grant → delegation walk. Stage 1 RBAC adds a filter to the query — negligible impact on the database's query plan. Stage 2 field masking runs over result sets at a few microseconds per guarded field per row. Stage 3 write validation adds a similarly small overhead. Total request time is dominated by the database and network, not the security checks.
Yes — use Delegation (Pro+). User A delegates "admin during 2026-05-18 09:00 to 17:00" to user B. During the window, B's permission set includes A's. Every action B takes is audited as "B acting as A." The delegation auto-expires; no manual revocation needed. Common pattern: oncall handoff during a maintenance window.
Multiple layers. (1) Per-user + per-IP rate limiting on the login endpoint via the existing rate-limit system. (2) Anomaly detection on login geo-velocity (Pro+). (3) Automatic account lockout after 5 failed attempts within 15 min (configurable). (4) MFA + WebAuthn structurally defeat credential stuffing — the attacker has the password but not the hardware key.