RASEA - cRoss-plAtform accesS control for Enterprise Applications

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

2010-01-17T14:52:00.007-03:00

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.

2009-11-10T07:42:00.008-03:00

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

2009-05-21T19:22:00.021-03:00

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

2009-05-16T16:50:00.005-03:00

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

2009-05-08T09:22:00.002-03:00

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

2009-04-25T09:50:00.004-03:00

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

2009-04-25T09:41:00.007-03:00

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).

Independência de plataforma

2009-03-14T17:31:00.002-03:00

Uma das premissas do RASEA é garantir a operabilidade com aplicações parceiras em diferentes plataformas. Para garantir a independência de plataforma, optou-se por duas estratégias: i) basear-se no Platform-Independent Model (PIM) (IBM, 2009); e ii) empregar WebServices no canal de comunicação. De acordo comLi e Karp (2007, p. 9, tradução nossa), os padrões abertos, adotados pela especificação WebServices, “removem muitas dependências, [...] tornando fácil o desenvolvimento de componentes independentes [de tecnologias]”.

A Figura 13 destaca a utilização de padrões abertos na conexão entre o servidor “C” e os agentes. O item “A” representa um conjunto de aplicações parceiras, acopladas aos seus motores de especialização (IBM, 2009): os agentes RASEA. Cada aplicação parceira possui sua respectiva base de dados “B”, que armazena informações relativas ao negócio. Os dados de controle de acesso “D” e credenciais dos usuários “E” são mantidos pelo servidor RASEA, abstraindo todos os detalhes técnicos para as aplicações parceiras. As informações das bases “D” e “E” são transferidas para os agentes exclusivamente por meio de WebServices via SOAP, assegurando a independência de plataforma.

Figura 13 – Comunicação utilizando padrões abertos

Na solução RASEA, os serviços foram projetados com base na técnica sugerida por Jones (2006, p. 9), respondendo as seguintes perguntas: “o quê?”, “quem?”, “por quê [ou para quê]?” e “como [ou quando]?”. Os serviços foram agrupados em dois EndPoints: controle de acesso e gerenciamento. O EndPoint de controle de acesso contém serviços consumidos pelos agentes e provê informações para o efetivo controle de acesso. O consumo deste EndPoint ocorre no processo de autenticação e verificação de autorização. O EndPoint de gerenciamento reúne os serviços de administração do servidor RASEA, acessados por aplicações (parceiras ou autônomas) que necessitam modificar informações do servidor. Não existe uma periodicidade definida para o acesso a este EndPoint.

Considerando que “todos os serviços [devem ser] autônomos” (PAPAZOGLOU; HEUVEL, 2007, p. 390) e estar em conformidade com a especificação funcional do RBAC (FERRAIOLO, 2001, p. 242–243), segue a especificação dos serviços do EndPoint de controle de acesso:

· assignedRoles(application, user): role[] – Retorna a listagem contendo todos os papéis que o usuário possui em uma determinada aplicação. Caso a aplicação ou o usuário informado não exista, retorna uma listagem nula.

· assignedUsers(application, role): user[] – Retorna a listagem contendo todos os usuários que possuem o papel em uma determinada aplicação. Caso a aplicação ou o papel informado não exista, retorna uma listagem nula.

· roleOperationsOnResource(application, role, resource): operation[] – Verifica e retorna todas as operações que um papel pode executar sobre um determinado recurso de uma aplicação. Caso a aplicação, o papel ou o recurso informado não exista, retorna uma listagem nula.

· rolePermissions(application, role): permission[] – Provê a listagem das permissões autorizadas ao papel em uma determinada aplicação. Uma permissão é composta pelo par “operação × recurso” (Barker, 2008, p. 144). Caso a aplicação ou o papel informado não exista, retorna uma listagem nula.

· userOperationsOnResource(application, user, resource): operation[] – Verifica e retorna todas as operações que um usuário pode executar sobre um determinado recurso de uma aplicação. A verificação é feita com base nos papéis associados ao usuário. Caso a aplicação, o papel ou o recurso informado não exista, retorna uma listagem nula.

· userPermissions(application, user): permission[] – Provê a listagem das permissões autorizadas ao usuário em uma determinada aplicação. A verificação é feita com base nos papéis associados ao usuário. Uma permissão é composta pelo par “operação × recurso” (Barker, 2008, p. 144). Caso a aplicação ou o usuário informado não exista, retorna uma listagem nula.

· authenticate (username, password): boolean – Executa o processo de autenticação do usuário tomando como base o seu nome e senha. Este serviço retorna um valor verdadeiro em caso de sucesso, ou falso caso ocorra falha no processo de autenticação. Este serviço não é exigido pelo padrão RBAC.

· userDetail (username): user – Obtém as credenciais do usuário com base no seu nome. Se o usuário existir, retorna um objeto contendo as suas credenciais; caso contrário, retorna um objeto nulo. Este serviço não é exigido pelo padrão RBAC.

Ao contrário do EndPoint de controle de acesso, o EndPoint de gerenciamento provê operações de modificação de dados no servidor. Em concordância ao padrão RBAC e aos conceitos SOA, segue a especificação dos serviços de gerenciamento:

· addUser(user) – Adiciona um novo usuário na base centralizada de usuários. Caso o usuário já exista ou ocorra alguma falha na validação dos dados, uma notificação de erro será emitida.

· deleteUser(user) – Remove um usuário existente da base centralizada de usuários. Caso ocorra alguma falha durante o processo, uma notificação de erro será emitida.

· assignUser(application, user, role) – Atribui o usuário ao papel de uma aplicação. Caso ocorra falha durante o processo de associação, uma notificação de erro será emitida.

· deassignUser(application, user, role) – Desassocia o usuário ao papel de uma aplicação. Caso ocorra falha durante o processo, uma notificação de erro será emitida.

· changePassword(username, oldPassword, newPassword) – Efetua a modificação da senha do usuário. Caso ocorra alguma falha na validação dos dados, uma notificação de erro será emitida. Este serviço não é exigido pelo padrão RBAC.

· addRole(application, role) – Adiciona um novo papel em uma aplicação. Caso o papel já exista ou ocorra alguma falha na validação dos dados, uma notificação de erro será emitida.

· deleteRole(application, role) – Remove um papel existente de uma determinada aplicação. Caso ocorra alguma falha durante o processo, uma notificação de erro será emitida.

· grantPermission(application, permission, role, allowed) – Concede permissão ao papel para executar uma operação sob um determinado recurso da aplicação. Uma autorização pode ser positiva ou negativa (BERTINO, 2001, p. 42). Caso ocorra falha na validação dos dados, uma notificação de erro será emitida.

· revokePermission(application, permission, role) – Remove a permissão de um papel a um recurso do sistema. Uma permissão é composta pelo par “operação × recurso” (Barker, 2008, p. 144). Caso ocorra falha na validação dos dados, uma notificação de erro será emitida.

Todos os serviços foram adaptados para suportar o controle de acesso aos múltiplos sistemas da organização, acrescentando-se o parâmetro “application”. Este assunto já foi discutido nos capítulos “2.2 RBAC” (p. 16) e “3.2 Modelo de dados” (p. 26).

RBAC

2009-03-10T23:31:00.005-03:00

A sigla RBAC, do inglês Role-Based Access Control, significa controle de acesso baseado em papéis. Um papel é um grupo de usuários de uma organização, que reúne pessoas do mesmo cargo, função, responsabilidade, atividade ou outro critério de categorização. Para o RBAC, segundo Sandhu, Ferraiolo e Kuhn (2000, s. 1, tradução nossa), este conceito possibilita “estabelecer permissões baseadas em papéis funcionais da organização e [...] associar usuários a um ou mais papéis”. A abordagem orientada a papéis é o diferencial do modelo RBAC em relação aos seus antecessores Mandatory Access Control (MAC) e Discretionary Access Control (DAC).

Por mais de 30 anos, o conceito de papéis é empregado em sistemas informatizados, contudo apenas em meados da década de 1990 atingiu a maturidade (FERRAIOLO, 2001, s. 1.1). O modelo RBAC é considerado mais adequado que o MAC e DAC para utilização em ambientes empresariais (BEZNOSOV; DENG, 1999, p. 19). O MAC garante o controle de acesso de acordo com rótulos de segurança aplicados a cada usuário, enquanto o DAC baseia-se na concessão de permissões por usuário (SANDHU, 1996, p. 4). Os modelos MAC e DAC enfocam no usuário e não no seu papel funcional, dificultando o gerenciamento das políticas de segurança. De acordo com Beznosov e Deng (1999, s. 1, tradução nossa), “o maior propósito do RBAC é facilitar a administração [...] do controle de acesso”.

Por oferecer redução de complexidade, contenção de custos e diminuição de erros na concessão de permissões, a demanda pelo RBAC aumentou, incorporando produtos como: bancos de dados, sistemas operacionais e gerenciamento de sistemas. Devido à diversidade de padrões RBAC, o National Institute of Standards and Technology (NIST) consolidou as idéias em um único modelo (SANDHU; FERRAIOLO; KUHN, 2000, s. 1). A arquitetura do projeto RASEA tem como base o padrão RBAC do NIST, doravante referenciado apenas como RBAC.

Figura 6 – Relacionamento RBAC (WANG, 2006, s.1, adaptado)

Na Figura 6, Wang (2006) apresenta o relacionamento entre os elementos do modelo RBAC (SANDHU; FERRAIOLO; KUHN, 2000, p. 232), onde o item “object” simboliza um “[...] recurso do sistema sob proteção” (KERN, 2004, p. 91, tradução nossa). O elemento “operation” representa as ações que podem ser executadas pelos usuários autenticados. Quando as ações são associadas aos recursos, originam-se as “permissions”. Os usuários “users” fazem parte das “roles”, que por sua vez são compostas por usuários. Esta associação é representada pelo relacionamento “user-role assignment”. A concessão de permissões às “roles”, também conhecida como autorização, é definida pelo elemento “permission-role assignment”.

O padrão RBAC é composto por componentes que abordam o modelo de referência e a especificação funcional. O modelo de referência estabelece rigorosamente os elementos RBAC e seus relacionamentos, enquanto a especificação funcional define as operações suportadas pelo RBAC. Dentre os quatro componentes RBAC, este trabalho se concentrará em dois: o Core RBAC e o Hierarchical RBAC. (FERRAIOLO, 2001, s. 2)

O componente Core RBAC fundamenta-se no conceito básico do RBAC, que, conforme Ferraiolo (2001, s. 2.1, tradução nossa), é o seguinte: “usuários são associados aos papéis, permissões são associadas aos papéis, e usuários adquirem permissões por serem membros dos papéis”. O Core RBAC estabelece que a relação entre as entidades usuário e papel necessita ser do tipo muitos para muitos. Além disso, deve ser possível associar usuários aos papéis e vice-versa. Da mesma forma, a relação entre papéis e permissões deve ser do tipo vários para vários. (FERRAIOLO, 2001)

O Hierarchical RBAC acrescenta ao Core RBAC o conceito de hierarquia de grupos, onde um papel pode herdar as autorizações de outro papel (SANDHU; FERRAIOLO; KUHN, 2000, s. 2.2). Supondo a existência de um grupo denominado “Gerência”, o qual possui determinados privilégios que devem ser aplicados para todas as gerências da organização. Neste caso, basta que a “Gerência de Recursos Humanos” herde de “Gerência” para que todas as permissões sejam atribuídas à Gerência de Recursos Humanos.

Como o modelo RBAC não menciona o controle de múltiplos sistemas, Kern (2004, p. 93, tradução nossa) propôs o modelo Enterprise RBAC (ERBAC) que permite a “[...] administração de usuários e seus direitos de acesso de todos os sistemas [...] de uma organização”. A arquitetura do projeto RASEA utiliza o padrão RBAC, acrescentando o elemento “sistema” almejando a o controle de acesso a várias aplicações comerciais simultaneamente.

Modelo de dados do RASEA

2009-02-27T23:01:00.005-03:00

A representação dos dados mantidos pelo RASEA advém em dois diagramas: entidade-relacionamento e classes de domínio. O diagrama de entidade-relacionamento apresenta uma abordagem relacional dos dados persistidos, enquanto o diagrama de classes de domínio utiliza a Unified Modeling Language (UML). De acordo com Eden e Kazman (2003, s. 7.2), a “UML é amplamente utilizada como notação [...] de arquitetura”. Os diagramas estão de acordo com a definição do padrão RBAC (FERRAIOLO, 2001, p. 232) acrescendo-se a entidade “Application” para suportar o controle de acesso às aplicações comerciais, conforme a proposta de Kern (2004, p. 93).

A Figura 11 apresenta o Diagrama Físico de Entidade-relacionamento (DER), onde é possível observar os elementos do RBAC. A entidade “OBJECT” representa um recurso que está sob controle de acesso. As operações “OPERATION” são associadas aos recursos, dando origem à entidade “PERMISSION”. As permissões podem ser associadas aos grupos de usuário, ilustrada pela entidade “PERMISSION_ASSIGNMENT”. Os grupos de usuários, também conhecidos como papéis, são representados por “ROLE”. Um papel agrupa usuários “USER” a partir da associação “USER_ASSIGNMENT”.

Figura 11 – Diagrama Físico de Entidade-relacionamento do RASEA

A relação “USER x USER_ASSIGNMENT” – na Figura 11 – é lógica, por conta disto não pôde ser visualizada no modelo físico. A decisão por manter a relação lógica está fundamentada na integração com bases de usuários legadas. Na prática, a tabela “USER” é opcional, podendo ser utilizada por organizações que não possuem uma base de usuários centralizada. A base para controle de acesso é constituída por todas as entidades, exceto pela tabela “USER”.

Uma aplicação “APPLICATION”, na Figura 11, é formada por recursos “OBJECT”. Cada aplicação possui suas próprias operações “OPERATION” e grupos de usuários “ROLE”. Assim é possível que, por exemplo, o papel “P” da aplicação “A1” seja composto por usuários distintos do papel “P” da aplicação “A2”. Ou seja, “P (A1) ? P (A2)”.

Figura 12 – Diagrama Lógico de Classes de Domínio do RASEA

O Diagrama de Classes de Domínio, ilustrado na Figura 12, representa a visão lógica do padrão RBAC utilizando UML (RAY, 2004). Por se tratar de uma percepção orientada a objetos, algumas entidades relacionais sofreram adaptações na sua nomenclatura, aproximando-se mais da realidade. A associação “PERMISSION_ASSIGNMENT” é representada pela classe “Authorization”. A entidade “OBJECT” ganhou o nome “Resource”, por ser mais intuitivo. A associação “USER_ASSIGNMENT” é representada pela classe “Member”. No modelo lógico é possível observar a relação “Member x User”, inexistente no modelo físico.

Arquitetura RASEA

2009-02-26T07:43:00.008-03:00

A Arquitetura de Software auxilia na identificação dos componentes e seus “relacionamentos de alto nível” (SHAW; GARLAN, 1994), facilitando o entendimento da solução como um todo. O projeto RASEA fundamenta sua arquitetura sob quatro perspectivas para assegurar o controle de acesso cross-plataforma às aplicações comerciais, que, conforme a Figura 9, são: independência de plataforma, integração, servidor e agente.

Figura 9 – Perspectivas da arquitetura RASEA

Cada perspectiva funciona como uma peça de quebra-cabeça, completando o modelo com o encaixe perfeito de todos os elementos. O componente “independência de plataforma” agrega padrões, paradigmas e tecnologias, possibilitando que aplicações comerciais em diferentes tecnologias beneficiem-se com a solução proposta. O elemento “integração” permite que o RASEA utilize dados legados da organização e que as aplicações consumam os serviços providos pelo RASEA. Enquanto a perspectiva “servidor” preocupa-se com serviços e disponibilidade, o “agente” aborda aspectos das plataformas das aplicações. Tais elementos serão tratados em detalhes mais à diante.

Figura 10 – Visão geral da arquitetura RASEA

De acordo com Kruchten (1995), a arquitetura define os componentes, suas conexões e relacionamentos, conforme ilustrado na Figura 10. O elemento “A” representa o servidor, o qual disponibiliza telas “B” para que o administrador do acesso “C” gerencie as permissões e autorizações dos sistemas. O servidor também provê serviços “D” agrupados em dois EndPoints: controle de acesso e gerenciamento. Os serviços para controle de acesso respaldam os agentes com informações suficientes para executar o seu trabalho. Os agentes são conectados às aplicações, a exemplo de “E” e “F”, denominadas aplicações parceiras. As aplicações que não utilizam o controle de acesso do RASEA são chamadas de aplicações autônomas, que podem acessar os serviços de gerenciamento, caso desejem.

Ainda na Figura 10, o servidor “A” mantém a base de dados “H”, que contém informações estruturadas nos moldes do padrão RBAC, possibilitando o controle de acesso às aplicações comerciais. A base de dados “I” detém credenciais dos usuários da organização, geralmente mantidas em um Lightweight Directory Access Protocol (LDAP). O servidor “A” acessa a base de dados legada “I” para verificar a autenticidade dos usuários. Almejando a flexibilidade da solução, o servidor “A” pode ser parametrizado a partir de um arquivo de configuração “J”.

Objetivando a padronização de vocabulário, segue a relação dos os elementos envolvidos na arquitetura RASEA e suas respectivas descrições, conforme Eden e Kazman (2003, s. 1 apud SHAW; GARLAN, 1996):

Credenciais de usuário: dados dos usuários da organização, tais como: nome, senha, e-mail, etc.
Base de dados: repositório com dados persistidos estruturadamente com base no padrão RBAC, sendo dividido em dois domínios: dados para controle de acesso e credenciais de usuários.
Servidor: principal elemento da arquitetura, responsável por centralizar o controle de acesso, manter a conexão com as bases de dados e prover telas e serviços.
Telas: interface gráfica com o usuário, também conhecida como GUI (do inglês Graphical User Interface), que possibilita o gerenciamento das permissões e autorizações das aplicações.
Serviços de controle de acesso: agrupamento de serviços (ou EndPoint) consumido pelos agentes. Disponibilizam informações necessárias para controle de acesso.
Serviços de gerenciamento: agrupamento de serviços (ou EndPoint) acessado por consumidores que desejem gerenciar o servidor RASEA.
Agente: elemento da arquitetura responsável por interceptar e analisar as requisições às aplicações, liberando ou revogando o acesso com base nas informações obtidas no serviço de controle de acesso.
Aplicação parceira: é toda aplicação conectada a um agente, que utiliza o servidor RASEA como dispositivo de controle de acesso centralizado. As aplicações parceiras podem, adicionalmente, consumir os serviços de gerenciamento.
Aplicação autônoma: é toda aplicação não está conectada a um agente e que, conseqüentemente, não utiliza o RASEA como dispositivo de controle de acesso centralizado. As aplicações autônomas podem consumir os serviços de gerenciamento, caso necessitem.
Container: representa um Servidor de Aplicação ou Servidor WEB que hospeda as aplicações.

Nos próximos tópicos, cada uma das perspectivas da arquitetura (independência de plataforma, integração, servidor e agente) será abordada em detalhes. Para tanto, serão considerados requisitos de performance, disponibilidade, concorrência, distribuição e tolerância à falhas, assuntos imprescindíveis para a definição da arquitetura do software (KRUCHTEN, 1995). Porém, faz-se necessário conhecer a estrutura dos dados mantidos pelo RASEA, tratada a seguir.

Autenticação, autorização e controle de acesso

2009-01-29T22:10:00.005-03:00

É comum que pessoas não habituadas com o assunto confundam os termos “autenticação” e “autorização”. Resumidamente, a autenticação enfoca na identificação, enquanto a autorização define o que é possível fazer. Para controlar o acesso a um recurso é preciso que haja a identificação do indivíduo (autenticação) e a possibilidade de acessar o que se deseja (autorização), permitindo ou revogando a solicitação. Basicamente, estas são as diferenças entre autenticação, autorização e controle de acesso.

De acordo com Silva (2004, p. 66), “autenticação é a capacidade de garantir que alguém, ou alguma coisa, é de fato quem diz ser, dentro de um contexto definido”. Existem diversas técnicas e tecnologias que auxiliam neste processo, tais como: biometria, OpenID (OPENID, 2007), Certificado Digital, Single Sign-On. Não faz parte do escopo deste projeto tratar detalhadamente sobre autenticação, e sim focar na autorização e no controle de acesso.

Garantir a confidencialidade da informação é uma necessidade latente nas aplicações comercias, por isso somente usuários autorizados devem ter acesso ao sistema. Assegurar a autorização significa que ninguém poderá executar ações sobre um recurso caso não tenha permissão (JAAS, 2001). Segundo Barker (2008, p. 144, tradução nossa) “[...] permissão é um par (‘A’, ‘R’), onde ‘A’ é uma ação e ‘R’ é um recurso, e uma autorização é uma permissão associada a um determinado usuário”. Alguns autores, tais como Sandhu, Ferraiolo e Kuhn (2000), utilizam o termo “operações” para referenciar às “ações”.

A figura ilustra a funcionalidade de um sistema operacional para concessão de permissões de grupos de usuários (papéis) de uma organização. O item “A” representa um recurso: uma pasta ou um arquivo. Na solução apresentada neste trabalho, um recurso simboliza uma tela ou um relatório de uma aplicação comercial, por exemplo. O elemento “B” representa os grupos que tem permissão para acessar o recurso “A”. As operações ou ações que podem ser executadas em “A” são ilustradas pelo item “C”. A associação entre a operação “C” e o recurso “A”, atribuída ao grupo de usuários “B”, representa uma autorização “D”.

Controle de permissões do Microsoft Windows

A definição de controle de acesso segundo a norma internacional ISO/IEC 10181-3 (1996, p. 1, tradução nossa), que trata sobre framework para controle de acesso, é a seguinte: “o processo de determinar quais utilizações dos recursos [...] são permitidas, [...] prevenindo o acesso não autorizado, é chamado de controle de acesso”. Com base neste conceito, este trabalho assume que o controle de acesso de uma aplicação comercial abrange desde o estabelecimento das permissões até o processo de verificação das requisições. Conforme Barker (2008, tradução nossa), “a maioria dos modelos de controle de acesso assume que uma requisição é feita por um usuário pré-autenticado para realizar uma ação [...] em um recurso do sistema”.

A regra para garantir o controle proposto neste trabalho segue a “premissa ‘tudo é proibido, a menos que expressamente permitido’ em lugar da regra mais fraca ‘tudo é permitido, a menos que expressamente proibido’” (ISO/IEC 17799, 2005, p. 66). Desta forma, o usuário somente terá acesso ao recurso caso o administrador de segurança autorize-o explicitamente, assegurando a confidencialidade necessária para as informações mantidas por uma aplicação comercial.

Autorizações podem ser concedidas ou negadas aos usuários. Esta característica é também conhecida como autorizações positivas ou negativas (BERTINO, 2001, p. 42). Suponha um usuário participante do grupo “gerentes” (positivamente autorizado ao recurso “X”) que, simultaneamente, faz parte do grupo “hackers” (negativamente autorizado ao recurso “X”). Caso este usuário tente acessar “X”, a proibição prevalecerá sobre a concessão e a requisição será recusada.

JAX-WS no Rasea

2009-01-16T15:34:00.025-03:00

JAX-WS é uma API que veio para substituir o antigo JAX-RPC (veja comparativo aqui). E para ficar dentro dos padrões e das especificações JEE, o Rasea Server usa como API de webservices o JAX-WS em sessions stateless EJB3.

Para o lado cliente, esta API fornece alguns modelos de consumo de serviços, sendo o consumo via proxy escolhido por nós do Rasea. Para consumir um serviço via classes proxy, é necessário executar o comando wsimport (via ant task ou linha de comando) para que sejam geradas as classes do serviço e os tipos usados.

wsimport http://localhost:8001/rasea-ws/AccessControl?wsdl

Excelente! Porém, o código da classe Service gerada instancía uma java.net.URL - num bloco static - para este caminho, além de estabelecer uma conexão a cada comunicação para o parse do WSDL em questão. Logo, podemos enumerar 2 problemas:

Web service endpoint. Enpoint statico nas classes client;
Wsdl location. Consumo de recursos - de rede - para fazer o parse do wsdl que se encontra no server.

Certamente o local do WSDL, bem como enpoint do serviço em uma companhia não coincidirão com os locais de WSDL e Web service enpoint de desenvolvimento do Rasea.

Como apresentado no post anterior, a companhia pode, e até recomenda-se, fazer uso de um barramento de serviços, logo é necessário que o usuário possa informar o endpoint correto. Por isso, o Rasea Client usa um arquivo de propriedades para configurar o servidor onde o serviço ficará de fato deployado.

Para o primeiro problema, decidimos embarcar o WSDL no próprio jar das classes client, o que evita o consumo de rede para alcancá-lo. Então foi necessário criar um xml de catalog JAX-WS que descreve um nome para o wsdl e um local alcançável a partir da pasta META-INF do jar.

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="system">

<system systemId="http://rasea.org/wsdl/AccessControl"
uri="../AccessControl.wsdl"/>
</catalog>
<!-- https://glassfish.dev.java.net/public/CDDL+GPL.html -->

Note que o WSDL vai ficar na pasta raiz do jar. Mas para as classes client "entenderem" esta decisão nossa, precisamos de uns parâmetros a mais no wsimport.

wsimport -catalog ws/jax-ws-catalog.xml -wsdllocation
http://rasea.org/wsdl/AccessControl AccessControl.wsdl

É necessário informar o arquivo de catalog (que deve ser colocado na pasta META-INF do jar) e o local do wsdl (que será anotado na classe de serviço). Por último fornecemos o wsdl acessado localmente.

Como resultado temos:

@WebServiceClient(name = "AccessControlService", targetNamespace =
"http://rasea.org/ws/AccessControl", wsdlLocation = "http://rasea.org/wsdl/AccessControl")
public class AccessControlService
extends Service
{
...
}

Nos falta um meio de informar à esta classe, em tempo de execução, a localização correta do endpoint do serviço. A a interface javax.xml.ws.BindingProvider fornece um contexto de requisição através do método .getRequestContext() retornando um Map, eque é onde devemos informar o endpoint do seviço.

AccessControlService service = new AccessControlService();
AccessControl port = service.getAccessControlPort();
BindingProvider bindingProvider = (BindingProvider) port;

Map<String, Object> requestContext = bindingProvider.getRequestContext();

requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, 
http://myserver:7001/rasea-ws/AccessControl);

Este trecho substitui o endpoint original provindo do WSDL do serviço permitindo que o client se conecte ao endpoint correto.

Pronto! Agora você pode deployar seu jar com os clients em qualquer lugar sem a necessida de acessar a rede constatemente para obter o WSDL do serviço e sem usar estaticamente um endpoint para acessar o serviço. Você pode ver a aplicação completa destas duas dicas no código fonte do Rasea Client.

Outra informação é que ao utilizar @WebServiceRef num session EJB, alguns servidores (ex.: BEA Weblogic Server) não conseguem fazer o deploy da aplicação quando os WSDLs dos serviços não sejam alcançáveis durante o deploy. Ou seja, se seus provedores de serviço estiverem indisponíveis, sua aplicação pode não ser publicada até que estes serviços voltem a funcionar.

Daí a importância de adotar uma política adequada na localização do WSDL e definição do endpoint não estaticamente.

Até a próxima!

Rasea e SOA - Parte I

2009-01-05T08:53:00.016-03:00

SOA considera serviços como cidadãos de primeira classe. A motivação para o emprego de serviços como building blocks de software reutilizáveis é a possibilidade de construir novas aplicações mais rapidamente e, consequentemente, atender o negócio com mais eficácia.

A arquitetura SOA recomendada por grandes players do mercado SOA/EAI categoriza serviços em camadas de acordo com suas responsabilidades. A figura a seguir apresenta uma arquitetura SOA básica.

Num cenário SOA, é necessário a disponibilização de uma camada de infraestrutura que permita a habilitação de funcionalidades corporativas existentes como serviço, assim como as novas funcionalidades. Esta camada é conhecida como facilitadora, ou de suporte, e nela residem serviços comumente independentes de contexto de negócio.

Rasea se enquadra nesta categoria focando na autorização de acesso a qualquer recurso corporativo, incluindo serviços corporativos de qualquer camada. Sobre SOA Security, o Rasea atende os seguintes requisitos básicos desta disciplina:

Integração com a infraestrutura de usuários existente na corporação;
Gerenciamento centralizado de papéis, usuários e aplicações;
Prover autenticação e autorização.

Rasea oferece estas funcionalidades através de um conjunto de serviços que permite que Rasea Agentes e clientes independentes de tecnologia façam asserções de segurança no diretório de usuários e recursos da corporação.

Webservices é a tecnologia comumente eleita na implantação SOA devido a sua natureza padronizada e bem conhecida pelo mercado, o que motivou a construção do framework utilizando uma abordagem orientada a serviços.

É possível construir, pelo menos, os seguintes cenários de serviços de segurança providos pelo Rasea dentro da arquitetura SOA:

Os serviços Rasea podem ser expostos diretamente no barramento de serviços da corporação (ESB - Enterprise Service Bus) para o consumo de Rasea Agents e outros consumidores;
O barramento pode fazer uso internamente das funcionalidades Rasea no controle das requisições aos serviços nele publicados.
Provedores de serviço podem utilizar os serviços Rasea publicado no ESB, numa abordagem de segurança end-to-end.

Nas partes seguintes deste post, serão apresentados com mais detalhe dois dos principais serviços fornecidos pelo Rasea, Rasea Access Control Service e Rasea Management Service. Em posts futuros apresentaremos a empregabilidade do framework em conjunto com um barramento de serviços.

Modelo Independente de Plataforma

2008-12-26T00:12:00.028-03:00

É 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?

Figura 1 – Modelo Dependente de Plataforma (não recomendado)

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.

O termo "Modelo Independente de Plataforma" é também conhecido pela sigla PIM (Platform-independent Model). O Rasea é PIM!

O que é Rasea?

2008-12-19T06:07:00.001-03:00

Rasea é algo que nós, profissionais da área de Desenvolvimento de Software, sempre precisamos e nunca tivemos. É um acrônimo do inglês cRoss-plAtform accesS control for Enterprise Applications, que pode ser traduzido como controle de acesso cross-plataforma para aplicações comerciais. O objetivo do Rasea é tornar-se uma referência de mercado para controle de acesso às aplicações.

O Rasea é cross-plataforma porque pode ser utilizado por aplicações desenvolvidas em qualquer linguagem de programação que suporte o consumo de WebServices. Assim, durante o desenvolvimento de software, será possível focar nas regras de negócio, deixando o controle de acesso para o Rasea. A solução é simples, existe um servidor e vários clientes que consomem os seus serviços. Os clientes são chamados de agent, e devem ser "encaixados" nas aplicações que querem se beneficiar das vantagens do Rasea, chamadas de aplicações parceiras.

Apesar do Rasea Server ser escrito em Java, utilizando tecnologias de ponta (tais como JSF, JPA, WS), as aplicações parceiras não têm conhecimento disso, o que elas conhecem de fato são os serviços. Para que uma aplicação parceira utilize o Rasea, é preciso conectar o Rasea Agent referente à tecnologia da aplicação (Java, .NET, PHP, ASP). Todas as ferramentas (server e agents) estão em fase de desenvolvimento e, em breve, você poderá se beneficiar de tudo isso, já que o Rasea é um projeto Open-Source publicado no Source Forge, regido pela licensa LGPL.

A equipe que compõe o projeto é formada atualmente por Cleverson Sacramento, Robson Ataíde, Paulo Suzart e Abraão Isvi. Todos os integrantes são ou já foram funcionários da Avansys Tecnologia, onde a idéia se concretizou em um projeto chamado inicialmente de AvanSEG e atualmente conhecido como S4A (Security for Applications). Apesar de tudo, o Rasea é completamente diferente (arquitetura, projeto e implementação), agregando mais poder e flexibilidade à solução. Como estamos dedicando apenas as nossas madrugadas para o desenvolvimento do Rasea, peço que aguardem só mais um pouco que, em breve, o Rasea será disponibilizado!