Disponível a versão 0.4.0.RC1 para download

Está disponível para download a versão 0.4.0.RC1 do Servidor Rasea. Antes mesmo de descrever as mudanças e novidades desta versão, quero evidenciar todas as mudanças e evoluções do projeto, relacionadas direta ou indiretamente com esta nova liberação.

Durante muito tempo vínhamos estudando a infra-estrutura que o SourceForge nos oferece, acompanhado todas as mudanças nos seus serviços (e.g., gerenciamento de arquivos, tracker, fórum, etc). Tendo em vista a estabilização das suas novas funcionalidades, dedicamos esforços em começar a utilizar plenamente os seus recursos.

Atualmente o Rasea disponibiliza alguns recursos para seus usuários, visando maior transparência no processo de desenvolvimento, proporcionando um canal de comunicação mais direto com a comunidade. Para isso, focamos na disponibilização dos serviços: Site, Tracker, Fórum, Twitter (já existia) e Blog (já existia).

• Site: O site do projeto é o ponto central da infra-estrutura, contendo documentações sobre o Rasea bem como link para os outros serviços;
• Tracker: O tracker possibilita aos usuários abrir chamados facilmente para a equipe Rasea, propondo melhorias no projeto ou comunicando erros;
• Fórum: Através do fórum, os usuários podem trocar experiências sobre a utilização do Rasea, além de tirar dúvidas sobre todos os detalhes do projeto;
• Twitter: No twitter são publicadas novidades sobre o projeto. Aproveite e siga o projeto Rasea;
• Blog: Aqui no blog você encontrará postagens menos formais que o Site, porém mais completas que o Twitter.

Pois bem, agora que já descrevi as novidades que motivaram essa nova versão, ficará mais fácil entender as suas novidades. Dentre elas destaco a integração com o Maven, que automatizou o processo de build do projeto integrado com toda a infra-estrutura que dispomos. Utilizando a nova estrutura do projeto, as novas funcionalidades são:

• Rasea server liberado como WAR ao invés de EAR: Este trabalho de melhoria é o primeiro passo para integração com o Apache Tomcat, atendendo aos pedidos de várias pessoas que entraram em contato. Por enquanto o Rasea está sendo testado com o JBoss AS (v. 4.2.3.GA), mas aceitamos contribuições de quem estiver interessado em testá-lo em outros servidores de aplicação. Ainda não é possível utilizar o Rasea no Tomcat, mas em breve será;
• Configuração do banco de dados no rasea-server.properties: Agora toda configuração necessárias para o funcionamento do Servidor Rasea fica no arquivo de configuração rasea-server.properties. Esse é também um passo importante para a futura integração com o Tomcat e independência do JBoss AS;
• Criação da versão v1 dos WebServices: Refatoramos as interfaces dos WebServices (v1), porém sem perder a compatibilidade com a versão anterior (v0). Basicamente foi feito um trabalho de melhor organização, tornando o uso mais fácil e intuitivo;
• Novo campo DESCRIPTION na tabela R_OPERATION: Criação de um novo campo na tabela de ações, seguindo o padrão dos outros elementos RBAC no modelo do Rasea, e.g., Application, Role, Resource e User.

Mas as novidade não param por aí. Veja a lista de tudo que foi modificado nesta versão aqui. Aguardamos contatos e sugestões. A opinião da comunidade é muito importante para a evolução do projeto, como aconteceu até agora.

Faz tempo não posto novidades aqui no blog. Nesses últimos tempos estive super-atarefado na finalização do mestrado, no qual o Rasea é o objeto de estudo. Mas tudo ocorreu bem. Em contrapartida, o Twitter está sendo atualizado constantemente.

Fiz um vídeo, que está publicado no YouTube, para demonstrar o controle de acesso de uma aplicação JBoss Seam utilizando o servidor Rasea. Notem que o layout do servidor Rasea foi melhorado e está completamente diferente.

Layout incial do Rasea

Apresento-lhes o layout incial do Rasea. Focamos em algo leve e intuitivo, com pequenos detalhes para não deixar a coisa tão quadrada.

Tela de login

Tela sem muita informação:

Quando existem informações na tela de login:

Telas internas

Menu solto com um pequeno detalhe no canto direito, mensagem de boas vindas no canto direito abaixo do menu e versão do sistema no rodapé sobre um div semi-transparente:

As outras telas seguem o mesmo layout:

Efeito do mouse sobre a lista:

Estilo mais destacado evidencia o registro selecionado:

Edição do registro:

Selecionando o sistema, que está contextualizado:

Redimensionando a janela mantendo um layout agradável:

Aguardem o post de usuabilidade!!!

Rasea no Twitter

Para quem ainda não sabe, o projeto Rasea está na rede social Twitter, sendo possível acompanhar o andamento do projeto de forma online. É preciso que você possua uma conta no Twitter, crie a sua caso você não tenha. Para acompanhar o projeto, acesse http://twitter.rasea.org e clique em "Follow".

Agente

Toda aplicação parceira deve estar conectada a um agente. Tomando como base o modelo PIM, o agente RASEA é um motor de especialização (IBM, 2009), responsável por converter a linguagem dos WebServices em mensagens específicas das tecnologias das aplicações parceiras. Além disso, o agente executa efetivamente as tarefas de controle de acesso às aplicações, prevenindo o acesso não autorizado ao sistema. Neste tópico serão abordadas as duas principais funções do agente RASEA: i) motor de especialização; e ii) controlador de acesso.

A Figura 19 destaca a especialização do agente RASEA em diferentes tecnologias. O item “A” representa os serviços, providos pelo servidor, que são acessados pelos agentes “B”. A comunicação entre os serviços “A” e os agentes “B” se dá por meio de WebServices, garantindo a independência de plataforma. Os agentes “C”, “D” e “E” são especializações do agente conceitual “B”, construídos para tecnologias específicas, tais como: Java, .NET e PHP. O item “F” representa agentes desenvolvidos em qualquer tecnologia que suporte o consumo de WebServices, proporcionando flexibilidade à solução.

Figura 19 – Tipos de agente

Os agentes devem se especializar ao máximo, garantindo o encaixe perfeito com a tecnologia da aplicação parceira. Como exemplo, pode-se citar a utilização de Java na construção de aplicações comerciais. Existem diversas ferramentas, paradigmas, frameworks, bibliotecas e tecnologias que podem ser utilizadas na construção de aplicações na plataforma Java, tais como: i) JavaServer Faces (JSF); ii) Apache Struts; iii) Google Web Toolkit (GWT); iv) Abstract Window Toolkit (AWT); dentre outras. É fundamental que exista um agente para cada tecnologia específica, ao invés de um motor de especialização genérico para a plataforma Java.

O agente é responsável por interceptar todas as requisições feitas às aplicações parceiras, conforme estabelecido pelo padrão de projeto Front Controller (ALUR; CRUPI; MALKS, 2003, p. 164). Todas as tentativas de acesso devem ser tratadas com base nas informações consultadas no servidor RASEA. De acordo com Kern (2004, p. 90, tradução nossa), “lentidão nas decisões de acesso são críticas para o negócio”, portanto recomenda-se armazenar em cache todas as permissões associadas ao usuário. Segue a baixo o processo executado pelo agente para realizar a autenticação e o armazenamento dos privilégios de acesso:

1.      O usuário informa as credenciais para acessar a aplicação parceira;

2.      O agente acessa o serviço de autenticação provido pelo servidor;

3.      O servidor verifica a autenticidade acessando a base única de usuários;

4.      Caso a autenticação seja bem sucedida, o agente é notificado e o fluxo prossegue. Em caso de falha na autenticação, o usuário é notificado e o fluxo é finalizado;

5.      O agente solicita todos os papéis que o usuário possui e os armazena em cache;

6.      O agente solicita todas as permissões atribuídas ao usuário e as armazena em cache;

7.      O usuário é notificado que o processo de autenticação foi bem sucedido, ganhando acesso à aplicação.

O fluxo a seguir estabelece as etapas do controle de acesso, executadas pelo agente RASEA, ao interceptar requisições aos recursos da aplicação parceira:

1.      O usuário acessa um recurso de uma aplicação executando uma determinada ação.

2.      O agente intercepta a requisição.

3.      Caso esteja autenticado, o fluxo continua. Caso contrário, o usuário é direcionado para o processo de autenticação.

4.      O agente verifica a autorização para executar a ação sob o recurso solicitado. A verificação é feita com base nas informações em cache, armazenadas pelo fluxo de autenticação.

5.      Caso o usuário esteja autorizado, a ação é executada sob o recurso. Caso contrário, o usuário é notificado que a solicitação de acesso foi negada.

O servidor RASEA, elemento central da arquitetura, é também uma aplicação que requer o controle de acesso às suas funcionalidades. Este requisito possui caráter recursivo, visto que o servidor acessa os seus próprios serviços para garantir o controle de acesso a si mesmo, caracterizando-o como uma aplicação parceira. A Figura 20 ilustra o agente acoplado ao servidor “B” acessando os serviços “D” por meio da conexão “C”. Percebe-se que a estrutura do servidor “B” é a mesma adotada pelas aplicações parceiras “A”. Esta técnica é conhecida como bootstrapping, onde o processo é executado sem auxílio externo (DAVISON; HINKLEY, 1997).

Figura 20 – Bootstrapping no RASEA

Existe no mercado uma grande variedade de tecnologias e linguagens de programação. Deve-se construir um agente para cada tecnologia que pretenda utilizar o RASEA. O projeto RASEA está aberto à colaboração da comunidade para a criação de novos agentes, seguindo o modelo Bazaar proposto por Raymond (2001). Durante o desenvolvimento do projeto, diversos codificadores e arquitetos contribuíram para a evolução do RASEA.

Servidor

O servidor é o ponto central da arquitetura RASEA, responsável por: i) implementar o modelo RBAC; ii) prover serviços por meio de WebServices; iii) integrar com dados legados da organização e; iv) disponibilizar interface gráfica para gerenciamento do controle de acesso. A Figura 17 destaca o servidor “A” interagindo com elementos essenciais para o seu funcionamento. O item “B” representa a interface para gerenciamento do controle de acesso às aplicações parceiras cadastradas no RASEA. Os itens “C” e “D” representam os serviços providos para aplicações parceiras ou autônomas.

Figura 17 – Arquitetura do servidor RASEA

Todas as informações fornecidas pelos serviços do RASEA têm sempre como fonte duas bases de dados: i) base de autorização, que implementa o modelo RBAC e; ii) base de autenticação, que contém as credenciais dos usuários. A base de autorização é mantida única e exclusivamente pelo servidor RASEA, sendo possível efetuar modificações nos dados através de telas de cadastro ou via serviços de gerenciamento. A base de autenticação, ou base legada de credenciais de usuários, deve ser parametrizada no arquivo de configuração do servidor. É recomendado que esta base (autenticação) seja mantida pela organização, por tratar de dados compartilhados entre diversos sistemas.

As telas que compõem a interface gráfica com os usuários (GUI) devem ser restritas aos administradores de acesso da organização. Segue a baixo as funcionalidades disponíveis via GUI no servidor RASEA:

·         Cadastro de aplicações – Possibilita a inclusão, alteração e exclusão de aplicações parceiras que serão controladas pelo RASEA.

·         Cadastro de operações – Após o cadastro de uma aplicação parceira, é preciso informar quais as operações (ou ações) fazem parte do seu controle de acesso. Esta funcionalidade contempla a inclusão, alteração e exclusão das operações de uma determinada aplicação parceira.

·         Cadastro de recursos – Os usuários executam operações sobre os recursos de uma aplicação parceira. Esta funcionalidade prever a inclusão, alteração e exclusão dos recursos de uma aplicação parceira, bem como a associação com as operações que podem ser executadas sobre o recurso (ou permissões).

·         Cadastro de usuários – Possibilita a manipulação dos dados legados da organização, possibilitando a inclusão, alteração e exclusão de usuários e suas credenciais.

·         Cadastro de papéis – Provê a inclusão, alteração e exclusão de papéis (ou grupos de usuários) de uma aplicação parceira, bem como a associação dos usuários aos papéis.

·         Concessão de autorização – Tendo efetuado o cadastro da aplicação parceira, suas ações, recursos, permissões e papéis; é possível conceder ou revogar acesso ao sistema. A concessão da autorização é a associação de uma permissão (recurso × operação) a um papel.

·         Configurações – Exibe as parametrizações do servidor definidas no arquivo de configuração. Também possibilita a seleção de idioma das telas do servidor RASEA.

Como resposta ao modelo descentralizado, a arquitetura proposta concentra todas as funcionalidades e serviços necessários em um único elemento do modelo: o servidor RASEA. Todas as aplicações parceiras dependem dos serviços para executar tarefas de controle de acesso, portanto é fundamental que o servidor possua: i) alta disponibilidade; ii) performance e; iii) escalabilidade. Enquanto a alta disponibilidade assegura o atendimento às requisições dos agentes, a performance garante a execução em tempo hábil, evitando impactos no negócio da organização (KERN, 2004, p. 90, tradução nossa). A estrutura deve ser escalável, possibilitando o crescimento sem prejuízos à alta disponibilidade e performance da solução.

Figura 18 – Balanceamento de carga

Para garantir a alta disponibilidade, performance e escalabilidade, recomenda-se o uso de cluster com balanceamento de carga no servidor RASEA, conforme ilustrado na Figura 18. O elemento “A” representa aplicações parceiras acopladas aos agentes, que acessam os serviços do RASEA. O balanceador de carga “B” intercepta as chamadas dos agentes e decide, com base em uma heurística, qual o servidor atenderá as requisições. Os itens “C”, “D” e “E” ilustram os servidores RASEA, responsáveis por tratar as requisições redirecionadas pelo balanceador de carga. Cada servidor é um nó que compõe o cluster. A sessão de cada nó é replicada no cluster, garantindo o remanejamento de servidores sem interrupções no serviço.

Integração

O RASEA não pretende substituir tecnologias, arquiteturas, aplicações ou fontes de informação existentes na organização, e sim possibilitar a integração com o legado utilizando padrões abertos. Os problemas de integração (ANAYA; ORTIZ, 2005, p. 27) são analisados e tratados sob três pontos de vista: i) aplicação; ii) informação e; iii) tecnologia. Os pontos de integração foram avaliados com base no modelo Enterprise Application Integration (EAI).

A interação com aplicações pode acontecer de duas formas: i) comunicação com aplicações parceiras ou; ii) autônomas. A interoperabilidade entre o servidor RASEA e as aplicações, sejam elas parceiras ou autônomas, ocorre mediante o uso de Web Services. A Figura 15 destaca a integração entre as aplicações autônomas “B” por meio dos serviços de gerenciamento “A”, que possibilitam que sistemas legados interajam ativamente com o servidor RASEA manipulando informações e modificando seu comportamento. Em conformidade com EAI, este nível de integração é conhecido como Wrapper de Legado (CUMMINS, 2002, p. 317).

Figura 15 –  Integração com o serviço de gerenciamento

Além da integração com os serviços, o RASEA possibilita a conexão com repositórios de credenciais de usuários. Como exemplo tem-se o Lightweight Directory Access Protocol (LDAP), adotado por diversas organizações com o propósito de unificar o armazenamento e centralizar a autenticação dos usuários. A Figura 16 ilustra a integração entre o servidor “A” e a base de usuários legada “B”. A estratégia de armazenamento das credenciais deve ser definida no arquivo de configuração do servidor, representada pelos itens “C”, “D” e “E”. Para garantir a extensibilidade da solução, o RASEA permite que novas estratégias “F” sejam plugadas, atendendo às necessidades específicas que possam ocorrer.

Figura 16 – Integração com base de usuários legada

É extremamente recomendável que todos os níveis de integração – desde o Banco de Dados Compartilhado (CUMMINS, 2002, p. 316) até o Wrapper – estabeleçam conexões seguras pra garantir integridade, autenticidade e confidencialidades da informação. A integração entre as aplicações e os serviços RASEA deve empregar o HyperText Transfer Protocol Secure (HTTPS), utilizado por instituições financeiras para efetuar transações via Internet. A conexão com a base de credenciais deve utilizar dutos criptografados, tal como o Secure LDAP (LDAPS). Não faz parte do escopo desde trabalho detalhar protocolos e técnicas de segurança.

Integrar soluções existentes ao invés de reinventá-las. Essa característica está evidenciada nos agentes RASEA, que se beneficiam de diversas tecnologias para desempenhar o seu trabalho, encaixando-as como peças de quebra-cabeça. Todos os detalhes sobre os agentes serão explicitados no tópico “3.6 Agente” (p. 41).