First we need oblige that the reasons for restricting access can be manifold. It may be as simple as to avoid confusing a user with too many options at the wrong time in the process – or it may be as crucial as to protect highly secretive information getting in 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 in this particular moment. And at other times we do not even want to show you that a given action exist 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 – so this is one way to make actions disabled. But if we have a rule that is the same for many actions we may consolidate the rule to an AccessGroup;

The accessgroups are good for the static rules like to check is 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:

And we may also want to give the user a hint 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 also have the possibility to work on the whole view:

Setting the Readonly expression on this level effects 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. In order to allow for you to disable an action that would bring up a view that has an access expression that will evaluate to false given a certain root object – you may check the result of the Access expression prior to 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. This also enables you to stop reports from being created based on a ViewModel and a root object that is not allowed based in 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 the ocl rules use a few ocl-operators but mostly names from your model that probably is an 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 in order to protect their information and still allow for a fast-paced development.