6.2 Entity Access Rules & Attribute-Level Security

6.2 Entity Access Rules & Attribute-Level Security

Exam Focus: Entity Access is the cornerstone of data security in Mendix. Intermediate Developer certification exams test your ability to configure granular member access matrices, determine effective permissions when multiple rules overlap, navigate association security from owning versus non-owning ends, resolve security consistency check errors, and choose the correct 'Apply entity access' setting on microflows.

When an application operates under Production Security, the Mendix Runtime enforces an absolute deny-by-default model on data. If an entity exists in the domain model without explicit access rules granting privileges to a user's role, that user cannot query, view, create, update, or delete instances of that entity. Even if a user navigates to a page containing a data grid connected to that entity, the grid will render completely empty, and unauthorized REST/OData requests will return HTTP 403 Forbidden or empty payloads.

---

Anatomy of an Entity Access Rule

Entity access rules are configured inside the Domain Model by opening an entity's properties dialog and navigating to the Access Rules tab. Each rule consists of four architectural components:

ENTITY ACCESS RULE
├── 1. Module Roles (One or more roles to which this rule applies)
├── 2. Instance Operations (Allow Creating new objects: Yes/No | Allow Deleting: Yes/No)
├── 3. XPath Constraint (Row-level filter, e.g., [System.owner = '[%CurrentUser%]'])
└── 4. Member Access Rights (Matrix of attributes & associations: None / Read / Read-Write)

1. Module Roles

Specifies which Module Roles within the current module are governed by this rule. A single rule can target multiple module roles if they share identical data access requirements.

2. Instance Operations (Create & Delete Rights)

• Allow creating new instances (Create): Permits the module role to instantiate new records of this entity via page 'New' buttons, Create Object microflow activities, or REST POST endpoints.
• Allow deleting instances (Delete): Permits the module role to delete records via Delete buttons or Delete Object microflow activities.

3. XPath Constraint

An optional filter restricting the rule to a specific subset of rows in the database (explored in depth in Section 6.3). When omitted, the rule applies globally to all rows of the entity.

4. Member Access Rights (Attributes & Associations)

Defines the granular visibility and editability for every individual attribute and association belonging to the entity:

• No Access (None): The attribute or association is completely invisible. The runtime strips this data before transmitting it to the client browser, and queries returning this member return null.
• Read-Only (Read): The user can view the value in data grids, text boxes, and read it in expressions, but cannot edit it via UI controls or update it in microflows running with entity access enabled.
• Read/Write (Write): The user can both view and modify the attribute value, or link/unlink the association.

---

The Member Access Matrix in Practice

Consider an enterprise entity CustomerOrder in a B2B commerce application. Different organizational personas require vastly different visibility into order details, pricing margins, and approval statuses:

Critical Observations from the Matrix:

1. Data Leak Prevention: The Customer role has No Access to ProfitMargin and InternalAuditNotes. If a developer mistakenly places ProfitMargin on a customer-facing page, the Mendix client engine does not render the value, preventing sensitive financial data exposure.
2. Separation of Duties: SalesRepresentative can create orders and enter TotalAmount, but only FinancialController has Write permissions on ApprovalStatus and Delete privileges on the order records.

Securing Associations: The Ownership Principle

Securing associations is a frequent source of confusion on the Intermediate Developer exam. In Mendix, associations are directional at the relational schema level:

Association Ownership Architecture

• Every 1-to-1 and 1-to-Many association has an Owner entity (indicated by the dot or originating end in the domain model editor, or explicitly selected in the association properties dialog).
• The foreign key reference is physically stored on the table of the owning entity.
• In Studio Pro's Access Rules, the association appears as a configurable member in the Member Access list of the owning entity.

The Three Rules of Association Security:

1. Modifying an Association: To change, set, or clear an association (e.g., assigning a Customer to an Order using a reference selector widget or a Change object activity), the user must have Read/Write access to the association on the owning entity (Order).
2. Target Entity Requirement: To select an object to link, the user must have at least Read access to the target entity (Customer). The user does not need Write access to the target entity merely to reference it.
3. Navigating from the Non-Owning End: If an association is configured with ownership set to Both (common in Many-to-Many associations), the association member appears in the access rules of both entities, allowing security to be managed from either perspective.

Exam Trap: If a developer grants a role Read/Write access to both the Order entity and the Customer entity, but forgets to grant Write access to the Order_Customer association member on the Order entity, the user will be unable to set the customer on an order! The reference selector on the page will render disabled/grayed out.

---

Additive Permission Union: How Overlapping Rules Combine

A central rule of Mendix security evaluation is that permissions are strictly additive. When a user is assigned multiple user roles, or when an entity defines multiple access rules for the same module role:

Effective permission = the union of the permissions granted by every applicable rule.

Additive Evaluation Rules:

• No Access + Read = Read
• Read + Read/Write = Read/Write
• No Access + Read/Write = Read/Write
• Cannot Create + Can Create = Can Create
• Cannot Delete + Can Delete = Can Delete

There is no concept of a 'Deny' rule in Mendix. A restrictive rule cannot override or revoke a privilege granted by another rule. If Rule A grants Read-only access to CreditLimit and Rule B grants Read/Write access to CreditLimit for the same role, the user will enjoy full Read/Write access.

---

Microflow Security Context: 'Apply Entity Access' Yes vs. No

Every microflow in Mendix contains a critical security setting in its properties panel: Apply entity access (Boolean: Yes or No).

CALLING USER: JuniorClerk (Has Read-Only access to Invoices)
       │
       ├──► Executes Microflow A (Apply entity access = YES)
       │      └── Attempts to Change Invoice.Status to 'Paid'
       │            └── 🛑 RUNTIME ERROR: SecurityException (Write Denied!)
       │
       └──► Executes Microflow B (Apply entity access = NO)
              └── Attempts to Change Invoice.Status to 'Paid'
                    └── ✅ SUCCESS: Status updated with elevated system privilege

Operational Differences:

Best Practice: Always set 'Apply entity access = Yes' for microflows exposed directly to end-user buttons or REST endpoints, unless elevated privileges are explicitly required for a backend system calculation.