Security and Access Control
Security and access control
Mendix security has three layers: module roles (defined per module, the unit of authoring), user roles (combinations of module roles assigned to end users), and the access rules attached to each modellable document.
For every entity, entity access rules grant create, read, write and delete per module role, optionally with member-level read/write and an XPath constraint that limits which rows the role can see. Pages need page access per module role, microflows and nanoflows need "allowed to execute", and navigation items need navigation access. Nothing is granted by default: an entity with no access rules is invisible to every role.
Traps
- Read is not enough to save. Changing an object requires write on the entity and on the individual attributes being changed; a microflow that changes an attribute the role cannot write fails at runtime even though the triggering button was allowed.
- Entity access XPath constraints also apply to retrieves inside microflows, so a microflow can return fewer rows than expected for a restricted user.
- Microflow access set to none produces an error when a button triggers it; page access without navigation access produces a page the user cannot reach.
- Published REST, OData and web services have their own authentication settings and must be secured explicitly - leaving them open is a classic prototype leftover.
Rule of thumb
Work top-down: user role → module roles → document access → entity access. If any link in the chain is missing, the feature breaks at runtime, usually with a client- or core-level error rather than a consistency error at model level.