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