Model Changes When Security Is Enabled in Studio

1 Introduction

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.

1. 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.
2. The Mendix SSO module is set up if the project does not have it yet (for more information on this process, see the Modules Set Up section). If the Mendix SSO module has been already installed for this project, the process stops.
3. 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).
4. 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).
5. Studio checks if the login.html file exists, backs it up, and replaces it with a new version (for more information on this process, see the File Set Up section).
6. 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).

3 Modules Set Up

When security is enabled in Studio, the Mendix SSO 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:

1. The Mendix SSO startup microflow (MendixSSO.MendixSSO_AfterStartup) is created. For more information on possible outcomes of this process, see the Project Security Level Set Up section.
2. login.html file is checked and changed if necessary. For more information, see the File Set Up section.

The Mendix SSO module also adds user management to your app. With user management you can manage app users.

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:

1. Studio checks if the Administrator role and the User role exist at the Project level. If they do not exist, they will be created.

   

2. 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.

3. Studio links the Administrator role at the project level to MendixSSO.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 MendixSSO.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 MendixSSO.User and the Administration.User in the MendixSSO and Administration modules correspondingly.

4. Studio checks if demo users named demo_administrator and demo_user exist, and if not, Studio creates them.

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

6 File Set Up

As the last stage, Studio applies the changes login.html file 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

This procedure enables single sign-on and allows existing users to automatically sign in to your app using their Mendix accounts.

7 Project Security Level Set Up

On the Project level, Studio does the following:

1. The Project Security is set to Production.

2. 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 MendixSSO.MendixSSO_AfterStartup 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 MendixSSO.MendixSSO_AfterStartup 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 Mendix SSO module has been installed
• The security level has been be set to production
• Demo users have been 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 do not have more than one user role connected to them

9 Read More

• Security, Roles & Permissions
• Project Security
• Module Security