IIS 7.0 : Runtime Web Server Extensibility (part 1)

The Web server extensibility model provides a foundation for IIS 7.0’s modular architecture, enabling the low-footprint, low attack surface area, as well as highly specialized Web server deployments. All of this is possible because built-in IIS 7.0 features are implemented as pluggable modules on top of the same extensibility APIs that are exposed to third-party modules and are configured and managed with the same configuration and management tools.

What Is a Module?

Logically, a module is a Web server component that takes part in the processing of some or all requests and typically provides a service that can involve anything from supporting specific authentication methods (such as the Windows Authentication module) to recording and reporting requests that are currently executing (such as the Request Monitor module). The modules operate by executing during different stages of the request processing pipeline and influencing the request processing by using the APIs exposed by the Web server extensibility model. The majority of modules provide independent services to add functionality to the Web application or otherwise enhance the Web server.

The application developer or IT administrator can then essentially put together the Web server with the precise functionality that is required by controlling which modules are enabled for the application, much like building a structure from a set of LEGO blocks. IIS 7.0 provides a fine degree of control over which modules are enabled, giving administrators control of functionality on both the server as a whole and of specific applications.

Physically, IIS 7.0 modules are implemented as either native dynamic-link libraries (DLLs) developed on top of the new IIS 7.0 native C++ extensibility model, or as managed .NET Framework classes that leverage the new ASP.NET integration model available in IIS 7.0. Both of these APIs enable modules to participate in the IIS 7.0 request processing pipeline, and manipulate the request and response processing as needed. Though these two extensibility models use two different APIs and have a number of different characteristics from both the developer and IT administrator perspective, they both implement the logical module concept. This enables IIS 7.0 to provide a consistent development abstraction to both C++ and .NET Framework developers for extending the Web server. The logical module concept also enables IIS 7.0 to expose the administrator to a largely unified view of managing the Web server feature set. 

The Request Processing Pipeline

The IIS 7.0 request processing pipeline is the foundation of the modular architecture, enabling multiple independent modules to provide valuable services for the same request.

Note

In IIS 7.0, the amount of processing the Web server engine itself performs is minimal, with the modules providing most of the request processing.

The pipeline itself is essentially a deterministic state machine that enables modules to interact with the request during a fixed set of processing stages, also known as events. As shown in Figure 1, when the request is received, the state machine proceeds from the initial stage toward the final stage, raising the events and giving each module an opportunity to do its work during the stages it is interested in.

Figure 1. The request processing pipeline.

The majority of events in the request processing pipeline are intended for a specific type of task, such as authentication, authorization, caching, or logging. Modules that subscribe to these events can provide a specific service appropriate for the particular stage. For example, the authenticate event is home to a number of IIS 7.0 modules, including the Windows Authentication module (NTLM and Kerberos authentication), the Basic Authentication module, the ASP.NET Forms Authentication module, and so on. These events enable multiple modules to execute during the request processing and perform typical Web server processing tasks in the correct order. For example, determining the user associated with the request during the authentication stage needs to happen before determining whether that user has access to the requested resource during the authorization stage.

Other events are present for additional flexibility, enabling modules to perform tasks at a specific time during request processing (typically between the events that have specific intended roles such as authentication and authorization). Table 1 lists all the events, along with some IIS 7.0 modules that subscribe to them.

Table 1. Request Processing Events

Event	Description	Modules
BeginRequest	The request processing is starting.	Request Filtering module, IP Restrictions module
AuthenticateRequest	The authenticated user for the request is determined.	Authentication modules, including Windows Authentication module, Basic Authentication module, ASP.NET Forms Authentication module
AuthorizeRequest	Access to the requested resource is checked for the authenticated user, and the request is rejected if access is denied.	URL Authorization module
ResolveRequestCache	The server checks if the response to this request can be retrieved from a cache.	IIS Output Cache module, ASP.NET Output Cache module
MapRequestHandler	The handler for this request is determined.
AcquireRequestState	The required state for this request is retrieved.	ASP.NET Session State module
PreExecuteRequestHandler	The server is about to execute the handler.
ExecuteRequestHandler	The handler for the request executes and produces the response.	All modules that provide request handling, including Static File module, Directory Listing module, Default Document module, ISAPI extension module, ASP.NET PageHandler
ReleaseRequestState	The state is released.	ASP.NET Session State module
UpdateRequestCache	The cache is updated.	IIS 7.0 Output Cache module, ASP.NET Output Cache module
LogRequest	The request is logged.	Custom Logging module
EndRequest[a]	The request processing is about to finish.	Request Monitor module
[a] All of the events in this table except the EndRequest event also have a corresponding Post event, such as PostBeginRequest for BeginRequest. Post events exist primarily to provide additional flexibility to modules so that they can perform tasks that need to happen between specific events.

It is important to understand that though the majority of modules are self-contained and provide independent services during request processing, they do operate on a common set of request and response state and can affect the other’s operation. In some cases, these relationships are part of formal patterns (such as the authentication and authorization pattern), and in others they may be unintentional. In the latter case, some modules may not be compatible with each other, or they may require a specific ordering to function correctly. 

Differences Between Managed (.NET) and Native (C++) Modules

As we mentioned earlier, IIS 7.0 supports modules developed with the native IIS 7.0 C++ API as well as modules developed using the ASP.NET module API, sometimes referred to as managed modules.

The IIS 7.0 C++ module API replaces the legacy ISAPI filter and extension API as the new native extensibility model for IIS 7.0 and future versions of IIS. Existing ISAPI filters and extensions are still supported, but developers are encouraged to take advantage of the module extensibility model to build new server components. In fact, the support for ISAPI filters and extensions in IIS 7.0 is implemented as a native module, developed with the new native API, which hosts and executes ISAPI DLLs. Modules developed using the new native API are similar to the ISAPI filters in that they are Win32 DLLs loaded in-process by each IIS worker process, and they can affect the processing of every request. Because they execute under the rights and privileges of the IIS worker process, they have the same security impact and therefore have to be trusted by the server administrator.

However, this is where many of the similarities end, because IIS 7.0 modules use a much more refined and significantly more powerful C++ API, have access to many more extensibility points by subscribing to one or more of the events in the request processing pipeline, and can accomplish much richer tasks. The new C++ API also significantly improves the server development experience and reduces the potential for reliability issues that plagued the overly complex ISAPI interface. This makes IIS 7.0 native modules the most powerful—and yet simpler and more reliable—way to extend IIS.

Also, for the first time in the history of IIS, IIS 7.0 provides a full-fidelity .NET extensibility model based on ASP.NET. This makes server development significantly more accessible to developers and enables them to rapidly build server features while taking advantage of powerful features of ASP.NET and the .NET Framework. This is made possible by the new ASP.NET integration engine, which elevates ASP.NET from being an application framework to being a first-class extensibility mechanism for IIS 7.0.

As a server administrator, extending IIS with the .NET Framework enables you to delegate IIS extensibility to application owners who do not have administrator privileges on the server. This is possible because of the Code Access Security (CAS)–based ASP.NET hosting model, which constrains the execution of code in ASP.NET applications when configured to run with partial trust. Unlike native modules that execute with full privileges of the IIS worker process, managed ASP.NET modules can execute with limited privileges that can prevent them from negatively affecting the server itself or other applications on the server. This enables IIS 7.0 applications to deploy IIS features to the server without requiring administrative action (such as installing COM objects or ISAPI filters), without compromising server security.

Table 2 is a summary of the differences between native and managed modules.

Table 2. Comparing Native and Managed Modules

	Native Modules	Managed Modules
Developed with	IIS 7.0 C++ module API	ASP.NET module API, any .NET language
Represented by	Win32 DLL	.NET class in a .NET assembly DLL
Scope of execution	IIS worker process	ASP.NET application domain
Execution privilege	IIS worker process identity	IIS Worker process identity, plus constrained by the ASP.NET Trust Level
Deployment model	Globally for the entire server	Globally for the entire server by using the .NET Global Assembly Cache, or xcopy-deploy inside a specific application
Deployment privilege	Administrators only	Application owners can deploy with application

IIS 7.0 configuration is aware of the differences between native and managed modules. It also enables administrators to take full advantage of the constrained execution nature of managed modules by enabling managed modules to be added on a per-application basis by packaging them together with the application content. Application-based deployment of managed modules allows for simple xcopy deployment of IIS applications because they can specify their own IIS configuration and modules.

How It Works: ASP.NET Integrated Pipeline

With the unified pipeline model that IIS 7.0 provides, both native modules developed using the IIS 7.0 native extensibility model and managed modules developed using the ASP.NET module model can participate in the Web server’s request processing (when using the ASP.NET Integrated mode). Both native and managed modules can participate in all request processing stages and operate on a shared set of request and response intrinsic objects.

In practice, however, ASP.NET and IIS are two separate software products. Moreover, ASP.NET Integrated mode uses the standard ASP.NET interfaces that are used to provide request processing services to the ASP.NET application framework on previous versions of IIS. How, then, is such a tight integration possible?

The answer lies in the special native module, ManagedEngine, that is installed on IIS 7.0 when the ".NET Extensibility" Windows Setup component (Windows Vista) or Role Service (Windows Server 2008) is installed. This module implements the ASP.NET Integrated mode engine that enables the ASP.NET request processing pipeline to be overlaid on the IIS request processing pipeline, proxying the event notifications and propagating the required request state to support the pipeline integration. This module is responsible for reading the managed modules and handler entries in the IIS module and handler configuration and working together with the new ASP.NET engine implementation in System.Web.dll to set up the integrated pipeline. As a result, it enables ASP.NET modules and handlers to act as IIS modules and handlers.

So, when you see the ManagedEngine module in the IIS modules list, pay it some respect—it is arguably the most complex and powerful module ever written for IIS 7.0. Also keep in mind that this module must be present for the integrated pipeline and ASP.NET applications in general to work in IIS 7.0 Integrated mode application pools.

Mike Volodarsky

IIS Core Program Manager

However, IIS 7.0 also provides a consistent view of managing modules, whether they are native or managed, so that administrators can control the server feature set in a standard manner regardless of the module type. You will review the differences in the installation of native and managed modules, as well as standard management tasks, later in this section.