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

Most line-of-business applications will require only a small number of security measures - for example, only some staff will be allowed into the maintenance menu to change values such as prices stored in lookup tables. A smaller number of staff still might be allowed into the security menu to change the details of who's allowed to do what, and only supervisors might be allowed to change some values on the main forms. Whenever the application comes to display a form containing something that's security controlled, it will have to check whether this menu item or control should be enabled, read-only, disabled or hidden from the current user.

While the names of the users, and the groups to which they belong to, can be gathered from the Windows environment and the network's Active Directory, the settings that determine who has what access to which menu or control would still be better stored within the application's own database. However, if you also store the list of which controls can be secured in the database, you run the risk that a new version of the application will introduce a new secured control without any data in the database to enable the security to be controlled. Instead, it is better if you put the data about what items can be secured into the code itself, so it cannot ever get out of sync with the database.

You can use a public Enum to define the security levels, which makes the code much more readable:

Public Enum SecurityLevel

Undefined = -1

Enabled_ReadWrite = 0

Read_Only = 1

Disabled = 2

Hidden = 3

End Enum

(Note that you have to write Read_Only with the underscore because ReadOnly is a reserved word in Visual Basic .NET.) You can then define a global variable to hold a data table containing details of all the controls that can be secured, the default security level for each control and its security level for this particular user (see form table on page 5)

With a strongly typed data table defined in your dataset, this becomes very easy - just put:

Public gdtSecurityControls As New dsProjects.SecurityControlsDataTable

in the declarations of your main module. In the InitializeSecurity method called from Sub Main(), put the few lines of code needed to define what can be secured, such as:

gdtSecurityControls.AddSecurityControlsRow("Main", "Maintenance Menu", "Menu", SecurityLevel.Disabled, SecurityLevel.Undefined)

Next, you need to get the current user's name and find out from Active Directory which groups they are a member of. The .NET Framework contains a whole namespace of objects for dealing with Active Directory, called Directory Services, and one of these objects is called a DirectoryEntry. Using the Lightweight Directory Access Protocol (LDAP) it is easy to construct the path to a particular user's directory entry - the Common Name (CN) will be their username and the network administrator will be able to tell you which Organisational Unit (OU) the users are in. The rest of the path would consist of two or three Domain Component Name (DC) entries to fully qualify the domain, so for example 'yourdomain.co.uk' would be written in the code as 'DC=yourdomain,DC=co,DC=uk'.

Dim objUserEntry As New DirectoryServices.DirectoryEntry("LDAP://CN=" & Environment.UserName & ",OU=Domain Users,DC=yourdomain,DC=co,DC=uk")

Creating a DirectoryEntry for this user gives you access to all the properties of their entry and one of those properties, called 'memberof', is a list of the groups of which this user is a member. Note that if you specify a path that does not exist, a wrong username or OU, then the DirectoryEntry object will still be created but accessing its properties will cause an error, which should be trapped.