22.April.2005 Update: I have changed my feature request concerning delegated administration.  I would like to be able to delegate that site and application owners both be able to create new applications within their physical folder hierarchy.  The creation of virtual directories can remain a server administrator function.

Today the focus of the IIS 7.0 DevLabs centered around new monitoring and diagnostics features as well as security.

Monitoring and Diagnostics apparently is an expansion of some new things that have been released with Windows 2003 Service Pack 1.  I was not aware of any new monitoring features in this service pack so I now have some new things to explore that I can use today!  I am told the best place to start to get a handle on the new features is the webcast: IIS 6.0 Service Pack 1 Tracing: Inside and Out.  In addition to this I imagine that some of the new performance and health monitoring features in ASP.NET 2.0 will also be merged in.  This area of IIS and ASP.NET development is something I have not spent much time, but it is certainly needed.  It has been far too difficult to troubleshoot IIS hosted applications.

IIS 7.0 is going to allow us to get information on the state of all running sites, application pools, worker processes, and application domains.  Additionally it looks like we will get programmatic control of starting and stopping some of these services at levels that are lower than the site.  The ability to drill into the currently executing requests through the Admin Tool and WMI is going to finally enable us to easily see which applications are hogging the CPU and memory.

The ASP.NET tracing model has made its way into IIS and both can actually be combined into a single log.  Essentially IIS becomes and ASP.NET trace listener if you want to configure it that way.  By merging the tracing we get a complete picture into the request/response cycle with all trace details in order and in context.  A fantastic feature that will be included with IIS is the ability to automatically log tracing details for failed requests.  For example, if the application does not respond, is too slow to respond, or responds with an error, the auto-tracing feature can take care of guranteeing that the trace details get recorded. There is an admin service that runs outside of the IIS server itself, so even if the application fails completely, trace data still gets written, which apparently is not the case with ASP.NET alone.  Modules participating in the IIS pipeline can be both providers and consumers of tracing output.  Administrators will appreciate the ease with which they can enable or disable tracing through the admin tool.

Security has been greatly enhanced as I have previously alluded to.  Today we dove deeper into some of the scenarios and looked at how to start with totally locked down server and slowly add functionality to it as needed.  This differs greatly for current defaults where most IIS functionality is enabled out of the box.  IIS 6 certainly improved on this over IIS 5, but the modular architecture of IIS 7 takes this idea to the extreme.  Limiting the installed modules reduces the attack surface and patch requirements to only those features that are installed.  For example, if you plan to only server static content you would not need to worry about attacks and patches for ASP or ASP.NET.

Wearing my site and server administrator hat I get very excited about the new security delegation features as I mentioned yesterday.  An additional and very helpful aspect of this includes the ability to delegate administration to non-Windows users.  That will be fantastic for hosting scenarios.  Delegation follows the standard hierarchy of site and application. Hmm, I wonder if non-Windows uses can be configured as server admins?  Comments IIS team?  Currently only server admins are able to create virtual directories and applications.  Personally I see this as a huge mistake.  As a consumer of hosting services I have to have the ability to create IIS applications within my hosting space so that I can run applications like dasBlog and others in a sub folder of my site.  If you agree then join me in asking for delegated administration of virtual directories and applications.  At the moment this is my 2nd biggest request for the IIS team.

Putting my ASP.NET developer hat (favorite) back on I'd like to buy Scott Guthrie at least a case of beer (or whatever his favorite beverage is) for merging the authentication an authorization of IIS and ASP.NET.  (Share it with the team doing the work!)  Finally the authentication options are all configured in only 1 place.  In addition I can just interact with the reuesting User in the context and not be concerned about how that user was authenticated.  Further we finally have a solution the problem of applications that want to first check for a Windows user and then fail over to forms authentication.  Today that scenario requires configuring a page to use Windows authentication in IIS and then handling a security exception and and it gets messier from there.

Good stuff abounds in the IIS 7.0 security picture:

• Impersonation has been improved so that is not so confusing about which account the application is running under.
• All authentication mechanisms can be applied to all content, including ASP.NET 2.0 membership authentication solutions.

Note to self: Research ADFS (Active Directory Federated Services) and how it may tie into a custom SSO solution.

URLScan and some of the other tools currently available to tighten security and assist with URL authorization have been replaced by, as one would imagine by now, powerful new configuration elements and of course corresponding modules.

• The features of URL Scan have been built in and enhanced.
• System policy can enforce authorization and serving rules.
• There are 12 new 404 error sub status codes to help determine the rules blocking access.
• Authorization is granular all the way down to the URL level.
• Rules can be deployed with the application as expected when using config files.
• File extensions can be restricted.
• Verbs can be restricted. (POST, GET, etc)
• Specific files and folders can be protected from being served. This can be accomplished with "hidden namespaces" or sequences.  Sequences are string patterns that allow you to block say all URI's that contain "bin" or something like that.  This enables easy blocking of specific patterns that may exploit vulnerabilities as they come up.

Tomorrow the DevLab will wrap up and I will head home.  Stay tuned for the final post in the series.