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

Independência de plataforma

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

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.