Servidor
Autor: Cleverson Sacramento | Publicado: 2009-04-25T09:50:00-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 <!--[if supportFields]> REF _Ref224786377 \h <![endif]-->17<!--[if gte mso 9]>  08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200320034003700380036003300370037000000 <![endif]--><!--[if supportFields]><![endif]--> 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 <!--[if supportFields]> SEQ Figura \* ARABIC <![endif]-->17<!--[if supportFields]><![endif]--> – 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 <!--[if supportFields]> SEQ Figura \* ARABIC <![endif]-->18<!--[if supportFields]><![endif]--> – 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 <!--[if supportFields]> REF _Ref224796385 \h <![endif]-->Figura 18<!--[if gte mso 9]>  08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003200320034003700390036003300380035000000 <![endif]--><!--[if supportFields]><![endif]-->. 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.