|Visual Guard for .NET
James discovers that adding security to an application can be remarkably
BY MIKE JAMES
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
Dim login As
If login.ShowDialog() = _
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
||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
|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
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
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.
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