Verificando autorização através de Roles


Em aplicações ASP.NET ou qualquer outro tipo de aplicação, é comum verificar se um determinado usuário tem permissão para algum recurso, como por exemplo uma página, botão, comando, etc.. Nos últimos dias, eu recebi um e-mail onde um rapaz tinha problemas de performance neste ponto.

Na página dele, existe um botão de exclusão para cada linha do controle GridView. Então, no evento RowDataBound do mesmo, ele verifica se o usuário corrente está ou não em uma role específica. Mas o problema é que ele chama o método IsUserInRole para cada linha/registro. Em centenas de linhas/registros no GridView, este método será sempre chamado e, para cada chamada, todo o código deste método será executado. Abaixo o código antigo e o código melhorado:

[ Antigo ]
if(e.Row.RowType == DataControlRowType.DataRow) {
     e.Row.FindControl(“btnDelete”).Visible = Roles.IsUserInRole(“Administrator”);
}

[ Novo ]
private bool _isInAdministratorRole;
//….
this._isInAdministratorRole = Roles.IsUserInRole(“Administrator”);
//….
if(e.Row.RowType == DataControlRowType.DataRow) {
     e.Row.FindControl(“btnDelete”).Visible = this._isInAdministratorRole;
}

Pequenas técnicas como esta podem aumentar a performance da aplicação. “Caching code” é explicado no livro Code Complete – Segunda Edição, no capítulo 26, páginas 628 e 629.

Existem outras técnicas relacionadas com roles em uma aplicação ASP.NET. Estas técnicas permitem armazenar as roles em cookies do lado do cliente através do atributo cacheRolesInCookie. Ele previne em cada requisição, fazer uma nova query no banco de dados (ou outro repositório), para procurar pelas roles específicas do usuário que está logado no momento e anexar no objeto HttpContext.

Armazeando roles no cliente podem aumentar a performance se sua aplicação tem uma lentidão no acesso a dados ou um número grande de roles. Mas essa técnica tem problemas de segurança e voce precisa ser bastante cuidadoso em alguns pontos:

  1. Cookies com informações de autorização serão persistidos no profile do usuário e, um hacker que tiver acesso físico a máquina deste usuário poderá acessá-lo e, conseqüentemente, alterá-lo. Isso também causará problemas para aqueles usuários que esquecem a aplicação aberta (esquecendo de fazer o logout) em máquinas compartilhadas entre vários usuários.
  2. Enviar cookies sem SSL também pode compromenter a segurança, já que hackers podem pegar uma cópia do cookie e emular uma determinada role e elevar os privilégios dentro do sistema.

Se o caching de roles do lado do cliente for necessário (cookies), então habilite o atributo cookieRequireSSL no elemento roleManager por questões de segurança. Mas SSL exige um certificado (se voce não tiver, é necessário comprá-lo) e a performance pode ser prejudicada. É muito importante analisar o cenário e adotar a melhor estratégia.

Anúncios

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s