Segurança SOA - Arquitetura de Serviços e Gerenciamento de Identidade e Acesso II

A disciplina IAM ("Identity and Access Management" - Gerenciamento de Identidade e Acesso) pode ser dividida em diversos temas. Para simplificar, em uma primeira classificação, teríamos as questões funcionais separadas em dois grupos: (1) gestão de usuários e (2) garantia ou execução ("enforcement") das políticas descritas a tempo de gestão.

A figura abaixo ilustra este agrupamento:

Toda a estória começa aqui: em um ambiente corporativo, é natural que tenhamos uma infinidades de bancos de dados que armazenam as contas de usuários de aplicações e sistemas. Dentre eles:

• Sistemas Operacionais
• Servidores de Diretório: LDAP, NIS, X.500, Microsoft Active Directory, etc
• Gerenciadores de Bancos de Dados
• Sistemas de Autenticação: RADIUS, Kerberos, RACF, TopSecret, etc.
• Pacotes de Aplicações: ERP, CRM, SCM, etc
• Bancos de Dados proprietários de aplicações caseiras
• etc, etc, etc.

Gestão de Usuários
Nem todo usuário deve existir em todo sistema ou aplicação. Os processos de Gestão de Usuários (basicamente Aprovisionamento e Gerenciamento de Perfis) preocupam-se em definir quais usuários devem ser inseridos em quais sistemas e bancos de dados de usuários. Chamamos de Ciclo de Vida dos Usuários as operações realizadas desde a criação de um usuário, eventuais alterações, até a sua eliminação dos sistemas.

Veja que os processos de Gestão de Usuários deve se relacionar com diversas categorias de bases de dados e sistemas, localizados em diferentes níveis de abstração desde sistemas operacionais, pacotes de mercado, bancos de dados de aplicações customizadas.

Autenticação e Autorização de Usuários
Definições sucintas:

• Autenticação de Usuário: processo de reconhecimento de um usuário por um sistema. Uma credencial é fornecida pelo usuário para a sua autenticação: par usuário/senha, certificado digital, "tokens" de senhas, dado biométrico, etc.

• Autorização de Usuário: processo de controle de acesso a recursos protegidos. Recursos são quaisquer elementos que um usuário ou aplicação deseja manipular: tabelas de banco de dados, URLs, arquivos, impressoras, etc. O processo de autorização ocorrre após a autenticação do usuário.

Estes processos basicamente consomem as informações inseridas e manipuladas pelos processos de Gestão para implementar uma inteligência específica e necessária que não seria possível de ser realizada por uma única base de dados de usuários. Dentro deste contexto, é possível então que tenhamos autenticação baseada em contexto (por exemplo, considerando data e hora, endereço IP, etc), autenticação multi-fator, etc.

As aplicações basicamente resolvem estas questões de duas formas:

• As lógicas de AuthN e AuthZ fazem parte da própria aplicação: neste caso a aplicação faz um contato com alguma base de dados de usuário como LDAP, X.500, MS Active Directory, etc.

• As lógicas de AuthN e AuthZ são implementadas por servidores específicos. Neste caso, as aplicações enviam requisições a estes servidores e o contato com as bases de dados é feito por estes servidores.

Distribuição e Consolidação de Processos

Outra observação importante é que os processos de Gestão de Usuários (Aprovisionamento, Gerenciamento de Perfis, etc) tendem a ser consolidados enquanto os processos de Autenticação e Autorização são inerentemente distribuídos. Em uma arquitetura de software corporativa é absolutamente natural que tenhamos vários pontos de autenticação e autorização de usuários. A figura abaixo ilustra esta questão. Veja que há domínios de aplicações que fazem uso, para efeito de Autenticação e Autorização de Usuários de um infraestrutura própria. Aplicações Mainframe, por exemplo, provavelmente apoiam-se em softwares como RACF ou TopSecret.

Em SOA, é bastante comum o uso de servidores STS ("Secure Token Service") também representados na figura acima. Um STS é responsável pela autenticação dos usuários que consumirão os serviços disponíveis. Como qualquer Servidor de Autenticação, o STS permite que vários tipos de credenciais sejam fornecidas. Caso a autenticação tenha ocorrido com sucesso, o STS emite um "token" de autenticação que deverá ser "carregado" pelo consumidor de serviço em interações seguintes.

A figura abaixo ilustra uma composição básica com a Arquitetura de Serviços, STS e Intermediador de Serviços.

A figura aponta a interação entre o Intermediador de Serviços (responsável pela Governança em tempo de execução ("run time")) e o STS. Na verdade quaisquer outros pontos da arquitetura podem eventualmente se relacionar com o STS. Por exemplo, um dos consumidores de serviços pode vir a ser um engenho BPM ("Business Process Management"). O contato com o STS pelo BPM pode ocorrer para que o "token" seja criado no momento de uso de um Processo de Negócio definido pelo BPM. O "token", posteriormente, é transferido para os demais elementos da arquitetura como o próprio intermediador, Serviço de Negócio, etc.

O "post" seguinte tratará com mais detalhes o componente STS e os padrões de mercado que normalmente são implementados por ele.