Application security is such a problem that most developers prefer to ignore it. If ignoring it is impossible then we often implement a custom solution with user lists and passwords, or we simply expect the user control provided by the operating system to do the job. What we generally end up with is something that might appear to do the job but which is in practice nearly impossible to administer and quite impossible to validate. Visual Guard for .NET puts an end to this shoddy approach to security by making it trivial to implement and by providing good administration tools, and it works for both desktop applications and ASP.NET websites.

What is really surprising about Visual Guard for .NET is how easy it is to add to an existing application, and how widespread and fine-grained the resulting security is. Using reflection Visual Guard can reach inside your code and apply access rights to individual objects, selectively disabling features according to who is using your application – something you might have assumed needed you to make changes to your code. Indeed all you have to do is to add a few references to the Visual Guard assemblies and place the occasional line of initialisation code and add a user/password style logon form. A suitable logon form is provided for you to use, but you can opt to create a custom form. You really don’t need to make any changes to the architecture of your program, and you certainly don’t need to have had security of any sort in mind when you created it.

If you do opt to use the supplied form then adding Visual Guard is just a matter of changing the Main method, i.e. where your application starts to read:

Dim login As New VGLoginForm
If login.ShowDialog() = _
          DialogResult.OK Then
     login.Dispose()
     Application.Run(New MDIForm)
End If

This displays the login form which asks for user name and password, if it returns the OK dialog result then it’s ok for your application to run, i.e. the user has been authenticated. This protects access to all of the forms in your application, and if this is all you want to do your programming task is complete!

Visual Guard automatically detects the instantiation of forms and applies the protection that you have selected. Protecting other types of object is also easy, however. You simply add the VGISecurable interface and a call to SetSecurity in the constructor of any class you want to protect. You don’t have to implement any methods in the VGISecurable interface; it simply determines which classes are visible in the administration console – see later.

You can select any form from the list to assign permissions		Once selected you can set any property of any control on the form to any value as the result of the action
enlarge the picture		enlarge the picture

Administration

An administrator can manage users and assign them appropriate permissions using the console
enlarge the picture		As soon as you have made the minor changes needed to implement Visual Guard you could pass the task of administering the security to someone else. They don’t even really need to know anything about your program. In most cases, though, the developer probably would set up an initial configuration. All administration is performed using the Visual Guard Console. Your first task is to set up a repository which contains all the information on the users and their permissions. You can select either Visual Guard’s own built in authentication, standard Windows authentication or database authentication. Each has its advantages in different situations. You can add users and define permission sets and roles. A permission set is, as its name suggests, is a list of permissions that can be applied as a whole. Permission sets can be contained within permission sets, so making it very easy to establish a hierarchy of permissions from none to everything. However it should be equally obvious that you don’t have to organise things hierarchically if this doesn’t suit. A role is essentially a group of users all assigned the same permissions. The idea here is that you create roles that correspond to the people and departments within the company using the application – so a role could be a sales person who is allowed to enter orders but not to modify existing orders, for example. Notice that users are defined independently from the application they are being given access to, and each user can have more than one role – which applies can be selected when they log on.

Much of creating users accounts and roles is a standard and familiar administration task and highly delegateable. The area that you might not consider quite as delegateable is the setting up of the permissions. Not that this is difficult, but someone who has a good knowledge of the application has a better chance of doing a logical job of working out what should be controlled. For example, you can determine that a particular button on a particular form should be disabled to restrict access to some facility. You don’t have to assign this permission and you don’t have to group it into a permission set at this stage – simply make it clear that this is a critical facility and needs to be controlled.

It seems almost magical that you can decide to enable or disable a button from outside of the application, but this is the advantage of being able to use reflection to get inside the application and get and set properties. A permission is a set of actions, such as setting the enabled property of a button or menu item to false or setting the visibility of a data column to hide a field, that Visual Guard will carry out on the application before allowing a user with that permission to work with the object. Two types of action are supported: property actions which simply set a property belonging to an object to a specified value; and script actions which can be much more sophisticated. You can use either C# or VB to create a script action. In many cases the simpler property actions are all you need to secure an application.

Creating a new permission is just a matter of picking from a list. You can select property or script action and Visual Guard then presents you with a list of objects in your application – forms or web pages are likely to be the most common object that you are going to apply permissions to, but any class that has the VGISecurable interface applied will appear in the list and can be modified.

Notice that not only can you disable features of the user interface leaving them greyed out, you can also customise the interface by hiding controls. You can also pick an event that will trigger the action. Usually this is just before the object loads, but you can select to tie the action to any of the usual events that an object supports, mouse down, mouse up, etc. A further level of sophistication is that you can set a condition that has to be true for the action to be applied. For example, you could arrange to apply the action only if the control was visible. Finally you can edit any of the properties of any of the controls in a form or web page. You can set as many properties on as many controls in a single action as you care, and the editor works in much the same way as the Property window in Visual Studio, allowing you to select property values where appropriate.

A script action can be set up in more or less the same way but, instead of editing properties as the final step, you are allowed to type into a code window. Here you can do almost anything you want to the object in question as the method that you are typing into executes within the application when the action is triggered. In most cases you should be able to protect an application with just a few simple actions (e.g. disabling buttons and hiding data and options), but it is reassuring to know that you can do more if it’s really necessary.

Once you grasp the power of the mechanism you can’t help but wonder if there are other uses for it as well as securing applications? It’s a sort of aspect oriented programming that allows code injection using visual editors – all very clever!

Once you have permissions and permission sets the only job that really remains is working out who should be allowed to get at what. It is also going to be easy to administer on a day-to-day basis, as long as you define roles in a meaningful way, e.g. sales people access features that are relevant to sales and nothing else.

Conclusion
Visual Guard for .NET is a product worth knowing about. In one easy-to-use package it solves all your security problems almost without putting you to any effort. It also creates a security environment that will be familiar to network administrators and so gives you the opportunity to delegate much of the initial set-up and all of the day-to-day administration. And I almost forgot to mention that it has reporting, logging and auditing facilities that should keep the admin very happy! It’s a very clever idea, it’s well implemented and I don’t think I’ll worry about designing security into my applications ever again.

_ In addition to his roles as hands-on developer and editor of VSJ, Mike James acts as network administrator for a distributed team of consultants and writers. He is therefore all too aware of security headaches.

APRIL 2008 - VISUAL SYSTEMS JOURNAL - WWW.VSJ.CO.UK