o you really think user interface security comprises slapping a login screen in front your application the way you’d slap cheese on a turkey sandwich? For some of you it will suffice, after all, all things are relative. What one considers to be secure another may find woefully inadequate. Thus, the interpretation of security is a matter of perception. One rule of thumb used to determine the appropriate level of security is to analyze the costvalue relationship: In essence, so long as the cost to circumvent the security is higher than the value of the assets secured, the system is deemed sufficiently secure (government secrets and the bank accounts of the authors are notable exceptions).

With this in mind, this article is fashioned for those who are on the long, perilous road toward the security of singularly valuable assets. It is not for the faint of heart. An encompassing knowledge of authentication (identification) and authorization (principles) and the ability to apply them to the underlying operating system and the development environment (.NET) are prerequisite. In short, the concepts in this article are not for the tyro .NET developer.

For those who are up to the challenge, here’s what you’re in for: We will explore one approach to building a generic user interface framework to enforce authorization-based security for Windows applications. There is one caveat: We will restrict our discussion to the security of the user interface of the application, which is intended only as an additional layer of security. It is insufficient to simply lock down the user interface of an application if the business objects (and the underlying data engine) are left unsecured. Even a neophyte hacker can create a new user interface to call into unsecured business objects thereby bypassing any UI-based security discussed herein. But, you wouldn’t let that happen. You’ve secured every thing else? Of course you have. I’ll take some mayo with that turkey sandwich.

So why are we covering UI security? The area of user interface security has received less attention than it merits. The best practice principles that have been drilled into our heads have been promptly and previously addressed, and often the User Interface is the only tier which is left largely unsecured. That said, let’s get on with it.

Hypothesis
Let’s agree as to what we want to accomplish with the sample application and why.

Common Approaches to Locking Down UI
Software developers often use message dialog boxes to inform users that they do not have access to certain features. While it’s a prevalent practice, it creates a number of difficulties. The primary problem is that dialog boxes interrupt the flow of a skillful user, thus hampering productivity, and may even be an unfavorable annoyance. Moreover, the reactive nature of dialog boxes does little after the user has dismissed the dialog and forgotten the box’s message. Lastly, a dialog box does not provision for the restriction of privileged information (e.g. if a field is present on a screen, even a well placed dialog box will not prevent sensitive information, such as salary, from being shown by a data bound text box).

Hence, we must now ask how to architect a generic solution that will allow developers to specify which user interface elements should be enabled or visible and which should be disabled or invisible based upon the user’s role. Ideally the solution should be easy to implement (i.e. the less code the better). The most common technique would have the developer code a method to secure individual controls; called from the form load. While effective, this method is tedious since it requires manual coding. Each form would require another method to be coded.

Another approach is to subclass each control and create custom properties that can be used to specify for which roles the widget is enabled/visible. Like the last solution, this is effective but tedious. Do you really want two types of buttons on the form: a “SecuredButton” and “normal button”? And, more to the point, do you want to subclass every .NET control? Do you really want to subclass a frame? The answer, obviously, is no.

UI Lockdown Code Conference Style
There’s a better way to handle user permissions on forms: Microsoft Windows Forms Extender Provider Controls. What is an Extender Provider? Microsoft’s .NET documentation says “An extender provider is a component that provides properties to other components. For example, when a ToolTip Component (Windows Forms) is added to a form, it provides a property called ToolTip to each control on that form. The ToolTip property then appears in the Properties window for each control and allows the developer to set a value for this property at design time.”

The property provided by the extender provider actually resides in the extender provider object itself and therefore is not a true property of the component it modifies. At design time, the property will appear in the Properties window for the component that is being modified. At runtime, however, the property value is referenced (first located then referenced) by iterating through the extender control rather than through the component itself.

Figure 1. In this figure, an instance of an extender control (SecurityEnableComponent1) appears in the tray area of the form.

OK, here comes the complicated part. What this means is that we can create a suite of extender provider controls such as DisableControl, HideControl, etc. When we drop one of these extender controls onto a form, the control appears to “add properties” to other controls on the form. We can put values into these “extended properties” that identify the specific roles that have permission to access the widgets.

Figure 1 shows an instance of an extender control that has been placed onto the form (circled blue). The control appears in the tray area of the form because it is a non-visual control (i.e. a component class). The extender control is named SecurityEnableComponent1. Notice how the properties window now has the property SecurityEnableComponent on SecurityEnableComponent1 (in red). This is the property that has been added as a result of the extender control. We set the value of this property to “Manager.”

Using the Extender Control
The extender control does absolutely nothing on its own to enforce security. It serves merely to add the property. We should make clear that security at the user interface level is less about enforcing security than it is about representing visually the underlying security of the business logic and data engine layers of the application. It may be deemed impetuous even to presume that user interface security alone will stand as an impediment to a determined belligerent. We therefore represent the underlying application security in the UI by writing code that will examine the user’s security principal and the control’s extended property and take action to hide or disable those controls with which the user is not authorized to interact. This code will need to be invoked for every form that gets loaded. This would require a single line of code to be added to the Form’s Load event:

securityEnableComponent1.Secure(this);

Alternatively, an abstract base form can be created which can run this code automatically. Your forms would then inherit from this abstract base form.

The code mentioned would need to loop through each control within the form. A normal looping structure is insufficient to accomplish this though, since looping through the Form.Controls collection will only provide controls whose parent is the form itself. In other words, it will not pick up any controls whose parent is another container.

For example, if the form contains a panel or a frame then any controls that are placed on the panel or frame would not be accessible by simply looping through the Form.Control collection. The application of a Depth First Traversal recursive loop, however, ensures that all form controls are appropriately secured, as you can see in Listing 1 (this code is part of a code block “helper” class and thus uses additional parameters that are not exposed to the user of the extender control). Take a minute to make sure you understand why the code in Listing 1 is needed. Remember that if every control were accessible directly from the Form’s Controls collection then recursion would be superfluous. Every control is not accessible from this collection. Now take a bite of that sandwich and swallow.

At this point everything will work, but there’s one situation you might be concerned with. Does your system need to be smart enough to prevent a software developer from writing code that makes a hidden control visible? Should the security system be smart enough to prevent such an occurrence? The answer to this question is completely up to you. If the control must never be visible/enabled then you can prevent it by overriding the Visible/EnabledChanged events of the controls on the form. Do this wisely and avoid the need to manually write code to listen to each event. Do some creative delegate remapping, partition the code into code blocks, use form inheritance, and you can accomplish what you need to without giving yourself carpal tunnel syndrome.

The Value Add
While the underlying intricacies of UI security are certainly interesting, a primary goal is to enable even the most novice developer to take advantage of UI security in their applications. Bring the advantage of user interface security into your applications with as little as a single line of code. Code less; have fun.