Uma nova forma de Autenticação/Autorização

Grande parte das aplicações que desenvolvemos nos dias de hoje, exigem um alto nível de segurança, o que nos obriga a desenhar um sistema consistente e evolutivo, que permite de forma simples, manipulá-lo de acordo com as necessidades que surgem durante a vida do mesmo. Isso faz com que todos os desenvolvedores, além de se preocuparem com as regras de negócio, ainda precisam saber como lidar com dois aspectos importantes de toda aplicação: autenticação e autorização.

A autenticação consiste em saber quem o usuário é identificá-lo dentro do sistema; já a autorização, determina quais privilégios esse usuário tem dentro do sistema, e para isso, obrigatoriamente deverá ocorrer depois da autenticação, já que primeiro preciso saber quem ele é para depois conseguir encontrar os direitos que ele possui dentro do sistema.

Isso não seria uma tarefa difícil se não houvesse vários mecanismos diferentes, e que permitem configurar e gerenciar tanto a autenticação quanto a autorização. Cada um destes mecanismos tem como alvo um cenário distinto, e é complicado achar uma solução que atenda à todos os cenários em que a aplicação está exposta, tornando extremamente complicado gerenciar esses aspectos em um ambiente mais amplo, e que muitas vezes acarreta em duplicação de código e possíveis vulnerabilidades.

Além disso, é importante dizer que para cada forma de autenticação e autorização que utilizamos, temos que entender o mínimo sobre como ela funciona. Como disse antes, há varias opções que temos atualmente, como por exemplo: Kerberos, Forms Authentication, Url Authorization, certificados, etc. Cada uma delas tem suas peculiaridades, e exige de nós um entendimento mínimo para saber qual desses modelos se encaixa melhor com a nossa necessidade.

Em uma análise rápida, o Kerberos é a melhor opção se queremos autenticar um usuário que consome uma aplicação ASP.NET dentro da empresa, mas não traz nenhuma informação extra além de seu token. Esse modelo é fácil de implementar até que alguém, fora da empresa, também precise acessar essa mesma aplicação. Como esse modelo exige que o usuário esteja devidamente cadastrado no Active Directory da respectiva empresa, pessoas que estão além dela, não conseguirão acessá-la, e como sabemos, manter contas para usuários "voláteis", não é uma tarefa viável. Para entender a complexidade em que vivemos atualmente, veja a imagem abaixo:

Note que dentro do quadrado verde temos uma empresa qualquer, que por sua vez, possui vários funcionários. Cada funcionário, toda manhã, efetua o login no Windows, que vai até o controlador de domínio (Active Directory), valida o usuário, e caso seja válido, permite o acesso ao sistema operacional. Felizmente, na empresa que temos como exemplo acima, os desenvolvedores se preocuparam em reutilizar as credenciais do Windows para as aplicações que rodam dentro dela, onde uma delas é uma aplicação Windows (chamada de App) e que consome um serviço WCF, e a própria intranet, hospedada no IIS, e que também utiliza autenticação integrada aoWindows.

Agora repare que este mesmo usuário também acessa outras aplicações, que estão fora do domínio da empresa em que ele trabalha. O acesso a loja para comprar presentes, possui seu próprio sistema de autenticação e autorização, obrigando este usuário a criar uma conta ali. Já quando ele tenta acessar o site do banco, um certificado é exigido para que ele proceda com o login. E, como se não bastasse, a empresa em que ele trabalha mantém relações comerciais com outros parceiros, e cada um desses parceiros possui um sistema próprio de pedidos, e como já era de se esperar, cada um possui seu próprio esquema de autenticação e autorização.

Mas note que no caso do parceiro 1, a aplicação somente permite acesso para aqueles usuários que estão cadastrados dentro do AD da respectiva empresa, sendo assim, como acessá-la? Na maioria das vezes, o parceiro 1 cria uma aplicação simples, baseada em internet, e permite o acesso aos parceiros. Mas o que vai acontecer é que o parceiro 1 precisará, novamente, de uma nova forma para controlar os usuários que irão acessar tal aplicação, e muito provavalmente, irá recorrer à uma base de dados customizada para isso (se a aplicação for ASP.NET, podemos recorrer ao Membership). Mas essa solução dá início a outro problema, que ocorrerá no momento em que este usuário não fizer mais parte da minha empresa, pois terei que lembrar à quais parceiros ele tinha acesso, para assim removê-lo, já que ele não poderá continuar acessando, e isso ainda obrigará ao parceiro, criar uma interface (tela) para a administração de usuários.

Deixar para cada um implementar, de forma arbitrária, o modelo de autenticação e autorização, dá margem para que os desenvolvedores façam isso de qualquer modo, não se preocupando com pontos importantes, como por exemplo, o armazenamento das senhas de forma segura (hash), tráfego das credenciais através de um protocolo que não permita ninguém interceptar, evitar ataques de brutal-force, DoS, etc. Além destes problemas de infaestrutura, ainda temos as políticas de senhas, já que muitas aplicações não asseguram que a senha escolhida pelo usuário seja uma senha segura; a reutilização de senhas é um problema grave, pois para evitar o esquecimento, muitas pessoas utilizam a mesma senha para todas as aplicações que elas utilizam, e uma vez que isso cai em mãos erradas, o estrago pode ser irreparável. A reutilização é fácil até que você encontre aplicações com políticas de senha diferentes, pois o que pode ser uma senha válida para uma aplicação, não é para outra, obrigando a você escolher outra senha que se enquadre com as políticas desta aplicação, voltando assim, ao inferno das senhas diferentes.

Outro grande desejo que existee que é difícil de implementar, é a capacidade de termos SSO (Single Sign-On) entre as aplicações, ou seja, a capacidade que damos ao usuário de se autenticar uma única vez, e assim poder acessar todas aquelas aplicações que confiam naquele autenticador. Algo mais ou menos como o que acontece com o Windows Live Id, onde você se autentica uma única vez, e tem acesso à todos os sites da Microsoft que são protegidos por ele.

Qual seria então o modelo ideal para resolver grande parte dos problemas que vimos acima? O modelo ideal seria a possibilidade de centralizar a autenticação em um único local, que determinará como ela deverá ser realizada e protegida. A centralização evitará com que toda a aplicação se preocupe com a lógica de autenticação, já que não competirá mais a ela esse papel. Os desenvolvedores podem se concentrar apenas no desenvolvimento da aplicação em si, com as regras de negócios, interfaces (telas), serviços, etc. Com a autenticação "externalizada", não precisamos mais misturar códigos de infraestrutura com códigos de regras de negócios, tornando a aplicação muito mais limpa, e, além disso, outro grande benefício com a refatoração é a facilidade que teremos em dividir o que compete ao desenvolvedor e o que compete ao administrador da rede.

O modelo que visa esse cenário é conhecido como Claims-Based Identity Model, ou seja, modelo de identidade baseado em claims, que traduzindo significa "afirmações". Nesse modelo, as aplicações que desenvolveremos não serão mais responsáveis por autenticar e muito menos por armazenar suas senhas. Para fazer uma analogia ao mundo real de como esse modelo trabalha, podemos recorrer ao exemplo da compra de algum produto através do cartão de crédito. Quando você vai pagar por esse produto, você fala que vai pagar com o cartão de crédito, mas a loja não confia em você, quando você diz: “Olha, eu tenho R$ 2.000,00 de crédito, pode me vender!”. Na verdade, o que a loja faz é "validar" aquele cartão que você apresentou, junto aquele que o emitiu, que é a operadora. É ela quem dirá se aquele cartão é ou não válido e dizer até o quanto você poderá gastar. A loja utilizará essas informações para proceder ou não com a venda.

Neste cenário descrito acima, note que a loja nada sabe sobre o cliente, mas confia em alguém que o avaliza. A partir daí, a loja geralmente faz o cadastro do cliente, colhendo o seu e-mail, endereço, etc., para mais tarde conseguir enviar um catálogo dos novos produtos. Da próxima vez que você vai comprar novamente a validação é realizada na operadora do cartão, mas seus dados cadastrais já estão catalogados, podendo ser apenas atualizados.

Outro ponto importante deste cenário, é que a autorização ainda deve ser realizada pela aplicação, ou seja, ela ainda é responsável por determinar o que usuário pode ou não acessar. Mas atualmente, os direitos de acessos que concedemos à determinadas funcionalidades dentro da aplicação, geralmente são determinadas por grupos, ou seja, se o usuário fizer parte do grupo Administradores, então ele pode ter acesso às contas corrente dos clientes. Mas no cenário descrito acima, ele vai além disso, já que a autorização é concedida baseando-se no limite do cartão de crédito.

Isso é mais um dos benefícios das aplicações baseadas em claims. As afirmações emitidas por alguém contra outro alguém, pode ser qualquer tipo de informação, e você refina o acesso através delas. Muitas vezes a autorização vai muito além dos grupos (simples strings) que o usuário pertence, pois há situações em que podemos negar ou conceder acesso de acordo com a data de nascimento, ou seja, se ele tiver mais do que 21 anos, então poderá acessar o conteúdo.

Para fazer com que tudo isso funcione, a Microsoft tem trabalhado em três produtos que, juntos ou separadamente, fornecerão grande parte do que precisamos para atingir o nosso objetivo, que é a centralização e o gerenciamento do processo de autenticação. Cada um desses produtos, implementam padrões de mercado, e por isso podem ser utilizados separadamente, ou melhor, podemos ter uma dessas ferramentas Microsoft falando com outras desenvolvidas pela IBMutilizando Java, pois todas falam o mesmo "idioma". A Microsoft criou a solução completa, composta de três produtos que estão listados abaixo, com suas respectivas descrições:

WIF - Windows Identity Foundation: Trata-se de um framework para a construção de aplicações baseadas em claims, e que abstrai toda a complexidade do processo de autenticação que é realizado seguindo uma série de padrões de mercado (WS-*). Além disso, a sua API traz uma série de tipos que habilitam a extensibilidade, podendo mais tarde, criar novas opções de autenticação.
ADFS 2.0 - Active Directory Federation Services 2.0: Uma ferramenta que ajuda os administradores de rede, a gerenciar o ambiente de autenticação que será fornecido por aquelas aplicações que queiram fazer uso do modelo baseado em claims. Essa ferramenta implementa os mesmos protocolos do WIF, permitindo assim que eles interajam.
Windows Cardspace 2.0: Uma ferramenta que é instalada nos clientes, como uma espécie de carteira virtual, que cataloga os cartões que podem ser enviados para as aplicações baseadas em claims. Trata-se de uma interface amigável que permite ao usuário final uma visualização simples do que ele tem e do que será efetivamente enviado à aplicação, podendo ele decidir se deve ou não proceder.

Conclusão: Com as informações acima, pudemos entender um pouco mais dos cenários de complexidade que possuímos e dos problemas que temos atualmente. Cada cenário exige um modelo diferente, mas que não atende a 100% dos casos. A finalidade deste artigo introdutório foi apresentar os desafios que temos, e quais soluções estão sendo oferecidas pela Microsoft, para poder tornar essa tarefa extremamente importante, em algo bem mais simples e reutilizável do que temos hoje em dia. A partir de uma série de artigos, vamos explorar cada uma das ferramentas e elementos que compõem este novo modelo de autenticação.

Desenvolvimento - ASP. NET

Leia também