Algumas palavras sobre Autenticação, Identidade e Autorização com Claims-based Identity

Olá pessoal, tudo certo?

Essa semana foi bem dedicada para alguns projetos sobre autenticação, autorização e identidades. De fato, fazia tempo que não via o encadeamento de tantos projetos sobre o mesmo assunto.

Diversos aspectos estão envolvidos, como:

• Definição do projeto de autenticação e autorização de usuários
• Definição das funcionalidades e mapa de autorização para a aplicação
• Definição de páginas secretas, direitos de acessos, controles e funcionalidades
• Definição de claims, tokens e identidades que serão usadas
• Definição dos níveis de propagação de credenciais, tokens, identidades e delegação, entre diversos níveis de serviços,
• Além de outras ações…

Como destaque, vale comentar que em todos os casos acima estamos falando do modelo Claims-based Identity, onde nossas aplicações e serviços estão baseadas em tokens e claims.

O impacto da utilização de um modelo de Claims está em retirar os detalhes da autenticação/autorização da lógica da aplicação.

Como vimos em posts passados, o modelo CBA é baseado em um serviço emissor de tokens, que irá emitir um token de segurança com as declarações que a aplicação precisa para liberar um acesso. Para ficar mais claro, vamos fazer um resumo rápido de alguns conceitos:

O que é uma Identidade?

• Uma identidade é um conjunto de informações sobre alguma entidade, como um usuário. A maioria das aplicações trabalha com identidades. Como sabemos, informações de identidade orientam aspectos importantes sobre o comportamento de uma aplicação, como direitos de acesso de um usuário ou serviço, modo como uma aplicação interage com o usuário, etc.

O que é um Token?

• Um token é um conjunto de bytes que expressa informações sobre uma identidade. Essas informações consistem de uma ou mais declarações (claims), onde cada claim contém informações sobre a entidade para a qual o token se aplica. Exemplos de claims são Nome, Grupo, Idade, Data de Nascimento do usuário, etc.

O que é um Identity Provider?

• Um identity provider (ou issuer/emissor) é uma autoridade que faz declarações (claims) sobre uma entidade. Em uma rede corporativa, um exemplo de identity é a própria empresa, assim como na internet, o Windows Live ID é um exemplo de emissor. Um identity provider pode implementar um security token service (STS), que é um serviço responsável pela emissão de tokens. Para esse serviço, as requisições são feitas via o protocolo WS-Trust, enquanto que o token é formatado em Security Assertion Markup Language (SAML).

O que é um Relying Party?

• Um Relying Party é uma aplicação Claims-aware, isto é, que está preparada para tratar os aspectos de autenticação e autorização através de token/claims. Por exemplo, podemos criar uma Web Application que é baseada em Claims para decidir sobre a autenticação de um usuário, a partir de claims exigidos do usuário no momento do acesso.

O que é um Security Token Service (STS)?

• Como vimos acima, um STS é um serviço que emite tokens com os claims exigidos por uma aplicação chamada Relying Party, para liberar o acesso de um usuário para uma aplicação ou serviço.

Pensando na infraestrutura, a Microsoft possui um emissor de tokens chamado AD FS, apresentado inicialmente com o Windows Server 2003. Hoje, temos o recém lançado AD FS - Active Directory Federation Services V2.0, sobre Windows Server 2008. Através desse serviços, podemos emitir tokens/claims para uma aplicação CBA. Note que esses tokens são emitidos somente para os usuários autenticados, ou seja, algum serviços de autenticação garante que o usuário que requisita o token foi autenticado. Por exemplo, um AD FS (STS) pode emitir um token para um usuário previamente autenticado no AD, via Windows Authentication.

Como estamos falando de padrões e protocolos abertos, não precisamos trabalhar sempre em plataforma Microsoft. Podemos combinar um STS em Microsoft, um provedor de identidades em UNIX e mesmo uma Relying Party (nossa aplicação) baseada em plataforma JAVA/LINUX, sem problema algum. Tudo é padrão SAML, WS-TRUST, WS-POLICY, etc.

Notaram a beleza do cenário? :)

Uma vez emitido o token para um usuário, uma aplicação claim-aware pode acessar as claims presentes no token, tomando as decisões sobre direitos de acesso sobre as declarações apresentadas.

Pensando em desenvolvimento, a Microsoft possui um framework que permite manipular e acessar os claims de um token, chamado WIF – Windows Identity Foundation. o WIF oferece classes e interfaces que permitem acessar as propriedades de um token e navegar por coleções de claims recebidas por uma aplicação Relying Party.

Assim, para uma visão completa do ambiente Claims-based Identity na plataforma Microsoft, veja o desenho abaixo que retirei do documento sobre o assunto do arquiteto David Chappell:

No desenho acima, destaque para o AD FS v2.0 (que emite tokens para o usuário chamador), o WIF na aplicação Claims-aware, que espera claims para decidir sobre o direito de acesso do usuário, e finalmente o CardSpace 2.0 (que atualmente está em BETA).

Aqui, o CardSpace funciona como um seletor de identidades, que o usuário pode utilizar para escolher uma identidade que será apresentada para o emissor de tokens (STS), no momento da requisição de um token para acessar a aplicação desejada.

Esse assunto é muito interessante e vale a leitura do documento do Mr. Chappell, que citei acima, veja:

Claims-Based Identity for Windows, David Chappell
Ref.: https://www.davidchappell.com/writing/white_papers/Claims-Based_Identity_for_Windows_v2.pdf

O post aqui fez só alguns comentários sobre o assunto! Fica a dica para novas leituras.

Por enquanto é só! Até o próximo post :)

Waldemir.