Security and Access Control
This domain tests the security model end to end: security levels, the distinction between app roles and module roles, entity access with XPath constraints, page and microflow access, anonymous users, and demo users.
Security levels
- Off – no checks at all; anyone with the URL is effectively administrator. Prototyping only.
- Prototype – checks are active but you can log in as demo users, which is how you test roles before real accounts exist.
- Production – real accounts, no demo users, the only level acceptable for a live app.
Roles
The app role is what a user is assigned (for example on their Account). The module role is a role inside one module. In App security you map app roles onto module roles; a user gets every module role granted to their app role. Entity access rules, page access and microflow access are all specified per module role.
Entity access
For each entity and module role you set create, delete and read rights, attribute-level read/write, and an XPath constraint that filters which rows the role may see. A typical row-level rule only shows a user their own records.
Worked example
Requirement: a customer may only see their own orders. Reasoning: grant the module role read access on Order with an XPath constraint restricting rows to orders of the current user's customer, using [%CurrentUser%] and association navigation in the constraint. Granting read access without a constraint exposes every order; adding the constraint on the page instead would be useless, because pages do not enforce security - the entity access rule does.
Traps
- Anonymous access requires enabling anonymous users and granting the Anonymous module role; it does not follow from the security level alone.
- A role with no read access sees an empty page or a microflow error, not a helpful message.
- Microflow and page access are separate from entity access: all three must permit the action.