Compartilhar via

Introdução à configuração no IIS 7 e posterior

  • Artigo

por Tobin Titus

Resumo

O sistema de configuração no IIS 7 e posterior é baseado em arquivos XML distribuídos e de texto não criptografado que contêm as configurações de toda a plataforma do servidor Web, incluindo o IIS, o ASP.NET e outros componentes e, opcionalmente, podem ser definidas nos diretórios de conteúdo com o conteúdo da Web. Diferentes níveis da hierarquia de configuração podem ser delegados pelo administrador do computador a outros usuários, como o administrador do site ou o desenvolvedor de aplicativos. Proteger os padrões e o limite de bloqueio pronto para uso limita o acesso de gravação às configurações somente ao administrador do computador. No entanto, os recursos de bloqueio sofisticados e granulares permitem o desbloqueio seguro e a delegação do gerenciamento de configurações específicas para mais usuários, nos respectivos escopos do namespace da Web. O sistema é compatível com versões anteriores do IIS, no nível da API, e com versões anteriores do .NET Framework, no nível do XML. Este documento apresenta uma visão geral do novo sistema de configuração.

Introdução

O sistema de configuração no IIS é baseado em arquivos XML distribuídos e de texto não criptografado que contêm as definições de configuração para toda a plataforma do servidor Web, incluindo o IIS, o ASP.NET e outros componentes, e pode, opcionalmente, ser definida nos diretórios de conteúdo com o conteúdo da Web. Diferentes níveis da hierarquia de configuração podem ser delegados pelo administrador do computador a outros usuários, como o administrador do site ou o desenvolvedor de aplicativos. Proteger os padrões e o limite de bloqueio pronto para uso limita o acesso de gravação às configurações somente ao administrador do computador. No entanto, os recursos de bloqueio sofisticados e granulares permitem o desbloqueio seguro e a delegação do gerenciamento de configurações específicas para mais usuários, nos respectivos escopos do namespace da Web. O sistema é compatível com versões anteriores do IIS, no nível da API, e com versões anteriores do .NET Framework, no nível do XML.

O novo sistema de configuração foi projetado para ser:

  • Simples: todo o estado fica nos arquivos; nenhum repositório proprietário é usado; nenhum banco de dados de configuração na memória é o verdadeiro mestre do estado de configuração (ao contrário do serviço IISADMIN do IIS 6.0); o esquema é controlado por dados e é 100% declarativo e detectável.

  • TCO baixo: a configuração pode ser copiada com o XCopy junto com o conteúdo da Web; a administração delegada opcional elimina o envolvimento do administrador do computador em cada alteração de configuração; a unificação de definições de configuração e modelo no IIS, ASP.NET e o restante da plataforma do servidor Web fornece um lugar unificado para gerenciar o servidor por meio do mesmo conjunto de ferramentas e APIs (por exemplo, os arquivos web.config podem conter configurações do IIS e do ASP.NET, e há um lugar nos dois para controlar recursos como autenticação, autorização, erros personalizados); o backup, a restauração e o gerenciamento de segurança (ACLs) são baseados em processos e ferramentas padrão do sistema de arquivos.

  • Seguro: quando o IIS é instalado, o estado de configuração fica em um arquivo protegido somente para acesso do administrador do computador; nenhuma delegação está habilitada por padrão; nenhuma informação confidencial (como senhas) é armazenada por padrão; quando informações confidenciais precisam ser gravadas nos arquivos de configuração, elas são criptografadas automaticamente em disco; a configuração por aplicativo pode ser restrita e isolada em um arquivo dedicado (protegido pela ACL do sistema de arquivos), de modo que outros aplicativos não possam compartilhar nem ler as configurações.

  • Extensível: a adição ao esquema é simplesmente uma questão de soltar um arquivo XML na pasta de esquemas; não é necessário chamar APIs nem executar ferramentas para estender o esquema; as configurações são organizadas em blocos logicamente relacionados chamados ‘seções’ (exatamente como na configuração do .NET Framework) e a adição de novas seções é fácil (não é necessária nenhuma codificação, ao contrário da configuração do .NET Framework); a leitura das configurações de seção personalizadas em um módulo ou um aplicativo de servidor é simples e fácil.

  • Compatível: os aplicativos IIS existentes podem continuar chamando interfaces como o ABO (Admin Base Objects), o provedor ADSI do IIS e o provedor WMI do IIS 6.0; os aplicativos .NET Framework existentes podem continuar chamando interfaces como System.Configuration e System.Web.Configuration; os usuários familiarizados com o formato XML de machine.config e web.config continuarão experimentando o mesmo formato e sintaxe nesses arquivos, além de terem a capacidade de editar manualmente as configurações do IIS que seguem o mesmo formato e modelo; os usuários familiarizados com os nomes de propriedades da Metabase do IIS encontrarão os mesmos nomes para propriedades contidas nos novos arquivos de configuração do IIS 7.0 e posterior.

Esquema limpo

Aqui está um exemplo que demonstra o esquema de configuração.

Ele mostra como as configurações de autenticação são organizadas no IIS 6 e no IIS 7.0 e posterior.

Observação

Os leitores que não estão familiarizados com os conceitos do IIS 6.0 podem simplesmente ignorar a comparação com o IIS 6.0 e apenas ler os conceitos e os benefícios do IIS 7.0 e posterior.

Primeiro, vamos comparar a maneira como a configuração é mantida no arquivo e, em seguida, dar uma olhada na definição de esquema.

No próprio arquivo de configuração:

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

Lições importantes:

  • O IIS 6.0 usa uma lista de propriedades muito longa e “simples”. Não há nenhuma hierarquia ou agrupamento de propriedades. É difícil pesquisar as configurações entre centenas de configurações na mesma lista. O IIS 7.0 e posterior usa uma hierarquia de seções e grupos de seções, além de sub-elementos nas seções. É fácil pesquisar as configurações de autenticação, procurando-as no grupo de seções de autenticação ou em uma seção de autenticação específica.
  • O IIS 6.0 usa sinalizadores para definir esquemas de autenticação. O IIS 7.0 e posterior usa uma seção por esquema de autenticação, com enabled="true|false" em cada um. Configurações adicionais relevantes apenas para alguns esquemas de autenticação podem ser definidas apenas nas seções relevantes (por exemplo, o nome de usuário e a senha podem ser definidos apenas para a autenticação anônima).
  • O IIS 6.0 usa caminhos dentro do arquivo da Metabase para especificar o nível de configuração (serviço, diretório virtual, diretório físico). A configuração de todo o servidor fica em um só arquivo. O IIS 7.0 e posterior usa um arquivo por padrão, mas os usuários podem aproveitar arquivos web.config distribuídos nos diretórios de conteúdo, que especificam as configurações para os respectivos escopos.
  • O IIS 6.0 usa nomes de propriedade longos em uma tentativa de ter definições de configuração autodescritivas. Essa é uma tentativa de aprimorar a legibilidade do arquivo e ajudar o usuário a entender o que a propriedade faz. O IIS 7.0 e posterior usa nomes curtos, mas eles sempre estão no contexto de uma seção específica ou até mesmo no subconjunto da seção.
  • O IIS 6.0 usa cadeia de caracteres múltipla (elementos delimitados por vírgula em uma propriedade de cadeia de caracteres) e sinalizadores para processar vários valores de elemento, como NTAuthenticationProviders. O IIS 7.0 e posterior usa coleções, com a sintaxe simples de adicionar/remover/limpar, exatamente como a configuração do .NET Framework. Isso permite que níveis inferiores da hierarquia adicionem (ou removam) apenas o elemento de que precisam, em vez de duplicar todos os dados com (ou sem) o elemento em questão. Também proporciona mais legibilidade do arquivo (que se traduz em menos erros humanos quando ele é editado diretamente).

No arquivo de 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>

Lições importantes:

  • O IIS 6.0 usa IDs (números) para identificar as configurações. O IIS 7.0 e posterior usa cadeias de caracteres amigáveis para nomear as configurações.
  • O IIS 6.0 usa conceitos não intuitivos, como UserType, e terminologia, como InternalName. O IIS 7.0 e posterior usa nomes amigáveis que fazem sentido para os leitores humanos, não apenas para os aplicativos.

Hierarquia de arquivos de configuração

O estado “mestre” da configuração é sempre os arquivos de configuração (ao contrário do IIS 6.0, em que era o banco de dados de configuração na memória, que era liberado para o disco periodicamente).

No nível raiz (ou global), há dois arquivos separados:

  • system32\inetsrv\config\applicationHost.config: mantém os padrões globais para as configurações do IIS (servidor Web).
  • \windows\microsoft.net\framework\v2.0.50727\config\machine.config: mantém os padrões globais para as configurações do .NET Framework, incluindo algumas do ASP.NET (o restante fica no web.config na mesma pasta, que às vezes é chamada de web.config raiz)

O motivo pelo qual há dois arquivos separados ainda é porque as duas tecnologias têm uma versão diferente (em termos de agendamento e de produto). O IIS faz parte do Windows e o .NET Framework pode ter um controle de versão independente, como parte das versões do Visual Studio.

Nos diretórios de conteúdo da Web, pode haver arquivos web.config opcionais que controlam o comportamento para o nível da hierarquia e abaixo. Eles podem ser locais ou remotos (se o diretório de conteúdo estiver em um compartilhamento UNC, por exemplo). Eles podem conter o IIS, o ASP.NET ou qualquer outra configuração do .NET Framework que possa ser especificada no respectivo nível. Por padrão, não há nenhum arquivo web.config.

Em termos de hierarquia de herança, o arquivo raiz é machine.config, depois, web.config no mesmo diretório (conhecido como web.config raiz), depois applicationHost.config e, em seguida, os arquivos web.config opcionais ao longo do namespace.

Arquivos de inclusão da configuração

Em alguns casos, é útil fazer com que o arquivo web.config inclua algum outro arquivo .config. Isso pode ser feito usando o atributo configSource. Atualmente, ele está limitado a apontar para caminhos físicos relativos em subdiretórios, por motivos de segurança (ou seja, o arquivo A só pode incluir o arquivo B se B estiver no subdiretório físico de A). Aqui está um exemplo básico que mostra como 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>

Neste exemplo, o cliente desejava mover o conteúdo da seção staticContent para um arquivo separado, a fim de ter um applicationHost.config mais curto e legível.

Observe que, quando as definições de configuração forem alteradas em um arquivo .config, o servidor selecionará automaticamente as alterações e realizará uma ação sobre elas. O cliente não deve se preocupar com a reciclagem de aplicativos ou pools de aplicativos ou todo o servidor (o próprio servidor pode reciclar pools de aplicativos, por exemplo, dependendo de quais configurações foram alteradas).

Organização das configurações

Dentro de um arquivo de configuração (ou seja, para um determinado nível da hierarquia), as configurações são organizadas de maneira estruturada e não como uma lista simples. A unidade básica de implantação, registro e extensibilidade é a seção de configuração. Uma seção está contida em um grupo de seções, que, por sua vez, pode estar contido em um grupo de seções pai. As seções em si não estão aninhadas. Já os grupos de seções estão aninhados.

Veja um exemplo 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>

As definições de configuração sempre pertencem a uma seção específica.

Os grupos de seções só existem para melhor estruturação. Eles não contêm configurações diretamente, apenas seções.

Em uma seção, a estrutura é a seguinte:

  • Elemento de configuração: contém configurações e, potencialmente, outros elementos de configuração. Representado como um elemento XML. As seções também são elementos.
  • Coleção de configurações: um caso privado de elemento de configuração, que contém uma lista de elementos de configuração, na forma de adicionar/remover/limpar (que são chamadas de diretivas de coleção). Representado como um elemento XML com os sub-elementos <adicionar>, <remover> e <limpar>.
  • Propriedade de configuração: essa é uma definição de configuração [folha]. Representada como um atributo XML.

Veja um exemplo 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>

Por padrão, applicationHost.config contém dois grupos de seções principais: system.applicationHost e system.webServer. Ele também contém uma seção chamada <configSections>, que é um tanto especial, pois é usada internamente pelo sistema de configuração para registrar todas as outras seções.

Por padrão, machine.config contém vários grupos de seções. As configurações do ASP.NET estão no grupo de seções system.web.

Marcas de localização vs. arquivos de configuração

Em muitos casos, o ideal é evitar arquivos web.config nos diretórios de conteúdo, mas ainda ter uma configuração por URL que substitui os padrões globais. Por exemplo: o administrador deseja especificar que um site específico precisa usar um esquema de autenticação, e os administradores do site (e os desenvolvedores de aplicativos nesse site) não devem ter a capacidade de desativá-lo.

A maneira mais fácil de fazer isso é usando marcas de localização. Esse é um mecanismo usado para especificar a configuração de um caminho específico, sem ter um web.config na pasta mapeada para o caminho virtual.

Este exemplo mostra como uma marca de localização é usada em 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>

As marcas de localização podem ser usadas para especificar a configuração para o nível global (path="."), para um site ou para um caminho específico dentro de um site. Pode haver várias marcas de localização em um arquivo. As marcas de localização podem estar em qualquer arquivo .config, não apenas em applicationHost.config ou em machine.config.

Elas também podem ser usadas para bloquear e desbloquear seções. Confira mais detalhes sobre isso no laboratório de bloqueio de configuração.

Em alguns casos, não há alternativa para o uso de marcas de localização:

  • Dois ou mais caminhos virtuais mapeados para a mesma pasta física. Obviamente, se os dois caminhos virtuais tiverem uma configuração diferente, ele não poderá ser especificado em um arquivo web.config porque ele é compartilhado.
  • Configuração específica do arquivo. Não há nenhum arquivo web.config para arquivos, somente para a pasta inteira.

Resumo

Este documento apresentou uma visão geral inicial e de alto nível do sistema de configuração no IIS 7.0 e posterior. Ele destacou o formato de esquema mais limpo; a natureza distribuída do sistema de configuração e como ele habilita a delegação de configurações para o proprietário do site ou desenvolvedor de aplicativos; a organização estruturada de configurações em arquivos de configuração; e a integração entre os sistemas de configuração do IIS e do ASP.NET.

Para obter mais informações, recomendamos ler o restante dos documentos de configuração, em particular, o documento Elementos intrínsecos de configuração, que entra em detalhes de baixo nível sobre o sistema, incluindo o design e a arquitetura.