Datasheet
<section name=”MyNewModule” />
....
</configSections>
With these simple changes to the configuration files, you’ve added the custom module MyNewModule
to IIS, with its own custom schema.
Componentization
Extensibility doesn’t only apply to configurations. Because of the changes to the request processing
pipeline, the core server itself is extensible, using both native and managed code. This extensibility
comes from the componentization of the core IIS functions. Instead of having to work with ISAPI filters
to modify the request process, you can now inject your own components directly into the processing
pipeline. These components can be your own code, third-party utilities and components, and existing
Microsoft core components. This means that if you don’t like Microsoft’s Windows authentication
process, you can not only choose to use forms authentication on all files, but also you can choose to
bypass all built-in authentication and roll your own. This also means that if you don’t need to process
classic ASP files, you can simply not load that component. Unlike in previous versions, where compo-
nents were loaded into memory in a single DLL, you can reduce the memory footprint of IIS 7.0 by not
loading what you don’t need.
Security
Componentization also increases the already strong security that existed in IIS 6.0. A perennial com-
plaint against Microsoft had always been that IIS installed by default and that all services were active by
default. IIS 6.0 and Server 2003 reversed that course — almost nothing was installed by default, and
even when you did install it, the majority of components were disabled by default. To enable ASP.NET,
you had to choose to allow ASP.NET as a web service extension. Classic ASP had to be enabled sepa-
rately, as did third-party CGI application processors such as Perl or PHP.
With the exception of third-party software, though, IIS 6.0 still loaded all the services into memory — it just
loaded them as disabled. For example, if you didn’t want to use Windows authentication, as would be the
case if you were using your own authentication scheme, you could choose not to enable it, but the code still
resided in memory. Similarly, default IIS 6.0 installations were locked down to processing static HTML files,
a good choice from a security standpoint. But what if you were never going to use static HTML files in your
application or site? In IIS 7.0, you have the option of never loading the code in the first place.
This book devotes three chapters to security-related issues. In Chapter 13, securing your server is dis-
cussed. In Chapter 14, authentication and authorization are covered. Finally, in Chapter 15, SSL, and
TLS are discussed. General Windows and network security precautions are not a major part of this
book, but remember that IIS doesn’t operate in a vacuum. Security risks need to be mitigated in all areas
of your network infrastructure as well as all applications on your servers. A SQL Server breach won’t
technically be a compromise of your IIS security, but if the server is compromised, it really doesn’t mat-
ter that it wasn’t an IIS configuration, does it?
14
Part 1: Introduction and Deployment
97823c01.qxd:WroxPro 2/4/08 6:47 PM Page 14