Article ID: 893662 - View products that this article applies to.
Beta InformationThis article discusses a Beta release of a Microsoft product. The information in this article is provided as-is and is subject to change without notice.
No formal product support is available from Microsoft for this Beta product. For information about how to obtain support for a Beta release, see the documentation that is included with the Beta product files, or check the Web location where you downloaded the release.
ASP.NET Support Voice column
Full content protection using ASP.NETTo customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It
(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)form. There's also a link to the form at the bottom of this column.
My name is Adam Semel. I have been with Microsoft for over 5 years working with technologies such as Windows Installer and Visual Studio Deployment. I have spent the last couple of years working on the ASP.NET team as a support professional. I love troubleshooting computer-related issues, which is what got me started in computers 23 years ago when my commodore PET would run out of memory. Let me share with you some great timesaving and powerful tips I’ve picked up along the way.
This month I will cover how we can protect any content that lives inside a Microsoft ASP.NET application directory using the built-in functionality of both ASP.NET and Microsoft Internet Information Services (IIS). The functionality works in any version of ASP.NET, including ASP.NET 2.0, which contains several rich new logon controls, and works in both IIS 5.0 and IIS 6.0.
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:
http://msdn2.microsoft.com/en-us/library/eeyk640h(vs.71).aspxFor 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.
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.
For more information about the RedirectFromLoginPage function, see the following MSDN Web site:
http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication.redirectfromloginpage(vs.71).aspxASP.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!
As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base using the Ask For It