Training:Security

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

One importing 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.

And 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 users 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 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 at any time check if the current user fulfills some requirement like:

SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

This means that 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 shows up in their own dialog:

() x3

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 you 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 reducing 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:

()