Mendix 7 is no longer supported unless you have Extended Support (for details, please contact Mendix Support). Mendix 7 documentation will remain available for customers with Extended Support until July, 2024.
Project Security
In the project security dialog you can configure security settings related to the project, such as the security level, user roles, administrator access, and anonymous users.
Security Level
The security level defines how security is applied and which security settings need to be configured.
| Value | How security is applied | Which security settings need to be configured |
|---|---|---|
| Off | No security is applied. Users do not have to sign in and can access everything. | (none) |
| Prototype / demo | Security is applied to signing in, forms, and microflows. Users can access all data. | Administrator and anonymous access, user roles, and security for forms and microflows. |
| Production | Full security is applied. | Administrator and anonymous access, user roles, and security for forms, microflows, entities, and reports. |
Check security (only for security level Production)
If the security level is production, you can specify whether the consistency of security settings should be checked. For each user role the Modeler checks which forms are accessible, either directly in the menu bar or indirectly by following forms and microflows. For each of those forms, the Modeler checks whether referred attributes and associations are accessible for the current user role. If not, an error is added to the error list. These errors are only shown if there are no other errors.
Project status
The project status indicates the security status for the current project security level.
| Value | Description |
|---|---|
| Complete | All security settings for the current security level have been configured. |
| Incomplete | Some security settings for the current security level need to be configured. See the module status for more information. |
Extra Settings
When the security level is set to ‘Prototype / demo’ or ‘Production’, a number of tab pages with extra settings are shown.
Module Status
The module status overview shows the security status for each module. It shows the total number of items for which security needs to be configured, as well as the number of items for which security has been configured already. At the ‘Prototype / demo’ security level, the status of form access and microflow access is shown. Additionally, at the ‘Production’ security level, the status of entity access and dataset access (if applicable) is shown.
User Roles
A user role aggregates a number of access rights on data, forms and microflows. An end-user of the application is assigned one or more user roles by an administrator, and gets all access rights that these user roles represent.
Every user role has one or more module roles, which means that users with that user role have all the access rights that are defined for those module roles. A typical user role has module role System.User and at least one other module role.
The purpose of the distinction between user roles and module roles is to make a module self-contained (independent from the project in which it is defined or used), so that it can be reused in different projects and/or published to the Marketplace.
End-users of your application only see the user roles and not the module roles.
General Properties
Name
The name property defines the name of the user role. This name is shown to end-users who can create or edit user accounts in the application.
Documentation
In this property you can document additional information about the user role. This information is shown to end-users who can create or edit user accounts in the application.
Module roles
A list of module roles of which the access rights are accumulated in the user role. An end-user that is assigned a user role gets all access rights of the module roles of that user role.
Check security
This specifies whether the consistency of security settings is checked for this user role. You can choose to not check security for a user role. For example, user roles that are used only for web service users do not need to be checked because they never sign in to the client. See Project Security for more information on the security check.
User Management Properties
Users with this user role can manage users with at most the following user roles
A user role can be allowed to manage users with a number of other user roles (including itself), called manageable roles. This means that end-users who have this user role, can create, view, edit and delete users with at most the manageable user roles.
| Value | Description |
|---|---|
| All | End-users with this user role can manage all users and grant all user roles. Usually this option should only be configured for an administrator. |
| Selected | End-users with this user role can manage users that have at most the selected user roles, and can grant only the selected user roles. If no user roles are selected, end-users with this user role cannot manage users at all. |
Administrator
User Name
The user name of the administrator user that can be used to sign into the application.
Default value: MxAdmin
Password
The password of the administrator user that can be used to sign into the application.
Default value: 1
User Role
The user role of the administrator user that can be used to sign in to the application.
Demo Users
In this section of the Project Security settings, you can define demo users that may be used during the development phase of your application for testing purposes, or to show the application to other people.
Each demo user can be assigned an entity and one or more user roles that apply when you sign in to your application with that user. When the application is started for the first time, the specified demo users are created automatically.
After signing in to your application with the administrator user, a small tab called the ‘user switcher’ is presented at the right side of your application. Expanding this tab shows a list with all the demo users that are defined in the project security settings. Selecting a user from this list will sign in to your application using the credentials of this user, thus allowing you to test or demo your application with the user’s role(s). This allows for rapid testing of your application with different user roles.
The user switcher is only shown and the demo users are only created when running your application locally on your development machine, or when running in a sandbox.
Enable demo users
Here you can configure whether the specified demo users are created and accessible in the user switcher.
| Value | Description |
|---|---|
| Yes | Demo users are enabled. A user switcher is shown in the right margin of your application. |
| No | Demo users are disabled. The user switcher is not shown in the application. |
Demo User Properties
Username
The name of the demo user. This name must be unique, and cannot be the same as the name of the administrator user.
Password
The password of the demo user is created automatically when the demo user is created. It cannot be changed, but it’s possible to put a copy of this password on the system clipboard. This makes it possible, for example, to share the credentials of a demo user with someone else.
Entity
The entity of the demo user. This must be the System.User entity, or a specialization thereof.
User roles
Here you can select the user roles of the demo user. Each demo user must have one or more roles.
Anonymous Users
Allow anonymous users
Here you can configure whether anonymous users are allowed to access your application.
| Value | Description |
|---|---|
| Yes | Anonymous users are allowed. End-users do not have to sign in to access the application. If the user clicks a button of which the microflow requires a user role other than the anonymous user role, the user is presented with a sign in screen. |
| No | Anonymous users are not allowed. End-users have to sign in to access the application. |
Anonymous user role
This is the user role that end-users of your application have when they are not signed in.
Sign-in microflow
When anonymous users are allowed, here you can optionally configure a sign-in microflow. This microflow can be used to transfer data from the anonymous user to the signed-in user. In this microflow the current user is set to the signed-in user.
The sign-in microflow has two parameters.
| Name | Type | Description |
|---|---|---|
| AnonymousUser | Object of entity ‘System.User’ | The ‘User’ object of the anonymous user. This object will be automatically deleted after the execution of the sign-in microflow. |
| SignedInUser | Object of entity ‘System.User’ | The ‘User’ object of the signed-in user. |
The sign-in microflow is executed when an end-user does the following:
- Uses your application without signing in (thus as an anonymous user).
- Clicks a button for which they do not have access, which causes a sign-in screen to appear.
- Signs in to your application.
Password Policy
You can specify a number of requirements for passwords. These requirements will be enforced when creating new users or changing passwords of existing users.
Minimum length
Specifies the minimum length of passwords.
Require digit
Specifies whether at least one digit is required in passwords.
Require mixed case
Specifies whether passwords must contain at least one lowercase character and one uppercase character.
Require symbol
Specifies whether passwords must contain at least one special symbol.
The following characters are considered symbols:
|
|