Crise das infinitas identidades - parte 2

No post anterior apresentei um cenário onde várias agências de uma mesma entidade, como o governo, pode se beneficiar de Claim Based Identity para criar uma aplicação de emissão de passagens e concessão de diárias, onde se cria um nível de abstração entre a autenticação e a autorização, em outras palavras, o usuário é autenticado localmente em seu órgão de origem e é autorizado (ou não) pela aplicação.

Acompanhando a mudança da indústria para o conceito de nuvem, seria possível ter a aplicação de emissão de passagens em um dos datacenter do Azure e as agências consumindo essa aplicação.

IMPORTANTE. Nem todas as empresas necessitam de aplicações que utilizem de Claim Based Identity. Para aplicações internas o uso da autenticação integrada ao Active Directory (AD) já seria o suficiente. POR OUTRO LADO, o uso de Claim Based Identity simplifica a lógica das aplicações Web. No caso dos tickets Kerberos, usados na autenticação do AD, estes contêm apenas a conta do usuário e os grupos que pertence. Se o aplicativo necessitar de alguma outra informação do AD é necessário adicionar código na aplicação para extrai-la. No Claim Based Identity o token já pode trazer essa informação ou qualquer outra que esteja em outra base de dados.

Outro ponto a considerar é que as novas tecnologias têm mudado os requisitos das aplicações para ser compatíveis com dispositivos móveis. Estes não fazem parte de um domínio corporativo. A autenticação dos usuários destes dispositivos vai ser orquestrada pelo serviço de claim, que faz com que a aplicação direcione a autenticação para os servidores que tem autoridade para autenticação do usuário, seguindo normas de segurança para que então possa acessar o recurso hospedado na nuvem.

Depois de tanto se falar em claim e token, você deve estar se perguntando o que são eles?  Ao invés de tentar achar uma palavra que traduza cada termo, acho mais simples dizer que um claim é uma declaração sobre alguma coisa, definida por outra entidade como verdadeira. Um conjunto de claims é chamado de token.

Fazendo uma analogia com o mundo real, o conceito de claims e tokens é usado o tempo todo. Por exemplo, nos é definido por lei que apenas os maiores de 18 anos têm o direito de dirigir quando aprovados por exame escrito e prático de direção. Logo, a carteira nacional de habilitação é um token que tem diversas declarações sobre aquelas que às possuem, como CPF, categoria, data de nascimento e etc, emitidas pelo Departamento Nacional de Transito do Ministério das Cidades que asseguram que essas informações são verdadeiras.

Imagine que você é parado pela polícia, você entrega o seu documento de identidade para o guarda que faz primeiro uma rápida autenticação (não tão boa quanto no mundo digital), analisando a sua foto e nome com você. Uma vez estando devidamente identificado (autenticado) vem o processo que requer a autorização para dirigir, que neste caso combina as declarações da sua carteira de motorista com as declarações do documento do carro. - Nota: No mundo digital seria possível criar um único token que agrega informações de bases diferentes.

Você pode imprimir da Internet um documento que seu carro está sem pendências alguma e falar que esqueceu o documento de habilitação em casa e sua mulher certificar que você é habilitado, mas essas declarações não são de fontes previamente certificadas para isso, e então você não mais vai ter autorização de dirigir o seu carro até apresentar os "tokens" corretos.

Eu pensei em colocar mais detalhes técnicos de como tudo isso se encaixa, incluindo a integração com o Azure, contanto, tem um pessoal da Microsoft que vem trabalhando pesado nessa área e vem publicando vários materiais no site https://claimsid.codeplex.com/, com exemplos práticos e códigos para quem quiser se aventurar nessa área.