Desde a primeira versão do ASP.NET, temos três formas de autenticação: Windows, Forms e Passport. A primeira opção consiste em permitir o acesso desde que o usuário faça parte do domínio/máquina. Essa opção torna o gerenciamento simples, facilita o Single Sign-On (SSO) interno, mas é útil em um ambiente controlado, como uma intranet. A opção Forms faz com que a aplicação se encarregue de gerenciar e autenticar seus usuários, baseando-se em um cookie que determinará quem é o usuário logado, e esta opção é a mais ideal para a internet. Finalmente, temos a Passport, que permitia autenticar o usuário utilizando o serviço de identidade da Microsoft, mas por haver um custo envolvido, acabou não evoluindo.

Com a vinda do ASP.NET MVC, grande parte dos serviços que são disponibilizados para o ASP.NET WebForms, já nasceram com o MVC ou estão aos poucos sendo adicionados à plataforma. Como já era de se esperar, a questão da autenticação e autorização já fazem parte desde a versão 1.0 do MVC, onde podemos utilizar a autenticação Windows ou Forms, mudando ligeiramente como devemos proceder para configurá-los e utilizá-los.

Para definir se vamos utilizar o modelo de autenticação Windows ou Forms, devemos recorrer ao elemento authentication no arquivo Web.config, como já fazíamos anteriormente. O atributo mode determina qual a opção de autenticação, e um sub-elemento chamado forms, nos permite customizar a autenticação baseada em Forms. O exemplo abaixo ilustra a configuração inicial:

<authentication mode=”Forms”>
    <forms loginUrl=”Authentication/LogOn” />
</authentication>

Aqui há uma mudança radical aqui. O ASP.NET WebForms é baseado em arquivos, ou seja, todas as requisições, sejam elas da aplicação ou da infraestrutura (como é o caso aqui), o alvo sempre será um arquivo físico, com extensão *.aspx. Já no ASP.NET MVC, o alvo será sempre uma ação, que nada mais é que um método dentro de uma classe, conhecida como Controller. No exemplo acima, o controller é uma classe chamada AuthenticationController e dentro dele há um método chamado LogOn. É dentro deste método que você colocará todos os passos necessários para autenticar o usuário. Geralmente esse método deve receber o login e a senha, mas eventualmente poderá ter algo mais rebuscado.

Quando tentamos acessar um recurso protegido através do FormsAuthentication, ele automaticamente redireciona o usuário para a página de autenticação configurada acima, embutindo na URL uma query string chamada ReturnUrl, com o caminho (do arquivo ou da ação) que tentamos acessar. Esse parâmetro é útil para depois que validar o usuário, redirecioná-lo para a mesma seção que ele solicitou antes de efetuar a autenticação. Sendo assim, é necessário que o método que efetua a autenticação do usuário, também receba esse parâmetro.

Em tempo, a versão 2.0 do ASP.NET MVC fornece um atributo chamado HttpPostAttribute, que permite você decorar uma determinada ação, para que ela seja executada somente via POST, garantindo assim que ela seja executada somente através desta forma. Para ilustrar, o método LogOn fica da seguinte forma:

public class AuthenticationController : Controller
{
    [HttpPost]
    public ActionResult LogOn(string userName, string password, string returnUrl)
    {
        //…
    }
}

É importante dizer que se você estiver utilizando a autenticação Windows, nada disso é necessário, já que a autenticação acaba sendo feita automaticamente pelo IIS/ASP.NET.

Se precisar saber qual usuário está autenticado naquele momento, você pode recorrer à propriedade User, exposta pela classe Controller. Assim como já acontece com a classe Page do WebForms, essa propriedade retorna a instância de uma classe que implementa a interface IPrincipal, fornecendo acesso ao username do usuário atual, e um método chamado IsInRole, caso você precisa refinar ainda mais a autorização. Para maiores detalhes sobre essa interface, consulte este o capítulo 9 deste artigo.

Autorização

A autorização pode continuar sendo realizada da mesma forma que fazíamos antes, ou seja, recorrendo ao arquivo de configuração (Web.config) para especificar as regras de autorização. A diferença se dá também pelo fato de que o MVC é baseado em ações, e ao invés de determinar páginas e/ou diretórios nessas regras, utilizaremos as ações para refinar o acesso dos usuários. Se temos um controller chamado MonitorController e dentro dele uma ação (método) chamada VisualizarItens, e o acesso à ela somente pudesse ser feita por usuários autenticados, a regra ficaria da seguinte forma:

<location path=”Monitor/VisualizarItens”>
    <system.web>
        <authorization>
            <deny users=”?” />
        </authorization>
    </system.web>
</location>

Caso você precise permitir o acesso à uma determinada ação para somente aqueles usuários que fazem parte de um determinado grupo (role), você pode configurar a regra da seguinte forma:

<location path=”Monitor/VisualizarItens”>
    <system.web>
        <authorization>
            <allow roles=”Financeiro” />
        </authorization>
    </system.web>
</location>

Apesar desta técnica funcionar, é difícil de manter. Para cada novo controller ou ação que são criados, você precisa se preocupar em olhar para o arquivo de configuração e configurar quem poderá ou não ter acesso. O problema desta técnica é que se você esquecer, usuários que talvez não deveriam ter acesso, acabarão visualizando. No ASP.NET MVC há uma outra forma de se trabalhar, também declarativa, mas recorrendo à atributos dentro dos controllers/ações, facilitando a centralização e manutenção das regras de acesso.

Para isso, o ASP.NET MVC fornece um atributo chamado AuthorizeAttribute que podemos decorar em classes (controllers) ou em métodos (ações). Esse atributo fornece duas propriedades do tipo string: Users e Roles. Na primeira propriedade, especificamos os usuários (separados por vírgula) que podem ter acesso aquele membro (classe ou método) em que o atributo está sendo aplicado. Já a segunda propriedade, Roles, permite especificarmos os grupos (separados por vírgula), onde somente usuários que estão dentro de um deles é que podem ter acesso ao recurso. Utilizar a propriedade Users não é o mais ideal, porque usuários são muito “voláteis”, e em pouco tempo, essa regra provavelmente não fará mais sentido.

Como dito acima, podemos aplicar esse atributo em nível de controller, e assim, as suas respectivas ações irão exigir que aquela regra seja atendida antes de permitir o acesso. No primeiro exemplo, aplicamos este atributo em nível de controller, e todas as ações exigirão que o usuário esteja autenticado:

[Authorize]
public class MonitorController : Controller
{
    public ActionResult VisualizarItens()
    {
        //…
    }

    public ActionResult RecuperarIndice()
    {
        //…
    }
}

Já o segundo exemplo, fará com que o controller seja acessado somente por usuários devidamente autenticados, mas isso não é o suficiente para o método VisualizarItens, que além disso, exige que o usuário esteja contido no grupo Financeiro:

[Authorize]
public class MonitorController : Controller
{
    [Authorize(Roles = “Financeiro”)]
    public ActionResult VisualizarItens()
    {
        //…
    }

    public ActionResult RecuperarIndice()
    {
        //…
    }
}

Caso você tenha uma regra de validação muito mais complexa do que isso, nada impede você de criar um filtro para efetuar essa customização, fazendo que a autorização siga os passos necessários para atender essa regra predefinida. E para finalizar, lembre-se que o MVC trata os métodos como “opt-out”, ou seja, por padrão, todos os métodos públicos estão acessíveis. Se mesmo com a autenticação e/ou autorização ele jamais deverá ser invocado, então você deve decorá-lo com o atributo NonActionAttribute.

Membership e Roles

A partir da versão 2.0 do ASP.NET, uma série de novos serviços foram adicionados, e entre eles temos o Memberhip Provider e Role Provider, algo que já falei extensivamente nestes outros artigos. Felizmente podemos continuar utilizando esses serviços, mas com um pouco mais de cautela.

Esses serviços seguem um padrão conhecido como Provider Model, e ao utilizar o Membership ou Roles, eu estou trabalhando de forma independente de repositório; posso trabalhar com SQL Server, Oracle ou Xml, apenas configurando os providers através do arquivo Web.config. Mas apesar desses serviços seguirem um padrão de extensibilidade bem definido, isso não quer dizer que é uma boa prática você pode utilizá-los diretamente dentro dos controllers.

É importante dizer que ao criar aplicações MVC, a testabilidade deve estar em foco, e utilizar as classes Membership ou Roles dentro dos controllers, o tornará dependente destas implementações, ou melhor, destes serviços, e que por sua vez, estão fortemente acoplados ao ASP.NET. Como disse anteriormente, a arquitetura do provider model é bem flexível, mas para criar uma versão “fake” é complexo demais, pois há uma infinidade de funcinalidades que as vezes serão desnecessárias. Além disso, utilizar essas classes torna meu controller dependente deste tipo de serviço mas, eventualmente, eu tenho o meu próprio repositório de usuários e suas respectivas permissões, e quero fazer uso deles ao invés daqueles que o ASP.NET fornece.

A classe AccountController

Quando criamos um novo projeto MVC, por padrão, uma série de recursos já são adicionados, e entre eles, temos a classe (controller) chamada AccountController. Essa classe foi desenhada para servir como um wrapper para os serviços de Membership e FormsAuthentication. Há vários problemas com essa classe, e o primeiro deles é aquele que descrevi acima, que é a forte dependência da API do Membership. Apesar da Microsoft ter refatorado o código e criado uma interface chamada IMembershipService, há ainda alguns tipos que estão sendo utilizados, como é o caso do enumerador MembershipCreateStatus. Além disso, essa classe ainda viola o princípio de SRP (Single Responsability Principle), que faz com que ela faça muito mais coisas do que realmente deveria.

Conclusão: O fato da Microsoft tem se preocupado em manter grande parte dos recursos do WebForms no MVC, é importante que você analise cuidadosamente como incorporá-lo ao MVC para não comprometer um dos maiores benefícios do MVC, que são os testes. É importante notar que grande parte do conhecimento adquirido no ASP.NET WebForms, acaba sendo reutilizado aqui, apenas com ligeiras mudanças devido à arquitetura do MVC.

Quando nossa aplicação ASP.NET exige o controle da autenticação e autorização para conceder ou negar acessos, é muito comum criarmos uma página chamada Logout.aspx, que no seu evento Load efetuamos a “limpeza”. Essa “limpeza” consiste em remover o cookie de autenticação (método SignOut), apagar eventuais variáveis de sessão e alguma outra finalização específica daquela aplicação.

O problema reside quando você coloca essa página dentro de um diretório que também está protegido. Imagine que tenho um diretório dentro da aplicação chamado AreaRestrita. Dentro dele temos as várias páginas da aplicação, incluindo a Logout.aspx que, provavelmente, em todas as páginas haverá um link apontando para ela. Na configuração, especificamos que somente usuários autenticados poderão ter acesso ao conteúdo – páginas – deste diretório.

Neste caso, se o usuário efetuar o login, e deixar a aplicação aberta, sem navegar por ela, o cookie irá expirar. Como ele não tem mais nada para efetuar na aplicação, ele clica no link Logout. Como qualquer página do diretório está protegida contra usuários não autenticados, ao tentar acessar a página Logout.aspx, o usuário será redirecionado para a página de Login, para que ele informe as credenciais de acesso, para depois acessar a página de Logout. Aparentemente o usuário saiu da aplicação, mas a página Logout.aspx não foi executada e, consequentemente, toda a “limpeza” que você faria, não irá ocorrer.

Mesmo que utilize outra técnica, como um LinkButton e a “limpeza” sendo realizada em seu evento Click, você irá esbarrar no mesmo problema. A solução aqui é manter a página Logout.aspx acessível a todos os usuários, definindo isso no arquivo de configuração da aplicação (Web.config), assim como é mostrado abaixo:

<?xml version=”1.0″?>
<configuration>
  <location path=”Logout.aspx”>
    <system.web>
      <authorization>
        <allow users=”*”/>
      </authorization>
    </system.web>
  </location>
</configuration>

Particularmente não gosto muito da necessidade de ter que criar uma página para isso. O Logout não deveria ser uma página, mas sim uma ação a ser executada. Ponto positivo para o MVC, que nos permite criar um método (Action) chamado Logout, e invocá-lo a partir de um controle da View, sem a necessidade de ter toda a complexidade de uma página ASPX por trás de uma tarefa, que na maioria das vezes, é muito simples.

Quando utilizamos FormsAuthentication para proteger uma determina página ou diretório, há um comportamento que talvez não agrade a maioria das pessoas. Suponhamos que você faça o login digitando o seu nome de usuário e senha. Ao validar esse usuário em algum repositório, o ASP.NET automaticamente redireciona o usuário para a página/diretório que ele tentou acessar inicialmente.

A partir daí, se você utilizar roles para restringir o acesso à alguma página/diretório dentro da aplicação e o usuário não esteja dentro dela, ele será redirecionado – novamente – para a página de login. Talvez isso não seja o ideal, já que o mais coerente seria redirecionar o usuário para uma página que contenha uma mensagem mais amigável e próxima ao que realmente aconteceu, algo como: “Você não tem permissão para acessar o recurso solicitado. Contate o Administrator.”.

Quando utilizamos a UrlAuthorization (que já é o padrão), a cada requisição ela verifica se o usuário que acessa uma determinada página, possui a permissão para isso. Caso a configuração no arquivo Web.config diz que, para acessar aquela página, é necessário que o usuário esteja na role de “Administradores”, e ele por sua vez não estiver, o UrlAuthorization define a propriedade StatusCode da resposta do HTTP para 401 (que significa “Acesso Negado”). O FormsAuthentication (mais precisamente, o FormsAuthenticationModule) se vincula ao evento EndRequest, e dentro dele analisa se a propriedade StatusCode foi definida como 401. Caso tenha sido, o FormsAuthenticationModule redireciona o usuário para a página de login, trocando o StatusCode para 302 (“Redirecionar”).

Para mudar este comportamento, podemos criar um módulo e nos vincularmos ao evento EndRequest. Dentro deste evento, podemos analisar se a propriedade StatusCode foi definida como 401, e se estiver, redirecionar para uma página que informa exibe a mensagem correta ao invés da página de login, melhorando assim a navegabilidade da aplicação. O módulo é extremamente simples, assim como podemos notar abaixo:

public class AccessDeniedModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.EndRequest += new EventHandler(context_EndRequest);
    }

    private void context_EndRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        if (app.Response.StatusCode == 401 && app.User.Identity.IsAuthenticated)
        {
            app.Response.Redirect(“~/AreaRestrita/AcessoNegado.aspx”);
        }
    }

    public void Dispose() { }
}

Como já sabemos, para que um módulo funcione, precisamos acoplá-lo na execução do ASP.NET, e fazemos isso através do elemento <httpModules />. Mas este módulo deve ter um cuidado especial para que funcione adequadamente. Já existem diversos módulos em execução pelo ASP.NET, e um deles é justamente o FormsAuthenticationModule. Se simplesmente adicionarmos o módulo que criamos na coleção de módulos da aplicação, o StatusCode vai chegar sempre como 302, pois a requisição primeiramente passará pelo módulo FormsAuthenticationModule, que como vimos acima, faz essa mudança. Com isso, a nossa condicional sempre irá falhar, fazendo com que o usuário seja redirecionado para a página de login. A dica aqui é ir até o arquivo Web.config que está em nível de servidor (%windir%Microsoft .NETFrameworkVERSÃOCONFIG), copiar a coleção de módulos e colar no arquivo Web.config da aplicação, como podemos ver abaixo:

<httpModules>
  <clear />
  <add name=”ScriptModule”
       type=”System.Web.Handlers.ScriptModule, System.Web.Extensions”/>
  <add name=”OutputCache”
       type=”System.Web.Caching.OutputCacheModule”/>
  <add name=”Session”
       type=”System.Web.SessionState.SessionStateModule”/>
  <add name=”AccessDeniedModule”
       type=”AccessDeniedModule”/>
  <add name=”FormsAuthentication”
       type=”System.Web.Security.FormsAuthenticationModule”/>
  <add name=”RoleManager”
       type=”System.Web.Security.RoleManagerModule”/>
  <add name=”UrlAuthorization”
       type=”System.Web.Security.UrlAuthorizationModule”/>
  <add name=”AnonymousIdentification”
       type=”System.Web.Security.AnonymousIdentificationModule”/>
  <add name=”Profile”
       type=”System.Web.Profile.ProfileModule”/>
</httpModules>

Depois de colocar os módulos no arquivo Web.config da aplicação, precisamos colocar o elemento <clear /> para que não duplique a execução dos módulos. E para finalizar, o módulo que criamos deverá ser colocado antes do módulo do FormsAuthentication para que funcione como o esperado. Aproveitando a oportunidade, é importante que você deixe somente os módulos que a sua aplicação realmente utiliza, ganhando alguma performance, já que evitará passar por passos desnecessários. Para maiores detalhes sobre isso, consulte este artigo.

Um amigo me pediu uma ajuda para escrever a seguinte mensagem na página de Login de uma aplicação ASP.NET: “A sua sessão expirou. Efetue o login novamente.”. Como ele está utilizando FormsAuthentication, pensei em analisar a existência da QueryString “ReturnUrl”, que geralmente é adicionada como parte da URL, quando você tenta acessar algum recurso protegido e que você não esteja devidamente autenticado.

O problema desta técnica é que as vezes o usuário tem o endereço (nos “Favoritos”, por exemplo) desta página restrita, e suponhamos que ele abra o navegador e tente acessá-la diretamente. O FormsAuthentication fará a parte dele, ou seja, redirecionará o usuário para a página de Login com a QueryString “ReturnUrl” contendo a página que ele tentou acessar. Se estiver analisando essa QueryString, a mensagem de “sessão expirada” será exibida, mas não faz sentido neste caso, já que é o primeiro acesso deste usuário.

Para tentar contornar esse problema, a solução foi a criação de um módulo, vinculando ao evento BeginRequest. Esse módulo será responsável por analisar a validade do cookie de autenticação, e se estiver expirado, redirecionará o usuário para a página de Login. Esse mesmo processo acaba sendo feito pelo próprio FormsAuthenticationModule, mas com este novo módulo, a ideia é nos antecipar ao FormsAuthentication e adicionar um novo item na coleção de QueryStrings, que especifica que a autenticação expirou. Esse valor será analisado pela página de Login, que baseando-se nele irá ou não exibir a mensagem em questão. Abaixo temos o módulo na íntegra:

using System;
using System.Web;
using System.Web.Security;

public class AuthenticationExpiredModule : IHttpModule
{
    private HttpApplication _app;

    public void Init(HttpApplication context)
    {
        this._app = context;
        this._app.BeginRequest += new EventHandler(this._app_BeginRequest);
    }

    private void _app_BeginRequest(object sender, EventArgs e)
    {
        if (this._app.Request.Path != FormsAuthentication.LoginUrl)
        {
            HttpCookie authCookie = 
                this._app.Request.Cookies[FormsAuthentication.FormsCookieName];

            if (authCookie != null)
            {
                FormsAuthenticationTicket ticket =
                    FormsAuthentication.Decrypt(authCookie.Value);

                if (ticket.Expired)
                {
                    this._app.CompleteRequest();
                    FormsAuthentication.RedirectToLoginPage(“Authentication=Expired”);
                }
            }
        }
    }

    public void Dispose() { }
}

Depois de criado, precisamos registrá-lo no arquivo de configuração (Web.config) para que ele comece a fazer parte da execução:

<httpModules>
    <add
        name=”AuthenticationExpiredModule”
        type=”AuthenticationExpiredModule”/>
</httpModules>

E, finalmente, já na página de Login, verificando a existência da QueryString:

this.AuthenticationExpiredMessage.Visible = Request.QueryString[“Authentication”] == “Expired”;