Introducción a la configuración de IIS 7 y versiones posteriores

  • Artículo

por Tobin Titus

Abstract

El sistema de configuración en IIS 7 y versiones posteriores se basa en archivos XML distribuidos, de texto no cifrado, que contienen las opciones de configuración para toda la plataforma del servidor web, incluido IIS, ASP.NET y otros componentes y que, opcionalmente, se pueden establecer en los directorios de contenido junto con el contenido web. El administrador de la máquina puede delegar distintos niveles de la jerarquía de configuración a otros usuarios, como el administrador del sitio o el desarrollador de aplicaciones. Los valores predeterminados seguros y el bloqueo preconfigurado limitan el acceso de escritura a las opciones de configuración solo al administrador de la máquina; sin embargo, las características de bloqueo sofisticadas y granulares permiten el desbloqueo seguro y la delegación de la administración de opciones de configuración específicas para más usuarios, para su ámbito del espacio de nombres web. El sistema es compatible con versiones anteriores, en el nivel de API, con versiones anteriores de IIS y en el nivel XML, con versiones anteriores de .NET Framework. En este documento se proporciona información general sobre el nuevo sistema de configuración.

Introducción

El sistema de configuración en IIS se basa en archivos XML distribuidos, de texto no cifrado, que contienen las opciones de configuración para toda la plataforma del servidor web, incluido IIS, ASP.NET y otros componentes y que, opcionalmente, se pueden establecer en los directorios de contenido junto con el contenido web. El administrador de la máquina puede delegar distintos niveles de la jerarquía de configuración a otros usuarios, como el administrador del sitio o el desarrollador de aplicaciones. Los valores predeterminados seguros y el bloqueo preconfigurado limitan el acceso de escritura a las opciones de configuración solo al administrador de la máquina; sin embargo, las características de bloqueo sofisticadas y granulares permiten el desbloqueo seguro y la delegación de la administración de opciones de configuración específicas para más usuarios, para su ámbito del espacio de nombres web. El sistema es compatible con versiones anteriores, en el nivel de API, con versiones anteriores de IIS y en el nivel XML, con versiones anteriores de .NET Framework.

El nuevo sistema de configuración está diseñado para:

  • Ser sencillo: todo el estado se encuentra en archivos, no se utiliza ningún almacén propietario, no hay ninguna base de datos de configuración en memoria que sea el elemento maestro real del estado de configuración (a diferencia del servicio IISADMIN de IIS 6.0), el esquema está controlado por datos y es un 100 % declarativo y reconocible.

  • Tener un TCO bajo: la configuración se puede copiar junto con el contenido web. La administración delegada opcional elimina la participación del administrador de la máquina en cada cambio de configuración. La unificación de las opciones de configuración y el modelo entre IIS, ASP.NET y el resto de la plataforma del servidor web proporciona una solución única para administrar el servidor mediante el mismo conjunto de herramientas y API (por ejemplo, los archivos web.config pueden contener la configuración de IIS y ASP.NET, y hay un lugar entre ambos para controlar características como la autenticación, la autorización y los errores personalizados). La copia de seguridad, la restauración y la administración de la seguridad (ACL) se basan en procesos y herramientas estándar del sistema de archivos.

  • Ser seguro: cuando se instala IIS, el estado de configuración se encuentra en un archivo protegido solo para el acceso del administrador del equipo. No hay ninguna delegación habilitada de manera predeterminada. No se almacena información confidencial (como contraseñas) de manera predeterminada. Cuando es necesario escribir información confidencial en los archivos de configuración, se cifra automáticamente en el disco. La configuración por aplicación se puede colocar y aislar en un archivo dedicado (protegido mediante ACL del sistema de archivos), de modo que otras aplicaciones no pueden compartir ni leer la configuración.

  • Ser extensible: agregar algo al esquema es simplemente una cuestión de colocar un archivo XML en la carpeta de esquemas. No es necesario llamar a las API ni ejecutar herramientas para ampliar el esquema. La configuración se organiza en bloques relacionados lógicamente denominados "secciones" (exactamente igual que en la configuración de .NET Framework) y agregar nuevas secciones es fácil (no es necesario escribir ningún código, a diferencia de la configuración de .NET Framework). Leer la configuración personalizada de una sección desde un módulo de servidor o una aplicación es fácil e intuitivo.

  • Ser compatible: las aplicaciones IIS existentes pueden seguir llamando a interfaces como la de objetos base de administración (ABO), el proveedor ADSI de IIS y el proveedor WMI de IIS 6.0. Las aplicaciones de .NET Framework existentes pueden seguir llamando a interfaces como System.Configuration y System.Web.Configuration. Los usuarios que están familiarizados con el formato XML de machine.config y web.config seguirán experimentando el mismo formato y sintaxis en estos archivos, además de que podrán editar manualmente la configuración de IIS que sigue el mismo formato y modelo. Los usuarios que están familiarizados con los nombres de propiedades de metabase de IIS encontrarán los mismos nombres para las propiedades en los nuevos archivos de configuración de IIS 7.0 y versiones posteriores.

Limpieza de esquemas

Este es un ejemplo que muestra el esquema de configuración.

Muestra cómo se organizan las opciones de autenticación en IIS 6 y en IIS 7.0 y versiones posteriores.

Nota:

Los lectores que no estén familiarizados con los conceptos de IIS 6.0 simplemente pueden ignorar la comparación con IIS 6.0 y leer sobre los conceptos y ventajas de IIS 7.0 y versiones posteriores.

Primero compararemos la forma en que la configuración se conserva en el archivo y, a continuación, echaremos un vistazo a la definición del esquema.

En el propio archivo de configuración:

//
// 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>

Conclusiones clave:

  • IIS 6.0 usa una lista de propiedades muy larga, "plana". No hay ninguna jerarquía ni agrupación de propiedades. Es difícil buscar opciones de configuración entre cientos de opciones de configuración en la misma lista. IIS 7.0 y versiones posteriores usan una jerarquía de secciones y grupos de secciones, y subelementos dentro de las secciones. Es fácil buscar las opciones de autenticación, buscándolas en el grupo de secciones de autenticación o en una sección de autenticación específica.
  • IIS 6.0 usa marcas para establecer esquemas de autenticación. IIS 7.0 y las versiones posteriores usan una sección por esquema de autenticación, con enabled="true|false" en cada una. La configuración adicional que es pertinente solo para algunos esquemas de autenticación, solo se puede establecer en las secciones correspondientes (por ejemplo, el nombre de usuario y la contraseña solo se pueden establecer para la autenticación anónima).
  • IIS 6.0 usa rutas de acceso dentro del archivo de metabase para especificar el nivel de configuración (servicio, directorio virtual, directorio físico). La configuración de todo el servidor está en un archivo. IIS 7.0 y versiones posteriores usan un archivo de manera predeterminada, pero los usuarios pueden aprovechar los archivos web.config distribuidos en los directorios de contenido que especifican las opciones de configuración para su ámbito.
  • IIS 6.0 usa nombres de propiedad largos en un intento de tener opciones de configuración autodescriptivas. Esto intenta mejorar la legibilidad del archivo y ayuda al usuario a comprender para qué sirve la propiedad. IIS 7.0 y versiones posteriores usan nombres cortos, pero siempre en el contexto de una sección específica, o incluso en un subelemento dentro de la sección.
  • IIS 6.0 usa multi-sz (elementos delimitados por comas en una propiedad de cadena) y marcas, para controlar varios valores de elemento, como NTAuthenticationProviders. IIS 7.0 y versiones posteriores usan colecciones, con una sintaxis simple para agregar, eliminar o borrar, exactamente igual que en la configuración de .NET Framework. Esto permite que los niveles inferiores de la jerarquía agreguen (o eliminen) solo el elemento que necesitan, en lugar de duplicar los datos completos con (o sin) el elemento indicado. También proporciona una mayor legibilidad del archivo (lo que se traduce en menos errores humanos al editarlo directamente).

En el archivo del esquema:

//
// 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>

Conclusiones clave:

  • IIS 6.0 usa identificadores (números) para identificar las opciones. IIS 7.0 y versiones posteriores usan cadenas descriptivas para asignar nombres a la configuración.
  • IIS 6.0 usa conceptos no intuitivos como UserType y terminología como InternalName. IIS 7.0 y versiones posteriores usan nombres descriptivos que tienen sentido para los lectores humanos y no solo para las aplicaciones.

Jerarquía de archivos de configuración

El estado "maestro" de la configuración siempre son los archivos de configuración (a diferencia de IIS 6.0, donde era la base de datos de configuración en memoria, la cual se vaciaba al disco periódicamente).

En el nivel raíz (o global), hay dos archivos independientes:

  • system32\inetsrv\config\applicationHost.config: retiene los valores predeterminados globales para la configuración del servidor web (IIS).
  • \windows\microsoft.net\framework\v2.0.50727\config\machine.config: contiene los valores predeterminados globales de la configuración de .NET Framework, incluidos algunos de los ASP.NET (el resto de la configuración se encuentra en web.config en la misma carpeta, que a veces es llamada web.config raíz).

La razón por la que todavía hay dos archivos independientes es porque las dos tecnologías tienen una versión diferente (según la programación y el producto). IIS forma parte de Windows y .NET Framework se puede versionar de forma independiente, como parte de las versiones de Visual Studio.

En los directorios de contenido web, puede haber archivos web.config opcionales que controlen el comportamiento de su nivel de jerarquía y hacia abajo. Podrían ser locales o remotos (si el directorio de contenido está en un recurso compartido UNC, por ejemplo). Pueden contener IIS, ASP.NET o cualquier otra configuración de .NET Framework que se pueda especificar en su nivel. De manera predeterminada, no hay archivos web.config.

En términos de jerarquía de herencia, el archivo raíz es machine.config, web.config en el mismo directorio (denominado root web.config), luego applicationHost.config y, a continuación, los archivos web.config opcionales junto con el espacio de nombres.

Configuración de archivos de inclusión

En algunos casos, resulta útil hacer que el archivo web.config incluya algún otro archivo .config. Esto se puede hacer mediante el atributo configSource. Actualmente se limita a apuntar a rutas de acceso físicas relativas en subdirectorios, por motivos de seguridad (es decir, el archivo A solo puede incluir el archivo B si B está en un subdirectorio físico de A). Este es un ejemplo básico que muestra cómo usar 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>

En este ejemplo, el cliente quería mover el contenido de la sección staticContent a un archivo independiente, con el fin de tener un archivo applicationHost.config más corto y legible.

Tenga en cuenta que cuando las opciones de configuración cambian en un archivo .config, el servidor seleccionará automáticamente los cambios y actuará sobre ellos. El cliente no debe preocuparse por reciclar aplicaciones o grupos de aplicaciones ni todo el servidor (el propio servidor puede reciclar grupos de aplicaciones, por ejemplo, dependiendo de qué opciones de configuración cambiaron).

Organización de la configuración

Dentro de un archivo de configuración (es decir, para un nivel determinado de la jerarquía), la configuración se organiza de forma estructurada y no como una lista plana. La unidad básica de implementación, registro y extensibilidad es la sección de configuración. Una sección se encuentra dentro de un grupo de secciones que, a su vez, puede estar contenido en un grupo de secciones primario. Las secciones en sí no están anidadas. Los grupos de secciones sí.

Este es un ejemplo de 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>

Las opciones de configuración siempre pertenecen a una sección específica.

Los grupos de secciones solo existen para una mejor estructuración; no tienen opciones de configuración directamente en ellas, solo secciones.

En una sección, la estructura es la siguiente:

  • Elemento de configuración: contiene las opciones de configuración y posiblemente otros elementos de configuración. Se representa como un elemento XML. Las secciones también son elementos.
  • Colección de configuración: un caso privado del elemento de configuración, que contiene una lista de elementos de configuración, con el formato add/remove/clear (que se denominan directivas de colección). Se representa como un elemento XML con los subelementos <add>, <remove> y <clear>.
  • Propiedad de configuración: se trata de una opción de configuración [hoja]. Se representa como un atributo XML.

Este es un ejemplo de 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>

De manera predeterminada, applicationHost.config contiene dos grupos de secciones principales: system.applicationHost y system.webServer. También contiene una sección denominada <configSections>, que es algo especial que el sistema de configuración usa internamente para registrar todas las demás secciones.

De manera predeterminada, machine.config contiene varios grupos de secciones. La configuración de ASP.NET se encuentra en el grupo de secciones system.web.

Etiquetas de ubicación en comparación con archivos de configuración

En muchos casos, se desea evitar archivos web.config en los directorios de contenido, pero aún así disponer de una configuración por dirección URL que invalide los valores predeterminados globales. Por ejemplo: el administrador quiere especificar que un sitio concreto debe usar un esquema de autenticación y los administradores del sitio (y los desarrolladores de aplicaciones de ese sitio) no deben poder desactivarlo.

La manera más fácil de lograr esto es mediante etiquetas de ubicación. Este es un mecanismo para especificar la configuración de una ruta de acceso específica, sin tener un archivo web.config en la carpeta asignada a la ruta de acceso virtual.

En este ejemplo se muestra cómo se usa una etiqueta de ubicación en 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>

Las etiquetas de ubicación se pueden usar para especificar la configuración del nivel global (path="."), para un sitio o para una ruta de acceso específica dentro de un sitio. Puede haber varias etiquetas de ubicación en un archivo. Las etiquetas de ubicación pueden estar en cualquier archivo .config, no solo applicationHost.config o machine.config.

Las etiquetas de ubicación también se pueden usar para bloquear y desbloquear secciones. Puede encontrar más información sobre esto en el laboratorio sobre el bloqueo de la configuración.

En algunos casos, no hay ninguna alternativa al uso de etiquetas de ubicación:

  • Dos o más rutas de acceso virtuales asignadas a la misma carpeta física. Obviamente, si las dos rutas de acceso virtuales tienen una configuración diferente, no se puede especificar en un archivo web.config porque se comparte.
  • Configuración específica de archivos. No hay ningún archivo web.config para archivos, solo para toda la carpeta.

Resumen

En este documento se proporciona información general inicial, de alto nivel, del sistema de configuración en IIS 7.0 y versiones posteriores. Se ha destacado el formato de esquema más limpio, la naturaleza distribuida del sistema de configuración y cómo permite la delegación de opciones de configuración al propietario del sitio o al desarrollador de aplicaciones. También se ha destacado la organización estructurada de la configuración en los archivos de configuración y la integración entre los sistemas de configuración de IIS y ASP.NET.

Para más información, se recomienda revisar el resto de los documentos de configuración y, en particular, el documento Aspectos intrínsecos de la configuración, que describe con más detalle el sistema, incluido su diseño y arquitectura.