Model Changes When Security Is Enabled in Studio

Last update: Edit

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 AppCloudServices 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 AppCloudServices 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. 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).
  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 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:

  1. The AppCloudServices startup microflow is created. For more information on possible outcomes of this process, see the Project Security Level Set Up section.
  2. 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. 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.

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

  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
  • All roles in the current module, except anonymous roles, have read and write access for associations if the entity is the association owner

6 Files Set Up

As the last stage, Studio applies the following changes to index.html and login.html files in your project:

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

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