Поделиться через

начало работы с конфигурацией в IIS 7 и более поздних версий

  • Статья

Тобин Тит

Краткие сведения

Система конфигурации в IIS 7 и более поздних версий основана на распределенных XML-файлах с прозрачным текстом, которые содержат параметры конфигурации для всей платформы веб-сервера, включая IIS, ASP.NET и другие компоненты. При необходимости ее можно задать в каталогах содержимого вместе с веб-содержимым. Администратор компьютера может делегировать различные уровни иерархии конфигурации другим пользователям, таким как администратор сайта или разработчик приложений. Безопасные параметры по умолчанию и встроенные блокировки ограничивают доступ на запись к параметрам конфигурации только администратору компьютера; Однако сложные и детализированные функции блокировки обеспечивают безопасную разблокировку и делегирование управления определенными параметрами конфигурации для большего числа пользователей для область пространства имен веб-сайта. Система обратно совместима на уровне API с предыдущими версиями IIS и на уровне XML с предыдущими версиями платформы .NET Framework. В этом документе представлен общий обзор новой системы конфигурации.

Введение

Система конфигурации в IIS основана на распределенных XML-файлах с прозрачным текстом, которые содержат параметры конфигурации для всей платформы веб-сервера, включая IIS, ASP.NET и другие компоненты, и при необходимости могут быть заданы в каталогах содержимого вместе с веб-содержимым. Администратор компьютера может делегировать различные уровни иерархии конфигурации другим пользователям, таким как администратор сайта или разработчик приложений. Безопасные параметры по умолчанию и встроенные блокировки ограничивают доступ на запись к параметрам конфигурации только администратору компьютера; Однако сложные и детализированные функции блокировки обеспечивают безопасную разблокировку и делегирование управления определенными параметрами конфигурации для большего числа пользователей для область пространства имен веб-сайта. Система обратно совместима на уровне API с предыдущими версиями IIS и на уровне XML с предыдущими версиями платформы .NET Framework.

Новая система конфигурации предназначена для следующих компонентов:

  • Простой: все состояние находится в файлах; Проприетарное хранилище не используется; Нет базы данных конфигурации в памяти, которая является реальным master состояния конфигурации (в отличие от службы IISADMIN в IIS 6.0); Схема управляется данными и является декларативной и обнаруживаемой на 100 %.

  • Низкий уровень владения: конфигурация может быть xcopied вместе с веб-содержимым; Необязательное делегированное администрирование исключает участие администратора компьютера в каждом изменении конфигурации; Объединение параметров конфигурации и модели в iis, ASP.NET и остальной части платформы веб-сервера обеспечивает единое окно для управления сервером с помощью одного набора средств и API (например, web.config файлы могут содержать параметры IIS и ASP.NET, и есть единое место для управления такими функциями, как проверка подлинности, авторизация, пользовательские ошибки); Резервное копирование, восстановление и управление безопасностью (ACL) основаны на стандартных средствах и процессах файловой системы.

  • Безопасность. При установке служб IIS состояние конфигурации находится в одном файле, защищенном только для доступа администратора компьютера; По умолчанию делегирование не включено; По умолчанию конфиденциальная информация (например, пароли) не сохраняется; Если конфиденциальная информация должна быть записана в файлы конфигурации, она автоматически шифруется на диске; Конфигурацию для отдельных приложений можно изолировать в выделенном файле (защищенном списком управления доступом файловой системы), чтобы другие приложения не могли совместно использовать параметры и читать их.

  • Расширяемый: добавление в схему — это просто удаление XML-файла в папку schemas; Нет необходимости вызывать API или запускать средства для расширения схемы; Параметры организованы в логически связанные блоки, называемые "разделы" (точно так же, как в конфигурации .NET Framework), и добавлять новые разделы легко (не нужно писать код, в отличие от конфигурации .NET Framework); Чтение параметров пользовательских разделов из серверного модуля или приложения является простым и простым.

  • Совместимость. Существующие приложения IIS могут продолжать вызывать интерфейсы, такие как Администратор базовые объекты (ABO), поставщик IIS ADSI и поставщик WMI IIS 6.0; Существующие приложения .NET Framework могут продолжать вызывать интерфейсы, такие как System.Configuration и System.Web.Configuration; Пользователи, знакомые с xml-форматом machine.config и web.config, по-прежнему будут работать с тем же форматом и синтаксисом в этих файлах, а также смогут вручную изменять параметры 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 использует пути внутри файла метабазы, чтобы указать уровень конфигурации (служба, виртуальный каталог, физический каталог). Конфигурация для всего сервера находится в одном файле. СЛУЖБЫ IIS 7.0 и более поздних версий по умолчанию используют один файл, но пользователи могут использовать распределенные web.config файлы в каталогах содержимого, которые указывают параметры конфигурации для своих область.
  • IIS 6.0 использует длинные имена свойств для самостоятельного описания параметров конфигурации. Это позволяет улучшить удобочитаемость файла и помочь пользователю понять, что делает свойство . В IIS 7.0 и более поздних версий используются короткие имена, но они всегда находятся в контексте определенного раздела или даже вложенного элемента с в разделе .
  • IIS 6.0 использует multi-sz (элементы с разделителями-запятыми в одном строковом свойстве) и флаги для обработки значений нескольких элементов, например NTAuthenticationProviders. В IIS 7.0 и более поздних версий используются коллекции с простым синтаксисом add/remove/clear, точно так же, как в конфигурации .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 использует идентификаторы (числа) для идентификации параметров. IIS 7.0 и более поздних версий использует понятные строки для имен параметров.
  • IIS 6.0 использует неинтуитивные понятия, такие как UserType, и терминологию, например InternalName. В IIS 7.0 и более поздних версий используются понятные имена, понятные пользователям, а не только приложениям.

Иерархия файлов конфигурации

Состоянием "master" для конфигурации всегда являются файлы конфигурации (в отличие от IIS 6.0, где это была база данных конфигурации в памяти, которая периодически сбрасывалась на диск).

На корневом (или глобальном) уровне есть два отдельных файла:

  • system32\inetsrv\config\applicationHost.config. Содержит глобальные значения по умолчанию для параметров веб-сервера (IIS).
  • \windows\microsoft.net\framework\v2.0.50727\config\machine.config. Содержит глобальные значения по умолчанию для параметров платформы .NET Framework, включая некоторые из ASP.NET (остальные находятся в web.config в той же папке, которую иногда называют корневой web.config).

Причина, по-прежнему существует два отдельных файла, заключается в том, что версии двух технологий отличаются (по расписанию и продукту). СЛУЖБЫ IIS являются частью Windows, и платформа .NET Framework может устанавливаться независимо в рамках выпусков Visual Studio.

В каталогах веб-содержимого могут быть необязательные файлы web.config, которые управляют поведением уровня иерархии и вниз. Они могут быть локальными или удаленными (например, если каталог содержимого находится в UNC-ресурсе). Они могут содержать IIS, ASP.NET или любые другие параметры конфигурации .NET Framework, которые можно указать на их уровне. По умолчанию файлы web.config отсутствуют.

С точки зрения иерархии наследования корневой файл machine.config, затем web.config в том же каталоге (который называется корневым web.config), затем applicationHost.config, а затем необязательный web.config файлы в пространстве имен.

Файлы включения конфигурации

В некоторых случаях полезно, чтобы файл web.config включал в себя другие .config файл. Это можно сделать с помощью атрибута configSource. В настоящее время он ограничен указанием относительных физических путей во вложенных каталогах из соображений безопасности (т. е. файл A может включать файл B, только если B находится в физическом подкаталоге A). Ниже приведен простой пример использования 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>

Параметры конфигурации всегда относятся к определенному разделу.

Группы разделов существуют только для лучшего структурирования; Они не имеют параметров непосредственно в них, только разделы.

В разделе структура выглядит следующим образом:

  • Элемент Configuration: содержит параметры конфигурации и, возможно, другие элементы конфигурации. Представляется в виде XML-элемента. Разделы также являются элементами.
  • Коллекция конфигураций: частный регистр элемента конфигурации, который содержит список элементов конфигурации в виде add/remove/clear (которые называются директивами коллекции). Представляется в виде XML-элемента с вложенными <элементами add>, <remove> и <clear> .
  • Свойство конфигурации: это параметр конфигурации [leaf]. Представляется в виде 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 содержит две группы разделов main: system.applicationHost и system.webServer. Он также содержит раздел под названием <configSections>, который является несколько особенным в том, что он используется внутренне системой конфигурации для регистрации всех остальных разделов.

По умолчанию machine.config содержит несколько групп разделов. Параметры ASP.NET находятся в группе разделов system.web.

Теги расположения и файлы конфигурации

Во многих случаях рекомендуется избегать web.config файлов в каталогах содержимого, но по-прежнему иметь конфигурацию по URL-адресу, которая переопределяет глобальные значения по умолчанию. Например, администратор хочет указать, что определенный сайт должен использовать определенную схему проверки подлинности, а администраторы сайта (и разработчики приложений на этом сайте) не должны иметь возможности отключить ее.

Самый простой способ добиться этого — использовать теги расположения. Это механизм для указания конфигурации для определенного пути без web.config в папке, сопоставленной с виртуальным путем.

В этом примере показано, как используется тег location в 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="."), для сайта или для определенного пути внутри сайта. В файле может быть несколько тегов расположения. Теги расположения могут находиться в любом .config файле, а не только applicationHost.config или machine.config.

Теги расположения также можно использовать для блокировки и разблокировки разделов. Дополнительные сведения об этом см. в лаборатории блокировки конфигурации.

В некоторых случаях нет альтернативы для использования тегов расположения:

  • Два или более виртуальных путей, сопоставленных с одной и той же физической папкой. Очевидно, что если два виртуальных пути имеют разную конфигурацию, они не могут быть указаны в файле web.config, так как они являются общими.
  • Конфигурация для конкретного файла. Нет web.config файла для файлов; только для всей папки.

Итоги

В этом документе представлен начальный общий обзор системы конфигурации в IIS 7.0 и более поздних версий. Выделен формат более чистой схемы; распределенный характер системы конфигурации и то, как она обеспечивает делегирование параметров конфигурации владельцу сайта или разработчику приложения; структурированная организация параметров в файлах конфигурации; и интеграция между IIS и системами конфигурации ASP.NET.

Для получения дополнительных сведений рекомендуется ознакомиться с остальными документами по конфигурации и, в частности, документом о встроенных функциях конфигурации, в котором рассматриваются более низкоуровневые сведения о системе, включая ее структуру и архитектуру.