Once you have your system in place and it is protected from all harm, you will want to let users in. The users should probably have different access rights and different abilities to look at and change data.

One important fact to achieve this is to make the current user available to your model. The current user is however handled differently by different implementation scenarios – like on the web or on the desktop.

Even for a particular scenario, there are several approaches to identify the user – like using federated authentication, local active directory authentication, Forms authentication, etc. Be that as it may, however, the chosen platform identifies the current user – you will want to have access to that user in the model.

In ASP.NET Identity, this is the model that covers the user and the user's claims:

I also added a Class called SysSingleton. Singleton is really the name of a design pattern that establishes a Class that will only have one object instance. Thus, it is THE Singleton. The Singleton pattern is very handy in situations where you do not have any other context on how to get data. It is so handy that OCL has its own operator for Singleton. In this case, SysSingleton->oclsingleton will give access to the only instance of SysSingleton. If there is no instance at the time of calling oclSingleton, one will be created (maybe only done on the first system use).

In the model above, I added a derived link that says that my SysSingleton points out the CurrentUser.

When I have this, I can check at any time if the current user fulfills some requirements like: SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

This means that the Enable and Visible expressions on ViewModel Columns and Actions and even derived attributes can use this information to enforce information security.

But since it is likely very common to check if an action should be enabled or not for a certain type of user – or if a ViewModel should be accessible or not for this user, another concept is introduced: AccessGroups.

AccessGroups show up in their own dialog:

You can have as many AccessGroups as you see fit. They will show up in the section marked with green in the dialog above. For each AccessGroup, define expressions in the blue section. The expressions should evaluate to true or false and state whether Enable, Visible, and View should be true or false for the things in the group. The things in the group are actions and ViewModels – defined in the purple section.

This way, you can define a group like MustBeAdmin and add all appropriate actions to this. You can also add ViewModels. This is a good way to have all your access rules in one place and reduce the need to repeat their definition in multiple places.

There is also an AccessExpression on each ViewModel. This allows you to test not only on user credentials – but also on the root object of the ViewModel. If it returns false, the AccessDenied ViewModel will be shown instead:

The MDriven Book - See: Information security