In IIS 4 and 5, a number of authentication solutions were available. The primary methods were those that integrated into the local- or domain-based user/password systems.
Although time has moved on, there aren't many new mechanisms available to us that provide additional authentication solutions. The original built-in systems still exist?anonymous authentication, basic authentication, integrated windows authentication, and digest authentication. As before, IIS will also authenticate users who it can identify as being within the AD.
Two new authentication systems are available in IIS 6, however?Passport Integration and Constrained/Delegated Authentication. The former is designed as an alternative to the existing mechanisms. The latter is a new way of assigning authentication credentials to an application so that it can communicate with other servers or backend services, such as SQL databases in the process of processing a request.
A third authentication system is available programmatically through the ASP.NET Web service extension. This provides mechanisms to authenticate a user for an application and provides pass through facilities to the Windows and AD authentication systems and the new Passport system.
For a tutorial on setting security based on the hosts visiting your sites, go to the Delta Guide series Web site at www.deltaguideseries.com and enter article ID# A020303.
We are generally used to the idea of Single Sign On (SSO) within the office environment?you log in to your Windows machine, and this provides you with access to all the servers, Intranet sites, and email services, for example. But what happens when we extend that to the Internet?
PILES OF PASSWORDS
I know I have a lot of passwords and login information across a range of Web sites?but it would be much more convenient if I could just use the same login and password, in a secure fashion, to gain me access to the sites I use regularly.
This is the point of Passport?a central Web site that holds credential and user information which can then be shared among other participating sites. IIS 6 incorporates the capability to communicate directly with the Passport system and authenticate your users through their Passport identities.
You can enable Passport authentication on Web sites served by your own IIS implementations by selecting the .NET Passport authentication. When a user connects to your Web site, IIS will look for a Passport cookie with the user's Passport identity. If the user has a cookie, he is redirected to the main Passport.net site to have his password verified. Once he has logged in correctly, he will be redirected back to the original URL. If he doesn't have a cookie, he is prompted to create one on the Passport site.
PASSPORT AND OTHER AUTHENTICATION TYPES
Passport cannot be used in conjunction with other authorization types because Passport operates with cookies rather than the standard HTTP-based authorization system. Therefore, you can only configure a site or directory to support Passport or any other authorization system combination, but not both.
If you need to provide specific access to an area of your site through Passport, you can map users within your Active Directory domain to a known Passport user, and then use the standard security controls and access control lists, merely using Passport as a login mechanism.
PASSPORT REQUIRES EFFORT!
Passport isn't something you can casually turn on and start using. You will need to become an official Passport Web Site, which involves paying fees to Microsoft and implementing special software. It can take several weeks or more to get fully integrated with Passport, and fees can run into several thousands of dollars per year.
If you are supporting a distributed application or are using remote UNC paths to support a local Web service, it's important to be able to retain security between the machines running these services to prevent malicious use or accidental failures causing serious problems.
Windows Server 2003 introduces a system of constrained, delegated authentication. This enables a user to be given access to specific types of services on specific servers as if he were accessing the system locally. Essentially, the primary server?that is, the IIS service?masquerades as the user.
The two recommendations to the use of constrained, delegated authentication according to Microsoft are as follows:
Delegation should not enable a server to connect on behalf of the client to any resource in the domain/forest. This is the constrained portion of the system; it defines that users (and servers supporting user access) should be granted access only to specific services?for example, to the SQL service on a given server?rather than to a SQL service on any server, or any service on any server.
Delegation should not require the client to share its credentials with the server. This reduces the chances of malicious attacks by enabling the communication to take place without actually exchanging user and password information, removing the ability to snoop and collect the credentials data.
To configure servers to use the constrained, delegated authentication system, you must configure individual server affiliations through the Active Directory Users and Computers tool by setting server and authentication systems.
You can get more information on the steps required to enable authentication at the Microsoft Windows Server 2003 Deployment guide; the URL for the relevant page is http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/deploy/confeat/remstorg.asp.
For authentication within an application, IIS 6 and ASP.NET provide three main forms of authentication system supported by a number of authentication providers within the ASP.NET system:
Windows authentication? This uses the authentication provided by the standard IIS 6 authentication mechanisms and interface (that is, digest, integrated, and so on).
Passport authentication? Works just like the integrated IIS-based Passport authentication system, but because it can be built into an ASP application, you can provide a friendlier interface.
Forms-based authentication? Enables a developer to use a standard ASP form to request credentials that can then be authenticated through the standard mechanisms or a built-in solution.
ASP.NET applications can directly make use of this authentication, and in turn the information can be used with the authorization system.