What is "full content protection"? Full content protection is the
ability to force a user to be validated when the user requests any content
from the Web server. By default, only .aspx pages require you to be
validated when using forms authentication. If you have a .pdf file or a .jpg file,
the URL can be sent in an e-mail or copied and pasted into a browser, and the
content will be served regardless of whether or not you have been validated.
Another scenario could be an existing HTML application that you now want to add
authentication to. Quite often we need to protect more than just .aspx pages;
in this column I will show you how you can fully protect any content on the
site level, the application level, or the subdirectory level.
First,
we are going to create a Web site that will reside on the Internet, so we will
use ASP.NET forms authentication to require users to log on before they can view
any pages or content on our site. I am not going to cover forms authentication
in detail in this column. For more information about forms authentication, see the following Microsoft Developer Network (MSDN) Web site:
For our application, all users have to do is
click a button and they are authenticated. (I have been told I am too nice!) The
first part is telling our application that we want to use forms authentication.
This is set in the web.config file as follows.
<authentication mode="Forms">
<forms name="Adam" loginUrl="Login.aspx" />
</authentication>
This tells ASP.NET to redirect a user to Login.aspx if the user is not authenticated so he or she can be authenticated. Login.aspx has a label asking the user to click the button to be authenticated. We are going to let the user into our site by just clicking the button. In a real world scenario, you
would validate the user here by checking a user name and password against a
data store of some sort. Here is the code behind our button.
private void Button1_Click(object sender, System.EventArgs e)
{
FormsAuthentication.RedirectFromLoginPage("Adam", false);
}For more information about the
RedirectFromLoginPage function, see the
following MSDN Web site:
ASP.NET will do the rest behind the scenes for us, including
redirecting the user back to the page we requested. So far so good. Now we have
forms authentication set up, but it will only validate .aspx pages. The last
part of this task is to configure IIS to process all requests (any file
extension) through our forms authentication.
In IIS when a request
comes in, we check the extension of the request and handle it appropriately.
Requests for .aspx pages are handed to the ASP.NET Isapi.dll file (Aspnet_isapi.dll).
This is set up for us when we install the Microsoft .NET Framework. You can check the
extension mappings in IIS by right-clicking the application in question. Then, select the
Virtual Directory tab, click
Configuration, and on the
Mappings
tab you will see all the mapped extensions for this application. We are going
to tell IIS to map any file extension (any request) to the ASP.NET ISAPI filter. To
do this, on the
Mappings tab, click
Add. For the executable, browse to Aspnet_isapi.dll
in the framework folder (%windir%\Framework\Microsoft.NET\v1.1.4322). For the
extension, add
.*.
If you are using IIS 6.0, there is a separate
section on the
Mappings tab called
Wildcard extensions. You
can make the same mapping to the ASP.NET Isapi.dll file in this section.
If you now try to request a .jpg file that lives in your application
directory, you will first have to be authenticated by our logon page. Lucky for
you, all you have to do is click one button in this example!
I
mentioned earlier that we can use this same logic to protect the site, the
application, or a subdirectory. To protect a site, right-click the site in
IIS, and map the wildcard extension on the
Home Directory tab.
Note that this means every application with any type of request on this site
will first have to go through the ASP.NET ISAPI filter. For standard HTML
applications, this might be a performance hit if you don't need to authenticate
these pages.
For the subdirectory level, you will have to add a
web.config file in the subdirectory you wish to protect. Set the
authentication section to forms authentication as we did earlier. You will also
have to mark this subdirectory as an application in IIS so that IIS will pick
up the setting in the web.config file. You can then make the wildcard mappings on
this directory level the same way that we did earlier.
You can probably
think of many different variations of authentication that you can use. For example, we may have
a scenario where if the user comes in to our site off the intranet (Windows
authentication), they don't need to use forms authentication. But if they
come in from the Internet, we force them to log on with forms authentication.
When you use the steps outlined in this article, the possibilities are endless!