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.

The third approach is to integrate your app with a third-party Identity Provider (IDP) external to your app.

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 platform-supported SAML SSO module in your app.

Needless to say, the SAML SSO module can be used with any IDP that supports the SAML 2.0 protocol. Mendix customers are currently using this module with IDPs such as Okta, Microsoft Azure AD, Microsoft Active Directory Federation Service (ADFS), Shibboleth IdP’s, ForgeRock, and the Dutch eIDAS schemes DigiD and eHerkenning.

Mendix also supports the OAuth protocol with the platform-supported OIDC SSO module. OIDC/OAuth can be used in consumer facing applications to achieve single sign-on with identity providers such as Amazon Cognito, Google, Microsoft, LinkedIn, Twitter, or Facebook. It can also be used to authenticate to APIs, including APIs from Mendix ‘back-end’ apps which provide services to other apps. And, if your corporate IDP supports OIDC, you can use it to authenticate your employees and automatically grant them roles in your apps.

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.

How Can My Employees Log In to the Mendix Platform?

The Mendix Cloud solution offers an Identity Provider (IdP) that allows users to log in to Mendix Platform services and Mendix Studio Pro. Moreover, your employees can also use this IdP to log in to Mendix applications that have been built with Mendix SSO.

You can set this up in one of two ways:

  1. Use a platform password which you set during sign up. This means you can easily get started with the Mendix platform. Mendix applies common password complexity rules to the platform password 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.
  2. Use an identity federation between the Mendix Platform and your corporate Identity Provider (IdP). This allows you to provide your end-users with an end-to-end SSO experience. Mendix calls this feature BYOIDP (Bring-Your-Own-IDentity-Provider), sometimes referred to as ‘customer IdP’ OR ‘customer IdP SSO’. It is available for any app using the standard or premium packages.

Benefits of Using BYOIDP SSO

  • Security. Customers are in control of the credentials and authentication of their platform users; they can apply password complexity rules and two-factor authentication (2FA). End-users don’t need to have credentials in the Mendix platform to access the (main) Mendix platform applications.
  • Access governance. Customers are in control of denying access to the platform via SSO, for example when an employee has left the company or your corporate policy does not allow an employee to work with Mendix.
  • Convenience. Platform users have convenience of SSO and don’t have to manage credentials for the Mendix platform.

Features of BYOIDP SSO

BYOIDP SSO includes the following features:

  • It is based on the OpenID Connect (OIDC) protocol which supports corporate IdPs such as Azure Active Directory.
  • Mendix platform services and Studio Pro can delegate authentication to the customer’s IdP.
  • Authentication will be delegated for any user that has an email address associated with your company. This includes service accounts (i.e. non-personal accounts ) that may have been created on the Mendix platform (e.g.“[email protected]”).
  • When you add a domain to your company account, it is automatically added to the active IdP configuration

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