O ASP.NET introduziu novas formas de configurar e gerenciar a autenticação e autorização em aplicações Web. Temos o Windows Authentication e Forms Authentication para a autenticação e Url Authorization ou File Authorization para autorização.
Com Windows Authentication, o usuário apresentará o token do Windows que será validado em algum local (sendo na própria máquina ou em algum domínio). Já com o Forms Authentication, a aplicação irá gerenciar a identidade do usuário gravando-a em cookie durante o login e reutilizando-o nas chamadas subsequentes. Em um ambiente de internet, esse modelo é o mais utilizado.
Para autorização, temos duas possibilidades, sendo a primeira delas a File Authorization. Neste modo, o usuário somente terá acesso a um arquivo ASPX se o mesmo tiver permissão (ACL) de acesso. Este tipo de autorização é comumente utilizada em conjunto com a autenticação Windows (geralmente utilizado em intranets), onde você customizará as permissões fisicamente nos arquivos. No modo Url Authorization, a configuração de acesso é feito baseando-se na URL, e em um ambiente de internet, é também o que mais se utiliza.
O foco dos posts será a configuração da Url Authorization. Para customizar a restrição de cada arquivo, devemos recorrer ao arquivo Web.config, configurando a página ou diretório e quem pode ou não pode acessá-los. Aqui você poderá refinar a autorização baseando-se em usuários (users) ou em papéis (roles). A forma mais simples de conceder e negar acesso é fazendo uso dos papéis, pois nome de usuários mudam com muita frequência, e em pouco tempo deixam de existir. Como exemplo, o trecho de código abaixo ilustra uma possível configuração:
<?xml version=”1.0″?>
<configuration>
<location path=”AreaRestrita”>
<system.web>
<authorization>
<deny users=”?”/>
</authorization>
</system.web>
</location>
</configuration>
Neste exemplo podemos notar que o diretório “AreaRestrita” é protegido contra usuários anônimos (representado pelo caractere “?”), ou seja, enquanto o usuário não estiver autenticado na aplicação, ele não terá acesso a qualquer conteúdo que está dentro deste diretório. Já no exemplo a seguir, apenas permitimos acesso à página “CriarUsuario.aspx” se o usuário fizer parte do papel (role) “Admin”:
<?xml version=”1.0″?>
<configuration>
<location path=”CriarUsuario.aspx”>
<system.web>
<authorization>
<allow roles=”Admin”/>
</authorization>
</system.web>
</location>
</configuration>
Neste modelo de definição de autorização, temos um grande problema que é a atualização das informações, ou melhor, a alteração das políticas ali definidas. Podemos facilmente recorrer a API System.Xml que temos dentro do .NET Framework ou, de forma mais simples, utilizar as APIs de configuração que me permite o acesso tipado às seções do arquivo Web.config. Mas o problema maior não é isso, mas sim o transtorno que a alteração causa. Qualquer mudança no arquivo Web.config causará a reciclagem do processo do ASP.NET e, consequentemente, todas as informações que estão em memória, como o caching, variáveis estáticas, de sessão e aplicação são completamente perdidas, podendo ocasionar erros inesperados em tempo de execução e um comportamento indesejado para os usuários.
Particularmente eu acredito que essas políticas não mudam com muita frequência, mas recebi diversos e-mails e questões em fóruns perguntando sobre isso. De qualquer forma, resolvi criar uma forma customizada para definir as políticas de acesso às páginas ASP.NET. A partir da série de posts abaixo vou mostrar uma possível solução para este caso:
DBAuthorization – Parte 1 – O Problema
DBAuthorization – Parte 2 – A possível solução
DBAuthorization – Parte 3 – Estrutura do Banco de Dados
DBAuthorization – Parte 4 – Estrutura dos Tipos
DBAuthorization – Parte 5 – Provider
DBAuthorization – Parte 6 – Caching
DBAuthorization – Parte 7 – DBAuthorizationModule
DBAuthorization – Parte 8 – Configuração do arquivo Web.config
DBAuthorization – Parte 9 – Interface de Administração
DBAuthorization – Parte 10 – Conclusão
Israel Aece 