É fácil observar que diversas aplicações comerciais carregam consigo um modelo para controle de acesso. As aplicações disponibilizam telas e acessam dados persistidos. É realmente necessário replicar tais telas para cada novo sistema? É preciso manter uma base de dados com usuários, grupos e permissões para cada aplicação? Qual o custo de replicar, manter e atualizar esse modelo descentralizado? Quanto tempo os codificadores perdem para construir "novas" (antigas) telas? Quanto o setor de Infra-estrutura de TI de uma organização perde diariamente para atender chamados de usuários que esqueceram as senhas das dezenas de sistemas que eles utilizam?
A figura 1 ilustra como o controle de acesso de uma aplicação comercial é geralmente projetado. É preciso deixar claro que as fatias não representam uma proporção de esforço na construção ou manutenção do módulo de controle de acesso. O que está em vermelho (o filtro, as funcionalidades para controle de acesso e a base de dados B) representa os elementos que geralmente compõem o módulo de segurança. É muito comum encontrar a base de dados B – que possui dados de usuário, grupos e permissões – fortemente acoplada ao modelo de entidades da aplicação (base de dados A). As funcionalidades para controle de acesso possuem telas que manipulam a base de dados B e disponibilizam as infomações para o filtro. O filtro é responsável por interceptar as requisições dos usuários e verificar os seus privilégios, concedendo ou revogando o acesso a um recurso. O que está em azul representa a aplicação que utiliza um modelo qualquer para controle de acesso.
Figura 2 – Modelo Independente de Plataforma (recomendado)
O primeiro passo é retirar da aplicação o que não precisa ser replicado: as funcionalidades para controle de acesso e a base de credenciais de usuários/grupos e permissões. Eis que surgem os elementos da Arquitetura Rasea, ilustrados na figura 2: servidor, agente e aplicação parceira. O servidor acessa uma base única e disponibiliza telas para a manipulação dos dados. Além disso o servidor publica serviços web para que os agentes consultem as informações necessárias para executar o seu trabalho. A aplicação parceira utiliza o agente específico de sua tecnologia para filtrar as requisições dos usuários. Não importa a tecnologia, estrutura ou plataforma da aplicação parceira. Ela poderá se beneficiar da solução desde que suporte o consumo de WebServices.


Cara muito bom... gostei muito... interessantíssimo!
ResponderExcluir