Overview
The RBAC engine evaluates policies based on user roles, document attributes, and context information. It supports:- Role inheritance - Roles can inherit permissions from other roles
- Fine-grained policies - Control access at the collection and document level
- Expression language - Powerful conditional expressions using document and user context
- Field-level security - Control which fields users can read or modify
- Field masking - Automatically mask sensitive data
Role definitions
Roles are defined inpolicy.yml with inheritance support:
policy.yml
manager role, they automatically inherit permissions from both user and viewer roles.
Collection policies
Policies define what actions each role can perform on a collection:policy.yml
Policy structure
actions- Array of permitted actions:create,read,update,delete,restore,aggregatewhen- Optional condition expression that must evaluate totruefor access to be grantedfields- Optional field-level restrictions (see below)
Expression language
Thewhen clause uses a custom expression language to define conditional access rules.
Variables
The document being accessed. Use dot notation to access nested fields:
resource.owner_id, resource.metadata.statusThe authenticated user context with these fields:
user.id- User IDuser.tenant_id- Tenant IDuser.roles- Array of user rolesuser.$subordinates- Array of subordinate user IDs (from hierarchy)user.$directReports- Array of direct report user IDsuser.$ancestors- Array of ancestor user IDsuser.claims.*- Custom JWT claims
Operators
Comparison operators:Expression examples
Policy evaluation
The RBAC engine evaluates access in this order:- Check if user has any applicable roles for the collection
- For each role (including inherited roles):
- Check if the role policy grants the requested action
- If a
whenclause exists, compile it to a MongoDB filter - Evaluate the condition against the document
- Grant access if any role allows the action
- Deny access if no role grants permission
Field-level security
Restrict access to specific fields within documents:policy.yml
Field policies
Whitelist of allowed fields. If specified, only these fields are readable/writable
Blacklist of fields that cannot be read
Fields that can be read but not modified
Fields to mask with transformation types:
email- Masks email:j***@example.comphone- Masks phone:+1-***-***-4567partial- Shows first/last 4 chars:1234****5678
Query filtering
For read operations, the engine automatically applies filters based on thewhen clause:
Default policy
Configure default behavior when no policy matches:policy.yml
deny_all: true- Deny access by default if no policy grants permission (recommended)deny_all: false- Allow access if no explicit policy exists (not recommended)audit_log: true- Log all access attempts including denials
Best practices
Use role inheritance for hierarchies
Use role inheritance for hierarchies
Define base roles like
viewer and extend them with user, manager, admin to avoid policy duplication.Apply tenant isolation at the policy level
Apply tenant isolation at the policy level
Always include tenant checks in your
when clauses: resource.tenant_id == user.tenant_idPrefer explicit deny over implicit
Prefer explicit deny over implicit
Set
deny_all: true in defaults to ensure secure-by-default behavior.Test policies thoroughly
Test policies thoroughly
Use the engine’s
CheckDocumentAccess method to validate policies against test documents before deployment.Use field-level security for sensitive data
Use field-level security for sensitive data
Mask or deny access to sensitive fields like emails, phone numbers, or financial data for lower-privilege roles.
Related resources
- Schema validation - Define document structure and constraints
- Hooks - Execute custom logic on CRUD operations
- Audit logging - Track all access and changes