Scott on Writing

Musings on technical writing...

Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site

Authenticating users visiting an Internet-based website is usually accomplished in one of two ways:

  • Using Forms authentication - here a user is prompted for their credentials through a standard web page form
  • Using HTTP authentication - RFC 2617 defines two standard HTTP protocol-level authentication schemes - Basic authentication and Digest authentication. When a browser interfaces with a site using this form of authentication, it displays that familiar modal dialog box prompting you for your credentials (see this image).

Many websites use Forms authentication, as it provides more control over the user experience and many platforms (such as ASP.NET) include tools for adding Forms authentication support. (In fact, with ASP.NET 2.0, you can build a complete user account-based website using Membership and Forms authentication without having to write a line of code; see Examining ASP.NET 2.0's Membership, Roles, and Profile for more information.)

However, Forms authentication is not a standard; while it's easy for a human to provide their credentials through Forms authentication, it's much more difficult for a computer program since the HTML inputs for the credentials can differ from site to site. With the standard HTTP protocol-level authentication schemes, however, the workflow for authentication is much more mechanical and can easily be supported by a computer program. In fact, tools like wget, Microsoft's Background Intelligent Transfer Service (BITS), and many RSS readers support built-in HTTP authentication.

Traditionally, Forms authentication is handled at the ASP.NET level, while the HTTP authentication schemes are configured from the web server level. This means that Forms authentication can easily be configured to authenticate users against a credential store located in some XML file, a database table... whatever. With HTTP authentication, the user credential store consulted for authentication is typically the Windows User Store.

Consider the case of a blog or forum site, where we have certain resources that we want to protect. For example, imagine that at a forum site there is a forum that is “private,“ meaning that only a set of users can view the forum's posts. It's easy to establish authorization rules in Web.config and use Forms authentication to identify users. However, imagine that our forum website offers RSS feeds of the forum's most recent posts. How do we share the RSS feeds for the private forums? RSS readers can't authenticate via Forms authentication.

One option, which is what is used by CommunityServer, is to use a unique RSS subscription URL per user. The only issue here is that if that particular URL is leaked somehow, anyone can consume the private forum feeds. Rob Howard and I discuss this feature in CommunityServer in this forum post: Enable RSS on non-public forums. Another option is to support both HTTP and Forms authentication and have it so that they both use the same credential store (such as that database table or XML file or what have you...)

Back in April 2006, Atif Aziz and I published an article on MSDN Online on how to build an ASP.NET web application that can do just this. In particular, the article examines MADAM, a collection of HTTP Modules for handling this sort of functionality. With MADAM you can define in Web.config what conditions would require the authentication scheme to switch from Forms authentication to HTTP authentication. For example, you might instruct MADAM that whenever anyone was attempting to access a particular resource, to switch to HTTP authentication. The MADAM HTTP Modules then detect when such a condition unfolds and intercept the HTTP response to include the necessary headers for the specified HTTP authentication scheme. Similarly, when the user agent responds with the user's credentials, the MADAM HTTP Modules work to validate the credentials against the configured credential store.

If you've ever needed to meld Forms authentication and HTTP authentication in a single web application using a single credential store, check out MADAM. You can learn more about it and download the complete source code at Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site.

posted on Friday, June 23, 2006 10:24 AM

Feedback

# re: Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site 6/24/2006 2:22 PM Thomas Eyde

Didn't you forget one thing? Basic authentication is not secure

# re: Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site 6/24/2006 4:52 PM Scott Mitchell

Thomas, Basic authentication is as secure as Forms authentication. For both techniques, it is essential that the communications be done over a secure channel (SSL).

# re: Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site 7/6/2006 2:57 AM Atif Aziz

Hey Scott, I noticed a glitch. The article says at the top that it applies to ASP.NET 2.0 whereas it should really say that applies across all current versions, i.e. 1.0, 1.1 and 2.0. In fact, it's quite wrong to say it only applies 2.0 because it could mislead the reader and leave them wondering why the Membership API wasn't considered up front instead of coming up with IUserSecurityAuthority.

# re: Supporting HTTP Authentication and Forms Authentication in a Single ASP.NET Web Site 7/11/2006 8:42 AM Atif Aziz

Also published a class diagram now, see: http://www.raboof.com/projects/madam/ClassDiagram.png

Might come in handy when the architecture needs to be briefly and visually presented to someone or otherwise serve as a reminder of how it's knitted together.

Title:  
Name:  
Url:
Protected by Clearscreen.SharpHIPEnter the code you see:
Comments   

My Links

Ads Via DevMavens

Archives

Post Categories

 

I am a Microsoft MVP for ASP.NET.
I am an ASPInsider.
<January 2009>
SMTWTFS
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

Comment Stats

DayTotal% of Total
Sunday 1996.9%
Monday 41014.2%
Tuesday 48716.8%
Wednesday 53618.5%
Thursday 56119.4%
Friday 52118.0%
Saturday 1806.2%
Total 2894100.0%

Hour1Total% of Total
12:00 AM 712.5%
1:00 AM 782.7%
2:00 AM 652.2%
3:00 AM 782.7%
4:00 AM 622.1%
5:00 AM 1164.0%
6:00 AM 1123.9%
7:00 AM 1685.8%
8:00 AM 1826.3%
9:00 AM 1545.3%
10:00 AM 1816.3%
11:00 AM 1866.4%
12:00 PM 1966.8%
1:00 PM 1816.3%
2:00 PM 1655.7%
3:00 PM 1344.6%
4:00 PM 1133.9%
5:00 PM 1023.5%
6:00 PM 983.4%
7:00 PM 1043.6%
8:00 PM 893.1%
9:00 PM 832.9%
10:00 PM 852.9%
11:00 PM 913.1%
Total 2894100.0%

Comments by Blog Entry Date/Time

Day Entry MadeAvg.Total
Sunday 5.18145
Monday 5.01371
Tuesday 4.25463
Wednesday 7.54656
Thursday 6.71658
Friday 5.32431
Saturday 5.00170
Total 5.662894

Hour1 Entry MadeAvg.Total
12:00 AM 5.2937
1:00 AM 1.002
5:00 AM 0.000
7:00 AM 6.3338
8:00 AM 4.52122
9:00 AM 6.04284
10:00 AM 6.14264
11:00 AM 4.30189
12:00 PM 6.75344
1:00 PM 3.12128
2:00 PM 5.23225
3:00 PM 8.36301
4:00 PM 3.7694
5:00 PM 5.89165
6:00 PM 4.56114
7:00 PM 9.15183
8:00 PM 8.53162
9:00 PM 5.00115
10:00 PM 6.3395
11:00 PM 4.5732
Total 5.662894

Learn More About Comment Stats
1 - All times GMT -8...


Blog Stats

Favorite Web Sites

My Books

My MSDN Articles