Mitigate User Risk

Governance is about optimizing value with acceptable risk (depending on your risk tolerance). User risk is one of the risk categories in the Mendix Governance Value Framework. Mitigating user risk involves managing the identity and access of the people who develop the platform’s applications and the app’s end-users.

There are three categories of users we have identified:

• Platform Users – These are your employees who either develop low-code applications or collaborate with these developers.
• Extended Workforce – This is a special category of platform users who are employees of implementation partners who may help you with your Mendix development efforts as platform users.
• Application Users – These are the end-users of the applications you build with Mendix. They may not be aware of the technology that was used to build those applications. Application users may become platform users as well when they want to give feedback on the application or collaborate otherwise to further enhance your portfolio of Mendix applications.

Control Platform User Risk

How can my employees be onboarded to evaluate the Mendix platform or to start developing applications?

Employees can onboard themselves to the Mendix development platform by simply signing up to the Mendix website. All they have to do is:

• Confirm their business e-mail address
• Choose a password (if needed), and
• Answer some questions to get started and receive guidance on their journey as a Mendix developer.

No need to have a contract with Mendix first; the same signup process applies when you want to evaluate the Mendix platform or when you’ve already decided to do low-code development with Mendix.

The Mendix platform recognizes users with the same email domain as colleagues and makes it easy for them to collaborate. Platform users can also invite each other, so clicking on an invitation link makes it even easier for them to onboard.

See also the Getting Started section.

How can my employees log into the Mendix platform?

The Mendix platform includes identity services that allow your employees to sign in to the online Mendix platform and the Integrated Development Environment (IDE) called Mendix Studio Pro.

You can arrange for the platform user authentication in one of the following ways:

1. User-defined password created during signup: This is the default mechanism and it enables you to quickly and 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.
2. Identity federation between the Mendix Platform and your corporate Identity Provider (IdP): This allows you to provide your platform users with an end-to-end SSO experience. Mendix calls the platform SSO feature BYOIDP (Bring-Your-Own-IDentity-Provider). This feature requires a standard or premium platform license. Each SSO login to Studio Pro uses the system browser for SSO, so that conditional access functionality in your IdP (e.g. to check for trusted devices) can be applied.
3. SAP BTP credentials or Siemens IdP for Siemens Xcelerator customers: This prevents your users from having yet another set of credentials.

How does the Mendix platform support multi-factor authentication?

Multi-factor Authentication (MFA) adds an additional layer of security and is important to prevent attacks from compromised accounts. Many companies want their multi-factor authentication coverage to include access to the Mendix platform.

Enabling platform SSO is the recommended approach to enforcing MFA (or 2FA, as many companies think two factors for authentication are enough) upon your platform users. This will extend the reach of your IdP to the Mendix platform and leverage the MFA processes you already have in place.

Moreover, the Mendix platform enforces two-factor authentication (2FA) for sensitive activities. This authentication step is required for every manual deployment of a production application to the Mendix cloud. The native 2FA capabilities of the Mendix platform include SMS login codes as well as Time-based One Time Passwords (TOTP). TOTP is compatible with Google’s or Microsoft’s Authenticator apps. Platform users can reset their 2FA credentials on the Mendix platform via a self-service mechanism, which uses confirmation links sent to their business email address.

How does the Mendix platform enable me to manage permissions for my platform users?

Mendix supports the definition of Mendix Administrators who can assign permissions to users following a delegated administration concept. You can have one or more Mendix Admins who have control over permissions granted to other platform users.

The Control Center is the administrative hub providing the Mendix Admin with a single overview of their app landscape, members, and cloud environments. In the Control Center, Mendix Admins can view team member activity, and they can perform these administrative tasks:

• Get an overview of all your company’s platform users, including their status (internal or external), Mendix certification level, and the apps to which they have access.
• Deactivate members they identify as a security risk.
• Get an overview of all your company’s applications, including who created the apps and when they were last modified.

Furthermore, the Mendix platform provides an API (the Projects API) to add users as Scrum Masters or remove them from individual app projects in an automated fashion.

How do I prevent developers from continuing to access the Mendix Platform after they have left my company?

The Mendix Control Center allows Mendix Administrators to deactivate platform users. This prevents that user from accessing any Mendix platform services or consuming any platform API.

If you have set up an identity federation between the Mendix platform and your corporate IdP (platform SSO), blocking the developer in your IdP will block logins to the Mendix platform. In this way, your central identity governance processes can also be applied to the Mendix platform.

How do I control how developers contribute to the development of my Mendix App?

The Mendix platform has a range of development roles that 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.

What is the current level of certification of the platform users in our company?

One key to governance is seeing that your people are properly trained. In Members Overview in the Control Center, all platform users that have access to your app development are listed, along with their current certification.

Which privileged accounts does Mendix have?

Privileged account management is key in cybersecurity since a vast majority of data breaches involve such accounts. The most privileged accounts on the Mendix platform are user accounts with Mendix Admin rights. These Mendix Administrators (or simply “Mendix Admins”) act on an organizational 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 app’s first point of contact and controls 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 application. Additionally, application logic may assign the local administrator role to other end-users as well. The developers are in full control of the rights that are included in this particular administrative user role. For example, it may not 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.

Control Extended Workforce Risk

Companies starting out or those requiring specific expertise may look to extend their developer workforce using freelancers, Mendix implementation partners, or Mendix Expert Services. Other companies may choose to outsource the development and maintenance of some of their apps to a partner.

How do I control external developers in my workforce?

If you want to be in control of how your external workforce is authenticated, you can create named accounts in your company’s IdP (i.e. [email protected]) for any external worker. This way, you manage external workers in the same way as your regular employees, including the automated deactivation of former workers.

If that is not a prerequisite, it is possible for people with the “invite” permission in their project role to invite external members to their project (e.g. [email protected]) to your app projects and this user will be authenticated by their own company’s authentication method.

Much in the same way as internal employees, you are able to see an overview in the Control Center of external members from other domains, the projects they are collaborating on, as well as the highest level of certification they’ve received.

You can remove them from the project when they are no longer part of the development team. If they are no longer on any project, they will no longer show up on your external members list.

How do I collaborate on applications with my implementation partner?

If you choose to outsource the development of a Mendix application to an implementation partner, the recommended approach is to create the app projects yourself and collaborate with your partners on those projects. This gives you full control over your IP and is the best way to govern those projects. It also allows your employees to take ownership or allow you to switch to another implementation partner.

You can give your partner the right permissions they need to work with you on these projects. When they are done contributing to the project, they can be removed from the project team. The app project and all the contributions the partner has made will remain in the project.

Alternatively, it is also possible for the partner to create a project and invite you to collaborate with them on that project. In that case, when the contribution of the partner is over, you can take ownership by creating your own project and importing the app that was developed by your partner.

Control Application User Risk

Paraphrasing a common definition for Identity and Access Management (IAM). We can say that Controlling Application User Risk is about ensuring that the right app users have access to the right Mendix applications with the right user roles for the right reasons. App users are defined as users of your Mendix application and include both end-users and privileged users a.k.a. admin users.

The following diagram indicates IAM capabilities used in a typical Business-to-Employee (B2E) Mendix application.

How are users authenticated when accessing my Mendix application?

The Mendix platform offers various possibilities to authenticate users of your Mendix Application.

The first possibility is to not authenticate your application users. You can give visitors anonymous access to restricted parts of your application. Especially if you’re building applications aimed at (potential) customers and/or consumers, you may want to give them access to limited functionality before trying to convert such users into registered users.

The second possibility is to authenticate your application users locally in your application; completely independent of any identity they may have already in any ecosystem or Identity Provider (IdP). Login with username and password is built into the core capabilities of a Mendix application (see Login Behavior as provided by the Mendix Runtime). Password reset functionality can be catered to by using the Forgot Password module as a building block. You can strengthen such local authentication using an MFA module from the Mendix Marketplace or with custom logic as well.

The third and most used authentication method is to delegate the user authentication to an external application that acts as an Identity Provider (IdP) via Single Sign-On (SSO).

How does Mendix support single sign-on (SSO) for my low-code applications?

Single sign-on is a user experience based on capabilities in both applications and the Identity Provider (IdP). With the Mendix platform, even citizen developers can build SSO-enabled applications. SSO is supported for regular Web Applications, Progressive Web Applications, and Native Mobile applications and can be enabled using the right SSO modules from the Mendix Marketplace. Mendix provides you with full Platform Support on these modules.

SSO capabilities are not limited to any deployment model. Whether you choose to deploy your Mendix applications on the Mendix Cloud, a partner cloud, your own private cloud, or even on-premises, SSO is supported. Mendix’s SSO capabilities do not depend on any identity services provided or hosted by Mendix.

Mendix provides support for today’s open standards for SSO: SAML 2.0 and OpenID Connect. Mendix developers can download the applicable modules (i.e. OIDC SSO or SAML) from the Mendix Marketplace and include these as a building block in their Mendix application to get the required SSO functionality. For native apps, the Mobile SSO module is needed. In addition to SSO based on the open standards, Mendix also supports SSO for applications running on the SAP Business Technology Platform (BTP); Mendix provides an XSUAA Connector for SAP BTP for SSO with the SAP identity infrastructure.

How can I have Multi-Factor Authentication for my Mendix applications?

The most common approach for Multi-Factor Authentication (MFA or 2FA) is to enable SSO in your applications and let your IdP enforce MFA during user login. If you authenticate your application users locally in your Mendix application, you can extend the default username and password validation with a second factor using one of the modules available in the Marketplace.

Which Identity Provider Solutions can I use with my Mendix applications?

You can integrate your Mendix applications with most Identity Provider solutions (IdPs). Existing Mendix customers have integrated their applications with Microsoft’s Entra ID (formerly known as Azure AD), Auth0, Ping, ForgeRock, AWS Cognito, Google, Salesforce, Apple, Okta, Ping, SAP Cloud Identity Services, Facebook, LinkedIn, KeyCloak, and AWS IAM Identity Center.

Any technology that supports common open standards (e.g. OpenID Connect, SAML v2.0) can be integrated. For example, the more advanced features in the SAML module allow for integration with IdPs that demand a higher level of security by utilizing the more secure ‘artifact binding’. Customers in the Netherlands, for example, are using this to integrate their applications with the government-regulated IAM infrastructures DigiD and eHerkenning, which are schemes based on the European eIDAS regulation.

How can I define user roles for my application?

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

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

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

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

How are user roles assigned to users in my app?

Every Mendix application has one or more user roles; which can be assigned to your application users in multiple ways.

The most simple way of assigning user roles is to include the Administration module in your application and have an admin user assign user roles to application users, manually.

The most used way of assigning user roles is to leverage your Identity Provider (IdP). When an application user logs in to your application via Single Sign-On (SSO), the IdP will typically provide information about the user and this information can be used to automatically assign a user role to the user. The SSO modules come with a few defaults to do so, and low-code developers can easily implement their own custom logic to assign the user roles. Such custom logic would be a semantic interpretation of the information provided by your IdP; which can take the form of assertions, claims, attributes, scopes, and roles, depending on the protocol and features used.

The latter approach has the obvious benefits of automation and central governance of authorizations. Larger organizations will want to automate their Joiner-Mover-Leaver processes, especially with a large number of applications and application users.

How can I provide an SSO experience to my multi-application solution without IdP integration?

When building a Business-to-Employee (B2E) solution, you typically achieve Single Sign-On (SSO) by integrating your SSO-enabled apps with your corporate Identity Provider (IdP). However, when building a Business-to-Consumer (B2C) or Business-to-Business (B2B) solution, integration with an external IdP may not be possible, desirable, or simply too costly.

The ‘simple’ approach would be to build a single Mendix application with local user login. Depending on the complexity of your solution, you may want to build a multi-application solution for better maintainability of your solution. You then face the challenge of providing your application users with an SSO experience across multiple applications. Mendix helps you to build such a solution where one of your Mendix applications acts as a portal application where your application users login. This portal application will be a central application that acts as an IdP for the other applications.

To do this, the Mendix Marketplace provides the so-called OIDC Provider module that can be included in the central portal application. An application user would sign in to the portal application (for example using a local username and password), navigate to other connected applications, and gain access without friction.

How can I create users in my Mendix application? And how can I deactivate or remove them?

You can choose between various approaches to do user-provisioning or onboarding of your application users.

The simple approach is to have a local ‘admin’ user create users manually in your app. The Administration module, available in the Mendix Marketplace, helps you build such a solution.

Users can also be created via so-called Just-In-Time (JIT) user provisioning. If your app is SSO enabled, a user who signs in for the first time can be automatically created in your app based on the user information provided by the Identity Provider (IdP). Your low-code developers can use the default user provisioning logic, which is included in the SSO modules, or they can create custom logic to do so.

When using JIT user provisioning, your IdP can apply access logic and deny access for certain users; hence controlling which users are created in your app. JIT user provisioning is flexible, easy to implement, and may avoid manual user provisioning. The downside is that this SSO-based mechanism cannot deactivate or remove users from your Mendix applications.

To deactivate or remove users from your application you have two options. The first is to go with local user administration where a local ‘admin’ can do user management locally in the Administration module. The second and better option is to integrate your Mendix application with your IDP and let that integration do the work. Applications can be integrated with an on-premises IdP via the LDAP protocol. A more modern approach is to use a SCIM integration. SCIM is an abbreviation for System for Cross-domain Identity Management. It is an open standard that is supported by most IdP solutions, such as Entra ID, Okta, and Ping. The Mendix marketplace provides an LDAP module and a SCIM module for your low-code developers to use.

How can I easily scale without IAM slowing me down?

If you plan to develop many Mendix applications, how can you avoid or minimize the need to repeat certain tasks? In the domain of IAM you can do the following:

1. First, create a starter template with the IAM modules of your choice.
2. Second, try to avoid customizing the IAM modules. If you do need a customized version, distribute it to your developers using your Private Mendix marketplace and starter template. Also, contact Mendix Product Management via your Customer Support Manager (CSM), to learn if your customization can be productized. Once productized, you don’t have to re-implement your customization when a new version of your IAM module is released by Mendix.
3. If you need custom user provisioning or custom authorization logic, put those custom microflows in a separate custom IAM module which you can distribute to your developers via your Private Mendix Marketplace and your starter template. Reuse of such custom logic prevents duplicate customization effort and maintenance.
4. Use the IAM modules’ design-time and/or deploy-time configuration possibilities. Your pipeline can move your app from one staging environment to the next and automatically connect it to the applicable test or production IdP.
5. Consider creating an SSO broker solution. Setting up SSO between your app and your IdP may require manual steps, and procedures may slow down the innovation. With an SSO-broker solution, your pipeline can automatically register Mendix applications at the SSO-broker and leverage a single SSO connection between the SSO broker and your IdP. You can build an SSO broker using the OIDC Provider module.