This document describes the process of model changes that are applied automatically when security is enabled in Mendix Studio. For more information on security settings in Studio, see Security, Roles & Permissions in the Studio Guide.
Users can enable security from Studio. While the Studio user simply clicks the Enable Security button, as a result, security is set to Production for the project and a number of checks and changes (if necessary) are performed automatically.
2 Process Overview
When security is enabled, a number of checks and changes are done at several levels.
- Studio checks if security is enabled. If security is set to Prototype/demo or Production, the process stops. If security is off, steps described below are executed.
- The AppCloudServices module is set up if the project does not have them yet (for more information on this process, see the Modules Set Up section). If the AppCloudServices module has been already installed for this project, the process stops.
- Studio does checks and changes (if necessary) to demo users , module roles , and user roles (for more information on this process, see the Module Roles and Demo Users Set Up section).
- Studio sets access rules for entities (and their attributes and associations), if entities do not have access rules yet (for more information on this process, see the Entity Access Set Up section).
- Studio checks if the login.html file exists, backs it up, and replaces it with a new version. Also, Studio checks if index.html exists, it searches for
document.cookie = "originURI=/login.html";and replaces it with
document.cookie = "originURI=/openid/login";(for more information on this process, see the Files Set Up section).
- Studio does checks and changes (if necessary) at the Project Security level (for more information on this process, see the Project Security Level Set Up section).
If security has already been set to Prototype/demo or Production in Studio Pro, these settings may be incompatible (too advanced) with Studio roles and permissions settings. In this case, you will not be able to edit roles and permissions in Studio. For more information on security settings in Studio, see Security, Roles & Permissions in the Studio Guide.
3 Modules Set Up
When security is enabled in Studio, the AppCloudServices module is set up. This module enables single sign-on and user management in your app.
To enable single sign-on the following checks and changes are performed:
- The AppCloudServices startup microflow is created. For more information on possible outcomes of this process, see the Project Security Level Set Up section.
- index.html and login.html files are checked and changed if necessary. For more information, see the Files Set Up section.
The AppCloudServices module also adds user management to your app, and when you deploy your app in the AppCloud, it will now be automatically added to your Launchpad. With user management you can manage app users.
If your project already has the AppCloudServices module installed, you will not be able to enable security from Studio. You can only set security manually in Studio Pro meeting the following requirements:
- Security should be set to Production
- The AppCloudServices module should be set up to enable single sign on (For more information on how to set the module up, see Mendix Single Sign On in the Developer Portal Guide)
4 Module Roles and Demo Users Set Up
After the After startup microflow is set up, Studio checks if the Administrator role, the User role, and demo users exist and creates them when necessary:
Studio checks if the Administrator role and the User role exist at the Project level. If they do not exist, they will be created.
After that, Studio checks if the Administrator and the User roles exist in each module of your project and if they are linked to the corresponding project roles.
Possible outcomes of this check are the following:
a. If the model has two or more module roles in one module that are connected to the Administrator project role or the User project role, then it will be Studio incompatible. Studio will not change anything in these roles, but roles and permissions will not be editable in Studio.
b. If the model has one module role connected to the Administrator project role or the User project role, Studio checks if the name of the module role is identical to the project role. If the names are different, Studio disconnects this module role from the project role, creates a new one with the name identical to the project role name, and links it to the project role.
c. If the model has no module roles connected to the Administrator project role or the User project role, Studio creates these roles.
d. If the module role exists, its name is identical to the project role, but it is not linked to this project role, Studio creates a new module role, names it Administrator_1 or User_1, and links it to the corresponding project role.
Studio links the Administrator role from the System module to the Administrator role on the project level. Every other project role created from Studio, including the original User project role, will be linked to the User module role for the System module.
Studio links the Administrator role at the project level to AppCloudServices.Administrator and Administration.Administrator (if they exist, if not, Studio will not do any linking). The User role at the project level is linked to AppCloudServices.User, and Administration.User (if they exist, if not, Studio will not do any linking). All other AppStore modules will remain unchanged.
Every other user role created in Studio will be linked to the AppCloudServices.User and the Administration.User in the AppCloudServices and Administration modules correspondingly.
Studio checks if demo users named demo_administrator and demo_user exist, and if not, Studio creates them.
If Administrator and User roles already exist and are compatible with Studio, they will get access to all microflows, nanoflows, pages, and entities (including entities’ attributes and associations).
All newly created roles get access to all pages, microflows, nanoflows, and entities (including their attributes and associations) that are in Studio, except for App Store pages, microflows, and entities (with their attributes and associations).
Also, all new pages, microflows, and entities (with their attributes and associations) that are created in Studio will be accessible for all existing app roles by default.
5 Entity Access Set Up
When you enable security, Studio creates access rules for all entities (and their attributes and associations) that do not have them. The following access rules settings are applied:
A description is added to Documentation of an Access Rule stating that it has been generated by Studio
All roles in the current module, except anonymous roles, get create and delete rights for entities. The following rules are created for attributes and associations of these entities:
- All roles in the current module, except anonymous roles, have read and write access for attributes
There are cases where entities inherit from System.Image or System.FileDocument. Some of those inherited attributes cannot be set to read/write, so they are set to read-only.
All roles in the current module, except anonymous roles, have read and write access for associations if the entity is the association owner
The rules described above are created if you create an entity in Studio.
If you copy-paste an entity, the access rules of the original entity are copied as much as possible. However, if you have a generalization on an entity and you copy it to another project, the generalization is removed.
6 Files Set Up
As the last stage, Studio applies the following changes to index.html and login.html files in your project:
If the login.html file exist, Studio backs it up in the same folder under the name login_backup_year-month-day_hour-minute.html, indicating the date and time of the backup. Studio also creates a new file under the name login.html
If the login.html file does not exist, Studio creates it under the name login.html
In theindex.html file, Studio replaces
document.cookie = "originURI=/login.html";with
document.cookie = "originURI=/openid/login";.
This procedure enables single sign-on and allows existing users to automatically log in to your app using their Mendix accounts.
7 Project Security Level Set Up
On the Project level, Studio does the following:
The Project Security is set to Production.
Studio checks if the After startup microflow exists in Project > Settings > Runtime.
There are two possible outcomes of this check:
a. If the model does not contain any After startup microflow, the AppCloudServices.StartAppCloudServices microflow is used.
b. If the model contains the After startup microflow, Studio creates CallBothStartupMicroflows microflow in the same place as the existing one. CallBothStartupMicroflows will call the AppCloudServices.StartAppCloudServices microflow first, then it will call the microflow that already existed in the project.
8 Studio Compatibility
Studio Pro security settings are compatible with Studio (that means that roles and permissions can be edited in Studio), when all of the following criteria are met:
- The AppCloudServices module has to be installed
- The security level must be set to production
- Demo users have to be enabled
- Demo users must have the correct name: identical to the project role name, but with the demo_ prefix (for example, demo_user)
- Demo users must have exactly one user role connected to them
- User roles must have a demo user connected to them
- User roles must have exactly one module role per module connected to them (Studio does not check System or App Store modules)
- Module roles may not have more than one user role connected to them