Last update: Edit

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 the Modeler. Access to forms, data and microflows can be limited to authorized users.

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.

Project versus 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.

User Roles versus 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 the Project Security form.

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 e-mail 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 his or her user roles and indirectly to the module roles that are contained by those user roles.

Entity Access versus Form 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 he is a part of”.

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

A combination of entity access and form 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.