ASP.NET Providers - Role Management
This blog post is part of a series about the ASP.NET Providers (namely Membership, Role Management, and Profile). The introductory post in the series can be found at the following link, which introduces the Provider Model pattern and gives a personal example of an implementation I have been working on:
This post will deal with adding Role Management to your website.
Creating roles and assigning users accounts to them is a great way to group users together under similar permissions and abilities. The ASP.NET Roles Management service allows you to restrict page viewing (or even just certain regions of a page) based on roles you define; you can even apply roles security to specific methods or classes using attributes, which I will show an example of a little later.
In order to add role management to your site, add an XML fragment like the one below; the process is much the same as it was with the Membership Provider:
WARNING: According to Microsoft, you should never use the default provider settings and should always add a new, configured provider; in addition you must be sure to specify the applicationName attribute! See Scott Guthrie’s blog post on this topic for more details. Apparently, you can also use a value of "/" for the applicationName and it will use the root application name.
Role names can be used in the Web.config in the same place we used the user class wildcard characters (namely, * for all users and ? for anonymous users); the following sample fragment would go under the system.web node:
Role names can be defined by using the ASP.NET Website Administration Tool launched from Visual Studio that I referred to earlier in this series with a post titled ASP.NET Providers - Getting Started. You can also use this utility to assign users to one or more roles. Roles can be programmatically assigned and verified in code as well, using the provided Roles .NET API.
Attribute-based Role Management
In order to put authorization rules on classes or methods, you use the attribute named PrincipalPermission. Here is a sample that contains a method only accessible by a user with the username of administrator AND in the role group Admin:
The OR version of the above logic (meaning the user account being verified need only satisfy one of these authorization rules) would be represented like this:
Here is an interesting sample that restricts a page to authenticated users (those not visiting anonymously); you would put the attribute on the code-behind of an ASPX page, like this example for SomePage.aspx:
In all of these cases, if the authorization criteria is not met, a SecurityException is thrown. You would want to catch that exception and perform alternate logic or display a more user-friendly error message.
Continue onward by reading the next blog post in this series found at the following link: