Parques de diversão e autenticação e autorização de usuários

No "post" anterior, eu comentei sobre aspectos de autenticação de usuários. Gostaria de detalhar e mostrar um visão sistêmica do assunto.

Na Arquitetura de Serviços a questão de segurança é sempre um tópico importante. Este assunto é muito amplo, podendo envolver “firewall”, criptografia, etc. Em particular, a questão envolvendo autenticação e autorização de usuário em SOA é muito relevante e pode ser melhor compreendido com uma boa analogia.

Imagino que você já tenha tido a oportunidade de entrar em um daqueles parques de diversão onde compramos um passaporte, temos a mão carimbada, e passamos um dia inteiro em rodas gigantes, trens fantasmas e em quaisquer outros brinquedos disponíveis.

Pois bem, este parque possui um processo de autenticação e autorização de usuários bem definido. A autenticação acontece, uma única vez, no momento do carimbo da mão. Já a permissão para a sua entrada em algum brinquedo é o processo de autorização. Analisando a metáfora com um pouco mais de atenção, chegamos a algumas conclusões:

• O fato de você ter usado dinheiro, cheque ou cartão de crédito é totalmente irrelevante para o funcionário do parque que verifica se você pode entrar em um brinquedo.
• Os funcionários postados na entrada de cada brinquedo se preocupam somente em verificar se você tem um carimbo na mão para autorizá-lo a brincar.
• Eventualmente, o parque de diversão pode passar a aceitar outras formas de pagamento sem que, mais uma vez, os funcionários responsáveis pela sua entrada nos brinquedos tenham conhecimento disto.
• A remoção ou inclusão de novos brinquedos no parque não altera o processo de venda de passaportes.
• É possível ainda que o parque ofereça passaportes com preços mais baratos e carimbos diferentes que possibilitem a entrada em um conjunto reduzido de brinquedos.

Na realidade, há uma completo isolamento das questões envolvendo os brinquedos, de tal forma que, caso haja a alteração de um dos processos, não ocorra impacto em outros. Eles estão fracamente acoplados entre si. É saudável a observação deste modelo para a implementação de processos de autenticação e autorização de usuários em SOA ou quaisquer outros sistemas de computação. O desenvolvimento, evolução e correção de sistemas são muito mais produtivos quando temos servidores específicos para a execução de tarefas bem definidas.

Assim, utiliza-se, por exemplo, um servidor de aplicações ou um ESB para a implementação de regras de negócio e/ou integração entre os sistemas. Já o processo de autenticação e autorização de usuários é melhor realizado por servidores de identidade específicos. A implementação das regras de autenticação e autorização de usuários envolvendo LDAP, certificados digitais, RADIUS, Kerberos, biometria, ou qualquer outro tipo de credencial não é influenciada pelas regras de negócio, e vice-versa, posto que tais questões são resolvidas, implementadas e executadas de forma independente.

A visão lógica dos servidores do "post" anterior pode ser incrementada como exibido abaixo:


Vários benefícios são atingidos com uma estrutura como esta:

• Da mesma forma que o ESB relaciona-se com o legado de sistemas, o servidor de autenticação e autorização conecta-se com o relaciona-se o seu "legado" formado pelas bancos de dados e tecnologias empregadas para armazenar as informações de usuários como LDAP, MS Active Directory, etc.
• A lógica de autenticação permite a definição de uma inteligência específica e superior àquelas encontradas nos bancos de dados de usuários. Por exemplo: classes de usuários devem ser submetidas a processos de autenticação distintos entre si (usuários internos através do par usuário/senha, usuários externos através de certificados digitais, etc)
• Mais uma vez o conceito de "Integração Distribuída" de David Chappell é usada. Um ESB pode não ser (e normalmente não é) o melhor componente tecnológico para implementar as funcionalidades de autenticação de usuários. De uma outra perspectiva: um servidor de autenticação pode ser visto como um "ESB de autenticação de usuários", ou um perfil funcional de um ESB.
• Em termos de padrões e tecnologias empregadas, usualmente os servidores de autenticação são baseados em "tokens" e suportam SAML, WS-Security, WS-Trust, etc. Em um visão específica para Web Services, os servidores de autenticação cumprem o papel de STS ("Secure Token Services"). Isso fica para um outro "post".

Resumindo, o nosso parque de diversões implementa, na vida real, os conceitos fundamentais da computação distribuída e que devem ser perseguidos bravamente em projetos SOA: fatoração de problemas. Toma-se um problema de certa magnitude e o divide em outros de nível de complexidade mais baixa, otimizando os recursos disponíveis. O que se busca no mundo dos sistemas e em SOA é que a computação, como a arte, imite a vida.