Identity and Access Management (IAM)

Mendix provides the Identity and Access Management (IAM) capabilities that an agile enterprise needs when introducing new business applications. This section of the Evaluation Guide describes how enterprises can ensure that the right individuals have the right access to both low-code applications developed with Mendix and to the Mendix platform services.

How Are Users Authenticated When Accessing My Mendix App?

The Mendix platform provides you with three approaches to the authentication of users of your app. Depending on your preference you can include modules in your app from the Mendix marketplace for each of these approaches.
The first approach is to have ‘local’ authentication in your Mendix app. With this approach, the users of your app are managed by your app. Users are authenticated against their password that is also stored within the app. In this approach the app is self-supporting and independent of any existing IAM infrastructure. 
The Mendix marketplace also provides modules to also add multi-factor authentication to the local login process.
A second approach is to have users authenticate via the Mendix Identity Provider through single sign on (SSO) using their Mendix credentials. This is the default option for citizen developers who deploy their application to the Mendix Cloud. In Mendix Studio, Mendix SSO is automatically configured when you publish an app. This brings the time you would spend on activating SSO with Mendix accounts in your app down to zero. 
The third approach is to integrate your app with a third-party Identity Provider (IDP) external to your app. 

How Can My Mendix App Get Single Sign-On (SSO) with Third-Party Identity Management Solutions?

Customers with an on-premises Active Directory can use Microsoft’s Active Directory Federation Services (ADFS) to get SSO in their Mendix app. If you have this, you can include the SAML SSO module in your app. Needless to say, the platform supported SAML SSO module can be used with any IDP that supports the SAML 2.0 protocol.

Mendix applications that are deployed to SAP BTP can have SSO with SAP’s IDP. Mendix provides a platform supported XSUAA connector to implement this federation in your Mendix app. More details are provided in the section SAP integration.  

The Mendix Marketplace also offers community supported modules for the OAuth protocol. These are used in consumer facing applications to achieve single sign-on with ‘social’ identity providers such as Google, Microsoft, LinkedIn, Twitter, or Facebook.

How Does Mendix Support Home Realm Discovery?

Mendix can have federations with multiple (external) identity providers, so how does Mendix know where to authenticate the user? The logic behind this is called Home Realm Discovery or IdP Discovery.
For access to the Mendix platform, we have the following options to control where the user is authenticated:
  • On the login page, the user can enter their email address. If the email domain is federated, Mendix will redirect the user to the IDP that is configured for that email domain (Bring Your Own IDP, or BYOIDP).
  • If the user’s email domain does not have such an SSO, the user will be authenticated through the Mendix IdP with the user’s Mendix credentials.
  • Instead of entering their email address, the user can select the SAP IDP or Siemens DISW IDP themselves. If SAP is selected, Mendix will present a list of regions where the user may have a SAP identity.
When using the SAML SSO module for access to applications, the SAML SSO module can be configured to present a list of SAML IDPs to the user. 

How Can I Define User Roles for My App?

Mendix apps provide full flexibility for Mendix developers to define and implement user roles in any way they want. 

The Mendix platform also supports module roles. These are roles that are related to modules within the application.

A user role aggregates multiple module roles, giving access rights for data, pages, and microflows (logic). Every user role can consist of one or more module roles and a module role can be included in multiple user roles. When an application is created on the basis of modules from the Mendix Marketplace, the Mendix developer can choose to include a selection of the out-of-the-box module roles in the user roles of their Mendix application.

Examples of module roles are “order entry” or “approval”.

For access management only the user roles are relevant. An end-user of your application is only aware of their user roles. The concept of module roles is only relevant for developers of the application; they are internal to the application.

There is more information on this in the How Can I Define User Roles for My App? section of Security Model.

How are User Roles Assigned to the Users of My Mendix App?

Assignment of a user role to a user can be done ‘locally’, within the application logic, by a user with administrator rights, or the assignment can be done by a central IAM system external to the application.

If you choose to do local self-supporting user management within your app, you can make use of the Mendix delegated administration concept. When building an app and creating the app’s user roles, the maker can include user management module roles in any user role, so that users with such a user role can then manage access rights for other users with that selected role.  The so-called MxAdmin user is the local ‘root’ user that gets administrative rights to assign user roles to other users of your Mendix App.  For local user management you can either use the Administration module or build user management functionality yourself. Mendix creates a password for the MxAdmin user when you deploy your app to the Mendix cloud.

If you choose to manage your users centrally and use the SAML module, a default role can be set-up for any user that logs in. It is also possible to implement custom logic to assign user roles based on attributes received from the SAML Identity Provider.

How Can I Give My Employees Access to the Mendix Platform to Start Developing Applications?

Employees can get access to the Mendix development platform by doing a simple sign-up on the Mendix website or by clicking on an invitation link in an email from a colleague. The Mendix platform puts users with the same email domain in the same company, where they can start collaborating. All it takes for a user is to choose a password, confirm their business e-mail address, and answer some questions to get started and receive guidance on their journey as a Mendix developer. It is also possible to invite users from other companies to collaborate with you.

See also the Getting Started section.

How Do I Control How Developers Can Contribute to the Development of My Mendix App?

The Mendix platform has a range of development roles which can be assigned via the Mendix Developer Portal. For every app you are developing, you can assemble your own App Team and assign App Team Roles to your team members or send invitations for additional developers to join your App Team. 

How Can I Enforce Strong (Multi-Factor) Authentication for My Developers?

Mendix applies common password complexity rules and allows you to configure a password expiration period, after which developers will have to change their password. Two-factor authentication is applied within the Mendix Cloud for sensitive activities, including all operations on production environments.

Furthermore Mendix allows you to Bring Your Own IDP (BYOIDP) for platform access. Based on the OpenID Connect (OIDC) protocol, you can set up an identity federation between the Mendix Platform and your corporate Identity Provider (IDP) system such as Azure Active Directory. This gives your Mendix developers a single sign-on experience and puts you in control of how users are authenticated; your corporate IDP can enforce your password policies and multi-factor authentication. The capability to federate with your IDP is currently a private beta feature.

How Do I Prevent Developers From Having Continued Access to the Mendix Platform After They Have Left My Company?

The Mendix Control Center allows Mendix Administrators to de-activate any user account in their company space. This prevents that user from accessing any Mendix Platform services.

When you have set up an identity federation between the Mendix platform and your corporate IDP, blocking the developer in your IDP will completely block access to the Mendix platform. In this way, your central identity governance processes can also be applied to the Mendix platform.

For more information see How Can I Administer My Company Within the Mendix Platform? section of Platform Security.

Which Privileged Accounts Does Mendix have?

The most privileged accounts are user accounts with the Mendix Admin rights. Mendix Administrators act on a company level overseeing the various Mendix apps your company has created. A Mendix Administrator can use the Mendix Control Center to (de)activate users, edit their project roles, and set up App Access Groups as well as manage settings on a tenant level for your company.

For every app you develop with Mendix, a Technical Contact is assigned. The technical contact is the first point of contact for an app and is in control of deployment settings.

For every app that is deployed on the Mendix Cloud, Mendix creates a ‘local’ Administrator user, MxAdmin, who gets an administrative user role as created by the developers of the app. The developers are in full control of the module roles that are included in this administrative user role; it may not really have any administrative rights and it could even be an ‘empty’ user role for companies that don’t want to use the local administrator user for reasons of access governance.