Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Put a 24-hour Lockdown on Your .NET UIs

Once you've secured your business objects and the underlying data engine, there are additional steps you can take to layer on more security. Find out how you can manipulate Windows Forms to give authorized data to authorized users.


advertisement
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 cost\value 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.

Fact

Enterprise applications need to provide various levels of functionality to users depending upon their profiles.

Example

A banking application, with two user profiles: tellers and managers. Each user profile has various levels of functionality enabled, e.g. print check functionality might only be permissible for managers and not for tellers.

Deduction

User interfaces should be designed to prevent a user from accessing widgets that they do not have permission for.

Applicability

While banking is the textbook example, you can apply these principles to numerous verticals including law enforcement, health care, sales, etc.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap