Last time in this series, I wrote about the concept of roles and ways to design roles for a Mendix application. This time I’m going to talk about implementing security in the Entity and how that compares to setting up security in the User Interface (UI).
As mentioned, there are two layers of a Mendix application’s security: Entity level and Form/Page level. Entity level security focuses on access to the data only whereas UI level security can be limited with constraints on the data based on roles, but it can also restrict access based on other values in enumerations or Booleans. More on that in a bit. First, let’s explore Entity-level security.
ENTITY-LEVEL SECURITY
When constructing your domain model, each entity that you create has a host of tabs and features associated to the construct. Where I am focused is the ‘Access Rules’ tab.
Once you’ve defined your roles and set them up in your module and changed your project security settings to “Production”, you will need to setup access for those roles in this tab of your entities. In this example, you see I have three separate Access Rules defined for my Administration.Account entity. Let’s take a closer look at these.
The first one is the set of roles that I’m allowing to created and modify Accounts. I selected the roles that I want to apply this ability, I determine that I do want them to be able to create new Accounts and even delete Accounts, and then I allow them the ability to both Read the attributes of an Account and Write (change) those attribute values. The idea of this particular role is that I wanted to show that your admins and super users that own a particular set of data should be given these rights in order to properly manage the data they hold.
The second Access Rule is the most restrictive in this particular entity. The goal of this Access Rule is to allow a user to edit details of their own Account only. Notice that this rule doesn’t allow any creation or deletion rights, and focuses on the attributes that they are allowed to modify with reads and writes. For example, the UserRoles_Backup association is a feature where upon expiring a user’s account for various reasons, the system saves the user’s Role’s to this backup association and sets their current role to ‘PasswordExpired’. That enables us to route them to the password reset screen upon a successful logon attempt where we need them to change their password. Once changed we retrieve the data from the backup association and restore it to the user’s current role settings. A User has no reason to interact with that association so we do not allow them access to read or write to it since we handle that with system microflows.
What makes this unique is the additional Xpath constraints in this Access Rule. By adding the Xpath constraint of [id = ‘[%CurrentUser%]’], we are setting the system so that this rule only affects the Account for the Current User trying to make a change.
The third Access Rule is also for the same role as the second Access Rule: ‘User’. What this rule does is allow every Account (because Account is a generalization of System.User so this affects all Accounts) to read the ‘FullName’ of any account retrieved. Therefore, any form or page in which you list or show the attribute of ‘FullName’, your users will be able to see the value. Otherwise they would just see a blank field.
IMPORTANT INFORMATION ABOUT ENTITY ACCESS!
Whenever you create two or more Access Rules that impact the same Role and the rights defined conflict (such as one has no access but the other has ‘Read’ access),
THE HIGHEST LEVEL OF RIGHTS WILL BE GRANTED!
This was a learning curve for me because in the world of BI, the opposite is true. Keep this in mind when designing your security model so that you don’t have to redesign it like I did!
UI LEVEL SECURITY
In the other layer of your application (the UI), you also have a host of options to restrict access to items in the UI. Nearly every type of widget or field placed on the page can be set to viewable or not-viewable based on four factors:
- A Boolean in the enclosing dataview
- An Enumeration in the enclosing dataview
- A Module Role in which the page is housed
- And finally if you use the DataGrid Extender, there are a host of additional show/suppress/CSS options available to you as well for columns in a datagrid object.
I suppose I could add a fifth if you build your own custom widgets or leverage Javascript in your HTML for specified classes on pages, but that is way outside of the scope of what I’m trying to cover.
UI security is also impacted by the roles setup in Microflows that a user is viewing or triggering in the UI. If their role doesn’t allow them to execute the Microflow, they won’t be able to see the button/link/label/etc. associated to the Microflow on the page.
Finally, each one of your datasource retrieves in your UI can be constrained with Xpath as a means to enforce UI security.
THINGS TO CONSIDER
Here is a quick cheat sheet on some basic pro’s and con’s of implementing security restrictions on the Entity versus the UI.
Entity
Pros
The rules are always applied unless a Microflow does not enforce it. This means that any retrieve of database data will be limited by these rules, whether it is a datagrid retrieve, an OQL query within the tool, an OData service, etc.
Change Once Affect Many principle is applied, meaning that all pages and forms (or external web services calling a retrieve) will be impacted by the change, rather than having to go update lots of pages or other objects that restricted based on Xpath.
Read, Write, and No Access control of every attribute.
Cons
It can be a performance issue. If you have lots and lots of Access Rules in your application, every retrieve will have to wait for the database to apply all of the levels of restriction checks every time instead of just fetching the specific data you might need.
UI
Pros
Only restrict at time of use to improve performance.
Allows unique visibility and data constraints each and every time instead of broad Access Rules
Allows restrictions based on Booleans and Enumerations
Cons
High Maintenance to keep track of
Doesn’t impact Read or Write, just simply a View/Not View level of security
There you have it. I think I’ve given you a lot to consider when designing your security model enforcement policies. I hope you can use this as a guide for your applications to help you build a robust and secure application that considers the long-term effects on your development team and users.