This has come up quite a bit for me recently as I’ve been attached to multiple new Mendix projects. I get asked about roles, read/write, prototype vs production, and then the big question: How to add additional layers beyond what Mendix provides out of the box? Given the scale and scope of this topic, I’m going to break it up into a series of posts to help make all of you out there masters of security within Mendix. This first post is going to deal with Roles.
The cornerstone of all security models, Mendix or not, is the concept of Roles. A Role is used to separate an account by the type of work to be performed in the application. At its most simplistic (which is what Mendix delivers “out of the box”, an application will have two roles: An ‘Administrator’ and a ‘User’. Wouldn’t it be nice if that was as complex as your security needed to be?
In the Enterprise, however, this is far, far from being all that is needed. A typical application will require 5 to 10 roles, but do not take that as a hard and fast rule. You’ll find out why as this series progresses and the needs of the business get more and more complex. But running for now with typical use case, what are these typical roles?
Administrator
First, let’s break down the ‘Administrator’. In some cases, your application might have one or two people responsible for the administration of it. You can get away with just the single ‘Administrator’ role. But if you are developing an Enterprise solution, you might find yourself breaking it down into the following groups:
- Department Administrator
- Systems Administrator
- Client Administrator
- Account Administrator
- Etc.
Each of these roles will require different rights and limits to their powers. For example, the Department Administrator will need read/write on the Department entity to create or edit the Departments as well as the Microflows that allow their assignment to other data in your domain models, but they won’t require access to the Account entity in order to manage users.
User
This common role is the first to be replaced by a host of new roles. ‘User’ never cuts it. If you have any workflow in your application at all you are going to need at least two user roles; one to create content and the second to receive the content. Examples of user roles are much more diverse than administration because they depend entirely on the focus of the application. For example, a Car Dealership app might need roles such as Anonymous, Lead, Customer, SalesAgent, SalesManager, Financier, etc., whereas a Hospital Record Management app might require roles such as Patient, PatientGuardians, ClientServiceAgent, Provider, etc.
User roles are the most diverse but usually the easiest to define. You simply translate the business terms used to define people in conversation into roles in the system. When your app business owners describe their process, they might say something like, “The form is handed off to the Administrative Assistant who completes their processing and emails it to Financial Analyst”. Right there you’ve heard two different roles needed in the application if you are attempting to recreate an existing process within your app. Which brings up the next crucial piece in designing your app: Recreation vs Overhauling.
Continuous Improvement (CI) of User Roles
What do I mean by these terms of “Recreation” and “Overhauling”? When you are designing your app, I bet 90% or more of the time you are being asked to recreate an existing set of processes. The goal is to make those processes digital. There is a lot of value in that in terms of storage, record keeping, audit accountability, visibility, etc. That’s why most applications just recreate what the business already does, and that’s OK. In fact, that’s the very business problem RAD tools like Mendix help address; Get it done quickly and move on to the next business process.
What is better than OK, though, is Overhauling. Taking the time before designing and developing an app to ANALYZE the current process could lead to major breakthroughs in performance gains, removal of non-value added processes, and features before thought to be impossible. For example, maybe that processing the Administrative Assistant in my previous example doesn’t need to be done because the application could handle that and route to the Financial Analyst automatically. Now there is no need for the Administrative Assistant role in your application, reducing the real world burden on the AA as well as simplify your security model design, implementation, and maintenance.
You almost never get the opportunity to do CI work before starting which is a real shame that currently speed is being prioritized over optimization by such a wide margin. It might not be your expertise, but everyone is responsible for CI. Don’t be afraid to think a bit out of the box and challenge the business problems and stakeholders accordingly if you see opportunities for improvement. One of these days I’ll get around to writing about ways to do CI using actual tools to help make data-driven decisions but for now just be aware that while you are thinking about Role development in your application you will have a great opportunity to insert some of these ideas for CI into your designs.
Next time I’ll write about using these roles to properly setup Read/Write accesses within the entities of the domain models.