Visual Guard for .NET
Mike James discovers that adding security to an application can
be remarkably easy
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 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
|
Request a trial version of Visual Guard!