Security and Access Control
Security and Access Control
This domain tests defence in depth: whether access is enforced at the model level rather than painted onto pages.
Core rules
- Security levels are Off, Prototype/Demo and Production. Production requires entity access rules for every entity and forbids demo users.
- Module roles are design-time; user roles are runtime and bundle module roles. Users get module roles only through their user role.
- Entity access defines create and delete rights plus XPath member constraints per role. Attribute access is separate and can hide a field even when the object is visible.
- Member constraints are appended to every retrieve for that role, so a constraint on an unindexed attribute turns into a full table scan - security and performance are the same conversation.
- Microflow and page access are granted per module role. A microflow that is not exposed to a role cannot be called from a page for that user.
- System-context execution (scheduled events, task queues) bypasses entity access. Any logic that must respect row-level rules has to run in the user's context.
Worked example
An HR app stores Employee records. The employee role gets a constraint [System.owner = '[%CurrentUser%]'] with read-only attribute access on salary; the manager role gets [MyModule.Employee_HasManager/MyModule.Manager = '[%CurrentUser%]'] with full attribute access. Because the manager constraint filters on an association, that association must be indexed. The page-level grid then needs no filtering at all - it shows exactly what the constraint returns.
Traps
- Hiding a button instead of restricting the microflow behind it.
- Relying on entity access alone while anonymous access is still enabled.
- Building constraints on non-indexed attributes and blaming the database.
- Assuming a scheduled event enforces the row-level rules it bypasses.