A lot of Mendix app developers are rightfully excited when they need to implement security; Mendix provides for the common options directly in the Business Modeler and in addition, there are modules such as LDAP and SAML that can be included into an app to take advantage of SSO. But what if you need to run security in the application but need to add customizations above and beyond what is provided in the default Mendix setup? I’m going to show you a few common requests that security teams ask for and show you how to implement them in your application.
First let’s establish what Mendix provides in the default application. In addition to the roles and how they are defined in each module of the project, a developer can set password policy requirements. You can set the minimum length, require digits, require mixed case, and require a symbol.
Beyond this policy lies additional policy requirements that in my experiences require me to develop custom solutions with Microflows and sometimes Java Actions. Here are a couple of those requests and how I dealt with them.
Deactivate an account after N failed attempts
Mendix applications will block a user’s account after three successive failed logon attempts. That block is primarily useful for stopping brute force attacks. After five minutes, the account is reset as no longer blocked and the user can try again (three times). A security team might ask that you deactivate the account as well so it requires an activation by an account administrator. To do this, it’s a simple ‘Before Commit’ event handler that looks like this:
Just be sure you don’t “commit” the account change or you’ll end up with an endless loop!
Password Expiration
Another common security request is to expire passwords after N days since the last update. You could leverage that field to expire passwords as most often an account won’t change once setup, but if you want to purely expire passwords based on password changes, you’ll need to add a datetime attribute such as ‘LastPasswordChange’.
In addition, create a boolean in the Account (or specialization of the Account entity depending on how you built your domain) called ‘ExpiredAccount’ defaulted to false.
Once you’ve established the datetime stamp attribute you want to use, build a scheduled event that runs daily. In this microflow, retrieve accounts that are “addDays(yourDateTimeAttribute,-ndaysVariable)”. Loop through the returned list and set the ‘ExpiredAccount’ Boolean to True.
Setup your project Navigation so that user roles default login pages point to a microflow. If the ‘ExpiredAccount’ is false, “Show Page” or whatever you need for the logon process that lands a user on a particular page. If it is ‘true’, call a sub_microflow that does the following:
- Show a “Change Password” page.
- If they successfully setup a new password, change the Account.ExpiredPassword back to false and point them back to the homepage, which will route them through the same role-based homepage as before except this time they will land on their respective pages.
- If they fail to create a new password because they don’t match or whatever criteria you build, the account will remain expired and they won’t be able to get in until they change the password.
These are two common examples of custom security settings. Next post I will show a couple of more complicated settings: No reuse of N passwords, and require a Password reset upon logon after an administrator resets an Account’s password.