Présentation de la délégation de configuration IIS 7.0

par Saad Ladki

Introduction

IIS introduit un système de configuration basé sur un nouveau fichier pour sa septième version de produit. Ce nouveau système met l’accent sur un système piloté par les données adapté à une plateforme web entière où des technologies telles que ASP.NET, Indigo et même des composants tiers peuvent utiliser et étendre ce magasin de configuration pour héberger n’importe quelle propriété de site ou d’application.

Le système est basé sur des fichiers XML définis dans un format simple et clair avec une syntaxe similaire aux fichiers ASP.NET web.config. Ces fichiers de configuration contiennent des paramètres dans des regroupements logiques et toute modification apportée aux fichiers est immédiatement reflétée sur le site ou l’application dont les propriétés sont modifiées.

Ce nouveau système offre également une expérience d’administration déléguée dans laquelle les administrateurs peuvent autoriser les propriétaires de site et d’application à modifier des paramètres spécifiques ; et, l’impact de ces modifications est limité au site ou à l’application spécifique en question. Ce modèle introduit le concept d’applications autonomes où le contenu et les paramètres de configuration sont hébergés dans le répertoire du site ou de l’application et peuvent être déployés à partir d’un ordinateur vers un autre.

Fichiers de configuration et schéma de configuration

IIS 7.0 et versions ultérieures possèdent un fichier de configuration central nommé applicationHost.config situé dans %WINDIR%\System32\InetSrv\Config\. Ce fichier remplace le fichier metabase.xml utilisé par IIS 6.0 pour son magasin de configuration. Ce nouveau système de configuration est très simple, basé sur des fichiers, et pourtant très puissant. Il n’existe aucun service de configuration, car IISADMIN n’est pas obligatoire. Chaque processus de travail a une instance d’un composant lecteur de configuration et extrait directement la configuration à partir des fichiers.

En outre, il n’existe aucune représentation en mémoire de la configuration. Une fois qu’une modification est émise dans un fichier, elle est récupérée immédiatement par le processus de travail et reflétée sur le site, l’application ou le répertoire virtuel donné.

Le fichier applicationHost.config héberge des paramètres globaux pour les différentes fonctionnalités et composants d’IIS et d’autres technologies web. Toute propriété définie dans ce fichier s’applique à tous les sites, applications et répertoires virtuels de la machine.

Le lecteur de configuration utilisé par IIS comprend le format, la syntaxe et le nommage correct de chaque section de configuration, élément et attribut, car ils sont définis dans un fichier de schéma. Le schéma de configuration est défini dans les fichiers situés dans le répertoire %WINDIR%\System32\InetSrv\Config\Schema\. Lors de l'instanciation du système de configuration, le processus de travail lit le schéma en mémoire, ce qui aide le système à comprendre les propriétés qui peuvent être définies et leur format. Au minimum, les fichiers IIS_schema.xml, ASPNET_schema.xml, et FX_schema.xml se trouvent dans ce répertoire et définissent la structure de configuration des sections qui s’appliquent à IIS, ASP.NET et les fonctionnalités .NET Framework respectivement.

Le schéma définit plusieurs aspects de la configuration et de ses sections, comme le nommage des sections et des propriétés, les types attendus pour les valeurs, la plage de ces valeurs ou si l’une d’elles est unique ou obligatoire. En outre, il définit la valeur par défaut qu’un attribut spécifique prendra. Dans le cas donné où une propriété n’est pas définie dans applicationHost.config, sa valeur est extraite du paramètre par défaut indiqué dans le fichier de schéma.

En plus de ce fichier central, applicationHost.config, plusieurs fichiers web.config peuvent apparaître à n’importe quel niveau de la hiérarchie d’URL. Ces fichiers peuvent apparaître sur le site, l’application, le répertoire virtuel ou même les niveaux de chemin d’accès physique. Ces fichiers définissent des propriétés dont les valeurs remplacent les paramètres globaux définis dans applicationHost.config. Toutefois, ces modifications s’appliquent uniquement à l’étendue à laquelle le fichier apparaît, c’est-à-dire pour le site, l’application, le répertoire virtuel ou le chemin d’accès physique à l’emplacement où réside le fichier web.config.

Hiérarchie de configuration et configuration effective

En plus d’applicationHost.config, IIS utilise ASP.NET, qui s’appuie à la fois sur machine.config et sur les fichiers racine web.config. Le fichier machine.config définit les propriétés requises pour toutes les fonctionnalités de Framework. Le fichier web.config racine définit les paramètres globaux des propriétés définies pour toutes les applications web ASP.NET. Ces deux fichiers sont analogues à applicationHost.config d’IIS. Les trois fichiers existent, car la version de .NET Framework et IIS séparément. Il peut y avoir plusieurs versions du Framework installées dans un système Windows Server donné qui a une seule version d’IIS.

Par conséquent, une hiérarchie de configuration est définie et calculée pour les paramètres de configuration du système. La hiérarchie démarre sur machine.config, puis passe au fichier web.config racine, suivi d’applicationHost.config. À partir de là, tout fichier web.config facultatif situé au niveau du site, de l’application ou du répertoire virtuel est ajouté et appliqué à la hiérarchie. À la fin, les propriétés héritent du fichier parent à enfant de machine.config jusqu’au dernier fichier web.config (le cas échéant) et la configuration effective est calculée pour un chemin donné.

Le comportement d’héritage est effectué par défaut. Tout paramètre à un niveau inférieur dans la hiérarchie remplace un paramètre parent défini dans un fichier au-dessus du niveau actuel. Toutefois, en passant plus loin dans la hiérarchie, l’étendue de la configuration est plus limitée. Lorsque les paramètres machine.config, web.config racine et applicationHost.config s’appliquent à tous les fichiers du système, les paramètres facultatifs des fichiers web.config s’appliquent uniquement à l’emplacement actuel et ci-dessous (qu’il s’agisse d’un site, d’une application ou d’un répertoire virtuel).

Sections Configuration

Dans un fichier de configuration, il existe des paramètres possibles qui peuvent être lus et définis. Les paramètres sont regroupés de manière structurée. Plusieurs paramètres similaires ou applicables à une fonctionnalité spécifique (i.e. ASP, authentification, ISAPI, etc.) sont regroupés dans des blocs d’unités logiques appelés sections de configuration. Chaque section de configuration peut inclure d’autres sections de configuration dans celles-ci, mais définit généralement des éléments, des collections ou des attributs.

Un élément de configuration est un élément XML qui définit plusieurs attributs de configuration. Une collection de configuration est un cas particulier d’un élément de configuration qui contient une liste d’éléments définis avec les directives de configuration ajouter/supprimer/effacer. Enfin, les attributs de configuration sont des paramètres de configuration nœud terminal qui représentent des attributs XML.

L’extrait de code suivant montre les paramètres de la section <defaultDocument>. Le mot activé est un attribut où le mot fichiers est un élément qui inclut une liste d’autres éléments définis par la directive ajouter et une série d’attributs.

<defaultDocument enabled="true"> 
    <files> 
        <add value="Default.htm" /> 
        <add value="Default.asp" /> 
        <add value="index.htm" /> 
        <add value="index.html" /> 
        <add value="iisstart.htm" /> 
        <add value="default.aspx" /> 
    </files> 
</defaultDocument>

Cette section de configuration a un schéma associé. L’extrait de code suivant montre le schéma de la section <defaultDocument> du fichier IIS_schema.xml. Le schéma définit le nom de la section et l’espace de noms dans lequel il apparaît (dans ce cas, system.webServer). En outre, le schéma décrit les attributs et les éléments et pour chaque nom, type, valeurs par défaut et autres données intéressantes.

<sectionSchema name="system.webServer/defaultDocument"> 
    <attribute name="enabled" type="bool" defaultValue="true" /> 
    <element name="files"> 
      <collection addElement="add" clearElement="clear" removeElement="remove" mergeAppend="false"> 
        <attribute name="value" type="string" isUniqueKey="true"/> 
      </collection> 
    </element> 
</sectionSchema>

Section spéciale : <configSections>

La section de configuration <configSections> est une section spéciale définie dans applicationHost.config. Il est utilisé comme point de Registre pour les sections de configuration du serveur IIS. Cette section est l’endroit où les sections de configuration actuelles disponibles dans le système sont inscrites. Dans le cas donné où le système de configuration est étendu et qu’une section personnalisée est ajoutée au serveur, elle doit être inscrite en ajoutant une entrée d’élément à cette section.

L’extrait de code suivant montre l’entrée <configSections> pour la section <defaultDocument>. D’autres entrées ont été omises pour des raisons de clarté. La partie intéressante de <configSections> est l’entrée de groupe de sections qui définit l’espace de noms de chaque section - dans ce cas system.webServer et la valeur de l’attribut overrideModeDefault, qui pour cette section est « Autoriser ». Étant donné que allowDefinition n’est pas déclaré, il est extrait du schéma et la valeur par défaut est « Everywhere ».

<configSections> 
    <sectionGroup name="system.webServer"> 
        <section name="defaultDocument" overrideModeDefault="Allow" />
    </sectionGroup>
</configSections>

Outre la définition d’une section et de son groupe de sections, il existe deux attributs clés définis : overrideModeDefault et allowDefinition.

L’attribut overrideModeDefault est un attribut facultatif qui définit l’état verrouillé d’une section. Ses valeurs disponibles sont Autoriser ou Refuser. La valeur par défaut est « Autoriser ». Toutes les sections IIS liées aux performances, à la sécurité ou à l’aspect critique du serveur sont verrouillées avec cet attribut défini sur « Refuser ». Si l’attribut overrideModeDefault est défini sur « Refuser », tous les fichiers de configuration à un niveau inférieur (c’est-à-dire les fichiers web.config) qui définissent une valeur pour une propriété pour la section de configuration spécifique ne peuvent pas prendre effet et remplacer les valeurs globales. Cela entraîne une violation de verrou et une erreur se produit.

L’attribut allowDefinition est un autre attribut facultatif qui définit le niveau de la hiérarchie dans laquelle la section peut être définie et les propriétés peuvent être définies. Si sa valeur est MachineOnly, la section ne peut être définie que dans applicationHost.config ou machine.config. Si sa valeur est MachineToRootWeb, la section peut être définie dans les fichiers MachineOnly ou également dans le fichier web.config racine. Si sa valeur est MachineToApplication, la section peut être définie dans les trois fichiers précédents ou également dans les fichiers web.config dans le dossier racine de l’application. Enfin, si sa valeur est Partout (qui est la valeur par défaut) elle peut être définie dans n’importe quel fichier de configuration, que ce soit dans les fichiers de configuration globalement ou dans les fichiers web.config qui s’appliquent à un site, une application ou un répertoire virtuel donné.

Le concept d’emplacement

Tout paramètre spécifié dans un fichier donné de la hiérarchie de configuration s’applique à ce niveau et en dessous, avec la possibilité d’être remplacé par des fichiers enfants. Toutefois, il existe la possibilité de spécifier et d’appliquer des paramètres de configuration à certains chemins d’accès sous le fichier de configuration actuel à l’aide de la balise emplacement avec un attribut de chemin d’accès. Si le fichier de configuration est applicationHost.config, les balises d’emplacement peuvent inclure un chemin allant de tous les sites, applications et répertoires virtuels dans le système à un site, une application, un répertoire virtuel ou un fichier spécifique. La balise d’emplacement peut également être spécifiée dans les fichiers web.config et peut inclure n’importe quel chemin relatif pour les chemins d’accès sous le site actuel, l’application ou le répertoire virtuel.

L’extrait de code suivant montre comment spécifier une propriété de configuration à appliquer uniquement au site développeur. Cela peut également être obtenu via un fichier web.config dans le contenu du site. La configuration effective pour le site développeur est la liste des entrées de la collection de fichiers dans applicationHost.config, ainsi que le chemin d’accès à l’emplacement et tout fichier web.config pour le site.

<location path="Developer Site" overrideMode="Allow"> 
    <defaultDocument enabled="true"> 
        <files> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location>

Si aucun chemin d’accès n’est déclaré, ce qui équivaut à spécifier un point (.), le chemin d’accès est compris entre ce niveau et en dessous de tous les chemins enfants. Faire cela dans applicationHost.config revient à spécifier la configuration pour le niveau global également.

Un attribut qui peut être défini dans une balise d’emplacement est le overrideMode. Comme overrideModeDefault, cela spécifie si la section de configuration donnée référencée et les propriétés définies dans la balise d’emplacement actuelle peuvent être modifiées et remplacées à des niveaux inférieurs de la hiérarchie.

Verrouillage et déverrouillage d’une section

Le concept initial de verrouillage d’une section via la balise overrideModeDefault dans la section <configSections> peut être pris et étendu pour être plus affiné. En autorisant une section à remplacer au niveau <configSections>, la section est ouverte et ses valeurs peuvent être remplacées par n’importe qui dans le système via des fichiers web.config à n’importe quel niveau de l’espace de noms d’URL. Toutefois, cela peut poser un risque de sécurité sérieux et peut entraîner des effets négatifs sur la disponibilité ou les performances du système. Par le biais de balises d’emplacement, vous pouvez utiliser l’attribut overrideMode et spécifier l’état de verrouillage d’une section et le limiter pour un chemin donné.

L’extrait de code suivant montre comment déverrouiller la section <windowsAuthentication> pour tous les sites, applications et répertoires virtuels dans le système. Pour ce faire, définissez « Autoriser » dans l’attribut overrideModeDefault. L’inconvénient de cette approche est qu’elle déverrouille une section pour tout le monde et que tout le monde est en mesure de remplacer les paramètres au niveau de leur site ou de leur application via des fichiers web.config.

<section name="windowsAuthentication" overrideModeDefault="Allow" />

L’extrait de code suivant montre comment obtenir la même chose, déverrouiller la section <windowsAuthentication>, mais uniquement pour le site AdministratorSite afin que les propriétés de cette section puissent être modifiées via des fichiers web.config au niveau administrateur du site. Les autres sites du système ont le comportement par défaut d’une section <windowsAuthentication> verrouillée. Cette opération s’effectue via l’attribut overrideMode.

<location path="AdministratorSite" overrideMode="Allow"> 
   <security> 
        <authentication> 
            <windowsAuthentication enabled="false"> 
                <providers> 
                    <add value="Negotiate" /> 
                    <add value="NTLM" /> 
                </providers> 
            </windowsAuthentication> 
        </authentication> 
   </security> 
</location> 
 
The location tag path can be specified here a site, application or even a virtual directory to which the administrator wants to unlock configuration and/or apply configuration at that level.

Le comportement opposé peut être obtenu, qui verrouille une section pour un site spécifique, tandis que le reste du système peut le modifier. Par exemple, <defaultDocument> est une section qui a l’attribut overrideModeDefault défini sur « Autoriser » dans la section <configSections> , mais via une balise d’emplacement, nous pouvons verrouiller cette section pour le site de base. Les extraits de code suivants montrent comment procéder tout en définissant également la seule valeur acceptée par le système comme page par défaut pour le serveur à afficher comme page d’accueil intitulée basic.htm. La directive Effacer annule toutes les valeurs héritées des niveaux supérieurs de la hiérarchie de configuration, qui dans ce cas est la liste globale des fichiers de applicationHost.config.

<location path="Basic Site" overrideMode="Deny"> 
    <defaultDocument enabled="true"> 
        <files> 
       </clear> 
            <add value="basic.htm" /> 
        </files> 
    </defaultDocument> 
</location>

Verrouillage granulaire

L’ouverture d’une section via une balise d’emplacement est un moyen efficace de déverrouiller une section et toutes ses propriétés pour le propriétaire du site ou de l’application du chemin spécifié. Cela est en effet une approche tout-ou-rien pour permettre aux propriétaires de site et d’application d’avoir un accès illimité à une section. Toutefois, parfois, les administrateurs veulent un contrôle spécifique sur certaines propriétés d’une section et désirent contrôler certaines valeurs. D’autres peuvent être délégués. C’est là que le verrouillage granulaire entre en jeu.

Le verrouillage granulaire est un regroupement d’attributs spécifiques qui peuvent être définis sur des éléments ou d’autres attributs. Le verrouillage granulaire peut déclarer si les chemins en dessous de l’actuel peuvent modifier les valeurs de configuration. Les valeurs peuvent être lues, mais si des verrous sont définis, ils ne peuvent pas être modifiés ou même déclarés. Ne modifiez pas les valeurs dont les verrous sont définis, car cela entraîne des erreurs de violation de verrouillage de configuration.

Le premier attribut du regroupement de verrouillage granulaire est lockAttributes. Le lockAttributes définit une liste séparée par des virgules d’attributs verrouillés pour les chemins d’accès inférieurs au niveau de configuration actuel. Il accepte également un astérisque (*) comme valeur, ce qui signifie que tous les attributs sont verrouillés. À ce stade, la section de configuration peut être lue dans les chemins d’accès au niveau enfant et même les attributs verrouillés, mais la modification des attributs protégés entraîne des erreurs.

L’extrait de code suivant montre comment verrouiller l’état activé de la section <defaultDocument> pour le site développeur. Si le propriétaire du site développeur désactive la fonctionnalité de document par défaut ou déclare même la propriété avec la même valeur que celle indiquée dans la balise d’emplacement, une violation de verrou se produit.

<location path="Developer Site" > 
    <defaultDocument enabled="true" lockAttributes="enabled" /> 
</location>

Le premier attribut du regroupement de verrouillage granulaire est lockElements. Les lockElements définissent une liste d’éléments séparés par des virgules qui sont verrouillés pour les chemins d’accès sous le niveau de configuration actuel. Comme lockAttributes, il accepte également un astérisque (*) comme valeur, ce qui signifie que tous les éléments sont verrouillés. Cela est très utile pour les sections de configuration qui ont plusieurs éléments ou collections et doivent être protégées pour les chemins d’accès au niveau enfant. Là encore, la modification de l’une des valeurs verrouillées entraîne des erreurs.

L’extrait de code suivant montre comment verrouiller la collection de fichiers pour le site développeur. Cela permet au propriétaire du site de décider si la fonctionnalité de document par défaut est activée ou non ; mais, s’il est activé, il ne peut pas modifier les valeurs globales et hérite de ce que l’administrateur de l’ordinateur a déclaré dans applicationHost.config.

<location path="Developer Site"> 
    <defaultDocument enabled="true" lockElements="files" > 
        <files> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location>

L’exemple lockElement est également utile dans les collections pour verrouiller les directives de cette collection. Les directives sont les mots clés tels que ajouter, supprimer, effacer d’une collection. En verrouillant les directives, un administrateur peut affiner si une liste de collections est disponible pour ajouter ou supprimer certains éléments ou tous les éléments.

L’extrait de code suivant montre comment verrouiller la suppression et l’effacement des entrées actuelles dans la collection de fichiers. Le propriétaire du site peut ajouter de nouvelles entrées à la collection de fichiers si nécessaire. Si le propriétaire du site spécifie une balise claire ou tente de supprimer une entrée, une violation de verrou se produit.

<location path="Developer Site"> 
    <defaultDocument enabled="true" > 
        <files lockElements="clear,remove"> 
            <add value="Developer.htm" /> 
        </files> 
    </defaultDocument> 
</location> 
 
Besides lockAttribute and lockElement, there are negative counterparts: lockAllAttributesExcept, and lockAllElementsExcept. These attributes achieve  the inverse action of the previous ones in which the comma-separated list declares the attributes and elements to be unlocked while the rest are not  available to be edited in child paths.

Il existe également un attribut lockItem . Cela verrouille un attribut et fonctionne au niveau de l’attribut XML. L’extrait de code suivant montre comment l’administrateur de site est en mesure d’effectuer tout ce qu’il souhaite faire, comme ajouter ou supprimer des entrées dans la collection, à l’exception de modifier l’entrée basic.htm dans la collection de fichiers.

<location path="Developer Site"> 
    <defaultDocument enabled="true" > 
        <files> 
            <add value="basic.htm" lockItem="true"/> 
        </files> 
    </defaultDocument> 
</location>

Résumé

Ce document a décrit une vue d’ensemble de base du système de configuration, de ses fichiers, de ses fonctionnalités de schéma et de délégation. Il a également abordé la hiérarchie de configuration et la configuration efficace. L’article a également présenté une introduction aux sections de configuration et à sa structure d’éléments et d’attributs. Il illustre le concept d’emplacement, de verrouillage et de verrouillage granulaire.

Dans l’ensemble, IIS introduit et nouveau système de configuration basé sur des fichiers avec des fonctionnalités permettant de disposer de toutes les configurations dans un fichier de configuration central ou distribuée via des fichiers web.config où les administrateurs de site et d’application peuvent modifier les propriétés qui s’appliquent à leurs applications et à leur contenu. Avec le modèle de configuration distribué, le concept d’applications autonomes où le contenu et les paramètres de configuration sont hébergés dans le répertoire du site ou de l’application et peuvent être déployés à partir d’un ordinateur vers un autre est activé.