Training:Access control system in MDriven

First, we must agree that the reasons for restricting access can be manifold. This may be as simple as avoiding confusing a user with too many options at the wrong time in the process – or it may be as crucial as protecting highly sensitive information from getting into the wrong hands. Any practical Access control is probably based on static information as “users belonging to group Fishermen should not have access to view Treasury”, but also dynamic information as “if a Fisherman has been granted payment but not collected it yet then he should be able to open the view Treasury”.

Another aspect is that we sometimes want to show that actions are available – but not enabled to you at this particular moment. At other times, we do not even want to show you that a given action exists in the system. These are all common requirements when dealing with access control. Since MDriven solves all user interaction through ViewModels and Actions, it is natural that these are our targets for Access Control.

We can set any expression in the Enable expression of an action – this is one way to disable actions. But if we have a rule that is the same for many actions, we may consolidate the rule to an AccessGroup:

Accessgroups are good for the static rules like checking if the logged-in user is part of the fisherman group:

SysSingleton.oclSingleton.CurrentUser.SysRoles->exists(name=’fisherman’)

For actions, we can set the Enable expression for more precision:

We may also want to give the user a hint as to why the action is disabled – this ability has reduced the support requests a lot in all the projects we have done:

For views, we refine the access control per placed widget by setting the ReadOnly expression or/and the Visible expression:

But in views, we can also work on the whole view:

Setting the Readonly expression on this level affects all the widgets in the view. Setting the access expression will control if the view is shown at all.

If the view’s Access expression evaluates to false, the system will look for a ViewModel named AccessDenied and if found, will show this instead. If no AccessDenied view is found, then a blank screen will show. To allow you to disable an action that would bring up a view with an access expression evaluating to false given a certain root object – you may check the result of the Access expression before bringing up the view. You do this with the OCL operator canAccess(vmname):bool

This enables you to disable actions that will end up showing AccessDenied and to stop reports from being created based on a ViewModel and root object that is not allowed based on the Access expression of the ViewModel.

Working with the described levels of expression, you will be able to tailor a perfect fit access control system that evaluates in the safe realm of your server. All OCL rules use a few OCL operators but mostly names from your model that are probably in a ubiquitous language shared with the security officers of your domain. The transparency and fine-grained control of this access control system is precisely what many organizations need to protect their information and still allow for fast-paced development.