6.1 Security Architecture & Security Levels

6.1 Security Architecture & Security Levels

Exam Focus: Security architecture is one of the most critical evaluation domains on the Mendix Certified Intermediate Developer exam. Candidates are expected to master the exact operational differences among Studio Pro's three security levels, understand the architectural decoupling between Project Security and Module Security, map User Roles to Module Roles effectively, configure built-in administrator accounts and password policies, and diagnose compiler consistency errors raised when advancing an application to Production security.

In enterprise low-code development, security cannot be treated as an afterthought or handled solely through external web application firewalls. The Mendix platform is engineered with a zero-trust, model-driven security core. Every user interaction—navigating to a page, triggering a microflow, executing a client-side nanoflow, reading an entity attribute, or updating an association—is continuously evaluated against compiled security models before the Mendix Runtime executes the request or sends data across the wire.

---

The Three Security Levels in Mendix Studio Pro

When developing an application in Mendix Studio Pro, developers configure application security via the App Security (or Project Security) dashboard. Studio Pro provides three distinct security levels tailored to different phases of the software development lifecycle:

[ Off ]  ──►  [ Prototype / Demo ]  ──►  [ Production ]
(Local Sandbox)     (UI / Wireframe Testing)    (Cloud / Enterprise Live)

1. Off

• Operational Behavior: Security checks are completely disabled across the entire application runtime.
• Access Control: Any user, authenticated or anonymous, can access all pages, trigger all microflows and nanoflows, and perform arbitrary read, write, create, and delete operations on every database entity.
• Consistency Checks: Studio Pro performs no security-related model validations. Missing access rules, unprotected microflows, and exposed administrative pages generate zero compiler warnings or errors.
• Intended Use: Initial technology spikes, sandbox experimentation, or local component testing.
• Deployment Restriction: Applications configured with Security Level Off can run only locally; the Mendix Cloud deployment engine strictly rejects deployment packages built with security turned off.

2. Prototype / Demo

• Operational Behavior: Enforces access control on the user interface and logic layer, but completely disables Entity Access rules.
• Access Control:
  • Page access and Navigation items are strictly restricted by assigned User Roles and Module Roles.
  • Microflow and Nanoflow execution permissions are fully checked; users cannot execute logic unless their role is explicitly granted access.
  • Entity Access is bypassed entirely: Once a user is authorized to view a page or run a microflow, the Mendix Runtime retrieves and updates all entity attributes without checking entity-level Read/Write rules or row-level XPath constraints.
• Intended Use: Wireframing, clickable prototype demonstration with business stakeholders, and user experience (UX) validation. It allows cross-functional teams to test real UI interactions without spending hours configuring hundreds of granular entity access rules for draft domain models.
• Deployment Restriction: Can be deployed to ephemeral demo environments, but is permanently blocked from production cloud deployments.

3. Production

• Operational Behavior: Total enterprise security enforcement across every layer of the platform.
• Access Control:
  • Page and navigation security is strictly enforced.
  • Microflow and nanoflow access rules are enforced.
  • Entity Access rules are fully active: Every entity, attribute, and association requires explicit Read or Write permissions. Row-level XPath constraints filter database queries at the SQL level.
  • Published and consumed web services (REST/OData/SOAP) enforce authentication and role permissions.
  • Password complexity, failed login lockouts, and administrator user credentials become active.
• Consistency Checks: Studio Pro activates exhaustive compiler verification. If an entity has no access rules, or an accessible page contains a widget bound to an unauthorized attribute, the modeler generates fatal consistency errors that prevent compilation.
• Deployment: Mandatory for all staging, acceptance, and production cloud environments.

Comprehensive Security Level Comparison Matrix

---

The Two-Tier Security Architecture: Project vs. Module Security

Mendix achieves enterprise modularity and reusability through a strict two-tier security model. Security is divided into Project-level configuration (global governance) and Module-level configuration (local functional encapsulation):

PROJECT SECURITY (Global Governance)
├── Security Level (Off / Prototype / Production)
├── User Roles (Administrator, OperationsManager, FieldWorker, Guest)
├── Role Mapping (User Roles ──► Module Roles)
├── Built-in Administrator Account (Credentials & Role)
├── Password Complexity & Expiration Policies
└── Anonymous User Access Configuration
       │
       ▼ maps to
MODULE SECURITY (Local Functional Encapsulation)
├── Module: CoreHR
│     ├── Module Roles: HR_Manager, HR_Employee
│     ├── Page Access & Navigation Rights
│     ├── Microflow & Nanoflow Execution Rights
│     └── Entity Access Rules & XPath Constraints
└── Module: InventoryControl
      ├── Module Roles: Inventory_Auditor, Inventory_Clerk
      ├── Page Access & Microflow Rights
      └── Entity Access Rules & XPath Constraints

Project Security (Global Governance)

Project Security sits at the root of the application model. It defines governance parameters that apply across the entire deployed instance:

1. User Roles: High-level personas representing business roles in the organization (e.g., Administrator, CustomerSupport, BillingSpecialist, Guest).
2. User Role to Module Role Mapping: The central matrix linking global User Roles to specific functional Module Roles inside each imported or authored module.
3. Password Policies: Rules governing credential strength, rotation intervals, and brute-force defenses.
4. Administrator Account: Configuration of the emergency root administrative identity (MxAdmin).
5. Anonymous Access: Enabling public visitor access and binding a designated guest user role.

Module Security (Local Functional Encapsulation)

Module Security is defined independently within each module in the project. This encapsulation enables Marketplace modules (such as Excel Importer, SAML, or AuditTrail) to be imported into any application without modifying the module's internal code:

1. Module Roles: Internal functional permissions defined specifically for that module's capabilities (e.g., Sales.Representative, Sales.Manager, Sales.Auditor).
2. Page Access: Defines which module roles can open specific forms, popups, and layouts.
3. Microflow & Nanoflow Permissions: Grants execution privileges to authorized module roles.
4. Entity Access Rules: Establishes granular Read, Write, Create, and Delete rights per entity, attribute, and association.
5. Service Security: Governs permissions for published REST, OData, or SOAP operations.

---

Role Mapping: Connecting Users to Modular Capabilities

A central design rule of the Mendix platform is that end users in the database are never directly granted Module Roles. Instead:

1. End user records (instances of System.User or its common specialization Administration.Account) are assigned one or more User Roles.
2. In Project Security > User Roles, each User Role is mapped to zero, one, or several Module Roles across every module in the application.
3. At runtime, the Mendix engine dynamically computes the effective permissions of a user by taking the union (additive sum) of all Module Roles mapped to all User Roles assigned to that user.

Real-World Role Mapping Example

Consider an enterprise enterprise resource planning (ERP) app with three modules: System, SalesManagement, and WarehouseOperations.

In this architecture, an OperationsManager inherits the capabilities of both SalesManagement.Manager and WarehouseOperations.Supervisor. If a user is assigned both SalesRepresentative and WarehouseClerk, they seamlessly receive the permissions of both roles without any architectural changes in either module.

Administrator User Configuration & Password Policies

Enterprise security governance requires strict control over administrative credentials and user authentication policies. These settings are configured directly within Project Security.

The Built-in Administrator Account (MxAdmin)

Every Mendix application includes a built-in root administrator account (historically identified by the default username MxAdmin):

• Purpose: Used for initial environment bootstrap, disaster recovery, emergency administrative maintenance, and executing automated database migrations.
• Configuration in Studio Pro: Located under Project Security > Administrator:
  • User Name: Can be customized (best practice is to rename it from the default MxAdmin to avoid credential-stuffing attacks).
  • Password: Configured for local development. In cloud deployments, this password is overwritten by environment-specific variables managed via the Mendix Cloud portal or Kubernetes secrets.
  • Assigned User Role: Must be linked to a high-privilege User Role (typically Administrator).
• Production Rule: In production environments, the built-in administrator account should never be used for daily operational tasks. Day-to-day administrators should log in with personal named user accounts that possess audit trails.

Enterprise Password Policy Configuration

Located under Project Security > Password Policy, Studio Pro allows architects to enforce corporate security baselines:

• Minimum Password Length: Enforces a minimum character count (typically 8 to 16 characters in enterprise environments).
• Character Complexity Requirements: Checkboxes requiring passwords to contain:
  • At least one digit (0-9)
  • At least one uppercase letter (A-Z)
  • At least one lowercase letter (a-z)
  • At least one special symbol (!@#$%^&*)
• Password Expiration (Aging): Forces users to update their credentials after a configurable interval (e.g., every 90 days).
• Failed Login Attempts & Account Lockout: Automatically locks a user account after a specified number of consecutive invalid password attempts (e.g., 3 to 5 failed attempts). Locked accounts can be configured to auto-unlock after a time window (e.g., 30 minutes) or require manual administrator intervention.

---

Production Security Consistency Checks & Compiler Gates

The moment an engineer switches the Security Level to Production, Mendix Studio Pro's consistency engine runs a comprehensive audit across all modules. If any security vulnerability or incomplete configuration exists, the compiler throws fatal consistency errors in the Error List:

1. Unsecured Entities: Every entity in every domain model must have at least one access rule defined. If an entity has no access rules, Studio Pro generates error CE0123: Entity 'X' does not have any access rules for security level Production.
2. Unassigned Pages: Every page defined in the application must either be accessible by at least one Module Role or be explicitly excluded/orphaned.
3. Unassigned Microflows & Nanoflows: Any microflow callable from the client or navigation must have execution rights assigned to at least one Module Role.
4. Inconsistent UI Member Bindings: If a page editable by Module Role Staff contains an input widget bound to attribute Salary, but Staff only has Read access to Salary in the entity access rules, Studio Pro flags a consistency error or warning.
5. Unreachable Navigation Items: If a menu item in the navigation document points to a page that the user role cannot access, the navigation tree fails compilation.

---

Practical Exam Scenarios & Architecture Best Practices

Scenario 1: Deploying with Prototype/Demo Security

A developer finishes building a customer portal and attempts to deploy the deployment package to Mendix Cloud Production. The build pipeline fails with a security compliance error.

• Root Cause: The project security level was left in Prototype/Demo mode.
• Exam Takeaway: The Mendix Cloud deployment engine strictly enforces that production environments only run packages built with Production security. Prototype/Demo security is forbidden in production because it completely bypasses entity and attribute access rules.

Scenario 2: Direct Assignment of Module Roles

An external audit asks why a new human resources contractor cannot be assigned the CoreHR.HR_Clerk module role in the user management page.

• Architectural Reality: End users cannot be granted Module Roles directly. The administrator must assign the user a global User Role (e.g., Contractor), and the Project Security settings must map that Contractor User Role to the CoreHR.HR_Clerk Module Role.

Scenario 3: Bypassing Microflow Security in Demo Mode

While testing in Prototype/Demo security, an unauthorized user triggers an expense approval microflow that modifies financial ledger records, and the update succeeds despite the user having no write access to the ledger entity.

• Explanation: In Prototype/Demo security, microflow execution security is checked at the entry point (the user had permission to run the microflow), but entity access is completely disabled. Therefore, any database write inside the microflow executes without validating attribute write permissions.