In this part of the series, we will comprehend the new IIS Metabase storage format that is completely based on XML. We then will outline the advantages of this new format, such as the ability to edit the configuration settings by using familiar tools such as Notepad, the ability to make changes while IIS is running without even having to stop and restart the service, and so on. After that, we will look at the changes in the security model of IIS 6.0 and the impact of those changes in ASP.NET applications. Finally, we will see how to secure ASP.NET applications by using the different authentication mechanisms in IIS.
Introduction
The typical Internet Web site no longer operates on just one server. Web sites now spread across multiple Web servers, or across Web farms. Even intranet sites have increased in number as businesses and organizations are developing and deploying more applications, especially Web-enabled applications. In addition, as remote administration has become more common, there has been an increasing demand to improve API access and direct configuration support. With the Internet and intranet changes over the past few years, managing a Web site is no longer as simple as managing one or a few Web servers from an office, but has become an intricate and complex process. IIS 6.0 introduces new features to improve the administration of Web sites. The IIS 6.0 configuration store is now expressed as plain text XML, which allows for direct text editing of the metabase configuration in a robust and recoverable fashion, even while the server is running.
XML Metabase
In previous versions of IIS, such as IIS 5.0, IIS configuration settings are stored in binary format, making the manual editing of configuration settings almost an impossible thing. The only way you could change the configuration settings is by using the IIS Management console. But now, in IIS 6.0, the configuration file is now stored in native XML format, which you can edit with any standard text editor. Furthermore, it also provides an excellent feature named “Edit While Running,” which allows administrators to change server configuration while the server continues running. For example, you can use this capability to add a new site, create virtual directories, or change the configuration of application pools and worker processes. Note that you can do all of the above even while IIS 6.0 continues to process requests without having to reboot the computer.
The metabase is a hierarchical store of configuration values used by IIS 6.0 that provides rich functionality, such as inheritance, data typing, change notification, and security. The metabase configuration for IIS 4.0 and IIS 5.0 was stored in a proprietary binary file and was not easily readable or editable. IIS 6.0 replaces the proprietary binary file, called MetaBase.bin, with a plain text XML formatted file named MetaBase.xml. The new XML metabase improves server manageability by enabling the following scenarios:
- Direct metabase configuration troubleshooting and editing in a robust fashion
- Reuse of rich text tools such as windiff, version control systems, and editing tools
- Configuration rollback
- Versioned history archives containing copies of the metabase for each change
- Web site and application configuration cloning
- Server-independent backup and restore
Editing the metabase using Notepad
To be able to edit the metabase by using familiar editors such as Notepad, you need to enable direct editing of the metabase file (MetaBase.xml) by using the IIS manager. To do this, select the Computer name node from the IIS manager and right-click on it to select Properties from the context menu to bring up the following dialog box.
In the above dialog box, check the option Enable Direct Metabase Edit. Once this is done, you can edit the Metabase.xml file by using an editor such as Notepad and effect changes in the IIS configuration.
Structure of MetaBase
As mentioned before, the configuration settings for IIS 6.0 are stored in an XML file named MetaBase.xml. When you double-click on the Metabase.xml from Windows Explorer, it will open up in the Internet Explorer. When viewed in the browser, the MetaBase.xml file looks like the following.
The schema for the MetaBase.xml file is called MBSchema.xml and is located in the same directory as that of the MetaBase.xml file. You can’t make changes to the schema file. Using an XML file to store the IIS configuration settings provides a number of advantages. Two main advantages of this approach are:
- Automatic Configuration Versioning and History
- Edit-While-Running Feature
We will provide an in-depth look at the above features in the following sections.
Automatic Configuration Versioning and History
As mentioned before, IIS 6.0 provides an automatic versioning and history feature by tracking changes to the configuration MetaBase file (MetaBase.xml). This file contains all the configuration settings related to IIS and can be found in the folder <Drive Name>:Windowssysteminetsrv. Any time a change is made, the metabase history feature automatically keeps track of the changes to the metabase. When the metabase is written to disk, IIS 6.0 marks the new MetaBase.xml file with a version number and saves a copy of the file in the history folder. Each history file is marked with a unique version number, which is then available for rollback or restore. If IIS 6.0 has been running while configuration changes are being made, IIS 6.0 responds to configuration errors by automatically reverting to a previous history file, preventing errors in the configuration metabase from crashing the server.
Edit-While-Running Feature
IIS 6.0 also gives administrators the capability to change the server configuration while the server continues running, through direct edit of the MetaBase.xml file. For example, this feature can be used to add a new site, create virtual directories, or change the configuration of application pools and worker processes—all while IIS 6.0 continues to process requests. No recompilation or restart is required. The administrator can do this easily by opening the MetaBase.xml file using Notepad, creating the virtual directory needed, and saving the file—again, all while IIS is running. The new changes will be detected, scanned for correctness, and applied to the metabase if the changes are valid according to the schema.
Security in IIS 6.0 and ASP.NET
Because an ASP.NET Web application runs on top of the IIS Web server, every ASP.NET application can leverage the security options provided by IIS. When the user requests a specific resource on the system, that request is routed to IIS. IIS authenticates the user requesting the resource and then hands off the request and the security token for the authenticating the user to the ASP.NET worker process. The ASP.NET worker process then decides whether to impersonate the authenticated user. If impersonation is enabled in the web.config file, the ASP.NET worker process impersonates the authenticated user. Otherwise, the thread runs under the ASP.NET worker process identity.
In the world of ASP.NET, authentication is implemented via Providers. Providers are basically classes that contain static methods to assist ASP.NET in authenticating requests from clients. ASP.NET provides built-in support for user authentication through several authentication providers.
- Forms-based authentication—The application is secured by using a custom authentication model with cookie support.
- Passport authentication—Passport authentication is part of Microsoft’s .NET strategy for authenticating users in Internet applications. Passport is a single sign on (SSO) service, which allows registered users to access participating Web sites with a single user ID and password. Microsoft Passport servers maintain user identity information and provide an authentication mechanism.
- Windows authentication—The application is secured by using integrated Windows authentication where access to a Web application is allowed only to those users who are able to verify their Windows credentials.
- Custom authentication—If none of the existing authentication modules satisfy your requirements, the .NET Framework allows you to implement your own custom authentication strategy.
One of the new features in IIS 6.0 is the support for .NET Passport integration. The next section provides you with an overview of the support IIS 6.0 provides for authenticating users via .NET Passport.
.NET Passport Integration with IIS 6.0
The integration of .NET Passport with IIS 6.0 enables .NET Passport authentication services from within the core Web server. .NET Passport 2.0 uses interfaces provided by standard Passport components, such as Secure Sockets Layer (SSL) encryption, HTTP redirects, and cookies. By using the .NET Passport, you can make your Web sites and applications available to the entire .NET Passport customer base, which is composed of over 150,000,000 users, without having to deal with account management issues such as password expiration or provisioning. After a user has been authenticated, the user’s .NET Passport Unique ID (PUID) can be mapped to an account in Microsoft Active Directory services—if such provisioning has been configured for your Web sites. A token is created by the Local Security Authority (LSA) for the user and set by IIS 6.0 for the HTTP request. You can use this security model for authorization based on Active Directory users. These credentials can also be delegated by using the new Constrained Delegation feature that is supported in Windows Server 2003. You can enable .NET Passport authentication by selecting the Default Web Sites-> Virtual Directory Name from the IIS manager and selecting Properties from the context menu. In the Properties dialog box, select the Directory Security tab and then click the Edit command button to bring up the following dialog box.
In the preceding dialog box, once you select .NET Passport Authentication as the authentication mechanism, the Default domain text box will be enabled, allowing you to specify the domain name.
Configuring Directory Permissions from IIS Manager
You also can set file permissions for the file system directory by using the Permissions option that is available from the context menu when you right-click on the virtual directory.
By using this new feature, you can set directory permissions from within the IIS manager itself.
Impersonation behavior in ASP.NET applications
Impersonation allows a worker process to run under security credentials that are different from its base identity. As discussed in Part 2 of this article, the identity for an ASP.NET Web application is configured at the application pool level. However, there are times when you might want to configure the ASP.NET Web application to execute using the credentials of the authenticated user or a specific user account. You can do this by enabling impersonation in the ASP.NET application.
Unlike ASP applications (where impersonation is enabled by default), in ASP.NET you need to explicitly configure the impersonation behavior for ASP.NET applications. By default, impersonation is disabled in ASP.NET. If you enable impersonation, ASP.NET receives the security token to impersonate from IIS. You can control the impersonation behavior by using the identity element in the web.config file. You have the following three options when specifying this setting:
Impersonation is disabled
This is the default setting. In this case, the ASP.NET thread runs using the process token of the application worker process regardless of which combination of IIS and ASP.NET authentication is used. By default, the process token of the application worker process is NetworkService. To disable impersonation, set the impersonate attribute of the identity element to false.
<identity impersonate="false" />
Impersonation is enabled
In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous user account (IUSR_machinename). For backward compatibility with ASP, you must enable impersonation. To enable impersonation, modify the identity element in the web.config file to look like the following:
<identity impersonate="true" />
Impersonation is enabled and a specific impersonation identity is specified
In this instance, ASP.NET impersonates the token that is generated using the configured identity. In this case, ASP.NET does not use the token of the authenticated client except when performing access checks.
To enable impersonation and specify an impersonation identity, modify the web.config file to look like the following:
<identity impersonate="true" name="domainuser"
password="password" />
An example ASP.NET application that demonstrates impersonation
To demonstrate the impersonation behavior, let us create a very simple ASP.NET application named ImpersonationExample. Once the project is created, we will enable Integrated Windows authentication for the Web application using the IIS manager. This is illustrated in the following screenshot.
After that, add the following lines of code to the Page_Load event of the default web form.
private void Page_Load(object sender, System.EventArgs e)
{
Response.Write("Credentials under which the ASP.NET application
executing is : <b>" + WindowsIdentity.GetCurrent().Name
+ "</b><br>");
Response.Write("Name of the logged on user name is :<b>" +
Context.User.Identity.Name + "</b><br>");
}
If you execute the preceding code, you will see an output that is somewhat similar to the following. In the output, it is important to note that the ASP.NET application runs using the credentials of NetworkService account.
Let us modify the web.config file by adding the identity element under the system.web element.
<identity impersonate="true"/>
Now if you execute this code, you will see that the ASP.NET application executes using the credentials of the logged-on user.
Conclusion
In this series of articles on IIS 6.0 and ASP.NET, we understood the new features of IIS and demonstrated how these features contribute to the increase in reliability, scalability, and security of your ASP.NET applications. We also looked at how XML-based storage is used to store the IIS configuration settings that provides for a number of enhancements when compared to the previous versions of IIS. Finally, we also understood the new security model of IIS 6.0, in which, by default, the code runs using the fewest possible privileges. All these new features of IIS 6.0 in conjunction with the seamless integration of IIS and ASP.NET should make a compelling case for the migration of your existing Web servers from IIS 5.0 to IIS 6.0.
About the Author
Thiru has six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing).
He is an expert with ASP.NET, .NET Framework, Visual C#.NET, Visual Basic.NET, ADO.NET, XML Web Services and .NET Remoting and holds MCAD for .NET, MCSD and MCP certifications.
Thiru has authored numerous books and articles. He can be reached at thiruthangarathinam@yahoo.com.
# # #
