Gallery

Application security

Posted on 17 Jan 2005 at 17:52

Simon Jones uses Windows facilities and Active Directory to implement workable levels of security in applications

Adding security to an application in practice means granting or restricting access to particular menu items or controls on forms to certain users, or groups of users. Often in the past, this list of authorised users of an application would have been held within the application itself, and therefore each user had to sign in to each application separately. The administrator for each application kept a separate list of users, groups and access rights for administration purposes, which was complicated and time-consuming.

However, why should you bother to get each user to sign in to your application when they are already signed in to the Windows network? Enforcing the choice of secure, frequently changed passwords and password verification on return from screensaver are all good security practices, and all are easily accomplished using Group Policies within Windows. Providing you trust the users not to hijack each other's machines, this is usually good enough for a business application.

Here's a checklist of the measures that you need to achieve a workable level of application security, all of which can be implemented using Windows security groups and the Active Directory:

Strong passwords (require mixed case and inclusion of number and punctuation characters)

Changed monthly

Warning five days before expiry

Screensaver on

Trigger screensaver after five minutes idle

Prompt for password on return from screensaver

Users not allowed to change screensaver settings

Train users to lock their workstations when leaving their desks

Train users never to disclose their password to anyone

Of course, if you are dealing with safety critical or financial systems you may want to be more secure than this list implies, but I personally do not think having a second password helps. If you set passwords for individual applications, they are most likely to be written down or disclosed to other users. People are more careful with their single password that identifies them to all their applications, gives access to their email, and so on. If you need further security, then you would better start considering hardware solutions such as smartcards, thumbprints or other security devices.

There is another valuable advantage to using Windows facilities to implement your application security: if you insist on maintaining separate user IDs for each application, you increase the likelihood that someone's username and password for an application will remain active long after that person has left the company, whereas if all security is tied to the Windows username, there is only that one thing to disable whenever someone leaves.

Not maintaining a list of permitted users within your application means one less thing to worry about and to code up. Instead of asking each user to identify themselves to your application, your application can just pick up the name of the current user from Windows, which is stored in an 'environment variable' and can be read from most programming languages. In Visual Basic .NET, the command to do this is just Environment.UserName(), while in Visual Basic 6 and Visual Basic for Applications you would use Environ$("Username"). This makes it easy enough to find out who the user is, but how do you check that they are allowed to run your particular application, or indeed which functions within the application they are allowed to use? For this, I would suggest using security groups and organisational units in Active Directory.