Overview

This module increases the security of your Mendix application by completely blocking all local login attempts on the Mendix runtime. By disabling so-called local logins at the back end (Java level), it ensures that users can only authenticate through approved mechanisms such as Single Sign-On (SSO) using SAML or OIDC.

The module is lightweight, effective, and specifically designed to protect against brute-force password attacks. Because login attempts are blocked before password validation occurs, no database connections are used, keeping system load to a minimum even under attack.

The solution operates entirely behind the scenes and does not affect the front end. Existing login pages, widgets, and user experience remain unchanged, making integration straightforward and low risk.

Advantages:

• No additional security measures required, such as rotating passwords or removing the MxAdmin user.
• No monitoring, alerting, or manual intervention needed to detect malicious login attempts.
• Minimal performance impact, even during brute-force attacks.
• Ideal companion for SSO-based authentication strategies.

This module is a practical security hardening measure for any Mendix application relying on external identity providers.

Documentation

Goal

This module improves the security of your Mendix application by blocking all login attempts handled by the Mendix runtime, also known as local logins. It is a lightweight yet effective measure against brute-force password attacks.

The module is intended to be used alongside alternative authentication mechanisms such as Single Sign-On (SSO) via SAML or OIDC.

The solution operates entirely at the back end (Java level) and does not affect the front end. Existing login pages, widgets, and user flows remain unchanged while all local authentication attempts are blocked.

Advantages

• No additional security measures required, such as password rotation or removal of the MxAdmin user.
• No monitoring or alerting needed to detect malicious login attempts.
• Minimal system load during brute-force attacks, as no database calls are made to validate credentials.

How to use

Required model changes

1. Add the microflow ASu_DisableMendixLogin to your After startup microflow.
2.  For multi-instance deployments, this must be configured for both leader and worker instances.
3. Optional / conditional:
4.  If you expose published APIs (such as REST or OData services) that use Basic Authentication, these requests will also be blocked.
   • If only one service account is used, configure the MendixLoginExceptedUsername constant to allow this account.
   • If multiple accounts are required, configure the published APIs to use Custom authentication and reference the microflow PRS_Authenticate_BasicAuthenticationUser.
   •  Note that allowing exceptions reduces the overall effectiveness of this module. Using a different authentication method for APIs is strongly recommended.

Configuring constants (no changes required by default)

1. MendixLoginDisabled
   • Default value: true
   • When enabled, all default Mendix logins are blocked and an alternative authentication method (such as SSO) is assumed.
   • Setting this to false fully disables the module and should only be done temporarily (for example, during troubleshooting).
2. MendixLoginExceptedUsername
   • Allows exactly one username to bypass the login restriction.
   • Intended for exceptional cases such as an administrator or test user, for example to configure SSO.
   • Leaving this empty is strongly recommended, as any exception weakens the security guarantees.

Dependency

• CommunityCommons