要約
IIS 7 以降の構成システムは、IIS、ASP.NET、その他のコンポーネントを含む Web サーバー プラットフォーム全体の構成設定を保持し、必要に応じて Web コンテンツと共にコンテンツ ディレクトリで設定できる、分散型のクリア テキスト XML ファイルに基づいています。 構成階層のさまざまなレベルは、コンピューター管理者によって、サイト管理者やアプリケーション開発者などの他のユーザーに委任される場合があります。 セキュリティで保護された既定値とすぐに使用できるロックダウンにより、構成設定への書き込みアクセスがマシン管理者のみに制限されます。ただし、高度で詳細なロック機能により、Web 名前空間のスコープに対して、特定の構成設定の管理を安全にロック解除し、より多くのユーザーに委任することができます。 システムは、API レベル、以前のバージョンの IIS、および XML レベルで、以前のバージョンの .NET Framework と下位互換性があります。 このドキュメントでは、新しい構成システムの概要について説明します。
イントロダクション
IIS の構成システムは、IIS、ASP.NET、その他のコンポーネントを含む Web サーバー プラットフォーム全体の構成設定を保持する、分散型のクリア テキスト XML ファイルに基づいており、必要に応じて Web コンテンツと共にコンテンツ ディレクトリで設定できます。 構成階層のさまざまなレベルは、コンピューター管理者によって、サイト管理者やアプリケーション開発者などの他のユーザーに委任される場合があります。 セキュリティで保護された既定値とすぐに使用できるロックダウンにより、構成設定への書き込みアクセスがマシン管理者のみに制限されます。ただし、高度で詳細なロック機能により、Web 名前空間のスコープに対して、特定の構成設定の管理を安全にロック解除し、より多くのユーザーに委任することができます。 システムは、API レベル、以前のバージョンの IIS、および XML レベルで、以前のバージョンの .NET Framework と下位互換性があります。
新しい構成システムは、次のように設計されています。
シンプル:すべての状態はファイルにあります。独自のストアは使用されません。(IIS 6.0 の IISADMIN サービスとは異なり) 構成状態の実際のマスターであるメモリ内構成データベースはありません。スキーマはデータドリブンであり、100% 宣言型で検出可能です。
低 TCO: 構成は Web コンテンツと共に実行できます。オプションの委任された管理により、すべての構成変更にマシン管理者が関与する必要がなくなります。IIS、ASP.NET、その他の Web サーバー プラットフォーム間での構成設定とモデルの統合により、同じツールと API のセットを使用してサーバーを管理するためのワンストップ ショップが提供されます (たとえば、web.config ファイルには IIS と ASP.NET の設定の両方が含まれる場合があり、認証、承認、カスタム エラーなどの機能を制御するための 1 つの場所があります)。バックアップ、復元、セキュリティ管理 (ACL) は、標準のファイル システム ツールとプロセスに基づいています。
セキュリティで保護された: IIS がインストールされると、構成状態は、コンピューター管理者アクセスでのみ保護されている 1 つのファイル内にあります。委任は既定では有効になっていません。既定では、機密情報 (パスワードなど) は保存されません。機密情報を構成ファイルに書き込む必要がある場合は、ディスク上で自動的に暗号化されます。アプリケーションごとの構成は、他のアプリケーションが設定を共有したり読み取たりできないように、(ファイル システム ACL によって保護される) 専用ファイルでサンドボックス化および分離できます。
拡張可能: スキーマへの追加は、単に XML ファイルを schemas フォルダーにドロップする必要があります。スキーマを拡張するために API を呼び出したり、ツールを実行したりする必要はありません。設定は、(.NET Framework 構成とまったく同じように) "セクション" と呼ばれる論理的に関連するブロックに編成され、新しいセクションの追加は簡単です (.NET Framework 構成とは異なり、コードを記述する必要はありません)。サーバー モジュールまたはアプリケーションからのカスタム セクション設定の読み取りは簡単で簡単です。
互換性: 既存の IIS アプリケーションは、管理ベース オブジェクト (ABO)、IIS ADSI プロバイダー、IIS 6.0 WMI プロバイダーなどのインターフェイスを引き続き呼び出すことができます。既存の .NET Framework アプリケーションでは、System.Configuration や System.Web.Configuration などのインターフェイスを引き続き呼び出すことができます。machine.config と web.config の XML 形式に慣れているユーザーは、これらのファイルで同じ形式と構文を引き続き使用できます。また、同じ形式とモデルに従う IIS 設定を手動で編集することもできます。IIS メタベースのプロパティ名に慣れているユーザーは、新しい IIS 7.0 以降の構成ファイル内のプロパティに同じ名前を見つけます。
クリーン スキーマ
構成のスキーマを示す例を次に示します。
IIS 6 と IIS 7.0 以降での認証設定の編成方法を示します。
注
IIS 6.0 の概念に慣れていない読者は、IIS 6.0 との比較を無視するだけで、IIS 7.0 以上の概念と利点を読むことができます。
まず、構成がファイルに保持される方法を比較し、次にスキーマ定義を見ていきます。
構成ファイル自体で次の手順を実行します。
//
// Snippet from IIS 6.0 Metabase.xml
//
<IIsWebService Location ="/LM/W3SVC"
... many lines here ...
AuthFlags="AuthAnonymous"
... many lines here ...
>
</IIsWebService>
<IIsWebDirectory Location ="/LM/W3SVC/1/ROOT/aspnet_webadmin/2_0_41016"
AuthFlags="AuthAnonymous | AuthNTLM"
>
</IIsWebDirectory>
<IIsWebVirtualDir Location ="/LM/W3SVC/Info/Templates/Public Web Site/Root"
AuthFlags="AuthAnonymous"
>
</IIsWebVirtualDir>
//
// Snippet from IIS 7.0 applicationHost.config
//
<anonymousAuthentication enabled="true" userName="…" password="" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<windowsAuthentication enabled="true" >
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
重要なポイント :
- IIS 6.0 では、非常に長い "フラット" プロパティの一覧が使用されています。 プロパティの階層またはグループ化はありません。 同じリスト内の数百の設定の中から構成設定を検索するのは困難です。 IIS 7.0 以降では、セクションとセクション グループの階層と、セクション内のサブ要素が使用されます。 認証設定は、認証セクション グループまたは特定の認証セクションで検索することで簡単に検索できます。
- IIS 6.0 では、フラグを使用して認証スキームを設定しています。 IIS 7.0 以降では、認証スキーマごとにセクションが使用され、それぞれに enabled="true|false" が設定されています。 一部の認証スキームにのみ関連する追加設定は、関連するセクションでのみ設定できます (たとえば、ユーザー名とパスワードは匿名認証にのみ設定できます)。
- IIS 6.0 では、メタベース ファイル内のパスを使用して構成レベル (サービス、仮想ディレクトリ、物理ディレクトリ) を指定しています。 サーバー全体の構成は、1 つのファイルに含まれています。 IIS 7.0 以降では既定で 1 つのファイルが使用されますが、ユーザーは、スコープの構成設定を指定するコンテンツ ディレクトリ内の分散 web.config ファイルを利用できます。
- IIS 6.0 では、自己記述型の構成設定を行うために、長いプロパティ名が使用されています。 これは、ファイルの読みやすさを向上させ、ユーザーがプロパティの動作を理解するのを助けようとしています。 IIS 7.0 以降では短い名前が使用されますが、常に特定のセクションのコンテキスト、またはセクション内のサブ要素でも使用されます。
- IIS 6.0 では、複数の sz (1 つの文字列プロパティのコンマ区切り要素) とフラグを使用して、NTAuthenticationProviders などの複数の要素値を処理しています。 IIS 7.0 以降では、.NET Framework の構成とまったく同じように、単純な追加/削除/クリア構文を持つコレクションが使用されています。 これにより、階層の下位レベルでは、必要な要素のみを追加 (または削除) でき、データ全体をその要素と重複させる (または含まない) の代わりにできます。 また、ファイルの読みやすさも向上します (直接編集する際のヒューマン エラーが少なくなります)。
スキーマ ファイルで次の手順を実行します。
//
// Snippet from IIS 6.0 MBSchema.xml
//
<Property InternalName="AuthFlags" ID="6000" Type="DWORD" UserType="IIS_MD_UT_FILE" Attributes="INHERIT" >
<Flag InternalName="AuthAnonymous" Value="1" ID="6218" />
<Flag InternalName="AuthBasic" Value="2" ID="6219" />
<Flag InternalName="AuthNTLM" Value="4" ID="6220" />
<Flag InternalName="AuthMD5" Value="16" ID="6221" />
<Flag InternalName="AuthPassport" Value="64" ID="6299" />
</Property>
//
// Snippet from IIS 7.0 IIS_Schema.xml
//
<sectionSchema name="system.webServer/security/authentication/basicAuthentication">
<attribute name="enabled" type="bool" defaultValue="false" />
<attribute name="realm" type="string" />
<attribute name="defaultLogonDomain" type="string" />
<attribute name="logonMethod" type="enum" defaultValue="ClearText">
<enum name="Interactive" value="0" />
<enum name="Batch" value="1" />
<enum name="Network" value="2" />
<enum name="ClearText" value="3" />
</attribute>
</sectionSchema>
重要なポイント :
- IIS 6.0 では、ID (数値) を使用して設定を識別しています。 IIS 7.0 以降では、フレンドリ文字列を使用して設定に名前を付けます。
- IIS 6.0 では、UserType などの直感的でない概念と、InternalName などの用語が使用されています。 IIS 7.0 以降では、アプリケーションだけでなく、人間の読者にも意味のあるわかりやすい名前が使用されています。
構成ファイル階層
構成の "マスター" 状態は常に構成ファイルです (IIS 6.0 とは異なり、インメモリ構成データベースであり、ディスクに定期的にフラッシュされていました)。
ルート (またはグローバル) レベルには、次の 2 つの個別のファイルがあります。
- system32\inetsrv\config\applicationHost.config: Web サーバー (IIS) 設定のグローバル既定値を保持します。
- \windows\microsoft.net\framework\v2.0.50727\config\machine.config: ASP.NET 設定の一部を含む、.NET Framework 設定のグローバル既定値を保持します (残りの設定は同じフォルダーの web.config にあり、ルート web.configと呼ばれることもあります)。
2 つの異なるファイルが存在する理由は、2 つのテクノロジのバージョンが異なるためです (スケジュールごとのバージョンと製品単位)。 IIS は Windows の一部であり、.NET Framework は Visual Studio リリースの一部として個別にバージョン管理できます。
Web コンテンツ ディレクトリには、階層レベルと下位レベルの動作を制御するオプションの web.config ファイルが存在する場合があります。 これらはローカルでもリモートでもかまいません (たとえば、コンテンツ ディレクトリが UNC 共有にある場合)。 IIS、ASP.NET、またはそのレベルで指定できるその他の .NET Framework 構成設定を含めることができます。 既定では、web.config ファイルはありません。
継承階層では、ルート ファイルが machine.configされ、同じディレクトリ (ルート web.configと呼ばれます) で web.config され、その後、名前空間に沿ったオプションの web.config ファイルが applicationHost.configされます。
構成のインクルードファイル
場合によっては、web.config ファイルに他の .config ファイルを含めるのが便利です。 これを行うには、configSource 属性を使用します。 現時点では、セキュリティ上の理由から、サブディレクトリ内の相対物理パスを指すように制限されています (つまり、ファイル A は、B が A の物理サブディレクトリにある場合にのみファイル B を含めることができます)。 configSource の使用方法を示す基本的な例を次に示します。
<!-- in inetsrv\applicationHost.config -->
<configuration>
<system.webServer>
<!-- mimemaps moved by the customer to a different file -->
<!-- so that this file is shorter and more readable -->
<staticContent configSource="staticContent.config"/>
<!-- the rest of system.webServer sections are here… -->
</system.webServer>
</configuration>
<!-- in inetsrv\staticContent.config -->
<configuration>
<system.webServer>
<staticContent>
<!-- all the mimemap definitions are here -->
<mimeMap ….. />
<mimeMap ….. />
<mimeMap ….. />
</staticContent>
</system.webServer>
</configuration>
この例では、お客様は、staticContent セクションのコンテンツを別のファイルに移動して、より短く、読みやすく、applicationHost.configしたいと考えていました。
.config ファイルで構成設定が変更されると、サーバーは自動的に変更を取得し、その変更に対処します。 お客様は、アプリケーションまたはアプリケーション プールまたはサーバー全体のリサイクルについて心配する必要はありません (たとえば、変更された構成設定によっては、サーバー自体がアプリケーション プールをリサイクルする場合があります)。
設定の整理
構成ファイル (階層の特定のレベル) 内では、設定はフラット リストとしてではなく、構造化された方法で編成されます。 展開、登録、および拡張性の基本的な単位は、構成セクションです。 セクションはセクション グループ内に含まれます。このセクションは、親セクション グループに含まれる場合があります。 セクション自体は入れ子になりません。 セクション グループは次のとおりです。
applicationHost.configの例を次に示します。
<!-- section group for web server configuration -->
<system.webServer>
<!-- section group for web server security configuration -->
<security>
<!-- section group for web server authentication configuration -->
<authentication>
<!-- three sections for authentication -->
<basicAuthentcation ... />
<windowsAutnentication ... />
<anonymousAuthentication ... />
</authentication>
</security>
</system.webServer>
構成設定は常に特定のセクションに属します。
セクショングループは、より良い構造化のためにのみ存在します。それ自体には設定がなく、セクションにのみ設定があります。
セクション内の構造は次のとおりです。
- 構成要素: 構成設定とその他の構成要素が含まれます。 XML 要素として表されます。 セクションも要素です。
- 構成コレクション: 構成要素のプライベート ケース。構成要素の一覧を、add/remove/clear (コレクション ディレクティブと呼ばれます) の形式で格納します。 <add>、<remove>、<clear> サブ要素を含む XML 要素として表されます。
- 構成プロパティ: これは [リーフ] 構成設定です。 XML 属性として表されます。
applicationHost.configの例を次に示します。
<!-- "windowsAuthentcation" is a section which is an element -->
<!-- "enabled" is a property -->
<windowsAuthentication enabled="true">
<!-- "providers" is a collection which is an element -->
<providers>
<!-- the collection contains two elements -->
<!-- "add" is the collection directive; "value" is the property -->
<add value="Negotiate"/>
<add value=""NTLM/>
</providers>
</windowsAuthentication>
既定では、applicationHost.config には system.applicationHost と system.webServer という 2 つのメイン セクション グループが含まれています。 また、 <configSections> と呼ばれるセクションも含まれています。これは、他のすべてのセクションを登録するために構成システムによって内部的に使用されるという点でやや特殊です。
既定では、machine.config には複数のセクション グループが含まれています。 ASP.NET 設定は、system.web セクション グループにあります。
場所タグと構成ファイル
多くの場合、コンテンツ ディレクトリ内のファイル web.config は避け、グローバルな既定値をオーバーライドする URL ごとの構成が必要です。 たとえば、管理者は、特定のサイトで何らかの認証スキームを使用する必要があり、サイト管理者 (およびそのサイトのアプリケーション開発者) がそれをオフにできないように指定する必要があります。
これを実現する最も簡単な方法は、場所タグを使用する方法です。 これは、仮想パスにマップされたフォルダーに web.config を持たずに、特定のパスの構成を指定するメカニズムです。
この例では、applicationHost.config内で場所タグがどのように使用されるかを示します。
<!-- the following will take effect on MyAdminSite -->
<___location path="MyAdminSite">
<system.webServer>
<security>
<authentication>
<basicAuthentication enabled="false"/>
<windowsAuthentication enabled="true"/>
<anonymousAuthentication enabled="false"/>
</authentication>
</security>
</system.webServer>
</___location>
場所タグを使用して、グローバル レベル (path=".")、サイト、またはサイト内の特定のパスの構成を指定できます。 ファイルには複数の場所タグを含めることができます。 場所タグは、applicationHost.config や machine.configだけでなく、任意の .config ファイルに含めることができます。
場所タグは、セクションのロックとロック解除にも使用できます。 詳細については、構成ロック ラボを参照してください。
場合によっては、場所タグを使用する代わりの方法はありません。
- 同じ物理フォルダーにマップされた 2 つ以上の仮想パス。 明らかに、2 つの仮想パスの構成が異なる場合は、共有されているため、web.config ファイルで指定することはできません。
- ファイル固有の構成。 ファイルに web.config ファイルはありません。フォルダー全体に対してのみ。
概要
このドキュメントでは、IIS 7.0 以降の構成システムの概要について説明しました。 よりクリーンなスキーマ形式が強調表示されました。構成システムの分散型の性質と、サイト所有者またはアプリケーション開発者への構成設定の委任を可能にする方法。構成ファイル内の設定の構造化された編成。IIS と ASP.NET 構成システムの統合。
詳細については、残りの構成ドキュメント、特に構成組み込みドキュメントを確認することをお勧めします。このドキュメントでは、設計やアーキテクチャなど、システムに関するより低レベルの詳細に進みます。