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

6.2. Design

Role-based security is not a new concept. In fact, the .NET Framework comes with built-in functionality to enable you to create roles, associate users with roles, and manage these tasks using the Web Site Administration Tool. The problem with this structure for the PaidTimeOff project is that you, as the developer, have to create the roles and associate them with specific pages in the application, not the user. Nor do you want to give users access to the Web Site Administration Tool to manage the security themselves.

In my opinion, the biggest challenge you face is deciding which roles go with which pages; and a role isn't really associated with a page, a capability is associated with a page, and that capability can be associated with one or more roles. The term "capability" refers to the smallest level of access a user can have in your system. For example, you may need to associate "run" capabilities for each report with different users. If you have 20 reports, then you would need 20 capabilities. You could set up an Accounting role that can only run accounting reports, but you could also set up an Administrator role that can run all reports.

A capability needs to be able to be defined as being read-only, editable, or potentially some other type of access, such as run or execute. This type of functionality isn't supported out of the box by the .NET Framework's security model. The pattern discussed in this chapter does address all of these issues, and clarifies the ...