Securing Directories with Role-based Forms Authentication
To make the role-based authentication work for Forms Authentication, make sure you have a Web.config file in your Web Application root. For the authentication setup, this particular Web.config file must be in your Web Application’s document root. You can override the <authorization/> in Web.config files for sub-directories.
To begin, make sure your Web.config file has at least the following:
<configuration>
<system.web>
<authentication mode=”Forms”>
<forms name=”MYWEBAPP.ASPXAUTH”
 loginUrl=”login.aspx”
 protection=”All”
 path=”/”/>
</authentication>
<authorization>
<allow users=”*”/>
</authorization>
</system.web>
</configuration>
The FormsAuthentication name (“MYWEBAPP.ASPXAUTH”) above it arbitrary, although the name there and the name in the HttpCookie we created to hold the hashed FormsAuthenticationTicket must match, for even though we are overriding the ticket creation, ASP.NET still handles the authorization automatically from the Web.config file.
To control authorization (access by a particular user or group), we can either 1) add some more elements to the Web.config file from above, or 2) create a separate Web.config file in the directory to be secure. While, I prefer the second, I will show the first method:
<configuration>
<system.web>
<authentication mode=”Forms”>
<forms name=”MYWEBAPP.ASPXAUTH”
loginUrl=”login.aspx”
protection=”All”
path=”/”/>
</authentication>
<authorization>
<allow users=”*”/>
</authorization>
</system.web>
<location path=”administrators”>
<system.web>
<authorization>
<!– Order and case are important below –>
<allow roles=”Administrator”/>
<deny users=”*”/>
</authorization>
</system.web>
</location>
<location path=”users”>
<system.web>
<authorization>
<!– Order and case are important below –>
<allow roles=”User”/>
<deny users=”*”/>
</authorization>
</system.web>
</location>
</configuration>
The Web Application always creates relative paths from the paths entered here (even for “login.aspx”), using it’s root directory as the starting point. To avoid confusion with that condition and to make directories more modular (being able to move them around without changing a bunch of files), I choose to put a separate Web.config file in each secure sub-directory, which is simply the <authorization/> section like so:
<configuration>
<system.web>
<authorization>
<!– Order and case are important below –>
<allow roles=”Administrator”/>
<deny users=”*”/>
</authorization>
</system.web>
</configuration>
Notice, too, that the role(s) is(are) case-sensitive. If you want to allow or deny access to more than one role, delimit them by commas.
That’s it! Your site is setup for role-based security. If you use code-behind, compile your application first. Then try to access a secure directory, such as “/administrators”, and you’ll get redirected to the login page. If login was successful, you’re in, unless your role prohibits it, such as the “/administrators” area. This is hard for the “login.aspx” page to determine, so I’d recommend a Session variable to store the login attempts and after so many times, return an explicit “Denied” statement. There is another way, however, which is discussed below.
Conditionally Showing Controls with Role-based Forms Authentication
Sometimes it’s better to show / hide content based on roles when you don’t want to duplicate a bunch of pages for various roles (user groups). Such examples would be a portal site, where free- and membership-based accounts exist and membership-based accounts can access premium content. Another example would be a news page that would display an “Add” button for adding news links if the current user is in the “Administrator” role. This section describes how write for such scenarios.
The IPrincipal interface, which the GenericPrincipal class we used above implements, has a method called “IsInRole()”, which takes a string designating the role to check for. So, if we only want to display content if the currently logged-on user is in the “Administrator” role, our page would look something like this:
<html>
<head>
<title>Welcome</title>
<script runat=”server”>
protected void Page_Load(Object sender, EventArgs e)
{
if (User.IsInRole(“Administrator”))
AdminLink.Visible = true;
}
</script>
</head>
<body>
<h2>Welcome</h2>
<p>Welcome, anonymous user, to our web site.</p>
<asp:HyperLink id=”AdminLink” runat=”server”
Text=”Administrators, click here.” NavigateUrl=”administrators/”/>
</body>
</html>
Now the link to the Administrators area of the web site will only show up if the current user is logged in and is in the “Administrator” role. If this is a public page, you should provide a link to the login page, optionally setting the QueryString variable called “ReturnUrl” to the path on the server you want the user to return to upon successful authentication.
Random Thoughts 