ASP.NET 3.5 Enterprise Application Development with Visual Studio® 2008: Problem - Design - Solution

6.1. Problem

Usually, when you review requirements with clients, they make a broad statement such as "we need security." This doesn't really help you much. Take Mary, for example. As I continued my discussions with her, she started to get a little more specific by saying a particular user should have access to a page but someone else shouldn't. Then, after showing her some prototypes, she asked if one person could view the page but not be able to change anything. Then she said, "Well, on this page I want to be able to click these two buttons, but someone else should only be able to click one button."

This chapter focuses on building a role-based security framework that can handle all types of scenarios, and one that enables you to control security down to the field level on each screen. After reading this chapter, you should never even have to ask the client about security anymore. Armed with this functionality, you can let clients keep changing their mind about how the pages work. Just don't let them know how easy it is to change them.

The other challenging issue with security is administration. How many applications have you built for which you become the security administrator because it takes some coding changes to create a user or grant access to a page? This isn't what developers are supposed to be spending time on. They should be coding (and occasionally let out to see the sunshine). Support is supposed to be handled by the help desk. The role-based security design for ...