Autenticação via Claims no ASP.NET MVC

A finalidade deste artigo é mostrar algumas dicas importantes para fazer com que o WIF seja acoplado ao pipeline de uma relying party construída com o ASP.NET MVC, pois ao contrário do que vimos no artigo anterior, não há templates de projetos com o WIF pré-configurado para o ASP.NET MVC.

por Israel Aéce

Anteriormente eu comentei como podemos utilizar o WIF em uma aplicação ASP.NET WebForms, analisando detalhadamente os passos necessários para efetuar a configuração dos módulos utilizados pelo WIF. Mas o WIF também pode ser utilizado em conjunto com aplicações ASP.NET MVC. A finalidade deste artigo é mostrar algumas dicas importantes para fazer com que o WIF seja acoplado ao pipeline de uma relying partyconstruída como ASP.NET MVC, pois ao contrário do que vimos no artigo anterior, não há templates de projetos com o WIF pré-configurado para o ASP.NET MVC.

O primeiro passo é importante para ser dito, é que para utilizar o WIF com o MVC, também devemos recorrer aos módulos WSFederationAuthenticationModule e SessionAuthenticationModule, que são acoplados ao pipeline do ASP.NET e são os responsáveis pelo processamento e gerenciamento do processo de autenticação do usuário. Sendo assim, é necessário adicioná-los manualmente na seção <httpModules /> do arquivo Web.config, ou se estiver utilizando o assistente Federation Utility, que está disponível a partir da IDE do Visual Studio, ele já fará essa configuração automaticamente.

Como sabemos, a infraestrutura de segurança do o ASP.NET MVC é igual ao do ASP.NET WebForms, e com isso devemos respeitar as mesmas imposições feitas quando utilizamos o WIF no WebForms, ou seja, configurar o modelo de autenticação como indefinido (None), pois essa tarefa não compete mais à esta aplicação. Além disso, temos também que criar e configurar adequadamente a seção <microsoft.identityModel />, que como já sabemos, isso acaba sendo realizado automaticamente quando utilizamos o Federation Utility.

O primeiro passo é você se preocupar em proteger as seções da aplicação MVC que não permitem o acesso anônimo. Ao contrário do WebForms, no MVC definimos quais são asactions (métodos) que são restritas. Para definir isso, podemos utilizar o arquivo Web.config ou através do atributoAuthorizeAttribute. O código abaixo negará o acesso anônimo aos métodos (actions) VisualizarItens e RecuperarIndice da classe (controller) Monitor. Para maiores detalhes, você pode consultar este artigo.

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

public ActionResult RecuperarIndice()
{
//...
}
}

Pelo fato de termos os módulos do WIF acoplados ao MVC, ao detectar que o usuário não tem permissão de acesso a um destes métodos, automaticamente o módulo WSFederationAuthenticationModule entrará em ação e redirecionará o usuário para o STS que ele confia, incluindo na requisição a action e o controller que ele tentou acessar, para que quando o STS validá-lo, o WIF consiga redirecionar o usuário para o mesmo local.

Outro detalhe importante quando configuramos o WIF no ASP.NET MVC, é o uso do atributo passiveRedirectEnabled do elemento wsFederation. Quando ele é definido como False, o desenvolvedor da relying party deverá explicitamente efetuar o redirecionamento para o STS quando necessário. No ASP.NET WebForms, podemos fazer uso do controle FederatedPassiveSignIn, que tem a finalidade de encapsular toda a complexidade deste processo. Mas como sabemos, no MVC não utilizamos esses tipos de controles, o que nos obriga a fazer o redirecionamento manual, lembrando que isso somente é necessário quando o atributo passiveRedirectEnabled for definido como False.

Quando necessitamos desligar o auto-redirecionamento, precisamos saber como proceder para conseguir interagir com o STS. Para exemplificar isso, temos que criar um controller que irá gerenciar o processo de login, logout e o processamento do token gerado. Esse controller utilizará alguns dos membros que são expostos pela API do WIF, que vimos em um artigo anterior. O controller irá definir actions que determina cada uma das tarefas que ele vimos acima, podendo criar nas views, links que direcionam para cada uma delas.

public class SecurityController : Controller
{
public ActionResult EfetuarLogin()
{
if (!User.Identity.IsAuthenticated)
{
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
var requestMessage = newSignInRequestMessage(newUri(fam.Issuer), fam.Realm)
{
Context = "EndereçoParaOndeUsuarioSeraDirecionadoDepoisDoLogin"
};

return newRedirectResult(requestMessage.WriteQueryString());
}

return this.View();
}

[ValidateInput(false)]
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult ProcessarToken()
{
var fam = FederatedAuthentication.WSFederationAuthenticationModule;

if (fam.CanReadSignInResponse(HttpContext.Current.Request, true))
{
stringurl = HttpContext.Current.Request.Form["wctx"];
return new RedirectResult(url);
}

return this.View();
}

public ActionResult EfetuarLogout()
{
if (User.Identity.IsAuthenticated)
{
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
var signOutMessage = newSignOutRequestMessage(newUri(fam.Issuer));

fam.SignOut(false);
return new RedirectResult(signOutMessage.WriteQueryString());
}

return this.View();
}
}

O primeiro método, chamado de EfetuarLogin, extrai alguns parâmetros do módulo WSFederationAuthenticationModule e cria uma mensagem de login para o STS. A mensagem de login é representada pela instância da classe SignInRequestMessage, que fornece uma propriedade chamada Context, que recebe uma URL para qual o usuário será direcionado depois do login ter sido realizado. Finalmente, utilizando o método WriteQueryString, que retorna uma string representando o endereço completo até o STS, incluindo os parâmetros necessários para que o STS faça toda a validação necessária, e passamos essa string através de um objeto RedirectResult, que faz com que o MVC redirecione o usuário ao STS.

Na sequência temos o método ProcessarToken, que é responsável por verificar se a requisição trata-se de um token gerado pelo STS, e isso é realizado através do método CanReadSignInResponse da classe WSFederationAuthenticationModule. Se este método retornar True, então extraímos o parâmetro wctx da requisição e redirecionamos o usuário para este endereço. O wctx representa o endereço que o usuário tentou acessar antes de efetuar o login no STS, qual utilizaremos o RedirectResult para direcionar o usuário novamente para lá. Podemos notar que este método está decorado com dois atributos, onde o primeiro deles desligamos a validação para permitir que informações com caracteres < e > sejam postadas para ele. Isso é necessário porque o token gerado é baseado em XML. Em seguida, utilizamos o atributo AcceptVerbsAttribute para garantir que este método será acessado somente através do verbo POST.

Finalmente, temos o método EfetuarLogout, que coordena o processo de logout do usuário. Ele utiliza o método SignOut da classe WSFederationAuthenticationModule, e na sequência utilizamos uma instância da classe SignOutRequestMessage, que recebe em seu construtor o endereço do STS. Depois da instância criada, utilizamos novamenteum objetoRedirectResult para redirecionar o usuário para o endereço gerado pelo método WriteQueryString da classe SignOutRequestMessage, que efetuará o logout no STS.

Depois deste controller criado, tudo o que precisamos fazer na aplicação, é mencionaras actionslogin e logout onde desejamos visualizar estes links. Para exemplificar, o código abaixo ilustra como criar esteslinks:

<%= Html.ActionLink("Login", "EfetuarLogin", "Security") %>
<%= Html.ActionLink("Logout", "EfetuarLogout", "Security") %>

Conclusão: Como percebemos neste artigo, apesar de não termos toda a facilidade de configuração e controles que existem no ASP.NET WebForms, é fácil acoplar o WIF à execução de uma aplicação ASP.NET MVC. A única exigência aqui é você tentar identificar se precisa ou não do auto-redirecionamento; caso não precisar, o controller que foi criado acima não será necessário.