Podem existir áreas de um site que não devam estar disponíveis para o público em geral, em outras palavras, existem situações em que pode ser necessário restringir o acesso a determinadas áreas de um site. Para definir tais restrições temos vários recursos, tanto do IIS, do Windows 2000 quanto do próprio ASP.NET. Neste tópico veremos algumas maneiras de restringir o acesso, utilizando um arquivo de configurações, para aplicações Web – Web.Config. Este é um arquivo que fica gravado na pasta raiz da aplicação Web e contém uma série de diretivas. Algumas destas diretivas são utilizadas para configurações de segurança.

Vamos iniciar o nosso estudo por um importante conceito: Impersonation.

Impersonation

Conforme descrevemos no início do capítulo, quando o usuário faz a requisição de uma página ASP.NET, a primeira coisa que acontece, antes da página ser processada é retornada para o usuário, é a autenticação do usuário. Através da autenticação, o IIS identifica o usuário que está fazenda a requisição. Para áreas de acesso público é utilizada a autenticação anônima, onde todos os usuários são autenticados utilizando a mesma conta: IUSR_NOME_DO_COMPUTADOR.

O mecanismo de Impersonation pode estar habilitado ou desabilitado. Por padrão este mecanismo está desabilitado. O mecanismo de Impersonation define se a requisição do usuário será executada utilizando a conta com a qual o usuário foi autenticado (IUSR_NOME_DO_COMPUTADOR para o caso de acesso anônimo, ou uma conta do Windows 2000 para outros tipos de autenticação), ou a conta System, que é uma conta local do servidor Windows 2000.

Este mecanismo pode parecer sem sentido prático, mas na verdade existe uma justificativa bastante plausível. Como as páginas ASP.NET são compiladas e mantidas em cache, pode acontecer situações onde o IIS precise gravar arquivos temporários, em áreas do disco nas quais a conta IUSR_NOME_DO_COMPUTADOR não tem permissões de acesso. Neste caso o IIS precisa “fazer de conta que está executando como se fosse o usuário System”, o qual tem permissões para as áreas para criação de arquivos temporários.

Se o mecanismo de Impersonation estiver habilitado e a página fizer parte de uma área do site, no qual o acesso anônimo está habilitado, a requisição será feita em nome do usuário configurado para o acesso anônimo, normalmente a conta IUSR_NOME_DO_COMPUTADOR. Se o mecanismo de Impersonation estiver desabilitado (que é o padrão), ao invés da conta configurada para o acesso anônimo, será utilizada a conta System.

Se o mecanismo de Impersonation estiver habilitado e a página fizer parte de uma área na qual o acesso anônimo não está habilitado, a requisição será feita em nome do usuário que está logado no Windows. No caso de uma rede com servidores Windows 2000 e clientes Windows 9x ou Windows 2000, o usuário, provavelmente, estará logado com uma conta de um domínio do Windows 2000. O mesmo acontece para o caso do mecanismo de Impersonation estar habilitado. Observe que a mudança de contexto (Impersonation) para a conta System, somente ocorre quando o acesso for feito a áreas nas quais o acesso anônimo é permitido.

Em qualquer uma das situações, após assumir a identidade de um determinado usuário, quer seja a conta de acesso anônimo, quer seja a conta System ou a conta com a qual o usuário está logado, será feita uma verificação se o usuário tem permissão para os recursos que ele requisitou. Se tiver permissão a página é compilada, executada e retornada para o cliente, caso contrário uma mensagem de erro será retornada. Quando falamos em permissões podem ser tanto permissões NTFS quanto as permissões configuradas no IIS, conforme descrevemos no início do capítulo.

O arquivo Web.Config

O arquivo Web.Config é um arquiovo de configuração que fica gravado na pasta raiz da aplicação Web. Por exemplo, no Capítulo 13, utilizamos o Visual Studio .NET, para criar a aplicação AppWebChap13. Na pasta raiz desta aplicação temos um arquivo chamado Web.Config, o qual contém diversas configurações para a aplicação. Neste tópico estaremos modificando algumas opções deste arquivo e testando o efeito das modificações.

Na Listagem 14.1 temos o arquivo Web.Config para a aplicação AppWebChap13.

<?xml version="1.0"  encoding="utf-8" ?>
   <configuration>
       
      <system.web>

     <!--  DYNAMIC DEBUG COMPILATION
              Set compilation debug="true" to enable ASPX debugging.  Otherwise, setting this value to
              false will improve runtime performance of this application. 
              Set compilation debug="true" to insert debugging symbols (.pdb  information)
              into the compiled page. Because this creates a larger file that executes
              more slowly, you should set this value to true only when debugging and  to
              false at all other times. For more information, refer to the  documentation about
              debugging ASP.NET files.
       -->
        <compilation 
             defaultLanguage="c#"
             debug="true"
       />

     <!--  CUSTOM ERROR MESSAGES
              Set mode="on" or "remoteonly" to enable custom error  messages, "off" to disable. Add
              <error> tags for each of the errors you want to handle.
        -->
        <customErrors 
        mode="Off" 
       /> 

     <!--  AUTHENTICATION 
                This section sets the  authentication policies of the application. Possible modes are 
   "Windows",  "Forms", 
                "Passport" and  "None"
        -->
        <authentication mode="None" /> 

     <!--  APPLICATION-LEVEL TRACE  LOGGING
              Application-level tracing enables trace log output for every page within  an application. 
              Set trace enabled="true" to enable application trace  logging.  If pageOutput="true",  the
              trace information will be displayed at the bottom of each page.  Otherwise, you can view the 
              application trace log by browsing the "trace.axd" page from  your web application
              root. 
       -->
        <trace
            enabled="false"
            requestLimit="10"
            pageOutput="false"
            traceMode="SortByTime"
            localOnly="true"
       />

     <!--  SESSION STATE SETTINGS
              By default ASP.NET uses cookies to identify which requests belong to a  particular session. 
              If cookies are not available, a session can be tracked by adding a  session identifier to the URL. 
              To disable cookies, set sessionState cookieless="true".
       -->
       <sessionState 
               mode="InProc"
                stateConnectionString="tcpip=127.0.0.1:42424"
                sqlConnectionString="data source=127.0.0.1;user  id=sa;password="
                cookieless="false" 
                timeout="20" 
       />

     <!--  PREVENT SOURCE CODE  DOWNLOAD
              This section sets the types of files that will not be downloaded. As  well as entering
              a httphandler for a file type, you must also associate that file type  with the aspnet_isapi.dll
              in the App Mappings property of the web site, or the file can be  downloaded.
              It is recommended that you use this section to prevent your sources  being downloaded.
        -->
        <httpHandlers>
                <add verb="*" path="*.vb"  type="System.Web.HttpNotFoundHandler,System.Web" />
                <add verb="*" path="*.cs"  type="System.Web.HttpNotFoundHandler,System.Web" />
                <add verb="*" path="*.vbproj"  type="System.Web.HttpNotFoundHandler,System.Web" />
                <add verb="*" path="*.csproj"  type="System.Web.HttpNotFoundHandler,System.Web" />
                <add verb="*" path="*.webinfo"  type="System.Web.HttpNotFoundHandler,System.Web" />
        </httpHandlers>

     <!--  GLOBALIZATION
              This section sets the globalization settings of the application. 
        -->
        <globalization 
                requestEncoding="utf-8" 
                responseEncoding="utf-8" 
      />
      
    </system.web>

</configuration>

A estrutura básica do arquivo Web.Config é a seguinte:

<?xml version="1.0"  encoding="utf-8" ?>
   <configuration>
       
      <system.web>
               Configuração  1
               Configuração  2
               ...
               Configuração  n

</system.web>

</configuration>

Onde temos diversos formatos para as cláusulas Configuração 1, Configuração 2, ... , Configuração n. Neste tópico aprenderemos a utilizar cláusulas referentes a configurações de segurança.

Definindo o tipo de Autenticação.

Uma das configurações que podemos definir como arquivo Web.Config, é o tipo de autenticação que será utilizado pela aplicação Web. Podemos definir um dos seguintes tipos:

• Windows built-in authentication: ASP.NET utiliza este tipo de autenticação em conjunto com a autenticação do IIS. Primeiro a autenticação é feita pelo IIS, utilizando um dos seguintes tipos: autenticação básica, digest, ou autenticação Integrada do Windows (NTLM). Quando a autenticação do IIS é finalizada ASP.NET utiliza a identidade do usuário autenticado para autorizar ou negar acesso as páginas e demais recursos da aplicação Web.

• Passport-based authentication: Este tipo de autenticação utiliza um serviço pago, disponibilizado pela Microsoft. Com este tipo de autenticação o usuário se identifica uma única vez e, automaticamente, estará autenticado para todos os sites e aplicações que utilizam a autenticação Passport-based. O inconveniente é que o serviço é pago, maiores informações em www.passport.com/business.

• Forms authentication: Quando uma requisição é recebida e ainda não foi autenticada, isto é, o IIS não conhece o usuário que fez a requisição, esta é redirecionada para um formulário HTML, através da utilização de redireção HTTP client-side. Neste formulário o usuário fornece um username e senha para login e envia o formulário para o servidor, normalmente clicando em um botão “Login”. Se a aplicação autentica a requisição, o sistema cria um cookie que contém as credenciais necessárias à autenticação do usuário. O navegador do cliente envia o cookie em todas as futuras requisições, desta forma o usuário pode continuar acessando a aplicação, sem digitar um username e senha, enquanto o cookie estiver gravado no seu computador.

Para definir o tipo de autenticação, no arquivo Web.Config, utilizamos a seguinte sintaxe:

<authentication mode=”"[Windows/Forms/Passport/None]">
           outras opções de  autenticação utilizadas para a aplicação
   </authentication>

No exemplo da listagem 14.1, observe que foi definido o tipo None:
<authentication mode="None" />

Além disso foi utilizada a sintaxe alternativa, ou seja, ao invés do fechamento </authentication>, utilizamos simplesmente “/>”.

Definindo os usuários e grupos que tem permissão de acesso à aplicação.

Para definir uma lista de usuários e grupos com permissão de acesso aos recursos da aplicação,  utilizamos uma cláusula <authorization> </authorization>, para definir uma lista de usuários ou grupos, com permissão de acesso. A sintaxe para esta cláusula é a seguinte:

<authorization>
           <allow users=’[lista de usuários,  separados por vírgula]’
                       roles=’[lista de grupos,  separados por vírgula]”
                      verb=”[GET/POST/HEAD]”
               
            />
           <deny  users=["lista de usuários, separados por  vírgula]"
                        roles="[lista de  grupos, separados por vírgula]"
                      verb=”[GET/POST/HEAD]”
            />
   </authorization> 

A definição de uma lista de usuários e grupos do Windows, com permissão de acesso é mais comum em uma Intranet, onde temos que definir permissões de acesso somente para um grupo específico de usuários. Vamos supor que exista uma aplicação Web, com informações gerencias sobre o desempenho dos funcionários, planos de promoção e carreira. Imagine que somente o Gerente de RH, diretores, vice-presidentes e o presidente devam ter acesso a essa aplicação. Esta é uma situação em que devemos utilizar a autenticação Windows built-in authentication e utilizar uma cláusula <authorization> </authorization> para definir quais os usuários que tem permissão de acesso.

Neste caso a primeira coisa a ser feita é definir o tipo de autenticação como Windows:

<authentication  mode="Windows"/>

“allow users” contém uma lista de usuários e grupos com permissão de acesso à aplicação.
“deny users” contém uma lista de usuários  e grupos, para os quais a permissão de acesso é negada.

Ao especificarmos o nome de um usuário, devemos utilizar a nomenclatura completa, na qual é especificado o nome do domínio. Na máquina que estou utilizando, está instalado um domínio Windows 2000 chamado GROZA. Para especificar uma conta deste domínio utilizo a seguinte nomenclatura:

GROZA\jsilva
GROZA\user1
GROZA\user2
GROZA\Administrador

Se a conta pertencer a um Member Server, isto é, um servidor que não faz parte de um domínio, basta substituir o nome do domínio pelo nome do servidor.

Importante! As configurações de segurança do ASP.NET somente são aplicadas e verificadas para recursos associados ao ASP.NET, em outras palavras, a arquivos associados para processamento da DLL: aspnet_isapi.dll. As configurações de segurança do ASP.NET não se aplicam para recursos não associados a DLL aspnet_isapi.dll, como por exemplo arquivos .txt, html, gif,  jpg, asp e outros tipos de arquivos. As limitações de acesso para este tipo de arquivo dependem das configurações de segurança do IIS e do Windows 2000. Poderíamos contornar esta situação, mapeando os demais recursos para a DLL aspnet_isapi.dll, porém isso teria um forte impacto em termos de performance, o que iria piorar muito o desempenho da aplicação.

Podemos utilizar alguns caracteres especiais na lista de usuários ou grupos:

• * : Significa todos os usuários ou todos os grupos.
• ? : Significa acesso anônimo. Para o caso de estarmos utilizando Windows authentication, será interpretado como a conta configurada para o acesso anônimo, normalmente a conta IUSR_NOME_DO_COMPUTADOR. Somente pode ser utilizado na lista de usuários – user.

Vamos considerar um exemplo simples, onde é permitido o acesso para três usuários do domínio GROZA e negado o acesso para todos os demais usuários:

<authorization>
           <allow  users=”GROZA\Usuário1,GROZA\Usuário2” />
            <deny  users=”*”/>
   </authorization>

Neste exemplo os usuários “Usuário1” e “Usuário2” poderão acessar a aplicação e todos os demais terão o acesso negado.

Porém existem situações mais complexas. Pode acontecer de existir um arquivo Web.Config no diretório raiz do site, um arquivo Web.Config na pasta raiz da aplicação e um outro arquivo Web.Config em uma pasta dentro da aplicação Web. Podemos perfeitamente criar arquivos Web.Config nos locais descritos no exemplo. Neste caso temos a seguinte questão: “Quais as configurações que são efetivamente aplicadas?”. Se em um dos arquivos o usuário tem permissão e em outro não, qual será a permissão que irá prevalecer?

Para responder a estas questões, devemos levar em consideração algumas regras:

• As cláusulas <allow> e <deny> são mescladas, a partir de todos os arquivos Web.Config existentes no caminho de um aplicação. Considere o exemplo da Figura 14.53:

Figura 14.53 Vários arquivos Web.Config no caminho de uma aplicação.

Neste caso, quando a página “pagina1.aspx” for acessada, serão mescladas as cláusulas <allow> e <deny>, dos três arquivos Web.Config existentes, desde a pasta raiz do site, até chegar na pasta odne está a página pagina1.aspx. Em caso de conflito é dado preferência para as configurações do arquivo Web.Config que está em um nível mais alto, isto é, mais próximo da pasta raíz do site. Após processados todos os arquivos Web.Config do caminho, é montada uma lista única de usuários e grupos para as cláusulas <allow> e <deny>.

Uma vez montada a lista única vamos entender como são aplicadas as permissões. O processador do ASP.NET vai lendo a lista de cima para baixa e aplica a configuração que melhor se encaixar, em outras palavras, a configuração mais específica. Você pode ter notado no exemplo que apresentamos anteriormente, onde a permissão é atribuída a dois usuários:

        <allow users=”GROZA\Usuário1,GROZA\Usuário2” />

e negada para todos:

        <deny  users=”*”/>

Aqui precisamos fazer alguns comentários para que não haja confusão entre a maneira como as permissões são aplicados com as cláusulas <allow> e <deny>, no arquivo Web.Config e a maneira como o Windows 2000 aplica permissões NTFS em pastas e arquivos.

Com as permissões NTFS, negar tem precedência sobre qualquer outra permissão. Então, se negarmos a permissão de acesso a uma pasta ou arquivo, para o grupo Todos (Everyone no Windows 2000 em inglês), ninguém terá acesso a pasta ou arquivo, independente de quantos usuários tenham permissões explícitas de acesso. Em resumo, nas permissões NTFS, negar tem precedência sobre permitir e as permissões são cumulativas, por exemplo, se um usuário tem permissão de acesso e o grupo ao qual ele pertence tem negada a permissão de acesso, o usuário herda o negar do grupo e, como negar tem precedência sobre permitir, o acesso será negado.

Já para as configurações do arquivo Web.Config, o comportamento é um pouco diferente. Será aplicada a permissão mais específica, ou seja, aquela que estiver mais especificamente definida. Vamos novamente nos reportar ao exemplo anterior. Os usuários:

GROZA\Usuário1
GROZA\Usuário2

tem permissão <allow> de acesso definida. O grupo todos (*) tem permissão negada - <deny>. Como os usuários tem permissão específica de acesso, estes poderão acessar a aplicação. Todos os demais usuários (* - GROZA\Usuário1 - GROZA\Usuário2), terão permissão de acesso negada. Mais uma vez cabe ressaltar que este comportamento é diferente do que temos com as permissões NTFS em relação a pastas e arquivos em partições NTFS.

Outro uso comum, onde precisamos combinar permissões <allow> e <deny> é para casos em que um determinado grupo deve ter permissões de acesso e um ou mais elementos do grupo devem ter a permissão negada. Vamos considerar a seguinte situação de usuários e grupos para um domínio chamado GROZA:

Grupo gerentes:

Membros do grupo:

user1
user2
user3
user4
user5

Nos queremos que o grupo gerente tenha permissão de acesso a uma aplicação Web, com exceção dos usuários: user2 e user5. Para implementar estas configurações de segurança, utilizamos a seguinte cláusula <authorization> </authorization>, no arquivo Web.Config da aplicação Web:

<authorization>
           <allow roles=”GROZA\gerentes”  />
           <deny  users=”GROZA\user2,GROZA\user5” />
   </authorization>

Neste caso o grupo gerentes tem permissão de acesso e, para os usuários user2 e user5 tenho negado, explicitamente o acesso. O resultado prático é que os usuários user1, user3 e user4 tem permissão de acesso e os usuários user2 e user5 não tem permissão de acesso. Observe que para permitir acesso a grupos utilizamos a cláusula <allow roles=.../> e para negar permissão a grupos, utilizamos a cláusula <deny roles=.../>.

A utilização da cláusula verb é opcional. Esta cláusula pode ser utilizada para definir o tipo de requisição que o usuário pode fazer. Conforme descrevemos anteriormente existem diferentes métodos de enviar os dados de um formulário para processamento no servidor. Os tipos mais comuns são “GET” e “POST”. Com a cláusula verb podemos limitar a forma de envio permitida para usuários ou grupos. Vamos a um exemplo prático.

Vamos definir que os usuários GROZA\user1 e GROZA\user2 devem ter permissão para utilizar o método GET e todos os demais usuários somente podem utilizar o método POST. Para implementar estas configurações, utilizamos a seguinte cláusula de autorização, no arquivo Web.Config:

<authorization>
            <allow verb=”GET”     users=”GROZA\user1,GROZA\user2” />
            <allow verb =”POST” users=”*” />
            <deny verb = “GET”    users=”*”  />       
   </authorization>

Observe que negamos o verbo GET para todos os usuários, de tal maneira que somente os usuários user1 e user2 tenham a permissão para utilizar GET. Para os demais usuários demos a permissão para utilizar POST.

Podem existir situações onde precisamos definir diferentes configurações de acesso, para uma página ou pasta da aplicação Web. Neste caso podemos utilizar a cláusula <location> </location> para especificar a qual arquivo ou pasta, as configurações devem ser aplicadas. No exemplo a seguir, aplicamos as configurações de acesso que se aplicam somente a página dados.aspx.

<location path=”dados.aspx”>
   <system.web>
   <authorization>
                                      <allow  roles=”GROZA\gerentes”  />
                                      <deny  users=”GROZA\user2,GROZA\user5” />
   </authorization>
               </system.web>
   </location>

Estas configurações somente se aplicam a página dados.aspx.

No Capítulo 15 veremos mais alguns detalhes sobre as configurações de segurança no ASP.NET.