Security

Last modified: February 13, 2024

1 Introduction

Security in Mendix has two sides: you want different people to see different parts of your application and you want to prevent unauthorized access. Both of these can be managed from Studio Pro. Access to forms, data and microflows can be limited to authorized users.

2 Security Levels

If you want full security, you need to explicitly give access to forms, entities and microflows before someone can access them. By default, no one can access anything. To make it easier to create prototypes and demos there are security levels that require less security settings than are needed for a production system.

See Project Security for a description of the security levels.

3 Project vs. Module Security

At the level of a project some global settings can be specified: the security level, the administrator account and whether or not to allow anonymous access.

See Project Security.

Most of the security settings take place at the module level. This has the advantage that a module can specify its own security and can be distributed and reused in other projects. Access to forms, entities, microflows and datasets can be configured.

See Module Security.

4 User Roles vs. Module Roles

An end-user in a Mendix application has one or more user roles. These roles can be assigned from within the client when creating or editing a user. User roles are at the level of a project and can be edited in Project Security.

See User Roles.

Each module defines its own set of module roles and you only have to specify security within a module in terms of those module roles. An email module maybe has two module roles, one for normal user and one for an administrator; other modules may have just one or more than two module roles depending on the requirements for those modules.

See Module Role.

A user role is a combination of module roles. A user that signs into the system gets the access rights of all of their user roles and indirectly to the module roles that are contained by those user roles.

5 Entity Access vs. Page Access

Per entity you can specify who can read or write what members (attributes and associations) under what circumstances. Using XPath constraints you can express powerful security behavior; for example, “an employee can only see orders created by the department they are a part of”.

Per page you can specify who can open it from navigation. The menu bar is optimized so that only pages that the user has access to are visible.

A combination of entity access and a page access is necessary because entities can also be accessed from microflows and custom widgets. Furthermore, you can express more advanced security through entity access.

See Entity Access.