O novo FACS consiste de uma aplicação web desenvolvida na linguagem java,
utilizando o Spring Framework6 e várias outras tecnologias. O código fonte pode ser
encontrado no repositório de projetos do IMD7. O sistema de gerenciamento de identidades
utilizado pelo FACS é FIM, ou seja, o FACS foi desenvolvido para ser integrado a uma federação, mais especificamente a CAFe. A integração com federação ocorre por meio do Shibboleth SP. Assim, somente usuários autenticados na federação podem acessar o FACS, desde que tenham permissão para tal. Já o sistema de controle de acesso desenvolvido, consiste do modelo ABAC utilizando XACML.
A interface do PDP do FACS para recebimento de requisições realizadas pelo PEP dos Provedores de Serviços foi implementada na forma de uma API REST. Essa API é formada por um único endpoint, o qual espera requisições na forma de um HTTP POST, cujos dados devem estar no formato JSON (JavaScript Object Notation), um padrão aberto
para representação de dados. A Listagem 4.4apresenta um exemplo de dados enviados em
uma requisição. Conforme pode ser visto, os dados enviados correspondem aos atributos
de um usuário liberados pelo seu IdP, além do entityID8 do IdP e do SP nas linhas 2 e
3. Como um sujeito pode ter mais de um vínculo junto a sua instituição, a entrada que representa os atributos correspondentes as afiliações entre as linhas 8 e 15 é especificada como um arranjo (array). Por fim, o sistema de autorização utilizado na API consiste de um simples mecanismo de fornecimento de token, no qual toda requisição deve vir acompanhada com um cabeçalho HTTP contendo um token gerado a partir da interface do FACS. 1 { 2 "serviceProviderEntityID":"https://cloudstack.imd.ufrn.br", 3 "identityProviderEntityID":"https://idp.imd.ufrn.br/idp/shibboleth", 4 "eduPersonPrincipalName":"alice", 5 "commonName":"Alice", 6 "surname": "Silva", 7 "mail":"alice@imd.ufrn.br", 8 "affiliations": [ 9 { 10 "brEduAffiliation": "2", 11 "brEduAffiliationType":"faculty", 12 "brEntranceDate":"20120215", 13 "brExitDate":"20120215" 14 } 15 ] 6 <https://spring.io/> 7 <https://projetos.imd.ufrn.br/facs/facs>
8 O entityID é um atributo definido na especificação SAML que identifica unicamente Provedores de
16 }
Listagem 4.4 – Exemplo de dados enviados a API do FACS.
A Figura9 apresenta o diagrama de pacotes parcial da aplicação, destacando os
principais pacotes, algumas de suas classes e relacionamentos. Os pacotes foram organizados de forma a agrupar classes com responsabilidades e características semelhantes. As classes do pacote controller são responsáveis por atender requisições HTTP vindas interface web utilizada pelos usuários do sistema. Nesse pacote, a classe UsersController prover serviços que são utilizados pelo administrador do FACS para gerenciar os usuários do sistema. As classes ServiceProvidersController e IdentityProvidersController são utilizadas pelos administradores de Provedores de Identidades e Serviços para configurar os provedores que eles estão autorizados a gerenciar. Já as classes SPDependentPoliciesController e SPIndependentPoliciesController são responsáveis por prover serviços para o gerenciamento de políticas dependentes de SP e políticas independentes de SP, respectivamente.
Figura 9 – Diagrama de Pacotes do FACS.
O pacote security em conjunto com o pacote configuration contém classes responsá- veis por aspectos relacionados a configurações de segurança e autenticação. Nesse pacote, as classes SAMLAuthenticationFilter, SAMLAuthenticationProvider e SAMLAuthenticati- onToken fornecem o sistema de autenticação para uma federação, capturando os atributos liberados por um IdP e iniciando a sessão do usuário, caso esse esteja cadastrado no
sistema. Caso não esteja, como o FACS é aplicado a si mesmo para gerenciar o controle de acesso, seu PEP realiza uma requisição a API do PDP questionando se o usuário com os atributos em questão pode acessar o sistema, liberando o acesso e iniciando a sessão em caso positivo. Já as classes APIAuthenticationFilter, APIAuthenticationProvider e APIAuthenticationToken implementam o mecanismo de autenticação da API. Embora as classes responsáveis pela autenticação em um ambiente federado possuam o prefixo SAML (ex.:SAMLAuthenticationProvider ), a aplicação não lida diretamente com esse padrão. O FACS apenas captura os atributos emitidos por um IdP em uma requisição HTTP, os quais são embutidos em uma sessão do Shibboleth SP.
No pacote service estão várias classes responsáveis por fornecer serviços específicos as demais classes do sistema. Nesse pacote são destacados os sub-pacotes wso2.is e xacml, além da classe PEPService. O pacote wso2.is contém os clientes das interfaces SOAP do PAP (classe WSO2ISEntitlementPolicyAdminServiceClient) e do PDP (classe WSO2ISEntitlementServiceClient) do WSO2 IS. Já o pacote xacml contém várias classes
responsáveis pela manipulação de requisições, respostas e políticas em XACML.
As classes do pacote api são responsáveis pela API do FACS, interface acessada pelo PEP dos provedores de serviço. Nesse pacote é destacada a classe PDPController, responsável por processar as requisições destinadas ao PDP do FACS, formado apenas por um endpoint. No pacote interceptor, a classe PEPInterceptor é responsável por interceptar todas as requisições realizadas pelos usuários do FACS na sua interface e verificar se elas são permitidas. Para tanto, todas as informações necessárias relacionadas ao usuário, ação e recurso que esta sendo acessado são capturadas e enviadas ao a classe PEPService do pacote service para ser feita uma requisição XACML questionando se o acesso do usuário ao recursos para realizar a ação desejada deve ser permitido. Juntas, as classes PEPInterceptor e PEPService implementam o PEP do FACS.
Por fim, o pacote adapter contém as classes relacionadas aos SP Adapters dos Provedores de Serviço. Conforme pode ser visto, são destacadas duas classes referentes ao SP Adapter do FACS (FACSAdapter ) e do CloudStack (CloudStackAdapter ), ambas estendendo da classe abstrata Adapter, que estabelece uma interface comum para todo SPAdapter. A classe AdapterFactory é responsável por fornecer instâncias das classes referentes aos SP Adapters.
Com relação aos perfis definidos, cada um é implementado na forma de uma sequência de validações, restringindo a estrutura, entidades, atributos e valores permitidos em uma política em XACML. Assim, uma vez definida uma política em XACML, seja política independente de SP ou política dependente de SP, a validação é feita da seguinte forma. Primeiro, é verificado se a política está de acordo com especificação do XACML, avaliando a política com relação ao esquema XML da especificação fornecido pela OASIS. Em seguida é verificado se apenas os elementos permitidos no perfil são utilizados. Para
tanto, cada perfil deve fornecer uma versão reduzida do esquema XML da especificação do XACML, removendo a declaração dos elementos que não deseja utilizar, para que a política seja avaliada em relação a esse esquema reduzido. Logo após, é verificado se as entidades, atributos e valores estão de acordo com os especificados no perfil. Para isso, cada perfil deve fornecer o conjunto desses itens na forma de um arquivo XML, conforme o esquema XML criado pelo FACS para tal. Por fim, é realizada a validação da estrutura da política, verificando se apenas os elementos permitidos definidos pelo perfil são utilizados, caso seja definida tal restrição.
Quando uma política de controle de acesso em XACML é definida por um adminis- trador no FACS, todos os passos da validação detalhada anteriormente são realizados pelo próprio FACS, desde que cada perfil forneça os artefatos para tal. Contudo, para políticas dependentes de SP, o último passo, que consiste na verificação da estrutura da política, é feito pelo SP Adapter. Uma vez verificada a validade da política quanto ao perfil, políticas independentes de SP são propagadas para o PAP do WSO2 IS e políticas dependentes de SP são propagadas para o Provedor de Serviço pelo SP Adapter.
Com relação a definição de políticas de controle de acesso, tanto para políticas independentes de SP quanto para políticas dependentes de SP, é necessário impor restrições no momento da definição, principalmente se a capacidade de gerenciamento de controle de acesso for delegada a administradores de Provedores de Identidade. Essas restrições podem estar relacionadas as limitações dos recursos e serviços providos por um Provedor de Serviço ou a aspectos contratuais estabelcidos entre um Provedor de Serviço e um
Provedor de Identidade (DINIZ et al., 2015).
As restrições para definição de políticas independentes de SP são as mesmas para todo Provedor de Serviço e consistem apenas na limitação no número de usuários de cada Provedor de Identidade que podem acessar um determinado Provedor de Serviço. Já para políticas dependentes de SP, as restrições variam conforme os recursos e serviços providos por um Provedor de Serviço. Assim, essas restrições são implementadas por meio de XML, no qual cada Provedor de Serviço deve fornecer um esquema XML especificando a estrutura de restrições para seus recursos e serviços. Essas restrições devem ser informadas pelo administrador do Provedor de Serviço para cada Provedor de Identidade autorizado a acessar o Provedor de Serviço, conforme o esquema fornecido. A validação das restrições informadas quanto ao esquema é feita pelo FACS, já a verificação das restrições para definição definição de políticas é feita pelo SP Adapter antes de propagar a política.
4.5
Considerações Finais
Esse capítulo apresentou os detalhes da introdução de XACML no FACS, detalhando a integração do servidor de autorização WSO2 IS para gerenciamento de políticas definidas
em XACML e do Provedor de Serviços de nuvem CloudStack, bem como alguns detalhes da implementação do FACS com as mudanças propostas. Foi utilizada a versão 3 do XACML, contemplando os componentes PAP e PDP da sua arquitetura de referência, os quais são fornecidos pelo WSO2 IS. Para a sua linguagem de definação de políticas, apenas um subconjunto dos elementos definidos foi utilizado, visando diminuir a compexidade da definição de políticas para os perfis deifnidos. A linguagem de requisição e repostas também precisou ser implementada para troca de mensagens entre o PDP do FACS e o PDP do WSO2 IS.
Por outro lado, a integração com CloudStack contemplou apenas o gerenciamento dos limites de utlização de alguns dos recursos providos, devido a quantidade de recursos e serviços fornecidos. Assim foi desenvolvido seu SP Adapter para atualização de sua base de dados e repositório de políticas a partir da sua API. Por fim, o FACS foi desenvolvido do zero, uma vez que seu código fonte original não estava disponível. Esse novo sistema, desenvolvido em java, foi implementado de forma a satisfazer todos os requisitos originais e permitir a definição de políticas de controle de acesso em XACML para administradores de Provedores de Serviços e Provedores de Identidades.
5 Avaliação
Esse capítulo apresenta a avaliação das mudanças propostas e introduzidas no FACS. Como as modificações efetuadas consistiram da introdução de XACML para definição de políticas de controle de acesso, a avaliação realizada consistiu na definição de cenários para avaliar a definição de políticas independentes de SP e políticas dependentes de SP. Assim, é detalhada a implantação e configuração da nova versão desenvolvida do FACS, suas dependências e do CloudStack em uma federação local para realização de testes envolvendo diferentes cenários de controle de acesso existentes em uma federação com a utilização do FACS. O objetivo da avaliação realizada foi verificar se de fato as políticas definidas surtiam o efeito desejado em seus respectivos cenários.
5.1
Ambiente
Para realização da avaliação, um ambiente simulando uma federação foi implantado e configurado. Nesse ambiente, foram instalados e configurados dois Provedores de Serviços e quatro Provedores de Identidades em duas máquinas virtuais, uma para cada tipo de provedor. Os Provedores de Serviço correspondem um ao FACS e outro ao CloudStack, respectivamente. Já os Provedores de Identidades foram instalados para permitir a simula- ção dos diferentes cenários de controle de acesso em uma federação abrangidos pelo FACS.
Uma representação esquemática do ambiente a é apresentada na Figura 10.
Figura 10 – Representação esquemática do ambiente de avaliação.
Como a nova versão do FACS é uma aplicação web desenvolvida em java com o Spring Framework, foi configurado um ambiente com o web container Apache Tomcat, no
qual o FACS foi implantado. Para integração com federação, foi instalado o Shibboleth SP através de um módulo do servidor web Apache HTTP Server, também instalado e configurado na máquina dos Provedores de Serviço. Por fim, o Apache Tomcat e o Apache HTTP Server foram configurados para se comunicar por meio do protocolo AJP (Apache JServ Protocol), utilizado para comunicação entre um servidor web e um web container. Nesse cenário, o servidor web atua como um proxy, recebendo todas as requisições e redirecionando aquelas voltadas para aplicações java ao web container. Além disso, também foi configurada uma base de dados MySQL utilizada pelo FACS e o servidor de autorização WSO2 IS.
Para o CloudStack, foi instalado o CloudStack Simulator, uma ferramenta de simulação criada criada pelos mantenedores do projeto para realização de testes. Essa ferramenta permite a simulação de uma nuvem completa, simulando o provisionamento dos vários recursos gerenciados pelo CloudStack, sem a necessidade de ter que implantar um Datacenter complexo para realização de testes. O CloudStack Simulator foi implantado através do Docker, um sistema para virtualização a nível do sistema operacional que cria pacotes de software isolados chamados containers.
Figura 11 – Tela do PHP Proxy.
A integração com o FACS requer a modificação no PEP de um Provedor de Serviço, o que inclui o CloudStack. Contudo, por ser um sistema complexo, uma modificação no PEP do CloudStack exigiria esforço de desenvolvimento. Além disso, uma modificação no PEP de um serviço nem sempre é possível. Assim, ao invés de realizar uma modificação no CloudStack, foi configurado um outro serviço que atua como um proxy para acesso ao CloudStack. Esse serviço consiste de uma simples aplicação web em PHP que, uma vez que
um usuário está autenticado e seu IdP libera os atributos, a aplicação faz uma requisição a API do FACS questionando se o usuário em questão pode acessar o CloudStack. Caso possa, o usuário é redirecionado para o serviço. A principal e única tela da qual essa
aplicação é composta é apresentada na Figura 11.
Para os Provedores de Identidade foi utilizado o Shibboleth IdP, no qual foram todos implantados na mesma máquina virtual, contudo cada um atuando de forma isolada com sua própria base de dados LDAP. Cada IdP teve sua base populada com diferentes usuários, cujos dados foram preenchidos de acordo com o esquema brEduPerson. Como o Shibboleth IdP é uma aplicação java, os provedores de identidades foram implantados no Apache Tomcat, e, assim como no ambiente do FACS, foi configurado o servidor web Apache HTTP Server para atuar como proxy.
5.2
Cenários
A fim de avaliar a definição de políticas nos diferentes cenários de controle de acesso, foi estabelecido um caso de teste para cada cenário. Para políticas independentes de SP foram definidos 4 cenários possíveis, um para cada modo de acesso que um Provedor de Identidade pode ter para um Provedor de Serviço, totalizando 3 cenários, e um para o caso de um Provedor de Identidade não estar autorizado a acessar um Provedor de Serviço. Esses cenários foram definidos a partir do fluxo de políticas independentes de SP
da Figura 5. A Figura 12 apresenta a tela do FACS com a listagem de cada Provedor de
Identidade autorizado a acessar o CloudStack, juntamente com o modo de acesso de cada um. Conforme pode ser visto, o modo de acesso para o IdP2, IdP3 e IdP4 foi definido, na ordem, para automático, manual e baseado em políticas.
Para políticas dependentes de SP, foi definido apenas um cenário, no qual são definidas políticas em XACML para um usuário que teve seu acesso liberado. Cada caso
de teste segue a estrutura da Tabela 5, apresentando nome, descrição, objetivo e resultado
esperado para cada um.
Tabela 5 – Estrutura utilizada para representação dos casos de testes.
Nome Nome do caso de teste.
Descrição Breve descrição do cenário sendo testado.
Objetivo Objetivo do caso de teste.
Resultado Esperado Resultado esperado com a execução bem sucedida do teste.
Para o primeiro cenário, o caso de teste é apresentado na Tabela 6. Nesse cenário,
o IdP1, embora cadastrado no FACS, não teve seu acesso liberado ao CloudStack. Assim, qualquer usuário desse Provedor de Identidade terá seu acesso automaticamente negado, o
que realmente se verificou, conforme pode ser visto na Figura 13, que apresenta a tela do
PHP Proxy com uma mensagem de erro para um usuário desse Provedor de Identidade que tentou acessar o CloudStack. Tal comportamento, conforme esperado, ocorre para qualquer usuário do IdP1.
Tabela 6 – Detalhes do teste realizado para o primeiro cenário.
Nome Teste01
Descrição Provedor de Identidade cadastrado e não autorizado a acessar um Provedor de Serviço.
Objetivo Verificar se qualquer usuário do Provedor de Identidade tem seu acesso negado.
Resultado Esperado O acesso de qualquer usuário do Provedor de Identidade é negado.
Para o segundo cenário, detalhado na Tabela 7, o IdP2 teve seu acesso liberado com o modo de acesso definido para automático. Dessa forma, qualquer usuário desse IdP
que tentar acessar o CloudStack terá seu acesso automaticamente liberado. A Figura 14
apresenta a tela de listagem de domínios do CloudStack, tendo o ROOT no topo e um dos
subdomínios referente ao IdP2. Já a Figura 15 apresenta a tela de listagem das accounts
do domínio do IdP2, e conforme pode ser visto há duas accounts referentes a dois usuários desse Provedor de Identidade que tiveram seus acessos automaticamente liberados. Da mesma forma, conforme esperado, qualquer outro usuário desse Provedor de Identidade terá seu acesso automaticamente liberado.
Tabela 7 – Detalhes do teste realizado para o segundo cenário.
Nome Teste02
Descrição Provedor de Identidade autorizado a acessar um Provedor de Serviço com modo de acesso automático.
Objetivo Verificar se qualquer usuário do Provedor de Identidade tem seu acesso liberado.
Resultado Esperado O acesso de qualquer usuário do Provedor de Identidade é liberado.
Figura 14 – Tela de gerenciamento de domínios do CloudStack.
Figura 15 – Tela de gerenciamento de accounts do domínio do IdP2 do CloudStack.
Para o terceiro cenário, detalhado na Tabela 8, o IdP3 teve seu acesso liberado
com o modo de acesso definido para manual. Assim, qualquer o usuário desse Provedor de Identidade que tentar acessar o CloudStack irá para uma lista de espera, a qual será
apresenta a tela do FACS com a listagem das solicitações de acesso do IdP3 ao CloudStack, nesse caso duas solicitações. Conforme esperado, isso também ocorrerá para qualquer outro usuário do Provedor de Identidade que tentar acessar o CloudStack.
Tabela 8 – Detalhes do teste realizado para o terceiro cenário.
Nome Teste03
Descrição Provedor de Identidade autorizado a acessar um Provedor de Serviço com modo de acesso manual.
Objetivo Verificar se qualquer usuário do Provedor de Identidade tem seu acesso moderado em uma lista de aprovação.
Resultado Esperado O acesso de qualquer usuário do Provedor de Identidade é liberado mediante ação de um administrador.
Figura 16 – Tela do FACS para gerenciamento de solicitações de acesso de usuários de um Provedor de Identidade a um Provedor de Serviço.
Para o quarto cenário, detalhado na Tabela 9, o IdP4 teve seu acesso liberado
com o modo de acesso definido para baseado em políticas. Assim, qualquer usuário desse Provedor de Identidade que tentar acessar o CloudStack terá sua tentativa de acesso avaliada conforme as políticas em XACML definidas pelos administradores. Dessa forma, somente usuários cujo contexto da requisição contenha atributos que satisfaça pelo menos
uma política em XACML terá seu acesso liberado. A Figura 17 apresenta a tela do
FACS que mostra a listagem das políticas definidas, nesse caso apenas uma, a qual é
apresentada na Listagem B.1do Apêndice B. Essa política especifica que somente usuários
desse Provedor de Identidade que possuem o vínculo do tipo faculty podem acessar o