uma proposta de controle de acesso como serviço para … · 2019-01-31 · silva, brunno moreira...

Brunno Moreira da Silva

Uma Proposta de Controle de Acesso comoServiço para Federação de Identidades

Brasil

2018


Uma Proposta de Controle de Acesso como Serviço paraFederação de Identidades

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada (DIMAP) da Universidade Federaldo Rio Grande do Norte como requisito par-cial para a obtenção do grau de Bacharel emEngenharia de Software.

Universidade Federal do Rio Grande do Norte – UFRN

Departamento de Informática e Matemática Aplicada – IMD

Bachalerado em Engenharia de Software

Orientador: Prof. Dr. Carlos Eduardo da Silva

Brasil2018

Silva, Brunno Moreira da. Uma proposta de controle de acesso como serviço parafederação de identidades / Brunno Moreira da Silva. - 2018. 86f.: il.

Monografia (Bacharelado em Engenharia de Software) -Universidade Federal do Rio Grande do Norte, Centro de CiênciasExatas e da Terra, Departamento de Informática e MatemáticaAplicada, Curso de Engenharia de Software. Natal, 2018. Orientador: Carlos Eduardo da Silva.

1. Engenharia de software - Monografia. 2. Federação deidentidades - Monografia. 3. Controle de acesso - Monografia. 4.FACS - Monografia. 5. XACML - Monografia. I. Silva, CarlosEduardo da. II. Título.

RN/UF/CCET CDU 004.41

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

Elaborado por Joseneide Ferreira Dantas - CRB-15/324


Uma Proposta de Controle de Acesso como Serviço paraFederação de Identidades

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada (DIMAP) da Universidade Federaldo Rio Grande do Norte como requisito par-cial para a obtenção do grau de Bacharel emEngenharia de Software.

Trabalho aprovado. Brasil, 27 de novembro de 2018:

Prof. Dr. Carlos Eduardo da SilvaOrientador

Prof. Dr. Silvio Costa SampaioConvidado 1

Prof. Ms. Itamir de Morais BarrocaFilho

Convidado 2

Brasil2018

À minha família, por seu apoio e capacidade de acreditar e investir em mim.Mãe, seu cuidado e dedicação incondicional foi o que deram, em alguns momentos, a

esperança para seguir.Pai, sua presença e companheirismo significou segurança e certeza de que não estou

sozinho nessa caminhada.Minha querida Josi, todo seu amor e confiança, seus olhos cheios de alegria e esperança

tornam meus dias melhores e me encoraja e motiva a não desistir.

Agradecimentos

A Deus por ter me dado saúde e força para superar as dificuldades.

A esta universidade, seu corpo docente, direção e administração que oportunizarama janela que hoje vislumbro um horizonte superior, eivado pela acendrada confiança nomérito e ética aqui presentes.

Ao meu orientador Carlos Eduardo da Silva, pelo seu suporte no pouco tempo quelhe coube, pelas suas correções e lições.

Aos meus pais, pelo amor, incentivo e apoio incondicional.

A minha amada noiva, por sua presença e fé constante.

E a todos que direta ou indiretamente fizeram parte da minha formação, o meumuito obrigado.

“Determinação coragem e autoconfiança são fatores decisivos para o sucesso. Se estamospossuídos por uma inabalável determinação conseguiremos superá-los. Independentemente

das circunstâncias, devemos ser sempre humildes, recatados e despidos de orgulho.“(Dalai Lama)

ResumoEm uma federação de identidades cada serviço é responsável por controlar o acesso dosusuários da federação, determinando quem pode acessar e seus privilégios. Nesse contexto,o Sistema de Controle de Acesso Federado (Federated Access Control System - FACS)foi proposto como um sistema de controle de acesso hierárquico para controlar o acessode usuários a serviços em ambientes federados. Entretanto, o FACS foi desenvolvidocom um alto acoplamento no que diz respeito a funcionalidade de gestão de políticas decontrole de acesso para controlar o acesso dos usuários a recursos e serviços fornecidos peloedudrive@RNP, além de não ser especificado uma forma para definição de políticas e ospassos necessários para integração de outros serviços da federação. Com isso, é proposta aimplementação de uma nova versão do FACS, com a introdução de XACML (eXtensibleAccess Control Markup Language) para a definição de políticas, fornecendo uma interfacecomum para gestão de políticas e permitindo a aplicação de um controle de acesso comgranularidade fina para controlar o acesso de usuários a serviços em uma federação deidentidades. Com esta proposta, a funcionalidade de gerenciamento de políticas de controlede acesso passa a ser delegada a um servidor de autorização e a nova versão do FACSdesenvolvida é integrada ao CloudStack, produto utilizado no serviço de computação emnuvem da Rede Nacional de Ensino e Pesquisa, a fim de avaliar as mudanças propostas.

Palavras-chave: federação de identidades. controle de acesso. FACS. XACML.

AbstractIn a federation of identities each service is responsible for control the access of the users ofthe federation, determining who can access and its privileges. In this context, the FederatedAccess Control System (FACS) has been proposed as a hierarchical access control systemto control users access to services in federated environments. However, the FACS wasdeveloped with a high degree of coupling with respect to access control policy managementfunctionality to control users access to resources and services provided by edudrive@RNP,besides not being specified a means for definition of policies and the required steps forintegration of others services in federation. Therefore, it is proposed to implementationof a new version of the FACS, introducing XACML (eXtensible Access Control MarkupLanguage) for policy definition, providing a common interface for policy managementand allowing the application of a fine-granularity access control to control the accessof users to services in an identity federation. With this proposal, access control policymanagement functionality is now delegated to an authorization server and the new FACSversion developed is integrated with CloudStack, product used in the cloud computingservice of the Rede Nacional de Ensino e Pesquisa, in order to evaluate the proposedchanges.

Keywords: federation of identities. access control. FACS. XACML.

Lista de ilustrações

Figura 1 – Componentes Funcionais do ABAC (HU et al., 2014). . . . . . . . . . . 23Figura 2 – Arquitetura padrão e fluxo de dados do XACML (OASIS, 2013). . . . . 25Figura 3 – Representação esquemática da linguagem de políticas do XAMCL (OA-

SIS, 2013). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 4 – Arquitetura do FACS (DINIZ et al., 2015). . . . . . . . . . . . . . . . 37Figura 5 – Fluxo para políticas independentes de SP do FACS (DINIZ et al., 2015). 38Figura 6 – Arquitetura do FACS integrada ao servidor de autorização. . . . . . . . 41Figura 7 – Arquitetura do CloudStack. . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 8 – Entidades do sistema de controle de acesso do CloudStack. . . . . . . . 49Figura 9 – Diagrama de Pacotes do FACS. . . . . . . . . . . . . . . . . . . . . . . 54Figura 10 – Representação esquemática do ambiente de avaliação. . . . . . . . . . . 58Figura 11 – Tela do PHP Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 12 – Tela principal do FACS para gerenciamento de políticas independentes

de SP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figura 13 – Tela com mensagem de erro do PHP Proxy. . . . . . . . . . . . . . . . 61Figura 14 – Tela de gerenciamento de domínios do CloudStack. . . . . . . . . . . . 62Figura 15 – Tela de gerenciamento de accounts do domínio do IdP2 do CloudStack. 62Figura 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. . . . . . . . . 63Figura 17 – Tela do FACS para listagem de políticas para políticas independentes

de SP do modo de acesso baseado em políticas. . . . . . . . . . . . . . 64Figura 18 – Tela do FACS para listagem de políticas dependentes de SP. . . . . . . 65Figura 19 – Tela de gerenciamento de accounts do domínio do IdP4 do CloudStack. 65Figura 20 – Tela de gerenciamento de uma account do CloudStack. . . . . . . . . . 66Figura 21 – Mensagem de erro exibida pelo CloudStack a um usuário ao tentar

realizar uma operação que exceda os limites de recursos definidos. . . . 66

Lista de tabelas

Tabela 1 – Entidades a alguns de seus atributos definidos no padrão XACML. . . 24Tabela 2 – Entidades e atributos permitidos definidos no perfil de políticas inde-

pendentes de SP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Tabela 3 – Entidades e atributos permitidos definidos no perfil de políticas depen-

dentes de SP do FACS. . . . . . . . . . . . . . . . . . . . . . . . . . . 45Tabela 4 – Entidades e atributos permitidos definidos no perfil de políticas depen-

dentes de SP do CloudStack. . . . . . . . . . . . . . . . . . . . . . . . 51Tabela 5 – Estrutura utilizada para representação dos casos de testes. . . . . . . . 61Tabela 6 – Detalhes do teste realizado para o primeiro cenário. . . . . . . . . . . . 61Tabela 7 – Detalhes do teste realizado para o segundo cenário. . . . . . . . . . . . 62Tabela 8 – Detalhes do teste realizado para o terceiro cenário. . . . . . . . . . . . 63Tabela 9 – Detalhes do teste realizado para o quarto cenário. . . . . . . . . . . . . 64Tabela 10 – Detalhes do teste realizado para o quinto cenário. . . . . . . . . . . . . 64

Lista de abreviaturas e siglas

ABAC Attribute Based Access Control

API Application Program Interface

AWS Amazon Web Services

CLI Command Line Interface

CAFe Comunidade Acadêmica Federada

CNC Computação em Nuvem para Ciência

FACS Federated Access Control System

FIM Federated Identity Management

GUI Graphical user interface

HTTP HyperText Transfer Protocol

IaaS Infrastructure as a Service

IAM Identity and Access Management

IdM Identity Management

IdP Identity Provider

IS Identity Server

JSON JavaScript Object Notation

NIST National Institute of Standards and Technology

OAM&P Operations, Administration, Maintenance, and Provisioning

OASIS Organization for the Advancement of Structured Information Standards

PAP Policy Administration Point

PDP Policy Decision Point

PEP Policy Enforcement Point

PIP Policy Information Point

RBAC Role Based Access Control

REST Representational State Transfer

RNP Rede Nacional de Ensino e Pesquisa

SAML Security Assertion Markup Language

SBRC Simpósio Brasileiro em Redes de Computadores e Sistemas Distribuídos

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SP Service Provider

SSO Single Sign On

XACML eXtensible Access Control Markup Language

XML eXtensible Markup Language

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.1 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 192.1 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.1 Autenticação, Autorização e Auditoria . . . . . . . . . . . . . . . . . . . . 202.1.2 Modelos, Mecanismos e Políticas . . . . . . . . . . . . . . . . . . . . . . . 202.2 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 Gerenciamento de Identidades . . . . . . . . . . . . . . . . . . . . . . 322.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 FACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Arquitetura do FACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 NOVA IMPLEMENTAÇÃO PROPOSTA PARA O FACS . . . . . . 404.1 Abordagem Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Integração com WSO2 Identity Server . . . . . . . . . . . . . . . . . 464.3 Integração com CloudStack . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 68

7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

APÊNDICES 75

APÊNDICE A – PERFIS XACML DEFINIDOS PARA O FACS . . 76

APÊNDICE B – POLÍTICAS XACML UTILIZADAS NA AVALIA-ÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . 82

15

1 Introdução

Controle de acesso consiste no processo de proteger recursos e serviços providospor uma organização de acessos não autorizados, controlando o acesso de usuários a umsistema através da definição de políticas, modelos e mecanismos, para limitar as ações queum usuário pode realizar sobre recursos em um sistema (SANDHU; SAMARATI, 1994).Do ponto de vista de uma organização, o controle de acesso permite o compartilhamentode informações de forma segura, protegendo o acesso a seus recursos e serviços contraacessos inadequados ou indesejados, garantindo que somente usuários autorizados possamefetuar o acesso a seus sistemas (HU; FERRAIOLO; KUHN, 2006).

Um sistema de controle de acesso é capaz de proteger o acesso a recursos de umsistema, limitando o acesso de usuários legítimos através dos processos de autenticação,que permite identificar um usuário e validar sua identidade, autorização, que define o queum usuário pode fazer no sistema, especificando quais recursos e serviços ele pode acessar,e auditoria, que consiste no processo de registro de todas as requisições e atividade dosusuários para análise posterior, permitindo observar o comportamento de cada usuário eidentificar algum acesso ou atividade suspeita (SANDHU; SAMARATI, 1994).

Por outro lado, uma federação de identidades consiste de um modelo de gestãode identidades distribuído no qual é estabelecida uma relação de confiança mútua entreProvedores de Serviço (Service Provider - SP) e Provedores de identidades (IdentityProvider - IdP). Um SP provê serviços a usuários da federação, enquanto que IdPs sãoresponsáveis por gerenciar identidades e emitir informações de autenticação e autorizaçãode usuários (CHADWICK, 2009). Essa relação de confiança é chamada de federação epermite o compartilhamento de recursos, serviços e informações entre organizações dediferentes domínios.

Num cenário geral, em uma federação, através da relação de confiança estabelecidaentre IdP’s e SP’s, um usuário pertencente a uma instituição pode, através das credenciaisde autenticação e autorização emitidas pelo seu IdP, acessar serviços providos por qualquerSP integrante. Assim, em um cenário básico, usuários provenientes de um IdP podemacessar qualquer serviço provido em uma federação. Enquanto que, em alguns cenáriosmais específicos, um SP precisa realizar o controle de acesso dos usuários da federaçãoao seu serviço, determinando a quais usuários e instituições o acesso será concedido.Isso ocorre, por exemplo, em um cenário no qual somente usuários de alguns IdPs temacesso ao serviço oferecido, resultado de um acordo contratual entre as instituições ouquando uma instituição paga para que seus usuários possam acessar o serviço provido.Outro cenário, ainda mais específico, seria quando somente alguns usuários de alguns IdPs

Capítulo 1. Introdução 16

podem acessar um serviço, decorrente por exemplo, do fato de o serviço estar em faseexperimental, permitindo o acesso apenas de alguns usuários da federação para realizartestes e conhecer suas capacidades. Tais cenários podem ocorrer na prática, como no casodo projeto CNC (Computação em Nuvem para Ciência), um serviço de armazenamentoem nuvem implantado na infraestrutura de redes da RNP (Rede Nacional de Ensino ePesquisa)1, e no serviço de computação em nuvem da RNP2.

Diante dessa situação, foi proposto o Federated Access Control System (FACS) (DI-NIZ et al., 2015) como um sistema de controle de acesso hierárquico para permitir adefinição e delegação de políticas de controle de acesso entre administradores de IdP eSP para serviços da federação. Esse sistema foi proposto, tendo como objetivo principal,atender os cenários de controle de acesso mais específicos apresentados anteriormente.Para tanto, ele permite ao administrador de um Provedor de Serviço definir políticas decontrole de acesso para determinar quais usuários da federação podem acessar o serviço edefinir seus privilégios, além de permitir a delegação dessa capacidade a administradoresde Provedores de Identidade. Entretanto, o FACS apresenta algumas limitações.

1.1 ProblemáticaEmbora tenha sido proposto como uma solução para diversos SPs, o FACS foi

inicialmente implementado para o edudrive@RNP, de forma que o sistema foi desenvolvidocom um alto acoplamento no que diz respeito a funcionalidade de gestão de políticas decontrole de acesso para controlar o acesso dos usuários a recursos e serviços fornecidos peloedudrive@RNP. Assim, a integração com novos provedores de serviços, como o serviço decomputação em nuvem da RNP, exigiria um alto custo de desenvolvimento, uma vez quecada um tem suas próprias caraterísticas, oferecendo diferentes recursos e serviços.

Além disso, em sua versão atual, embora seja baseado no Controle de AcessoBaseado em Atributos (Attribute Based Access Control - ABAC), não é especificadonenhum mecanismo para definição de políticas de controle de acesso, assim como a ausênciade suporte para definição de políticas de Controle de Acesso com Granularidade Fina paraoutros Provedores Serviços. Por causa disso, a definição de políticas para novos provedoresserviços teria que ser feita no formato especificado e compreendido por cada um, exigindoum maior esforço de desenvolvimento na integração de novos provedores serviços ao FACS.Assim, a adoção de um padrão, como a Linguagem de Marcação de Controle de AcessoExtensível (eXtensible Access Control Markup Language - XACML), estabeleceria umformato comum para definição de políticas de controle de acesso, facilitando a integraçãode diferentes provedores de serviços ao FACS.

1 O CNC foi renomeado para edudrive@RNP como parte da estratégia de lançamento do serviço pelaRNP<https://edudrive.rnp.br/>

2 <https://compute.rnp.br/>

https://edudrive.rnp.br/

https://compute.rnp.br/


Com a grande quantidade de provedores de serviços presentes em uma federação,uma demanda cada vez maior para integração de novas instituições que visam o com-partilhamento de recursos e serviços entre si e a necessidade de controlar o acesso dosusuários a serviços, definindo políticas de controle de acesso com granularidade fina edelegando o gerenciamento do controle de acesso. É exatamente nesse contexto que oFACS se apresenta como uma opção interessante.

1.2 ObjetivosA fim de superar as limitações apresentadas anteriormente, esse trabalho tem

como objetivo geral implementar uma nova versão do FACS, utilizando um servidor deautorização para gerenciamento de políticas de controle de acesso.

Como objetivos específicos, pretende-se (1) realizar a introdução de XACML paradefinição de políticas de controle de acesso com granularidade fina; (2) externalizar ogerenciamento de políticas de controle de acesso através da integração do FACS a umservidor de autorização para delegar a funcionalidade de gerenciamento de políticas e; (3)integrar o FACS a outro Provedor de Serviço para controlar o acesso a seus recursos eserviços a fim de validar as mudanças propostas.

1.3 MetodologiaA fim de permitir a realização deste trabalho, inicialmente será realizado um estudo

sobre conceitos básicos em Controle de Acesso e Gestão de Identidades, bem como modelos,mecanismos e tecnologias, como o Controle de Acesso Baseado em Atributos, o Modelo deGestão de Identidades Federado e a tecnologia XACML. Tal estudo torna-se importante,devido a necessidade de conhecer as diferentes formas de controle de acesso que podem serutilizadas por provedores de serviço, bem como entender o funcionamento do modelo degestão de identidades federadas e as tecnologias que o implementam.

Em seguida, será feito um estudo sobre o FACS, analisando o cenário no qual ele foiproposto, sua arquitetura, funcionalidades e características, destacando seus problemas elimitações. Esse estudo fornecerá um melhor conhecimento sobre o sistema. Posteriormenteuma nova versão do FACS, utilizando XACML e integrando a um servidor de autorizaçãoe a um Provedor de Serviço, será implementada.

Logo após, a fim de avaliar o novo sistema desenvolvido, será realizada uma avaliaçãoexperimental, testando a definição de políticas de controle de acesso no FACS em diferentescenários de controle de acesso em uma federação. Por fim, será realizado um estudo daliteratura a fim de identificar trabalhos que apresentem métodos e ferramentas de controle


de acesso em ambientes federados, apontando suas semelhanças e diferenças em relação aoFACS.

O restante deste trabalho está organizado da seguinte forma: O capítulo 2 apresentaum estudo dos temas envolvidos na realização deste trabalho, como Controle de Acesso,XACML e Gerenciamento de Identidades; O capítulo 3 aborda o FACS, apresentando suasprincipais funcionalidades e arquitetura, além de expor algumas das suas limitações; Ocapítulo 4 apresenta a solução para os problemas apresentados, detalhando a introduçãode XACML e a implementação do novo FACS; O capítulo 5 avalia a solução proposta,discutindo alguns cenários para utilização do FACS integrado com XACML para definiçãode políticas de controle de acesso para o CloudStack; O capítulo 6 discute trabalhosrelacionados; Por fim, o capítulo 7 apresenta algumas considerações do trabalho realizado.

19

2 Fundamentação Teórica

Este capítulo apresenta os conceitos e discussões dos assuntos de segurança pertinen-tes para realização deste trabalho, com base nos trabalhos (SANDHU; SAMARATI, 1994),(SAMARATI; VIMERCATI, 2001), (HU; FERRAIOLO; KUHN, 2006), (ANSI, 2004)e (OASIS, 2013). Na primeira seção são apresentados conceitos, mecanismos, modelose tecnologias relacionados a Controle de Acesso, destacando o modelo de Controle deAcesso Baseado em Atributos (Attribute Based Access Control - ABAC). Na segundaseção a Linguagem de Marcação de Controle de Acesso Extensível (eXtensible AccessControl Markup Language - XACML) é abordada. Por fim, na terceira seção são abordadosconceitos e modelos referentes a Gerenciamento de Identidades, apresentando o Modelo deGestão de Identidades Federadas e tecnologias que o implementam.

2.1 Controle de AcessoControle de acesso consiste no processo de mediação de todas as solicitações de

acesso a recursos e serviços em um sistema, determinando se elas devem ser concedidas ounegadas, garantindo que somente as solicitações autorizadas sejam permitidas (SAMA-RATI; VIMERCATI, 2001). O Controle de Acesso procura limitar o acesso de usuários aum sistema, restringindo as ações que usuários legítimos podem realizar diretamente eimpedindo ações de usuários não autorizados (SANDHU; SAMARATI, 1994).

Proteger o acesso a recursos em um sistema contra solicitações não autorizadas ouimpróprias é um requisito de segurança fundamental para qualquer sistema que desejagarantir a confidencialidade, integridade e disponibilidade de seus serviços e informações.Confidencialidade é a garantia de que apenas entidades autorizadas terão acesso aosrecursos protegidos, enquanto integridade garante a consistência das informações contramodificações não autorizadas e disponibilidade mantém o sistema sempre disponível parausuários legítimos e autorizados (SAMARATI; VIMERCATI, 2001).

O nível de proteção a ser implantado em um sistema depende dos requisitos desegurança especificados no projeto. Em algumas aplicações, um controle de acesso simplesé suficiente, como a concessão total de acesso uma vez que um usuário está autenticado.Contudo, outras aplicações com recursos mais sensíveis, como aplicações governamentais,empresas e grandes corporações, exigem um controle de acesso mais complexo e sofisticadocom regras mais elaboradas, dependendo de múltiplos fatores e mecanismos de proteçãocontra falhas (HU; FERRAIOLO; KUHN, 2006).

Na prática, o controle de acesso é aplicado pelo monitor de referência, um compo-

Capítulo 2. Fundamentação Teórica 20

nente confiável e inviolável responsável por interceptar as requisições de acesso a recursose aplicar as politicas de segurança especificadas. Assim, controlando todo o acesso nosistema, o controle de acesso procura prevenir a execução de atividades que possamlevar a falhas de segurança e comprometam o funcionamento de um sistema, afetandoa confidencialidade, integridade e disponibilidade dos serviços e informações fornecidos(SANDHU; SAMARATI, 1994).

2.1.1 Autenticação, Autorização e Auditoria

Contudo, controle de acesso não é uma solução completa e isolada para garantir asegurança dos recursos de um sistema, ele deve ser integrado a outros serviços de segurança.O controle de acesso depende e coexiste com os serviços de autenticação, autorização eauditoria (SANDHU; SAMARATI, 1994).

Autenticação é o serviço de segurança responsável por estabelecer corretamente aidentidade dos usuários, verificando a autenticidade e validade da identidade fornecida porum usuário. Tal serviço consiste de um dos primeiros recursos que um sistema apresentapara proteger suas informações, sendo essencial para garantir o sucesso dos demais serviços,uma vez que autorização e auditoria são realizados com base na identidade do usuáriointeragindo com o sistema.

Autorização, por sua vez, estabelece regras de acesso a recursos, definindo os direitosde acesso dos usuários sobre os recursos do sistema. Acesso a recursos deve ser permitidosomente quando explicitamente especificado e concedido. O comportamento padrão paraacesso a recursos é negar. Assim, caso uma solicitação de acesso seja feita e uma regra nãoesteja devidamente especificada, a solicitação deve ser rejeitada (SANDHU; SAMARATI,1994).

Por fim, auditoria monitora e registra todos os eventos relevantes que ocorremno sistema, como tentativas de autenticação, requisições de acesso a recursos e execuçãode ações. As informações registradas são utilizadas posteriormente para investigar falhasde segurança, analisar o comportamento dos usuários a fim de identificar atividadessuspeitas e avaliar possíveis brechas de segurança. Através da auditória é possível inibir osusuários a realizarem atividades que possam comprometer o funcionamento do sistema eresponsabiliza-los pelas suas ações (SANDHU; SAMARATI, 1994).

Este trabalho está focado em aspectos relacionados a autorização.

2.1.2 Modelos, Mecanismos e Políticas

O projeto, desenvolvimento e execução de um serviço de controle de acesso envolveos conceitos de políticas, mecanismos e modelos de segurança. Políticas são diretrizes geraisque especificam como o acesso deve ser determinado e controlado, determinando quem


pode acessar o que sobre quais circunstâncias, enquanto mecanismos representam funçõesde hardware e software que implementam as políticas, tornando possível a aplicação dasregras por elas definidas. Modelos de segurança são representações formais de políticas,utilizados para, teoricamente, analisar, avaliar e provar limitações e capacidades de umsistema de controle de acesso (SANDHU; SAMARATI, 1994).

Políticas de controle de acesso são criadas a partir de políticas de segurança doambiente do qual o sistema fará parte, que devem ser interpretadas e traduzidas empolíticas de controle de acesso bem definidas e não ambíguas a serem aplicadas emum sistema. Contudo, muitas vezes políticas do mundo real são ambíguas e complexas,no qual decisões de acesso dependem da aplicação de diferentes regras e fatores, comoleis, normas institucionais e condições ambientes (como data e local). Assim, políticasde controle de acesso devem ser especificadas visando abranger todos os requisitos desegurança estabelecidos, contemplando todas as políticas da organização e possíveis falhasde segurança decorrentes do uso do sistema (SAMARATI; VIMERCATI, 2001).

A especificação de políticas e o projeto de um sistema de controle de acesso como umtodo, requerem a identificação e mapeamento das entidades envolvidas, que são classificadasem sujeitos, objetos e ações. Os objetos representam os recursos a serem protegidos e asações representam as operações disponíveis e permitidas de serem executadas sobre cadaobjeto. Os sujeitos representam entidades ativas, nas quais os usuários serão mapeados,responsáveis por iniciar atividades no sistema, solicitando acesso para executar ações sobreos objetos.

Políticas definidas no escopo de um sistema dificilmente teriam utilidade ou asse-gurariam a segurança de outro sistema, devido as diferentes características e requisitos desegurança de cada um, sendo específicas no contexto em que foram definidas. Assim comosujeitos, objetos e ações, que são exclusivos de cada ambiente, no qual sistemas distintospossuem diferentes recursos a serem protegidos, com diferentes operações que podem serexecutadas sobre cada um e diferentes sujeitos que podem solicitar acesso (SANDHU;SAMARATI, 1994).

Um aspecto importante no controle de acesso é o gerenciamento do controle deacesso em si. A especificação e definição de políticas administrativas estabelece quemestá capacitado a gerenciar as permissões dos sujeitos sobre os objetos, ou seja, quem éresponsável por definir e gerenciar as politicas de controle de acesso. Essas podem sercentralizadas quando uma autoridade central ou grupo é responsável por administrar aspolíticas de controle de acesso, hierárquica e descentralizado quando uma autoridade podedelegar capacidades administrativas a outros indivíduos, ou cooperativa quando a definiçãode políticas depende da decisão de múltiplas autoridades (SANDHU; SAMARATI, 1994).

Modelos fornecem uma representação simplificada de politicas, facilitando a verifica-ção de propriedades de segurança em um sistema (SAMARATI; VIMERCATI, 2001). Uma


variedade de modelos são propostos pela literatura para atender as diferentes necessidadesde controle de acesso de diversos sistemas em diferentes contextos. De uma forma geral,os principais modelos propostos pela literatura são o Controle de Acesso Baseado emPapeis (Role Based Access Control - RBAC) e o Controle de Acesso Baseado em Atributos(Attribute Based Access Control - ABAC)1.

O RBAC requer a identificação de um conjunto de papeis, que representam asdiferentes atividades e responsabilidades organizacionais que usuários tem no sistema. Acada usuário é atribuído um papel e a cada papel é atribuído um conjunto de privilégios queespecificam as ações permitidas para cada objeto no sistema. Assim, o acesso é controladocom base no papel que um usuário possui no sistema, permitindo especificar as permissõesde grupos de usuários ao invés de cada usuário individual. Nesse modelo, múltiplos papeispodem ser concedidos a um único usuário, representando as diferentes responsabilidadesque ele possui, ou os papeis podem ser estruturados de uma forma hierárquica, no qualpermissões são herdadas (ANSI, 2004).

Por outro lado, o ABAC consiste de um modelo de controle de acesso no qual oacesso é controlado com base na avaliação de atributos dos sujeitos e objetos envolvidosem uma solicitação de acesso, bem como dos atributos da operação requisitada e condiçõesambiente no momento da solicitação. Tais atributos podem ser atribuídos às entidades nomomento de sua criação e gerenciados posteriormente. Assim, o ABAC permite um controlede acesso mais granular e preciso, na medida em que políticas de controle de acesso sãodefinidas contemplando os atributos associados a cada entidade envolvida, possibilitandouma maior combinação na definição de regras de acesso, as quais são limitadas apenaspela linguagem computacional e atributos disponíveis (HU et al., 2014).

O modelo ABAC foi padronizado pelo NIST em (HU et al., 2014), o qual defineuma arquitetura padrão que um sistema ABAC deve adotar. Essa arquitetura define umconjunto de componentes funcionais, especificando seus relacionamentos e responsabilidades.Assim, conforme pode ser visto na Figura 1, os componentes funcionais definidos são oPonto de Decisão de Política (Policy Decision Point - PDP), o Ponto de Aplicação dePolítica (Policy enforcement Point - PEP), o Ponto de Administração de Política (PolicyAdministration Point - PAP) e o Ponto de Informação de Política (Policy InformationPoint - PIP)2.

O PDP é o componente responsável pela tomada de decisões, determinando seuma determinada requisição de acesso a recursos no sistema deve ser concedida ou negadaa partir da avaliação das políticas definidas com os atributos da requisição. O PEP é

1 Deste momento em diante utilizaremos os termos RBAC e ABAC para nos referirmos a Controle deAcesso Baseado em Papeis e Controle de Acesso Baseado em Atributos

2 Deste momento em diante utilizaremos os termos PDP, PEP, PAP e PIP para nos referirmos a Pontode Decisão de Política, Ponto de Aplicação de Política, Ponto de Administração de Política e Ponto deInformação de Política


Figura 1 – Componentes Funcionais do ABAC (HU et al., 2014).

componente responsável por proteger o acesso a recursos em um sistema, interceptandoou recebendo as requisições de acesso a recursos por parte dos usuários e aplicando asdecisões tomadas pelo PDP. O PAP é o componente responsável pelo gerenciamento daspolíticas de controle de acesso, que são armazenadas no Repositório de Políticas (PolicyRepository), e por fornecer uma interface para gerenciamento de políticas. Por fim, o PIPé o componente responsável pelo gerenciamento dos atributos das entidades envolvidas nocontexto do controle de acesso, que são armazenados no Repositório de Atributos (AttributeRepository), e sempre que o PDP precise de mais atributos para avaliar a requisição, eleconsulta o PIP.

Além disso, também é definido um componente opcional, o Context Handler,responsável principalmente por coordenar a comunicação entre os demais componentes,definindo a ordem na qual políticas e atributos são recuperados e realizando a conversãodas requisições na sua forma nativa para o formato canônico (ex.: XACML) e vice-versa.

Por fim, em um cenário real, cada sistema emprega seu próprio serviço de controlede acesso, adotando e adaptando os modelos e mecanismos sugeridos na literatura a suaspróprias necessidades para atender seus requisitos. O tipo de controle de acesso utilizadoem um sistema pode ser resultado da adoção e adaptação de um único modelo, ou podeconsistir da combinação de múltiplos modelos.


2.2 XACMLXACML (eXtensible Access Control Markup Language) é um padrão aberto baseado

em XML (eXtensible Markup Language), especificado e publicado pela OASIS3, que defineuma tecnologia para gerenciamento de controle de acesso, permitindo a gestão de direitosde acesso e avaliação e aplicação de políticas de controle de acesso. Baseado no ABAC, ocontrole de acesso em XACML é feito com base nos atributos das entidades envolvidasem um determinado contexto de autorização. Sua especificação, atualmente na versão 3(OASIS, 2013), versão abordada e utilizada no presente trabalho, define toda a estruturanecessária para gerenciamento e aplicação de políticas de controle de acesso, incluindotrês artefatos principais: uma arquitetura de referência, uma linguagem para definição depolíticas e uma linguagem para troca de mensagens de autorização.

Juntamente com a linguagem para troca de mensagens de controle de acesso e alinguagem para representação de políticas, é definido um conjunto padrão de entidades, seusatributos e tipos de dados, bem como funções para combinação de valores. As entidadesdefinidas, também chamadas de categorias de atributos, são sujeito (subject), recurso(resource), ação (action) e ambiente (environment). Para cada uma dessas entidades édefinido um conjunto de atributos que podem ser utilizados e seus tipos de dados. ATabela 1 apresenta as entidades e alguns de seus atributos.

Tabela 1 – Entidades a alguns de seus atributos definidos no padrão XACML.

Entidade Atributosubject subject-idresource resource-idaction action-id

environmentcurrent-timecurrent-datecurrent-dateTime

A especificação da arquitetura de referência define um conjunto de componentes,suas funcionalidades, a sequência de troca de mensagens (fluxo de dados), bem comoalguns poucos detalhes de implementação. Como XACML implementa o modelo ABAC,sua arquitetura contempla os mesmos componentes definidos pela publicação do NIST(HU et al., 2014), possuindo as mesmas responsabilidades e funcionalidades, conformepode ser visto na Figura 2.

Assim, conforme a figura, o PAP deve fornecer uma interface para que as politicassejam acessadas pelo PDP (Passo 1). Toda vez que um sujeito faz uma requisição ao sistemapara executar uma ação sobre um recurso, essa requisição chega no PEP ou é interceptadapor ele (Passo 2). O PEP, por sua vez, monta uma requisição no seu formato padrão

3 <https://www.oasis-open.org/committees/xacml/>

https://www.oasis-open.org/committees/xacml/


Figura 2 – Arquitetura padrão e fluxo de dados do XACML (OASIS, 2013).

com as informações da requisição, e envia ao Context Handler (Passo 3). Uma vez que arequisição enviada pelo PEP chega ao Context Handler, ele extrai os atributos e montauma requisição XACML (XACML Request) para enviar ao PDP (Passo 4). Recebendoa XACML Request, o PDP é responsável por selecionar e aplicar as políticas definidassobre os atributos da requisição, tomando a decisão de permitir ou negar a requisição emquestão. As políticas são recuperadas do PAP, e caso precise de mais atributos o PDPsolicita ao Context Handler (Passo 5) que, por sua vez, consulta o PIP para recuperaros atributos solicitados (Passo 6). O PIP por sua vez, é responsável por recuperar osatributos das entidades envolvidas, nesse caso, atributos do sujeito (Passo 7a), ambiente(Passo 7b) e recurso (Passo 7c), e retorna os atributos ao Context Handler (Passo 8).Tendo tomado uma decisão, o PDP envia uma resposta XAMCL (XACML Response)para o Context Handler (Passo 11) que converte a requisição para o formato nativo doPEP e envia para ele (Passo 12). Por fim, o PEP aplica a decisão tomada pelo PDP,permitindo ou negando o acesso solicitado pelo sujeito e opcionalmente, caso presente,aplica obrigações estabelecidas (Passo 13).


A comunicação entre os componentes, mais especificamente entre o PDP e o ContextHandler ou entre o PDP e o PEP (quando esses se comunicam diretamente), ocorre atravésda troca de mensagens em XML, no formato definido pela linguagem de requisição/respostaespecificado no padrão XACML. Nessa linguagem, uma XAMCL Request consiste de umconjunto de atributos, suas categorias, tipos de dados e valores enviado ao PDP. Já umaXACML Response representa a decisão tomada pelo PDP e a resposta a uma XAMCLRequest, podendo ser: Permitir (Permit), quando a solicitação de acesso é liberada; Negar(Deny), quando a solicitação de acesso é negada; Não Aplicável (Not Applicable), quandonão foi possível encontrar nenhuma política que pudesse ser aplicada; Indeterminado(Indeterminate), quando ocorreu algum erro no processamento.

A Listagem 2.1 apresenta um exemplo de XACML Request. Essa requisição éformada por um atributo de cada entidade. Na linha 1 é feita a declaração de um elementopadrão de um documento XML, indicando a versão do XML sendo utilizada. Na linha 2 éfeita a declaração da requisição com o elemento Request, os atributos do tipo booleanoobrigatórios CombinedDecision e ReturnPolicyIdList, e o atributo xmlns especificando onamespace do documento XML para a versão 3 do XACML. O atributo CombinedDecisioné utilizado para informar ao PDP se ele deve combinar múltiplas decisões em uma únicadecisão. Já o atributo ReturnPolicyIdList especifica se a lista de políticas utilizadas paratomar a decisão deve ser retornada pelo PDP. Ambos os atributos são definidos para falso(false).

Das linhas 2 a 21 é feita a declaração dos atributos das entidades enviados narequisição. Cada elemento Attributes nas linhas 2, 7, 12 e 17 representa um conjunto deatributos de uma entidade específica. O atributo Category específica a entidade cujosatributos pertencem. No exemplo apresentado são enviados atributos do sujeito (urn:oasis:names:tc:xacml:1.0:subject-category:access-subject), ação (urn:oasis:names:tc:xacml:3.0:attribute-category:action), recurso (urn:oasis:names:tc:xacml:3.0:attribute-category:resource) e ambiente (urn:oasis:names:tc:xacml:3.0:attribute-category:environment), nessa ordem.

Dentro do elemento Attributes são especificados os atributos de cada entidade,através do elemento Attribute, o qual representa um único atributo. Esse elemento éacompanhado por dois atributos, o IncludeInResult e AttributeId. O IncludeInResult é umatributo booleano que especifica se o atributo da entidade deve ser incluído na respostada requisição, enquanto o AttributeId especifica o identificador do atributo sendo utilizado.No exemplo, é enviado um atributo para cada entidade, sendo o identificador do sujeito (urn:oasis:names:tc:xacml:1.0:subject:subject-id), o identificador da ação (urn:oasis:names:tc:xacml:1.0:action:action-id), o identificador do recurso (urn:oasis:names:tc:xacml:1.0:resource:resource-id) e hora do ambiente (urn:oasis:names:tc:xacml:1.0:environment:current-time). O elemento AttributeValue dentro de cada elemento Attribute, nas linhas 4,9, 14 e 19, especifica o valor de cada atributo, com o atributo DataType desse elemento


especificando o tipo de dados. Por fim, o valor de cada atributo na requisição é alice parao identificador do sujeito, access para o identificador da ação, history para o identificadordo recurso e 12:36:25 para a hora do ambiente.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Request CombinedDecision="false" ReturnPolicyIdList="false" xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">3 <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">4 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">5 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>6 </Attribute>7 </Attributes>8 <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">9 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">

10 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>11 </Attribute>12 </Attributes>13 <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">14 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">15 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">history</AttributeValue>16 </Attribute>17 </Attributes>18 <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">19 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time">20 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">12:36:25</AttributeValue>21 </Attribute>22 </Attributes>23 </Request>

Listagem 2.1 – Exemplo de uma XACML Request.

A Listagem 2.2 apresenta um exemplo de XACML Response. Nesse exemplo o valorretornado pelo PDP é Deny. Na linha 1 é feita a declaração da versão do XML sendoutilizada. Na linha 2 é feita a declaração da resposta com o elemento Response e o atributoxmlns especificando o namespace do documento XML para a versão 3 do XACML. Nalinha 2 é declarado o resultado da resposta com o elemento Result. No escopo do elementoResult são declarado dois elementos, o Decision e o Status. O elemento Decision contém adecisão tomada pelo PDP, nesse caso Deny. Já o elemento Status é opcional e representao status da requisição, indicando se ocorreu algum erro durante a avaliação da requisiçãoe informações sobre o erro.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">3 <Result>4 <Decision>Deny</Decision>5 <Status>6 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok" />7 </Status>8 </Result>9 </Response>

Listagem 2.2 – Exemplo de uma XACML Response.

Assim como as mensagens trocadas, as políticas também são definidas em XMLatravés da linguagem para definição de políticas de controle de acesso especificada pelopadrão XACML. Uma representação esquemática, demostrando o relacionamento dos


principais elementos dessa linguagem pode ser vista na Figura 3. Conforme visualizadona figura, alguns desses elementos são, uma Policy, que representa uma única política decontrole de acesso, enquanto um PolicySet representa um conjunto de políticas de controlede acesso, contendo uma ou mais Policy(ies). Por sua vez, uma Policy deve apresentaruma ou mais Rule(s), a qual especifica uma única regra de acesso e possui um único Effect,podendo ser Permit (Permitir) ou Deny (Negar). O Target é um elemento que especifica aaplicabilidade de uma política, estabelecendo em que situações ela deve ser aplicada.

O uso do Target é obrigatório, tanto a nível de uma Policy quanto a nível de umPolicySet, e opcional a nível de uma Rule. Um Target pode conter um ou mais elementosAnyOf, utilizado para montar uma sequência disjuntiva de elementos AllOf, que por suavez é utilizado para montar uma sequência conjuntiva de elementos Match (não mostradona figura). O Match é utilizado para combinação de valores de atributos no contexto deuma requisição enviada pelo ContextHandler. Ele deve conter um elemento AttributeValue,o qual especifica o valor de um atributo, e deve conter um elemento AttributeDesignator ouum elemento AttributeSelector, utilizados para recuperar uma bag de valores de atributosde uma requisição.

Figura 3 – Representação esquemática da linguagem de políticas do XAMCL (OASIS,2013).


Além do Target, uma Rule pode conter um elemento Condition, que representauma função booleana sobre atributos ou funções de atributos. Assim como o Target, umaCondition é utilizada também para definir a aplicabilidade de uma Rule, contudo, umelemento Condition é mais poderoso, na medida em que permite a comparação entreatributos de diferentes entidades. Um elemento que uma Condition pode conter é o Apply(não mostrado na figura), o qual é utilizado para aplicação de funções.

Como um PolicySet pode conter uma ou mais Policy(ies) e uma Policy podeconter uma ou mais Rule(s), o Policy Combining Algorithm e o Rule Combining Algorithm,definem como Policy(ies) devem ser combinadas em um PolicySet e como Rule(s) devem sercombinadas em uma Policy, respectivamente. Por fim, Obligation(s) e Advice(s) representamrestrições adicionais que o PEP deve cumprir antes de aplicar a decisão tomada peloPDP. O cumprimento das restrições em uma Obligation é obrigatório, enquanto que ocumprimento das restrições em um Advice é opcional. Ambos os elementos podem serdefinidos a nível de uma Policy, PolicySet ou Rule.

A Listagem 2.3 apresenta um exemplo de uma política em XACML. Essa políticaem questão, especifica que o sujeito Alice pode acessar seu histórico somente entre as8h e às 18h. Nesse exemplo, na linha 1 é feita a declaração da versão do XML sendoutilizada. Das linhas 2 a 6 é feito o início da declaração da política com o elementoPolicy, juntamente com um conjunto de atributos XML obrigatórios para esse elemento.O atributo xmlns especifica o namespace do documento XML para a versão 3 do XACML,o atributo PolicyId especifica o identificador da política, o atributo RuleCombiningAlgIdespecifica o Rule Combining Algorithm que será aplicado para combinação dos elementosRule na política e o atributo Version indica a versão da política.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="policy1"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Alice pode acessar seu histórico somente no horário de trabalho</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>13 <AttributeDesignator14 AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"15 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"16 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>17 </Match>18 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">19 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>20 <AttributeDesignator21 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"22 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"23 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>24 </Match>25 </AllOf>26 </AnyOf>


27 </Target>28 <Rule Effect="Permit" RuleId="Permit-Rule">29 <Target>30 <AnyOf>31 <AllOf>32 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">33 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">history</AttributeValue>34 <AttributeDesignator35 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"36 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"37 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>38 </Match>39 </AllOf>40 </AnyOf>41 </Target>42 <Condition>43 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">44 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than">45 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">46 <AttributeDesignator47 AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"48 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"49 DataType="http://www.w3.org/2001/XMLSchema#time" MustBePresent="true"/>50 </Apply>51 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">08:00:00</AttributeValue>52 </Apply>53 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than">54 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">55 <AttributeDesignator56 AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"57 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"58 DataType="http://www.w3.org/2001/XMLSchema#time" MustBePresent="true"/>59 </Apply>60 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">18:00:00</AttributeValue>61 </Apply>62 </Apply>63 </Condition>64 </Rule>65 <Rule Effect="Deny" RuleId="Deny-Rule"/>66 </Policy>

Listagem 2.3 – Exemplo de uma política em XACML.

Na linha 7 é feita a descrição da política com o elemento Description. Das linhas 8a 27 é feita a declaração do elemento Target com o elemento AnyOf especificando umasequência disjuntiva de elementos AllOf, que por sua vez especifica uma sequência conjuntivade elementos Match. Cada Match contém um AttributeValue e um AttributeDesignator. UmAttributeValue contém o valor do atributo sendo utilizado e o atributo XML obrigatórioDataType especificando o tipo de dados do valor. Um AttributeDesignator especifica qualatributo de qual entidade está sendo utilizado, através dos atributos XML obrigatóriosAttributeId e Category. O atributo XML obrigatório DataType, assim como no elementoAttributeValue, especifica o tipo de dados do atributo. Por fim, o atributo XML obrigatórioMustBePresent, determina se deve ser retornada uma bag vazia ou Indeterminate caso oatributo especificado não seja encontrado na requisição.

Para o exemplo, o Target da política especifica que ela deve ser aplicada somente arequisições cujos atributo identificador (urn:oasis:names:tc:xacml:1.0:subject:subject-id) do sujeito (urn:oasis:names:tc:xacml:1.0:subject-category:access-subject) tiver o valoralice e o atributo identificador (urn:oasis:names:tc:xacml:1.0:action:action-id) da ação (ur


n:oasis:names:tc:xacml:3.0:attribute-category:action) tiver o valor access. Caso isso sejaverdadeiro, a política é aplicada a uma requisição e o restante dela é avaliado.

O restante do corpo da política é formado por dois elementos Rule, um declaradoentres as linhas 28 e 64 e outro na linha 65. Cada um contém o atributo XML obrigatórioEffect, com o primeiro tendo seu valor definido para Permit e o segundo para Deny. Oatributo XML obrigatório RuleId especifica o identificador da Rule. O primeiro elementoRule é formado por outros dois elementos, um Target e um Condition. O Target refina aaplicabilidade da Rule somente para requisições que contém o atributo identificador (urn:oasis:names:tc:xacml:1.0:action:action-id) de ação (urn:oasis:names:tc:xacml:3.0:attribute-category:action) com valor history. Já o elemento Condition refina ainda mais aaplicabilidade da Rule, utilizando elementos Apply para aplicar funções de comparação detempo do XACML e o elemento AttributeDesignator para referencia o atributo da horaatual. Assim, esse elemento Condition especifica que a Rule deve ser aplicada somente arequisições que contenham o atributo hora atual (urn:oasis:names:tc:xacml:1.0:environment:current-time) do ambiente (urn:oasis:names:tc:xacml:3.0:attribute-category:environment) e o seu valor esteja entre os valores 08:00:00 e 18:00:00 horas. O segundo elementoRule é vazio.

Por fim, caso alguma requisição realizada satisfaça as condições do elemento Targetda política e não atendas as condições estabelecidas no primeiro elemento Rule, ou sejaas condições estabelecidas no elemento Target ou as condições estabelecidas no elementoCondition não sejam satisfeitas, o segundo elemento Rule é avaliado em sequência. Comoesse elemento não possui corpo (é vazio), suas condições sempre serão verdadeiras e elesempre será aplicado caso o primeiro não seja, e como seu efeito é negar, o resultado dapolítica para essas requisições será sempre negar.

Uma das caraterística do XACML é sua capacidade de extensão, podendo serestendida de várias formas, facilitando sua introdução em diferentes contextos, com aprópria especificação apresentando uma seção na qual lista seus pontos de extensão. Porexemplo, embora defina um conjunto padrão de entidades, seus atributos, tipos de dados efunções para combinação de atributos, novos elementos podem ser facilmente adicionadosa uma implementação.

Uma das formas de estender o XACML é por meio de perfis. Um perfil XACML(XACML profile) é uma proposta de extensão na especificação padrão que define comoutilizar XACML em um cenário específico, estabelecendo as melhores práticas para suautilização, propondo mudanças na arquitetura padrão com a adição de novos componentesou a modificação dos existentes, ou com a definição de novos elementos para as linguagensde definição de políticas e troca de mensagens. Vários perfis já foram e continuam a serpropostos. Alguns exemplos de perfis são o SAML Profile, que especifica como utilizarXACML em uma federação SAML, o RBAC Profile, que especifica como utilizar XACML


junto com RBAC e o Privacy Policy Profile que especifica como garantir a privacidadedos usuários na utilização do XAMCL.

O RBAC Profile, por exemplo, especifica como escrever políticas que satisfaçam osrequisitos do Core RBAC e do Hierarchical RBAC da especificação RBAC do ANSI (ANSI,2004). Para tanto, esse perfil define um novo atributo para representar o papel de umsujeito no sistema e diferences tipos de políticas com estrutura padrão para representar orelacionamento entre sujeitos, papeis e permissões.

2.3 Gerenciamento de IdentidadesGerenciamento de identidades (Identity Management - IdM) consiste de um sistema

integrado de políticas, tecnologias e processos de negócios que permite a uma organiza-ção prover serviços de forma segura e garantir a privacidade das informações dos seususuários (JOSANG; POPE, 2005). O gerenciamento de identidades é fundamentadoem processos que possibilitam o gerenciamento de todo o ciclo de vida de identidadesassociadas a entidades em um determinado contexto, utilizando um conjunto de funções ecapacidades que permitem a garantia da identidade de uma entidade e das informaçõescontidas nessa identidade, permitindo a realização de transações comerciais de formasegura (CHADWICK, 2009).

A identificação de um indivíduo em um sistema é essencial para conceder o acessoa recursos e serviços e permitir realização de ações. Assim, o processo de gerenciamento deidentidades é fundamental para garantir o sucesso de outros serviços de segurança, comoautenticação, autorização, auditoria e controle de acesso, uma vez que eles se baseiamfortemente na identidade de um indivíduo acessando um sistema. Portanto, as informaçõesda identidade de um usuário possibilitam sua autenticação no sistema, a aplicação deregras de autorização e o registro de suas ações.

Todos os usuários que acessam um sistema possuem uma identidade. Uma identidadeconsiste de um conjunto de informações relacionadas a uma entidade em um determinadocontexto, que permite que ela seja identificada unicamente nesse contexto. Uma entidadepode ser uma pessoa ou uma organização, e as informações que compõe a identidadesão chamadas de atributos e compreende um conjunto de características da entidadenecessárias para sua identificação e realização de ações no sistema. Não existe duas oumais entidades em um dado sistema com a mesma identidade. Além disso, um indivíduopode ter mais de uma identidade em um mesmo sistema, por exemplo, um usuário de umsistema de gestão de atividades acadêmicas pode ser tanto aluno como funcionário emuma instituição de ensino, possuindo assim um identidade para cada papel desempenhado(JOSANG; POPE, 2005).

A identidade de um usuário é composta por uma grande quantidade de informações,


que podem englobar desde dados pessoais, como nome e idade, a características físicas comodados biométricos, ou cargos ocupados, reponsabilidades e privilégios em uma organização.Cada sistema determina, conforme seus requisitos, as informações necessárias que farãoparte da identidade de um indivíduo. De fato, diferentes sistemas podem utilizar as mesmasinformações nas identidades dos seus usuários (WANGHAM et al., 2010).

Um aspecto importante da identidade é o atributo identificador, um atributo capazde identificar unicamente uma entidade em um domínio, não existindo duas ou maisentidades com o mesmo valor para o atributo identificador, embora possam compartilharsemelhança entre outros atributos. Um identificador está fortemente relacionado ao domíniono qual ele foi definido, no sentido que ele não pode ser movido de forma significativaentre domínios. Assim, diferentes sistemas utilizam diferentes identificadores, podendohaver sistuações nas quais sistemas distintos possam utilizar o mesmo identificador paraidentificar diferentes indivíduos (CHADWICK, 2009).

Além das entidades, que comumente correspondem a indivíduos que acessam umsistema, e das suas respectivas identidades, um sistema de gerenciamento de identidadesengloba também um ou mais Provedor de Identidades (Identity Provider - IdP), umcomponente confiável responsável por gerenciar identidades e autenticar usuários, e um oumais Provedores de Serviço (Service Provider - SP) 4, um componente que disponibilizarecursos e serviços a usuários. Nesse contexto, a comunicação entre IdP e SP ocorre atravésda troca de mensagens, por meio das quais o IdP é responsável por emitir mensagenscontendo credenciais de autenticação e autorização de seus usuários a um SP confiável.

Um Sistema de gerenciamento de identidades provê as ferramentas necessáriaspara a gestão de identidades. De acordo com (WANGHAM et al., 2010), sistemas degerenciamento de identidades podem ser classificados em tradicional (isolado), centralizado,federado ou centrado no usuário.

No modelo tradicional, cada Provedor de Serviço é responsável por, além de oferecere gerenciar recursos e serviços, gerenciar a identidade de seus usuários, atuando tambémcomo um Provedor de Identidade. Nesse modelo, um indivíduo tem múltiplas identidades,cada uma associada a um sistema ao qual ele acessa, tornando necessário de sua partea memorização de todas as suas identidades, especialmente os atributos identificadorese atributos correspondentes a tokens de autenticação, utilizados pelos sistemas pararealização do processo de autenticação.

O modelo centralizado se caracteriza pela presença de um único Provedor deIdentidades central em um determinado domínio, responsável pelo gerenciamento deidentidades e autenticação dos usuários, no qual todos os Provedores de Serviço devemconfiar nas informações emitidas por esse Provedor de Identidade. Nesse modelo há o

4 Deste momento em diante os termos Provedor de Identidade e IdP e Provedor de Serviço e SP serãoutilizados de maneira intercambiável


conceito de autenticação única (Single Sign On - SSO), no qual usuários se autenticandouma única vez junto ao seu Provedor de Identidade, são capazes de utilizar os demaisserviços dos Provedores de Serviço sem precisar se autenticar novamente.

No modelo federado, também chamado de modelo de Gestão de Identidades Fede-radas (Federated Identity Management - FIM), a responsabilidade de gerenciamento deidentidades e autenticação de usuários é distribuída entre múltiplos Provedores de Identi-dades, pertencentes a diferentes domínios administrativos. Um domínio administrativopode, por exemplo, representar uma instituição, podendo conter um ou mais Provedoresde Serviço. Nesse modelo são estabelecidos acordos entre as instituições dos diferentesdomínios, formando uma relação de confiança mútua conhecida como federação, permi-tindo que um usuário, proveniente do IdP de um determinado domínio, possa, com umaidentidade única, uma vez identificado e autenticado no seu IdP, acessar serviços providospor Provedores de Serviços em outros domínios. Assim como no modelo centralizado, oSSO é inerente ao modelo federado.

No contexto do gerenciamento de identidades federadas, a Linguagem de Marcaçãopara Asserções de Segurança (Security Assertion Markup Language – SAML) é um padrãoaberto baseado em XML, especificado e publicado pela OASIS5, utilizado para troca deinformações de autenticação e autorização entre parceiros de negócio em uma federação. Oprojeto Shibboleth, iniciativa do consórcio americano Internet2, é um exemplo de sistemaque implementa o padrão SAML, permitindo o estabelecimento de uma federação entreaplicações de diferentes domínios para o compartilhamento seguro das informações dasidentidades dos usuários.

Por fim, embora haja outros modelos de gerenciamento de identidades, como omodelo centrado no usuário, com foco na privacidade dos dados da identidade, no qualo indivíduo tem total controle sobre os seus dados, determinando quais informações daidentidade e para quem elas são liberadas, os modelos abordados aqui são comumente osmais utilizados.

2.4 Considerações FinaisEsse capítulo abordou os principais temas envolvidos na realização desse trabalho,

apresentando os conceitos fundamentais relacionados a Controle de Acesso e Gerenciamentode Identidades, dois processos de importância vital para garantir a segurança de sistemas,destacando suas principais características, modelos e padrões. Além disso, foi abordadotambém XACML, um padrão aberto baseado em XML que fornece uma solução completapara controle de acesso com granularidade fina.

5 <https://www.oasis-open.org/committees/security/>

https://www.oasis-open.org/committees/security/


Assim, o foco do presente trabalho consiste em propor a utilização de XACMLpara definição de políticas de controle de acesso em ambientes federados, a partir dodesenvolvimento de uma nova versão do FACS. Mais especificamente, o foco está emfederações que utilizam o padrão SAML por meio do sistema Shibboleth, como é o casoda Comunidade Acadêmica Federada (CAFe).

36

3 FACS

Este capítulo apresenta de forma resumida o sistema FACS, que foi apresentadoem um artigo do Simpósio Brasileiro em Redes de Computadores e Sistemas Distribuídos(SBRC) em 2015 (DINIZ et al., 2015). Iniciamos descrevendo uma visão geral do FACS,sua arquitetura, e concluímos com um breve levantamento de suas limitações.

3.1 Visão GeralO FACS (Federated Access Control System) é um sistema de controle de acesso

hierárquico, proposto para resolver os problemas relacionados a controle de acesso en-frentados em (DINIZ et al., 2015), na implantação de um serviço de armazenamento denuvem em uma federação de identidades na forma de um Provedor de Serviço.

Nesse cenário, o serviço de nuvem, ainda em sua fase experimental, não poderiapermitir o acesso de todos os usuários da federação devido à suas capacidades limitadas emodelo de implantação, que consistiu em um modelo comunitário no qual instituições quecontribuíam com a capacidade do serviço poderiam selecionar usuários para usufruir dassuas funcionalidades.

Contudo, uma vez na federação, um Provedor de Serviço pode ser acessado porqualquer usuário vinculado a qualquer IdP, ficando a cargo do próprio Provedor de Serviçocontrolar o acesso dos usuários da federação. Desse modo, o FACS foi proposto como umasolução que permita a administradores de SP controla o acesso dos usuários da federaçãoatravés da definição de políticas de controle de acesso. Além disso, o FACS tambémpermite que administradores de SP deleguem a administradores de IdP a capacidade degerenciamento de políticas de controle de acesso ao SP.

O FACS foi integrado ao serviço edudrive@RNP1, baseado no ownCloud2, com umalto nível de acoplamento, e suportando a definição de políticas de controle de acesso comalta-granularidade (tendo sido utilizado inicialmente para se definir quais usuários temacesso ao serviço).

3.2 Arquitetura do FACSA arquitetura do FACS é apresentada na figura 4. A esquerda tem-se um Provedor

de Serviço qualquer da federação com seu sistema de controle de acesso retratado segundo1 <https://edudrive.rnp.br/>2 <https://owncloud.org/>

https://edudrive.rnp.br/

https://owncloud.org/

Capítulo 3. FACS 37

os componentes do ABAC. A direita tem-se o FACS propriamente dito. A arquitetura doFACS é composta pelo System Administration Module, IdP Management Module, AccessManagement Module, SP Adapter e o PDP.

Figura 4 – Arquitetura do FACS (DINIZ et al., 2015).

O System Administration Module é o módulo utilizado pelo administrador doFACS (FACS Admin) para gerenciamento dos Provedores de Identidades, Provedores deServiços e seus administradores. O IdP Management Module é o módulo utilizado pelosadministradores dos Provedores de Serviços (SP Admin) para gerenciar os Provedoresde Identidades autorizados a acessarem os serviços. O Access Management Module é omódulo utilizado pelos administradores dos Provedores de Serviço para gerenciamentode políticas de controle de acesso, podendo ser utilizado também pelos administradoresde IdP quando o gerenciamento de controle de acesso é delegado pelo SP Admin a eles.Por fim, o SP Adapter é responsável por propagar as políticas definidas no FACS para osProvedores de Serviço no formato compreendido por cada um.

As políticas de controle de acesso gerenciadas pelo FACS são classificadas emdois níveis, políticas independentes de SP e políticas dependentes de SP. As políticasindependentes de SP especificam que usuários, de quais instituições podem acessar umdeterminado Provedor de Serviço, sendo armazenadas no repositório de políticas doFACS. Já as para políticas dependentes de SP estabelecem os privilégios dos usuários nosProvedores de Serviço, sendo propagadas para cada Provedor de Serviço ao qual foramdefinidas por meio do SP Adapter.

O nível de políticas independentes de SP contempla diferentes formas de acesso, asquais podem ser vistas na figura 5, que apresenta um fluxograma destacando os cenáriosde controle de acesso possíveis em uma federação e contemplados pelo FACS. Quando


um usuário de um IdP tenta acessar um SP, o PEP do SP irá interceptar a requisição econsultará o PDP para verificará se o usuário está autorizado a acessar o serviço. Casoesteja, o acesso é liberado. Caso contrário, o PEP do SP irá consulta o PDP do FACSquestionando se o usuário em questão pode ou não acessar o serviço. O FACS, por suavez, irá executar o fluxo da figura 5.

Assim, na sua forma mais básica, um IdP não está cadastrado no FACS ou emboraesteja cadastrado não foi autorizado a acessar o serviço. Caso algum usuário deste IdPtente acessar o serviço, o acesso será negado. Por outro lado, para um IdP cadastrado noFACS e autorizado a acessar o serviço, há três formas de acesso possíveis: automática,manual e baseado em políticas.

Figura 5 – Fluxo para políticas independentes de SP do FACS (DINIZ et al., 2015).

O modo de acesso automática representa o funcionamento básico de uma federação,no qual usuários de um IdP podem acessar automaticamente um Provedor de Serviço.No modo de acesso manual, quando um usuário tenta acessar um Provedor de Serviçoé criada uma solicitação de acesso para ser processada pelo administrador do SP. Porúltimo, no modo baseado em políticas, o acesso dos usuários é controlado com base empolíticas definidas pelo administrador do SP. O administrador do IdP também é capazcontrolar a acesso dos usuários do seu IdP ao Provedor de Serviço, caso o administradordo SP delegue essa capacidade.

3.3 LimitaçõesEmbora o objetivo do FACS seja gerenciar o controle de acesso de usuários a

Provedores de Serviço em uma federação através da definição de políticas de controle deacesso, não foi especificado nenhum padrão para definição de políticas, tanto para políticasdependentes de SP quanto para políticas independentes de SP quando o modo de acesso édefinido para baseado em políticas. Além disso, ainda que o FACS tenha sido propostocomo um sistema genérico capaz gerenciar o acesso para qualquer Provedor de Serviço


em uma federação, não foi apresentado os passos necessários para sua integração a outrosserviços.

A ausência de um padrão para definição de políticas de controle de acesso exigiria ofornecimento de uma interface em conformidade com a linguagem de autorização utilizadapor cada Provedor de Serviço integrado ao FACS, para permitir a gestão das políticaspor parte dos administradores de cada Provedor de Serviço, exigindo um alto custo dedesenvolvimento na integração de cada novo Provedor de Serviço. Assim, adotar umpadrão para definição de políticas de controle de acesso estabeleceria uma interface comum,permitindo que diferentes políticas utilizem a mesmo formato, facilitando sua definição,armazenamento, manipulação e avaliação.

Ainda que tenha sido definido que cada Provedor de Serviço integrado ao FACSprecise de um SP Adapter para tradução de políticas de controle de acesso para o formatoespecificado pelo Provedor de Serviço, não foi especificado a estrutura que um SP Adapterdeve contemplar, assim como não foi especificado como ele deve ser desenvolvido e integradoao FACS, dificultando a integração de novos Provedores de Serviço.

40

4 Nova Implementação Proposta para oFACS

Este capítulo apresenta os detalhes da introdução de XACML no FACS, abordandosua integração ao servidor de autorização WSO2 Identity Server e a ferramenta opensource para criação de nuvens privadas CloudStack.

4.1 Abordagem PropostaA fim de padronizar a definição de políticas de controle de acesso tanto para

políticas dependentes de SP, quanto para políticas independentes de SP quando o modode acesso for definido para baseado em políticas, e suportar a definição de políticas decontrole de acesso com granularidade fina, é proposto a utilização de XACML em conjuntocom um servidor de autorização.

Assim, foi desenvolvida uma nova versão do FACS integrado ao servidor de autori-zação WSO2 Identity Server (WSO2 IS). A Figura 6 apresenta a arquitetura do FACSintegrada ao servidor de autorização. Conforme pode ser visto, todos os componentes defi-nidos originalmente (SP Adapter, Access Management Module, IdP Management Module,e System Administration Module) são mantidos, passando a destacar o seu PAP e introdu-zindo o servidor de autorização para os aspectos relacionados a definição, armazenamentoe avaliação de políticas de controle de acesso em XACML. O PDP e o PAP do FACSpassam a se comunicar com o servidor de autorização. Deste modo, os componentes doFACS interagem com o WSO2 IS através de sua interface PAP para o gerenciamento depolíticas em XACML, e com sua interface PDP para avaliação requisições de acesso emXACML.

Uma vez definidas em XACML, as políticas do modo de acesso baseado em políticas,das políticas independentes de SP, serão enviadas para o PAP do servidor de autorização,enquanto que as políticas dependentes de SP serão enviadas diretamente para o SP Adapterdo Provedor de Serviço. Assim, um SP Adapter terá que se comportar como um XACMLEngine, sendo capaz de compreender e traduzir uma política em XACML para a linguagemutilizada pelo Provedor de Serviço, a fim de atualizar o seu repositório de políticas.

Como as políticas de controle de acesso serão definidas pelos administradoresdos Provedores de Serviços e pelos administradores dos Provedores de Identidades paraProvedores de Serviços específicos, e devido ao poder de expressividade do XACML,permitindo a representação de diferentes políticas de controle de acesso, assim comodiferentes representações para uma mesma política, torna-se necessário restringir o escopo

Capítulo 4. Nova Implementação Proposta para o FACS 41

Figura 6 – Arquitetura do FACS integrada ao servidor de autorização.

para definição de políticas, limitando tanto a estrutura das políticas permitidas, oselementos da linguagem utilizados e as entidades, seus atributos, tipos de dados e valorespermitidos.

Além disso, a introdução de restrições para definição de políticas em XACML noFACS, garante que um administrador de Provedor de Serviço defina políticas independentesde SP, do modo de acesso baseado em políticas, dentro do escopo da federação apenas parao seu Provedor de Serviço, e políticas dependentes de SP dentro do escopo dos recursose serviços providos pelo seu Provedor de Serviço. Tal abordagem, restringe também oescopo para definição de políticas para administradores de Provedores de Identidades,garantindo que um administrador defina políticas apenas para usuários do seu Provedorde Identidade. Essa abordagem também facilitará o desenvolvimento do SP Adapter, umavez que cada um saberá a estrutura exata da política e os elementos utilizados na suadefinição, facilitando a análise, interpretação e tradução da política em XACML para umapolítica no formato da linguagem de políticas utilizada por um Provedor de Serviço.

As restrições para definição de políticas de controle de acesso em XACML ocorreatravés da definição de perfis XACML (XACML Profiles), mais especificamente um únicoperfil para políticas independentes de SP1 e um perfil de políticas dependentes de SP paracada Provedor de Serviço que for integrado ao FACS. Para o presente trabalho foram

1 Embora o nome seja perfil de políticas independentes de SP, esse perfil foi definido apenas para o modode acesso baseado em políticas das políticas independentes de SP gerenciadas pelo FACS.


definidos três perfis, o perfil de políticas independentes de SP e dois perfis de políticasdependentes de SP, um para o próprio FACS e outro para o CloudStack. Com relaçãoas entidades e seus atributos, todos os perfis definidos utilizam as entidades definidasna especificação padrão do XACML, contudo para os atributos, alguns dos utilizadossão da especificação padrão e outros são definidos para cada perfil a fim de atender asnecessidades específicas do contexto ao qual cada perfil foi definido.

Na prática, o FACS atua como um Provedor de Serviço na federação, fornecendoo serviço de controle de acesso a outros Provedores de Serviços. Embora não tenha sidoabordado no trabalho de (DINIZ et al., 2015), o novo FACS aqui proposto é projetado paragerenciar o controle de acesso de si próprio, definindo o que cada usuário está permitido arealizar no sistema. Por isso, um perfil de políticas dependentes de SP também foi definidopara o FACS.

O perfil de políticas independentes de SP foi definido e é validado pelo FACS.Esse perfil específica que somente o elemento Policy pode ser utilizado para definição depolíticas, e que toda política definida deve conter obrigatoriamente um elemento Targetespecificando para qual Provedor de Serviço e para qual Provedor de Identidade ela deve seraplicada, bem como o tipo de ação que está sendo realizada, que nesse caso será sempre seráacessar (access). O restante do corpo da política fica a critério do administrador, desde queatenda as restrições de elementos e entidades permitidas. Com relação a essas restrições, operfil limita os elementos permitidos somente aos elementos da linguagem para definiçãode políticas apresentados na Figura 3, que apresenta os principais elementos da linguagem.Já para entidades e seus atributos, somente os definidos na Tabela 2 podem ser utilizados.Conforme pode ser visualizado, os atributos do sujeito (subject), retratam exatamente osatributos do esquema LDAP definido para Comunidade Acadêmica Federada (CAFe), oesquema brEduPerson2. Assim, o atributo brEduAffiliationType do subject, por exemplo,permite apenas os valores definidos na especificação desse esquema. A listagem completa,de elementos e entidades permitidas é apresentada no Apêndice A.

Um exemplo de política em conformidade com o perfil de políticas independentesde SP é apresentado na Listagem 4.1. Essa política em questão especifica que somenteusuários do IdP do IMD que possuírem um vínculo do tipo position podem acessar o FACS.Como a estrutura geral de uma política em XACML já foi detalhada anteriormente, serádestacado apenas os principais pontos dessa política, importantes para compreensão doperfil. Assim, conforme pode ser visto, o Target da política, declarado entre as linhas 8 e38, possui exatamente três elementos Match, nos quais são especificados o Provedor deIdentidade, o Provedor de Serviço e ação a ser realizada, nessa ordem, de acordo com operfil. O primeiro elemento Match, entre as linhas 11 e 19, especifica o identificador doprovedor serviço (urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:sp

2 <https://memoria.rnp.br/_arquivo/servicos/Esquema_brEduPerson.pdf>

https://memoria.rnp.br/_arquivo/servicos/Esquema_brEduPerson.pdf


Tabela 2 – Entidades e atributos permitidos definidos no perfil de políticas independentesde SP.

Entidade Atributoaction action-id

environment

current-timecurrent-datecurrent-dateTimesp-entityididp-entityid

subject

cnsnuidmaileduPersonPrincipalNameschacCountryOfCitizenshipbrEduAffiliationbrEduAffiliationTypebrEntranceDatebrExitDate

-entityid) para o qual a política está sendo definida e o valor https://cloudstack.imd.ufrn.br.O segundo elemento Match, entre as linhas 20 e 28, especifica o identificador do provedorde identidade (urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:idp-entityid) para o qual a política se aplica e o valor https://idp.imd.ufrn.br/idp/shibboleth. Oterceiro elemento Match, entre as linhas 29 e 35, especifica o identificador da ação (urn:oasis:names:tc:xacml:3.0:attribute-category:action) e o valor access.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="facs-sp-independent-policy-for-facs"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Política para permitir o acesso com base no vínculo do usuário</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">13 https://cloudstack.imd.ufrn.br14 </AttributeValue>15 <AttributeDesignator16 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:sp-entityid"17 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"18 DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false" />19 </Match>20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">22 https://idp.imd.ufrn.br/idp/shibboleth23 </AttributeValue>24 <AttributeDesignator25 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:idp-entityid"26 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"


27 DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false" />28 </Match>29 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">30 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>31 <AttributeDesignator32 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"33 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"34 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false" />35 </Match>36 </AllOf>37 </AnyOf>38 </Target>39 <Rule Effect="Permit" RuleId="Permit-Rule">40 <Target>41 <AnyOf>42 <AllOf>43 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">44 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">position</AttributeValue>45 <AttributeDesignator46 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEduAffiliationType"47 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"48 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />49 </Match>50 </AllOf>51 </AnyOf>52 </Target>53 </Rule>54 <Rule Effect="Deny" RuleId="Deny-Rule" />55 </Policy>

Listagem 4.1 – Exemplo de política XACML em conformidade com perfil de políticasindependentes de SP.

O restante do corpo da política é formado por dois elementos Rule, um entre aslinhas 39 e 53, e outro na linha 54. O primeiro, cujo efeito é Permit, possui um elementoTarget, especificando que essa regra será aplicada somente se o tipo da afiliação do sujeito(urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEduAffiliationType) forposition. Caso o Target do primeiro elemento Rule não seja satisfeito, o segundo com efeitoDeny será sempre aplicado, uma vez que é um elemento vazio. Assim, caso algum usuáriodo IdP IMD estiver tentando acessar o provedor de serviço FACS, seu acesso será negadopor essa política a menos que a sua afiliação seja do tipo position.

O perfil de políticas dependentes de SP definido para o FACS permite a definiçãode políticas que estabelecem o que cada administrador pode fazer no sistema e quaisProvedores de Identidades e Provedores de Serviço eles podem gerenciar. Da mesma formaque o perfil de políticas independentes de SP, esse perfil limita os elementos permitidossomente aos elementos da linguagem para definição de políticas apresentados na Figura 3.Já as entidades e atributos permitidos são apresentados na Tabela 3.

Os valores permitidos para o atributo role da entidade subject, por exemplo, sãoFACS_ADMIN, SP_ADMIN, IDP_ADMIN e USER, representando os diferentes tiposde usuário que acessam o FACS. Para o atributo resource-name da entidade resource,os valores permitidos são SERVICE_PROVIDERS, IDENTITY_PROVIDERS, AC-CESS_CONTROL e USERS, representando os diferentes recursos gerenciados pelo FACS.


Tabela 3 – Entidades e atributos permitidos definidos no perfil de políticas dependentesde SP do FACS.


resource resource-idresource-name

subjectsubject-ididp-entityidrole

Já para o atributo action-id da entidade action, os valores permitidos são MANAGE eCREATE, representado as diferentes ações que um usuário do FACS pode realizar sobre osrecursos providos. A listagem completa, de elementos e entidades permitidas é apresentadano Apêndice A.

Um exemplo de política em conformidade com esse perfil é apresentado na Listagem4.2. Essa política em questão especifica que o usuário que possui o identificador do sujeito(urn:oasis:names:tc:xacml:1.0:subject:subject-id) com valor alice pode gerenciar o recursocom identificador https://idp.imd.ufrn.br/idp/shibboleth, o qual representa um Provedorde Identidade. Isso significa que esse usuário pode criar políticas de controle de acessopara usuários desse IdP.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="facs-idp-manage-policy-1"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Um admin específico pode gerenciar um SP ou IdP específico</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>13 <AttributeDesignator14 AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"15 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"16 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>17 </Match>18 </AllOf>19 </AnyOf>20 </Target>21 <Rule Effect="Permit" RuleId="Permit-Rule">22 <Target>23 <AnyOf>24 <AllOf>25 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">26 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">27 https://idp.imd.ufrn.br/idp/shibboleth28 </AttributeValue>29 <AttributeDesignator30 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"31 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"32 DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false"/>33 </Match>


34 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">35 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MANAGE</AttributeValue>36 <AttributeDesignator37 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"38 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"39 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false" />40 </Match>41 </AllOf>42 </AnyOf>43 </Target>44 </Rule>45 <Rule Effect="Deny" RuleId="Deny-Rule" />46 </Policy>

Listagem 4.2 – Exemplo de política XACML em conformidade com perfil de políticasdependentes de SP do FACS.

Conforme pode ser visto na listagem, das linhas 8 a 22 é declarado o Target dapolítica, especificando que ela deve ser aplicada somente a requisições cujo o identificadordo sujeito (urn:oasis:names:tc:xacml:1.0:subject:subject-id) seja alice. Assim como napolítica anterior, essa política possui dois elementos Rule com efeitos Permit e Deny, naordem, sendo que o primeiro possui um elemento Target com uma sequência conjuntiva dedois elementos Match, especificando que esse elemento Rule deve ser aplicado somente arequisições cujo identificador do recurso (urn:oasis:names:tc:xacml:1.0:resource:resource-id) seja https://idp.imd.ufrn.br/idp/shibboleth e o identificador da ação (urn:oasis:names:tc:xacml:1.0:action:action-id) seja MANAGE. Caso o Target não seja satisfeito, o segundoelemento Rule, que é um elemento vazio, será sempre aplicado, e a requisição será negada,uma vez que seu efeito é Deny.

4.2 Integração com WSO2 Identity ServerWSO23 é uma companhia focada no desenvolvimento de tecnologias open source

para serviços que utilizam o estilo arquitetural Arquitetura Orientada a Serviços (Service-Oriented Architecture - SOA). Entre os seus produtos está o Identity Server, uma soluçãocompleta para Controle de Acesso e Gerenciamento de Identidades (Identity and AccessManagement - IAM), que atua de forma agnóstica, independente da tecnologia utilizada. OIdentity Server suporta vários padrões de autenticação, dentre os quais SAML 2.0, OpenID,WS-Trust, WS-Federation, Integrated Windows Authentication e OAuth2-OpenID Connect.Além de fornecer suporte a RBAC e políticas de controle de acesso com granularidade finaatravés de XACML.

O WSO2 Identity Server (WSO2 IS) é formado por diversos componentes, cada umprovendo serviços específicos no escopo de IAM. Com respeito a controle de acesso comgranularidade fina, o WSO2 IS fornece uma implementação em conformidade com a versão

3 <https://wso2.com/>

https://wso2.com/


3 da especificação do XACML. Sua XACML Engine é formada por dois componentesprincipais, o PAP e o PDP.

Para interação, o WSO2 IS fornece duas interfaces, uma interface gráfica e umaAPI. A interface gráfica, conhecida como Management Console, consiste de uma interfaceweb destinada a usuários finais, através da qual pode-se utilizar os serviços providos pelosseus componentes. Já a API, voltada para integração com outros sistemas, é provida pelosdiferentes componentes que compõem o WSO2 IS, sendo que alguns disponibilizam umaAPI REST e outros uma API SOAP, ou ambas as tecnologias.

O WSO2 IS disponibiliza uma API SOAP para acesso ao PAP e ao PDP, interfacesutilizadas para integração com o FACS. Assim, o FACS consome o serviço de gerenciamentode políticas em XACML oferecido pela interface SOAP do PAP do WSO2 IS paragerenciamento das políticas de controle de acesso independentes de SP, e consome o serviçode avaliação de requisições XACML oferecido pela interface SOAP do PDP do WSO2 ISpara avaliação dessas políticas.

4.3 Integração com CloudStackCloudStack4 é uma plataforma open source para criação de infra-estrutura de

nuvens privadas, fornecendo todo o conjunto de recursos necessários para criar e manteruma Infraestrutura como Serviço (Infrastructure as a Service - IaaS). Sendo utilizado pelaRNP para criar a Nuvem Acadêmica Brasileira5. Como IaaS o CloudStack fornece umavariedade de recursos que podem ser alocados aos usuários, como por exemplo máquinasvirtuais, armazenamento, processamento, endereços IP, entre outros.

Projetado com uma arquitetura modular, flexível e extensível, o qual permite aextensão de suas capacidades por meio da criação de plugins, o núcleo da arquiteturado CloudStack é formado por dois módulos, o Mangement Server (responsável pelogerenciamento da nuvem) e o ServerReource (responsável por fornecer uma camadacom o hardware). O Management Server é o principal componente do CloudStack, suasfuncionalidades principais são atuar na orquestração e alocação de recursos na nuvem,fornecendo uma interface web que pode ser acessada por administradores para gerenciara nuvem e usuários finais para usufruir dos recursos providos. Além disso esse módulo écomposto de vários outros componente, cada um com uma responsabilidade específica,conforme pode ser visualizado na figura 7, que apresenta as várias partes do ManagementServer.

IAM no CloudStack possui uma solução simples, limitada e funcional, estando emconstante evolução, conforme o lançamento de novas versões e desenvolvimento de plugins

4 <https://cloudstack.apache.org/>5 <https://compute.rnp.br/>

https://cloudstack.apache.org/

https://compute.rnp.br/


Figura 7 – Arquitetura do CloudStack.

Fonte: Documentação do CloudStack.

pela comunidade para adicionar mais flexibilidade e maior granularidade ao controle deacesso e gerenciamento de usuários.

Com um controle de acesso baseado no modelo RBAC, o CloudStack não permitiaa definição de papeis até a versão 4.8, disponibilizando quatro papeis padrões para serematribuídos aos usuários da nuvem. O Root Admin (responsável por configurar e gerenciara nuvem), o Doamin Admin (responsável por gerenciar um domínio e seus subdomínios),o Resource Owner (responsável por controlar recursos da nuvem) e o User (usuáriosfinais que vão usufruir dos recursos providos). Contudo, a partir versão 4.9 em diante, foiintroduzida a funcionalidade que permite a criação de novos papeis, que apesar de não seruma solução RBAC completa, dá maior flexibilidade para os administradores da nuvem.

Associado aos conceitos de domains, projects, accounts e users, o CloudStack permitea definição de papeis e a associação de permissões aos papeis definidos, no sentido de quaisoperações podem ser realizadas. Os papeis, por sua vez, são atribuídos a accounts. Umaaccount representa uma unidade organizacional, é atribuída a um domínio e pode possuirvários users. Users representam diferentes formas de acessar uma mesma Account, podemse autenticar e acessar os recursos da nuvem. Projects são entidades de gerenciamentoadicionais, que permite o controle de acesso a recursos entre accounts de diferentesdomains. Por fim, os recursos da nuvem são alocados a Domains, Accounts e Projects


pelo administrador do sistema, pelo administrador do domínio ou pelo administrador derecursos. O relacionamento entre esses conceitos é apresentado na figura 8.

Figura 8 – Entidades do sistema de controle de acesso do CloudStack.

Para exemplificar a aplicação desses conceitos na prática, com o mapeamentoentre os conceitos de controle de acesso do CloudStack e as unidades organizacionais deuma instituição, consideremos um cenário no qual uma nuvem gerida pelo CloudStackseria fornecida a várias instituições de ensino e pesquisa, cada uma formada por váriosdepartamentos, no qual cada um é composto por vários setores e grupos de pesquisa, eesses por sua vez são formados por vários usuários que gostariam da acessar a nuvem parausufruir dos recursos providos e poderem realizar suas tarefas diárias.

Nesse contexto, cada instituição juntamente com seus departamentos, setores egrupos de pesquisa são representados por meio de domínios e subdomínios. Por padrão, oCloudStack vem com o domínio ROOT, no qual todos os outros domínios são subdomíniosdeste. Somente users cuja account pertencem ao domínio ROOT podem ser adminis-tradores da nuvem (Root Admin). Para cada unidade organizacional, poderia ser criadoum subdomínio, que poderia ter várias accounts com diferentes papeis associados, comoadministradores para cada domínio (Domain Admin) e usuários (User).

Além disso, projetcs poderiam ser criados para controlar a distribuição de recursosentre accounts de diferentes domínios. Users cuja accounts pertencem ao domínio ROOTe tem o papel de administrador, seriam responsáveis por gerenciar a nuvem, distribuindorecursos entre os domínios, que por sua vez os administradores de domínios seriam respon-sáveis por controlar a distribuição dos recursos entre os usuários de cada domínio. Nesse


cenário novos papeis com diferentes permissões poderiam ser criados e atribuídos a novasaccounts, caso alguma instituição solicitasse um novo nível de acesso ou o administradorda nuvem necessitasse de um controle de acesso mais granular.

Para interação com os usuários, o CloudStack fornece três interfaces. A primeira,uma interface gráfica pro usuário (Graphical User Interface - GUI) na forma de aplicaçãoweb, consiste em uma dashboard que pode ser utilizada tanto por administradores paraauxiliar o gerenciamento, controle e provisão de recursos da nuvem, quanto por usuáriosfinais. A segunda, uma interface de linha de comando (Command Line Interface - CLI)conhecida como CloudMonkey, que fornece as mesmas capacidades da interface web epermite a administradores gerir a nuvem pela linha de comando. Por último, uma APIREST, usada mais para desenvolvimento de ferramentas e interações com outros serviços.Essa é dividade em quatro partes, como pode ser visualizado na figura 7 na camadaCloudStack WebServices API. A OAM&P (Operations, Administration, Maintenance, andProvisioning) API é destinada a administradores para gerenciamento da nuvem, a EndUser API é destinada aos usuários finais, a AWS API é destinada para compatibilidadecom serviços que desejam migrar da AWS (Amazon Web Services) para o CloudStack e aAPI fornecida por plugins, que estendem as capacidades do CloudStack.

Nesse trabalho, estamos interessados em interagir com o CloudStack através da suaAPI, que será utilizada para integração com o FACS, por meio da definição de politicasde controle de acesso. Para tanto, será necessário utilizar a OAM&P API e a End UserAPI, que permitem, dentre outras possibilidades, o gerenciamento de usuários e o controlede acesso a recursos da nuvem, capacidades necessárias para a propagação das políticasdefinidas no FACS.

A integração entre o CloudStack e o FACS ocorreu através da definição de umSP Adapter para o mesmo. Esse componente é responsável por implementar o perfil depolíticas dependentes de SP do CloudStack para validação das políticas definidas, atualizaro repositório de políticas do CloudStack com as políticas definidas pelos administradoresde SP e IdP e realizar o cadastro de usuários que tem o acesso liberado. Para tanto, o SPAdapter terá que, ao traduzir as políticas definidas, chamar as operações correspondentesna API do CloudStack para atualizar seu repositório de políticas.

Assim como nos perfis apresentados, o perfil do CloudStack limita os elementosde uma política apenas aos apresentados na Figura 3. Devido a complexidade do CloudS-tack e a limitação de tempo, o perfil de políticas dependentes de SP definido para elecontempla apenas o gerenciamento de três tipos de recursos em relação a accounts. Maisespecificamente, o gerenciamento de políticas dependentes de SP do CloudStack permitecontrolar somente a distribuição do número de máquinas virtuais, templates e snapshotsque uma account de um determinado domínio é permitida criar. As entidades permitidase seus atributos definidos pelo perfil podem ser visualizados na Tabela 4.


Tabela 4 – Entidades e atributos permitidos definidos no perfil de políticas dependentesde SP do CloudStack.


subject domain-idaccount-name

resourceresource-idresource-nameresource-value

Alguns desses atributos são limitados também com relação aos valores permitidos.Assim, o atributo action-id da entidade action permite apenas três valores possíveis,mapeando as ações para criação de máquinas virtuais (deployVirtualMachine), snapshots(createSnapshot) e templates (createTemplate). Já o atributo resource-id restringe seusvalores para os identificadores desses três tipos de recursos, que no caso é 0 para máquinasvirtuais, 3 para snapshots e 4 para templates, os quais represantam os valores permtidos.A listagem completa, de elementos e entidades permitidas é apresentada no Apêndice A.

Um exemplo de política XACML em conformidade com o perfil de políticas depen-dente de SP do CloudStack é apresentado na Listagem 4.3. Essa política especifica que aaccount alice do domínio https://idp.imd.ufrn.br/idp/shibboleth pode criar no máximo 10máquinas virtuais.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="cloudstack-policy-1"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Limita o número de máquinas virtuais que um conta pode criar</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">13 https://idp.imd.ufrn.br/idp/shibboleth14 </AttributeValue>15 <AttributeDesignator16 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id"17 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"18 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>19 </Match>20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">22 alice23 </AttributeValue>24 <AttributeDesignator25 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name"26 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"27 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>28 </Match>29 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">30 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">deployVirtualMachine</AttributeValue>31 <AttributeDesignator


32 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:action:action-name"33 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"34 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>35 </Match>36 </AllOf>37 </AnyOf>38 </Target>39 <Rule Effect="Permit" RuleId="Permit-Rule">40 <Target>41 <AnyOf>42 <AllOf>43 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">44 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">0</AttributeValue>45 <AttributeDesignator46 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"47 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"48 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>49 </Match>50 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal">51 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">10</AttributeValue>52 <AttributeDesignator53 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value"54 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"55 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>56 </Match>57 </AllOf>58 </AnyOf>59 </Target>60 </Rule>61 <Rule Effect="Deny" RuleId="Deny-Rule">62 </Policy>

Listagem 4.3 – Exemplo de política XACML em conformidade com perfil de políticasdependentes de SP do CloudStack.

Conforme pode ser visualizado, a política é formada por um Target entre aslinhas 8 e 38 e dois elementos Rule, um entre as linhas 39 e 60 e outro na linha 61.O Target é formado por uma sequência conjuntiva de três elementos Match, o qualespecifica que a política deve ser aplicada a requisições somente quando o identificadordo domínio (urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id) e o nome da conta (urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name) do sujeito (urn:oasis:names:tc:xacml:1.0:subject-category:access-subject) for https://idp.imd.ufrn.br/idp/shibboleth e alice, e o nome da ação (urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:action:action-name) da entidade ação(urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name) fordeployVirtualMachine.

O primeiro elemento Rule, cujo efeito é Permit, é formado por um único elementoTarget contendo uma sequência conjuntiva de elementos Match, especificando que a Ruledeve ser aplicada somente quando o identificador do recurso (urn:oasis:names:tc:xacml:1.0:resource:resource-id) for 0 e o seu valor (urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value) for menor ou igual a 10. Assim como naspolíticas anteriores, caso o Target do primeiro elemento Rule não seja satisfeito, ou seja,caso o identificador do recurso não seja 0 ou o valor do recurso seja maior que 10, seuefeito não é aplicado e o segundo elemento Rule com efeito Deny é avaliado, sendo sempre


aplicado a requisição, uma vez que é um elemento vazio.

4.4 ImplementaçãoO 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 serencontrado no repositório de projetos do IMD7. O sistema de gerenciamento de identidadesutilizado pelo FACS é FIM, ou seja, o FACS foi desenvolvido para ser integrado a umafederação, mais especificamente a CAFe. A integração com federação ocorre por meio doShibboleth 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 PEPdos 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 abertopara representação de dados. A Listagem 4.4 apresenta um exemplo de dados enviados emuma requisição. Conforme pode ser visto, os dados enviados correspondem aos atributosde um usuário liberados pelo seu IdP, além do entityID8 do IdP e do SP nas linhas 2 e3. Como um sujeito pode ter mais de um vínculo junto a sua instituição, a entrada querepresenta os atributos correspondentes as afiliações entre as linhas 8 e 15 é especificadacomo um arranjo (array). Por fim, o sistema de autorização utilizado na API consistede um simples mecanismo de fornecimento de token, no qual toda requisição deve viracompanhada com um cabeçalho HTTP contendo um token gerado a partir da interfacedo 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": "[email protected]",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

Identidades e Provedores de Serviço em uma federação.

https://spring.io/

https://projetos.imd.ufrn.br/facs/facs


16 }

Listagem 4.4 – Exemplo de dados enviados a API do FACS.

A Figura 9 apresenta o diagrama de pacotes parcial da aplicação, destacando osprincipais pacotes, algumas de suas classes e relacionamentos. Os pacotes foram organizadosde forma a agrupar classes com responsabilidades e características semelhantes. As classesdo pacote controller são responsáveis por atender requisições HTTP vindas interface webutilizada pelos usuários do sistema. Nesse pacote, a classe UsersController prover serviçosque são utilizados pelo administrador do FACS para gerenciar os usuários do sistema.As classes ServiceProvidersController e IdentityProvidersController são utilizadas pelosadministradores de Provedores de Identidades e Serviços para configurar os provedoresque eles estão autorizados a gerenciar. Já as classes SPDependentPoliciesController eSPIndependentPoliciesController são responsáveis por prover serviços para o gerenciamentode 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 atributosliberados 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 controlede acesso, seu PEP realiza uma requisição a API do PDP questionando se o usuário comos atributos em questão pode acessar o sistema, liberando o acesso e iniciando a sessãoem caso positivo. Já as classes APIAuthenticationFilter, APIAuthenticationProvider eAPIAuthenticationToken implementam o mecanismo de autenticação da API. Embora asclasses 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. OFACS apenas captura os atributos emitidos por um IdP em uma requisição HTTP, osquais 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íficosas demais classes do sistema. Nesse pacote são destacados os sub-pacotes wso2.is exacml, além da classe PEPService. O pacote wso2.is contém os clientes das interfacesSOAP do PAP (classe WSO2ISEntitlementPolicyAdminServiceClient) e do PDP (classeWSO2ISEntitlementServiceClient) do WSO2 IS. Já o pacote xacml contém várias classesresponsá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 acessadapelo 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 porum endpoint. No pacote interceptor, a classe PEPInterceptor é responsável por interceptartodas as requisições realizadas pelos usuários do FACS na sua interface e verificar seelas 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 PEPServicedo pacote service para ser feita uma requisição XACML questionando se o acesso dousuário ao recursos para realizar a ação desejada deve ser permitido. Juntas, as classesPEPInterceptor e PEPService implementam o PEP do FACS.

Por fim, o pacote adapter contém as classes relacionadas aos SP Adapters dosProvedores de Serviço. Conforme pode ser visto, são destacadas duas classes referentesao SP Adapter do FACS (FACSAdapter) e do CloudStack (CloudStackAdapter), ambasestendendo da classe abstrata Adapter, que estabelece uma interface comum para todoSPAdapter. A classe AdapterFactory é responsável por fornecer instâncias das classesreferentes aos SP Adapters.

Com relação aos perfis definidos, cada um é implementado na forma de umasequência de validações, restringindo a estrutura, entidades, atributos e valores permitidosem uma política em XACML. Assim, uma vez definida uma política em XACML, sejapolítica independente de SP ou política dependente de SP, a validação é feita da seguinteforma. 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çãodo XACML, removendo a declaração dos elementos que não deseja utilizar, para que apolítica seja avaliada em relação a esse esquema reduzido. Logo após, é verificado se asentidades, 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 oesquema XML criado pelo FACS para tal. Por fim, é realizada a validação da estrutura dapolí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 pelopróprio FACS, desde que cada perfil forneça os artefatos para tal. Contudo, para políticasdependentes 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íticasindependentes de SP são propagadas para o PAP do WSO2 IS e políticas dependentes deSP 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íticasindependentes de SP quanto para políticas dependentes de SP, é necessário impor restriçõesno momento da definição, principalmente se a capacidade de gerenciamento de controlede acesso for delegada a administradores de Provedores de Identidade. Essas restriçõespodem estar relacionadas as limitações dos recursos e serviços providos por um Provedorde Serviço ou a aspectos contratuais estabelcidos entre um Provedor de Serviço e umProvedor de Identidade (DINIZ et al., 2015).

As restrições para definição de políticas independentes de SP são as mesmas paratodo Provedor de Serviço e consistem apenas na limitação no número de usuários decada 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çosprovidos por um Provedor de Serviço. Assim, essas restrições são implementadas por meiode XML, no qual cada Provedor de Serviço deve fornecer um esquema XML especificando aestrutura de restrições para seus recursos e serviços. Essas restrições devem ser informadaspelo administrador do Provedor de Serviço para cada Provedor de Identidade autorizado aacessar o Provedor de Serviço, conforme o esquema fornecido. A validação das restriçõesinformadas quanto ao esquema é feita pelo FACS, já a verificação das restrições paradefinição definição de políticas é feita pelo SP Adapter antes de propagar a política.

4.5 Considerações FinaisEsse 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 detalhesda implementação do FACS com as mudanças propostas. Foi utilizada a versão 3 doXACML, contemplando os componentes PAP e PDP da sua arquitetura de referência, osquais são fornecidos pelo WSO2 IS. Para a sua linguagem de definação de políticas, apenasum subconjunto dos elementos definidos foi utilizado, visando diminuir a compexidadeda definição de políticas para os perfis deifnidos. A linguagem de requisição e repostastambém precisou ser implementada para troca de mensagens entre o PDP do FACS e oPDP do WSO2 IS.

Por outro lado, a integração com CloudStack contemplou apenas o gerenciamentodos limites de utlização de alguns dos recursos providos, devido a quantidade de recursose serviços fornecidos. Assim foi desenvolvido seu SP Adapter para atualização de sua basede dados e repositório de políticas a partir da sua API. Por fim, o FACS foi desenvolvidodo 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 originaise permitir a definição de políticas de controle de acesso em XACML para administradoresde Provedores de Serviços e Provedores de Identidades.

58

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 depolíticas de controle de acesso, a avaliação realizada consistiu na definição de cenários paraavaliar 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, suasdependências e do CloudStack em uma federação local para realização de testes envolvendodiferentes cenários de controle de acesso existentes em uma federação com a utilizaçãodo FACS. O objetivo da avaliação realizada foi verificar se de fato as políticas definidassurtiam o efeito desejado em seus respectivos cenários.

5.1 AmbientePara 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çose quatro Provedores de Identidades em duas máquinas virtuais, uma para cada tipo deprovedor. 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 oSpring Framework, foi configurado um ambiente com o web container Apache Tomcat, no

Capítulo 5. Avaliação 59

qual o FACS foi implantado. Para integração com federação, foi instalado o ShibbolethSP através de um módulo do servidor web Apache HTTP Server, também instaladoe configurado na máquina dos Provedores de Serviço. Por fim, o Apache Tomcat e oApache HTTP Server foram configurados para se comunicar por meio do protocoloAJP (Apache JServ Protocol), utilizado para comunicação entre um servidor web e umweb container. Nesse cenário, o servidor web atua como um proxy, recebendo todas asrequisições e redirecionando aquelas voltadas para aplicações java ao web container. Alémdisso, também foi configurada uma base de dados MySQL utilizada pelo FACS e o servidorde autorização WSO2 IS.

Para o CloudStack, foi instalado o CloudStack Simulator, uma ferramenta desimulação criada criada pelos mantenedores do projeto para realização de testes. Essaferramenta permite a simulação de uma nuvem completa, simulando o provisionamentodos vários recursos gerenciados pelo CloudStack, sem a necessidade de ter que implantarum Datacenter complexo para realização de testes. O CloudStack Simulator foi implantadoatravés do Docker, um sistema para virtualização a nível do sistema operacional que criapacotes 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 noPEP do CloudStack exigiria esforço de desenvolvimento. Além disso, uma modificação noPEP de um serviço nem sempre é possível. Assim, ao invés de realizar uma modificaçãono CloudStack, foi configurado um outro serviço que atua como um proxy para acesso aoCloudStack. 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çãoa API do FACS questionando se o usuário em questão pode acessar o CloudStack. Casopossa, o usuário é redirecionado para o serviço. A principal e única tela da qual essaaplicação é composta é apresentada na Figura 11.

Para os Provedores de Identidade foi utilizado o Shibboleth IdP, no qual foramtodos implantados na mesma máquina virtual, contudo cada um atuando de forma isoladacom sua própria base de dados LDAP. Cada IdP teve sua base populada com diferentesusuários, cujos dados foram preenchidos de acordo com o esquema brEduPerson. Comoo Shibboleth IdP é uma aplicação java, os provedores de identidades foram implantadosno Apache Tomcat, e, assim como no ambiente do FACS, foi configurado o servidor webApache HTTP Server para atuar como proxy.

5.2 CenáriosA 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 independentesde SP foram definidos 4 cenários possíveis, um para cada modo de acesso que um Provedorde Identidade pode ter para um Provedor de Serviço, totalizando 3 cenários, e um parao caso de um Provedor de Identidade não estar autorizado a acessar um Provedor deServiço. Esses cenários foram definidos a partir do fluxo de políticas independentes de SPda Figura 5. A Figura 12 apresenta a tela do FACS com a listagem de cada Provedor deIdentidade autorizado a acessar o CloudStack, juntamente com o modo de acesso de cadaum. Conforme pode ser visto, o modo de acesso para o IdP2, IdP3 e IdP4 foi definido, naordem, para automático, manual e baseado em políticas.

Figura 12 – Tela principal do FACS para gerenciamento de políticas independentes de SP.


Para políticas dependentes de SP, foi definido apenas um cenário, no qual sãodefinidas políticas em XACML para um usuário que teve seu acesso liberado. Cada casode teste segue a estrutura da Tabela 5, apresentando nome, descrição, objetivo e resultadoesperado 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, oque realmente se verificou, conforme pode ser visto na Figura 13, que apresenta a tela doPHP Proxy com uma mensagem de erro para um usuário desse Provedor de Identidadeque tentou acessar o CloudStack. Tal comportamento, conforme esperado, ocorre paraqualquer usuário do IdP1.

Tabela 6 – Detalhes do teste realizado para o primeiro cenário.

Nome Teste01Descriçã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.

Figura 13 – Tela com mensagem de erro do PHP Proxy.


Para o segundo cenário, detalhado na Tabela 7, o IdP2 teve seu acesso liberadocom o modo de acesso definido para automático. Dessa forma, qualquer usuário desse IdPque tentar acessar o CloudStack terá seu acesso automaticamente liberado. A Figura 14apresenta a tela de listagem de domínios do CloudStack, tendo o ROOT no topo e um dossubdomínios referente ao IdP2. Já a Figura 15 apresenta a tela de listagem das accountsdo domínio do IdP2, e conforme pode ser visto há duas accounts referentes a dois usuáriosdesse Provedor de Identidade que tiveram seus acessos automaticamente liberados. Damesma forma, conforme esperado, qualquer outro usuário desse Provedor de Identidadeterá seu acesso automaticamente liberado.

Tabela 7 – Detalhes do teste realizado para o segundo cenário.

Nome Teste02Descriçã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 liberadocom o modo de acesso definido para manual. Assim, qualquer o usuário desse Provedorde Identidade que tentar acessar o CloudStack irá para uma lista de espera, a qual seráprocessada pelos administradores a fim de liberar ou negar o acesso do usuário. A Figura 16


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 qualqueroutro usuário do Provedor de Identidade que tentar acessar o CloudStack.

Tabela 8 – Detalhes do teste realizado para o terceiro cenário.


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 umProvedor de Identidade a um Provedor de Serviço.

Para o quarto cenário, detalhado na Tabela 9, o IdP4 teve seu acesso liberadocom o modo de acesso definido para baseado em políticas. Assim, qualquer usuário desseProvedor de Identidade que tentar acessar o CloudStack terá sua tentativa de acessoavaliada 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 menosuma política em XACML terá seu acesso liberado. A Figura 17 apresenta a tela doFACS que mostra a listagem das políticas definidas, nesse caso apenas uma, a qual éapresentada na Listagem B.1 do Apêndice B. Essa política especifica que somente usuáriosdesse Provedor de Identidade que possuem o vínculo do tipo faculty podem acessar oCloudStack.

Por fim, no quinto cenário, detalhado na Tabela 10, o acesso a recursos no CloudS-tack foi restringido para um dos usuários que teve seu acesso liberado. Nessa caso, foidefinida uma política em XACML limitando cada recurso dentro do escopo do perfil de


Tabela 9 – Detalhes do teste realizado para o quarto cenário.


Serviço com modo de acesso baseado em políticas.Objetivo Verificar se qualquer usuário do Provedor de Identidade

tem seu acesso avaliado conforme as políticas definidas emXACML.

Resultado Esperado O acesso de qualquer usuário do Provedor de Identidade éliberado caso os atributos do contexto da requisição satisfaçaalguma políticas definida.

Figura 17 – Tela do FACS para listagem de políticas para políticas independentes de SPdo modo de acesso baseado em políticas.

políticas dependentes de SP do CloudStack. A Figura 18 mostra a tela do FACS queapresenta as políticas dependentes de SP definidas para um Provedor de Serviço em relaçãoa um Provedor de Identidade, nesse caso as três políticas em XACML definidas para umusuário do IdP4 que teve seu acesso ao CloudStack liberado.

Tabela 10 – Detalhes do teste realizado para o quinto cenário.

Nome Teste05Descrição Usuário tem acesso a recursos do Provedor de Serviço restrin-

gido conforme políticas em XACML definidas.Objetivo Verificar se políticas dependentes de SP definidas em XACML

são validadas, interpretadas e propagadas para o Provedor deServiço.

Resultado Esperado O repositório de políticas do Provedor de Serviço é atualizado eo acesso a recursos é limitado conforme as políticas definidas.

Essas políticas são apresentadas no Apêndice B. A primeira política (Listagem


Figura 18 – Tela do FACS para listagem de políticas dependentes de SP.

B.2) restringe o número de máquinas virtuais que o usuário pode criar para 10, a segunda(Listagem B.3) restringe o número de snapshots para 15, e a terceira (Listagem B.4)restringe o número de templates para 5.

A Figura 14 apresenta os domínios cadastrados no CloudStack, tendo um dossubdomínios do domínio ROOT referente ao IdP4. A Figura 19 apresenta a lista deaccounts desse domínio. Nesse caso, há apenas uma account referente a um usuário queteve seu acesso liberado. A Figura 20 apresenta os detalhes da account em questão, inclusiveos limites para utilização de cada recurso provido. Os recursos limitados pela definição depolíticas a partir do FACS estão destacados, e conforme pode ser vistos, os valores são osmesmos das políticas.

Figura 19 – Tela de gerenciamento de accounts do domínio do IdP4 do CloudStack.

Por fim, com o usuário cadastrado na base de dados do CloudStack e seu repositóriode políticas atualizado com políticas definidas para restringir o acesso a recursos desseusuário liberado, em seguida foi feita a autenticação do usuário na federação local junto aseu Provedor de Identidade para iniciar uma sessão no CloudStack e testar a utilização derecursos. Como esperado, ao tentar criar recursos acima do valor definido, uma mensagemde erro é exibida e o usuário não consegue finalizar a operação, conforme pode ser visto


Figura 20 – Tela de gerenciamento de uma account do CloudStack.

na Figura 21, a qual mostra uma mensagem de erro apresentada ao usuário quando eletentou realizar uma operação para criação de uma instância, que nesse caso excedeu olimite definido para 10.

Figura 21 – Mensagem de erro exibida pelo CloudStack a um usuário ao tentar realizaruma operação que exceda os limites de recursos definidos.

5.3 DiscussãoTodos os testes realizados obtiveram os resultados conforme o esperado. Todas as

políticas definidas em XACML foram validadas, tanto sintaticamente e semanticamente,interpretadas e avaliadas conforme cada perfil especificado. Para políticas independentesde SP um usuário teve seu acesso liberado ou negado de acordo com as políticas definidas.Para políticas dependentes de SP elas de fato foram traduzidas para a linguagem utilizada


pelo CloudStack, atualizando seu repositório de políticas e limitando as ações do usuário.Contudo, é preciso considerar que os testes foram realizados em um ambiente simulado, noqual os cenários e políticas foram predefinidos e o número de usuários, tanto da federaçãoquanto de administradores capazes de definir políticas, foram limitados e predeterminados.

68

6 Trabalhos Relacionados

No tocante a trabalhos relacionados, os seguintes trabalhos propoem soluções paraproblemas semelhantes: Access Control as a Service for Public Cloud Storage (ZHANG;CHEN, 2012), Authorization as a Service in Smart Grids: Evaluating the PaaS Paradigmfor XACML Policy Decision Points (RYBA; JUNG; KASTNER, 2013), ApplicationIndependent Identity Management (Zombo Fu et al., 2010), Controle de Acesso Baseadoem Políticas e Atributos para Federações de Recursos (Silva, Edelberto F and Muchaluat-Saade, Débora and Fernandes, 2014) e Um Estudo Sobre Autenticação Federada no Acessoa Recursos Computacionais por Terminal Remoto Seguro (GALHEIGO; GOMES, 2014).

Em (ZHANG; CHEN, 2012) é proposto um serviço de controle de acesso baseadoem atributos para nuvens de armazenamento públicas, no qual o proprietário dos recursosé responsável por controlar o acesso dos usuários a seus recursos. Para tanto é propostauma arquitetura que utiliza os componentes do ABAC em conjunto com encriptação, noqual o dono dos recursos é capaz de proteger o acesso a seus recursos através da definiçãode políticas de controle de acesso com diferentes privilégios. O FACS também utiliza oscomponentes do ABAC para definição de políticas e também pode ser integrado a nuvensde armazenamento. Contudo, apenas administradores de serviços e instituições são capazesde definir políticas para controlar o acesso a recursos e serviços, enquanto que aos usuáriosda federação não é provida tal capacidade.

Em (RYBA; JUNG; KASTNER, 2013) é proposto um serviço de autorizaçãoutilizando XACML e SAML para proteção dos dados gerados em ambientes de smartgrid, com foco em desempenho e escalabilidade. Nesses ambientes, os dados gerados sãodisponibilizados a partir de serviços web, que devido a suas características, apresentamproblemas de autorização e autenticação inerentes. A solução proposta permite que o donodos dados controle quem pode acessa-los e garante a privacidade dos dados. Nossa propostaintroduz XACML no FACS com a definição de perfis, e a nova versão desenvolvida éintegrada a uma federação SAML, podendo ser integrada para controle de acesso emserviços web. Contudo, a utilização do FACS em ambientes de Smart Grid deve ser avaliada.

Em (Zombo Fu et al., 2010) é proposta uma arquitetura hibrida para Gerenciamentode Identidades Independente de Aplicação entre diferentes domínios para ambientes decomputação aberta. A solução proposta foca na privacidade dos dados do usuário. O FACSnão lida diretamente com o gerenciamento de identidades, uma vez que essa tarefa já érealizada pelos Provedores de Identidade da federação.

Em (Silva, Edelberto F and Muchaluat-Saade, Débora and Fernandes, 2014)é proposta uma arquitetura para controle de acesso baseado em políticas e atributos

Capítulo 6. Trabalhos Relacionados 69

para organizações virtuais acadêmicas que utilizam autenticação federada. Nesse trabalhotambém é proposta a utilização de um provedor de atributos adicional a federação e umagregador de atributos. O FACS foi proposto para atuar em ambientes federados, suaaplicação em organizações virtuais para controle de acesso pode ser avaliada. A nova versãodesenvolvida não é capaz de lidar com provedores de atributos adicionais e agregadores deatributos.

Por fim, em (GALHEIGO; GOMES, 2014) é feito um estudo de métodos paraautenticação federada em terminais remotos seguros por meio do protocolo SSH, sendoproposta uma arquitetura para introdução de federação nesse meio. A proposta procurapreservar a interface desses ambientes e reduzir os impactos de modificações necessáriaspara Provedores de Identidades. O FACS atua em federações SAML por meio do sistemaShibboleth, sendo que a nova versão desenvolvida não é capaz de atuar em ambientes ssh,uma vez que foi projetada para ambientes HTTP.

70

7 Conclusão

Controle de acesso é um requisito de segurança fundamental para muitas aplicaçõesem diferentes ambientes. No contexto de ambientes federados, cada Provedor de Serviço éresponsável por controlar o acesso dos usuários da federação, determinando quem podeacessar seus recursos e serviços, e os privilégios de cada usuário. Cada um utiliza seupróprio mecanismo de controle de acesso, seja manual ou automático. A adoção do FACSem uma federação facilita esse processo, permitindo ainda a delegação do gerenciamentode controle de acesso a outros indivíduos.

7.1 ContribuiçõesNa sua primeira versão, proposto em (DINIZ et al., 2015), o FACS foi aplicado

ao edudrive@RNP para controlar o acesso dos usuários da federação da RNP, bem comodelegar a gerencia de controle de acesso a administrados de Provedores de Identidadesda federação. Na ocasião, o sistema especificado e proposto atendeu as necessidades dosadministradores do edudrive@RNP, reduzindo o trabalho manual para liberação de acessode novos usuários ao serviço e concedendo a possibilidade de gerenciamento de privilégiose alocação de recursos para usuários aos administradores dos Provedores de Identidades.Contudo, a integração de novos Provedores de Serviços necessitaria não só de um SPAdapter, mas seria necessário também modificações no core do FACS para incorporação dalinguagem de políticas utilizada por cada Provedor de Serviço para definição de políticas,exigindo portanto um alto esforço de desenvolvimento.

Assim, a realização do presente trabalho, em um primeiro momento, propiciou odesenvolvimento de uma nova versão do FACS, integrado a uma federação SAML queutiliza o esquema brEduPerson, como é o caso da CAFe. Essa nova versão contempla adefinição de políticas de controle de acesso com granularidade fina a partir da utilizaçãode XACML e integração com um servidor de autorização. As políticas em XACML sãovalidadas pelos perfis definidos.

Além disso, a introdução de XACML no FACS acaba por estabelecer uma interfaceúnica para definição de políticas de controle de acesso com granularidade fina, diminuindoo esforço para integração de novos Provedores de Serviço, tornando o FACS uma soluçãode controle de acesso mais atrativa e viável para ser utilizada na gestão de controle deacessos a serviços em uma federação. A capacidade da definição de políticas de controle deacesso para controlar o acesso a recursos e serviços fornecidos por um Provedor de Serviçoé limitada apenas pela sua interface fornecida para gerenciamento de controle de acesso, epelo seu SP Adapter e perfil definido.

Capítulo 7. Conclusão 71

Por fim, a integração do FACS ao CloudStack, fornece ao CloudStack a possibilidadede ter o acesso dos seus usuários provenientes da federação controlado a partir da definiçãode políticas de controle de acesso pelo FACS, facilitando o gerenciamento do controle deacesso dos usuários e permitindo a possibilidade de delegação dessa capacidade a outrosadministradores de instituições da federação.

7.2 LimitaçõesEmbora a introdução de XACML reduza o esforço no FACS para integração de

novos Provedores de Serviços, ainda há necessidade de realizar modificações no FACS paraincorporação do SP Adapter. Além disso, XACML é um padrão complexo, e a sua adoçãotorna necessário a tradução das políticas definidas para a linguagem utilizada por cadaProvedor de Serviço utilizando as interfaces disponíveis para atualização do repositório depolíticas. Assim, cada SP Adapter deve ser capaz de processar XACML para interpretaçãoe tradução das políticas, o que acaba por dificultar o seu desenvolvimento. Além disso, umadministrador deve definir uma política diretamente em XACML de acordo as restriçõesestabelecidas no perfil, tornando necessário que cada administrador conheça exatamenteas restrições estabelecidas para o perfil do tipo de política que está sendo definida. Issoacaba por dificultar a definição de políticas de Controle de Acesso, uma vez que exige umconhecimento a mais por parte de cada administrador, que além de conhecer os recursos eserviços providos pelo seu Provedor de Serviço, deve ser capaz também de definir políticasem XACML para controlar a sua utilização.

7.3 Trabalhos FuturosCom relação a trabalhos futuros, pretende-se avaliar a utilização da Linguagem

Abreviada para Autorização (Abbreviated Language For Authorization - ALFA) na definiçãode políticas em XACML pelos administradores a fim de diminuir a complexidade darepresentação das políticas, uma vez que ALFA é uma linguagem de pseudocódigo utilizadana formulação de políticas de controle de acesso, contemplando diretamente os elementosestruturais da linguagem de políticas do XACML, fornecendo uma alternativa a XMLna definição de políticas. Pretende-se também expandir o escopo do perfil de políticasdependentes de SP do CloudStack, aumentado o número de recursos e serviços cujocontrole de acesso pode ser gerenciado a partir da definição de políticas pelo FACS.Também pretende-se aplicar o FACS a outro Provedor de Serviço a fim de medir o esforçoda integração.

Com relação a integração de novos Provedores de Serviço, pretende-se avaliar apossibilidade de melhoraria dessa tarefa, automatizando o cadastro dos Provedores de Ser-viços sem a necessidade de modificações no FACS por meio de esforços de desenvolvimento.

Capítulo 7. Conclusão 72

Para tanto, será necessário melhorar o módulo de gerenciamento de Provedores de Serviçose seus SP Adapters. Por exemplo, o FACS poderia prover algum tipo de framework, noqual todo SP Adapter deveria utilizar. Um SP Adapter, por sua vez, deveria ser desenvol-vido na forma de um componente auto suficiente, utilizando os serviços oferecidos peloframework do FACS e adicionando dependências de terceiros quando utilizadas. Por fim, oSP Adapter e suas dependências seriam empacotados em um arquivo JAR (Java ARchive),e no momento do cadastro do Provedor de Serviço seria feito o upload desse arquivo.

Além disso, pretende-se implantar o FACS na nuvem do IMD da UFRN, a fim depermitir sua utilização por usuários reais e avaliar o funcionamento do sistema como umtodo em um ambiente real.

Por fim, a partir da aplicação do FACS no CloudStack foi possível identificar aseguinte indicação de processo para integração do FACS a outros Provedores de Serviços.É importante mencionar que nesse trabalho o foco não foi a definição de tal processo,porém os resultados alcançados podem ser utilizados para auxiliar em tal tarefa. Assim,foi possível verificar um processo composto por três fases: Especificação, Implementação eIntegração.

Na fase de Especificação, devem ser realizadas 4 tarefas. Primeiramente, deve serfeita definição de quais recursos e serviços do provedor de serviço serão controlados peloFACS a partir da definição de políticas de controle de acesso. Em seguida o perfil depolíticas dependentes de SP deve ser especificado, definindo quais elementos, entidades eatributos podem ser utilizados para definição de políticas em XACML, e se as políticasdefinidas serão limitadas quanto a estrutura. A terceira tarefa consiste em definir asconfigurações do Provedor de Serviço, como por exemplo informações de acesso a algumaAPI, que serão utilizadas pelo seu SP Adapter para propagação de políticas. Por fim, aquarta tarefa consiste da elaboração de restrições em relação a políticas dependentes deSP, como por exemplo restrições em relação ao número total de recursos que podem seralocados em uma política.

Já na fase de Implementação, o SP Adapter é implementado. Seu desenvolvimentodeve ser feito em java através de uma classe acompanhada com todas as dependênciasnecessárias, atendendo as especificações estabelecidas pelo FACS. Essas especificaçõesdizem respeito a necessidade do SP Adapter estender de uma classe abstrata, que estabeleceuma interface comum para todo SP Adapter.

Por último, na fase de Integração o Provedor de Serviço é integrado ao FACS,exigindo para isso esforço de desenvolvimento, no qual a classe do SP Adapter junto comsuas dependências é incorporada ao FACS.

73

Referências

ANSI. Role Based Access Control. [S.l.], 2004. ANSI/INCITS 359-2004. Disponível em:<http://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf>. Citado 3 vezesnas páginas 19, 22 e 32.

CHADWICK, D. W. Federated Identity Management. In: Foundations of SecurityAnalysis and Design V. [S.l.]: Springer Berlin Heidelberg, 2009, (Lecture Notes inComputer Science, v. 5705). p. 96–120. ISBN 978-3-642-03828-0. Citado 3 vezes naspáginas 15, 32 e 33.

DINIZ, T. F. S. et al. Managing access to service providers in federated identityenvironments: A case study in a cloud storage service. In: 2015 XXXIII BrazilianSymposium on Computer Networks and Distributed Systems. IEEE, 2015. p. 199–207. ISBN978-1-4673-7767-6. Disponível em: <http://ieeexplore.ieee.org/document/7320527/>.Citado 8 vezes nas páginas 9, 16, 36, 37, 38, 42, 56 e 70.

GALHEIGO, M. M.; GOMES, A. T. A. Um estudo sobre autenticação federada no acessoa recursos computacionais por terminal remoto seguro. In: PAISANTE, V. M. (Ed.). XIVSimpósio Brasileiro Segurança da Informação e Sistemas Computacionais. Belo Horizonte,MG: SBC, 2014. p. 507–512. Citado 2 vezes nas páginas 68 e 69.

HU, V. C.; FERRAIOLO, D.; KUHN, D. R. Assessment of Access Control Systems. [S.l.],2006. 60 p. Disponível em: <http://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf>.Citado 2 vezes nas páginas 15 e 19.

HU, V. C. et al. Guide to Attribute Based Access Control (ABAC) Definition andConsiderations. [S.l.], 2014. v. 800, 162 p. Citado 4 vezes nas páginas 9, 22, 23 e 24.

JOSANG, A.; POPE, S. User centric identity management. In: AusCERT Asia PacificInformation Technology Security Conference. Brisbane, Australia: [s.n.], 2005. p. 1–13.ISBN 0385094027. ISSN 15407993. Citado na página 32.

OASIS. eXtensible Access Control Markup Language (XACML) Version 3.0. [S.l.], 2013.v. 3, n. February, 154 p. Disponível em: <http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html>. Citado 5 vezes nas páginas 9, 19, 24, 25 e 28.

OASIS. OASIS XACML Technical Committee. 2018. Disponível em: <https://www.oasis-open.org/committees/xacml/>. Nenhuma citação no texto.

RYBA, G.; JUNG, M.; KASTNER, W. Authorization as a service in smart grids:Evaluating the paas paradigm for xacml policy decision points. In: IEEE 18th InternationalConference on Emerging Technologies and Factory Automation (ETFA). [S.l.: s.n.], 2013.p. 1–4. ISBN 978-1-4799-0862-2. ISSN 1946-0740. Citado na página 68.

SAMARATI, P.; VIMERCATI, S. C. de. Access control : Policies, models and mechanisms.In: FOCARDI, R.; ; GORRIERI, R. (Ed.). Foundations of Security Analysis and Design:Tutorial Lectures. Berlin, Heidelberg: Springer Berlin Heidelberg, 2001. v. 2171, p. 137–196.ISBN 3540428968. Disponível em: <http://dx.doi.org/10.1007/3-540-45608-2_3>.Citado 2 vezes nas páginas 19 e 21.

http://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf

http://ieeexplore.ieee.org/document/7320527/

http://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html



http://dx.doi.org/10.1007/3-540-45608-2_3

Referências 74

SANDHU, R. S.; SAMARATI, P. Access control: Principles and practice. IEEECommunications Magazine, v. 32, n. 9, p. 40–48, September 1994. ISSN 0163-6804.Disponível em: <http://ieeexplore.ieee.org/document/312842/>. Citado 4 vezes naspáginas 15, 19, 20 e 21.

SHIREY, R. Internet Security Glossary, Version 2. [S.l.], 2007. <http://www.rfc-editor.org/rfc/rfc4949.txt>. Disponível em: <http://www.rfc-editor.org/rfc/rfc4949.txt>.Nenhuma citação no texto.

Silva, Edelberto F and Muchaluat-Saade, Débora and Fernandes, N. C. Controlede acesso baseado em políticas e atributos para federações de recursos. In:PAISANTE, V. M. (Ed.). XIV Simpósio Brasileiro em Segurança da Informaçãoe de Sistemas Computacionais. SBC, 2014. p. 470–479. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/sbseg/2014/0073.pdf>. Citado na página 68.

WANGHAM, M. S. et al. Gerenciamento de identidades federadas. In: X SimpósioBrasileiro em Segurança da Informação e de Sistemas Computacionais. Fortaleza, CE:SBC, 2010. v. 1, p. 1–50. Citado na página 33.

ZHANG, Y.; CHEN, J.-L. Access control as a service for public cloud storage.In: 2012 32nd International Conference on Distributed Computing SystemsWorkshops. [s.n.], 2012. p. 526–536. ISBN 978-1-4673-1423-7. Disponível em:<http://dx.doi.org/10.1109/ICDCSW.2012.65>. Citado na página 68.

Zombo Fu et al. Application independent identity management. In: 2010 IEEEInternational Conference on Information Theory and Information Security. IEEE, 2010. p.625–628. ISBN 978-1-4244-6942-0. Disponível em: <http://ieeexplore.ieee.org/document/5689511/>. Citado na página 68.


http://www.rfc-editor.org/rfc/rfc4949.txt



http://www.lbd.dcc.ufmg.br/colecoes/sbseg/2014/0073.pdf

http://www.lbd.dcc.ufmg.br/colecoes/sbseg/2014/0073.pdf

http://dx.doi.org/10.1109/ICDCSW.2012.65



Apêndices

76

APÊNDICE A – Perfis XACML definidospara o FACS

Esse apêndice apresenta parte da especificação dos perfis XACML definidos parao FACS, listando os elementos e as entidades, seus atributos, tipo de dados e valorespermitidos. Na Listagem A.1 é mostrado o esquema XACML reduzido da versão 3 da suaespecificação, no qual foram removidos alguns elementos e deixados apenas os principaisapresentados na Figura 3. Todos os perfis utilizam o mesmo conjunto de elementospermitidos. A Listagem A.2 apresenta um XML contendo as entidade, seus atributos, tiposde dados e valores permitidos para o perfil de políticas independentes de SP. Nesse XML,cada elemento Category entre as linhas 4 e 28, 29 e 40, 41 e 94, representa uma entidade eseus atributos que podem ser utilizados na definição de políticas. Cada atributo, por suavez, é representado na forma de um elemento attribute, como por exemplo entre as linhas72 e 84, no qual é declarado o identificador do atributo (uri) na linha73, o seu tipo (type)na linha 74, e, se existente, o conjunto de valores permitidos (values) entre as linhas 75 e83. Da mesma forma, a listagem A.3 apresenta as entidades permitidas para o perfil depolíticas dependentes de SP do FACS e a listagem A.4 apresenta as entidades permitidaspara o perfil de políticas dependentes de SP do CloudStack.

1 <?xml version="1.0" encoding="UTF-8"?>2 3 <xs:schema xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 xmlns:xs="http://www.w3.org/2001/XMLSchema"5 targetNamespace="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"6 elementFormDefault="qualified" attributeFormDefault="unqualified">78 <xs:import namespace="http://www.w3.org/XML/1998/namespace"9 schemaLocation="http://www.w3.org/2001/xml.xsd"/>

1011 <xs:simpleType name="VersionType">12 <xs:restriction base="xs:string">13 <xs:pattern value="(\d+\.)*\d+"/>14 </xs:restriction>15 </xs:simpleType>1617 <xs:simpleType name="EffectType">18 <xs:restriction base="xs:string">19 <xs:enumeration value="Permit"/>20 <xs:enumeration value="Deny"/>21 </xs:restriction>22 </xs:simpleType>2324 <xs:element name="Policy" type="xacml:PolicyType"/>25 <xs:complexType name="PolicyType">26 <xs:sequence>27 <xs:element ref="xacml:Description" minOccurs="0"/>28 <xs:element ref="xacml:Target"/>29 <xs:choice maxOccurs="unbounded">30 <xs:element ref="xacml:Rule"/>

APÊNDICE A. Perfis XACML definidos para o FACS 77

31 </xs:choice>32 </xs:sequence>33 <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>34 <xs:attribute name="Version" type="xacml:VersionType" use="required"/>35 <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" use="required"/>36 <xs:attribute name="MaxDelegationDepth" type="xs:integer" use="optional"/>37 </xs:complexType>3839 <xs:element name="Description" type="xs:string"/>4041 <xs:element name="Rule" type="xacml:RuleType"/>42 <xs:complexType name="RuleType">43 <xs:sequence>44 <xs:element ref="xacml:Description" minOccurs="0"/>45 <xs:element ref="xacml:Target" minOccurs="0"/>46 <xs:element ref="xacml:Condition" minOccurs="0"/>47 </xs:sequence>48 <xs:attribute name="RuleId" type="xs:string" use="required"/>49 <xs:attribute name="Effect" type="xacml:EffectType" use="required"/>50 </xs:complexType>5152 <xs:element name="Target" type="xacml:TargetType"/>53 <xs:complexType name="TargetType">54 <xs:sequence minOccurs="0" maxOccurs="unbounded">55 <xs:element ref="xacml:AnyOf"/>56 </xs:sequence>57 </xs:complexType>5859 <xs:element name="AnyOf" type="xacml:AnyOfType"/>60 <xs:complexType name="AnyOfType">61 <xs:sequence minOccurs="1" maxOccurs="unbounded">62 <xs:element ref="xacml:AllOf"/>63 </xs:sequence>64 </xs:complexType>6566 <xs:element name="AllOf" type="xacml:AllOfType"/>67 <xs:complexType name="AllOfType">68 <xs:sequence minOccurs="1" maxOccurs="unbounded">69 <xs:element ref="xacml:Match"/>70 </xs:sequence>71 </xs:complexType>7273 <xs:element name="Match" type="xacml:MatchType"/>74 <xs:complexType name="MatchType">75 <xs:sequence>76 <xs:element ref="xacml:AttributeValue"/>77 <xs:choice>78 <xs:element ref="xacml:AttributeDesignator"/>79 </xs:choice>80 </xs:sequence>81 <xs:attribute name="MatchId" type="xs:anyURI" use="required"/>82 </xs:complexType>8384 <xs:element name="Expression" type="xacml:ExpressionType" abstract="true"/>85 <xs:complexType name="ExpressionType" abstract="true"/>8687 <xs:element name="AttributeDesignator" type="xacml:AttributeDesignatorType" substitutionGroup="xacml:Expression"/>88 <xs:complexType name="AttributeDesignatorType">89 <xs:complexContent>90 <xs:extension base="xacml:ExpressionType">91 <xs:attribute name="Category" type="xs:anyURI" use="required"/>92 <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>93 <xs:attribute name="DataType" type="xs:anyURI" use="required"/>94 <xs:attribute name="Issuer" type="xs:string" use="optional"/>95 <xs:attribute name="MustBePresent" type="xs:boolean" use="required"/>96 </xs:extension>97 </xs:complexContent>98 </xs:complexType>99

100 <xs:element name="AttributeValue" type="xacml:AttributeValueType" substitutionGroup="xacml:Expression"/>101 <xs:complexType name="AttributeValueType" mixed="true">


102 <xs:complexContent mixed="true">103 <xs:extension base="xacml:ExpressionType">104 <xs:sequence>105 <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>106 </xs:sequence>107 <xs:attribute name="DataType" type="xs:anyURI" use="required"/>108 <xs:anyAttribute namespace="##any" processContents="lax"/>109 </xs:extension>110 </xs:complexContent>111 </xs:complexType>112113 <xs:element name="Condition" type="xacml:ConditionType"/>114 <xs:complexType name="ConditionType">115 <xs:sequence>116 <xs:element ref="xacml:Expression"/>117 </xs:sequence>118 </xs:complexType>119120 <xs:element name="Apply" type="xacml:ApplyType" substitutionGroup="xacml:Expression"/>121 <xs:complexType name="ApplyType">122 <xs:complexContent>123 <xs:extension base="xacml:ExpressionType">124 <xs:sequence>125 <xs:element ref="xacml:Description" minOccurs="0"/>126 <xs:element ref="xacml:Expression" minOccurs="0" maxOccurs="unbounded"/>127 </xs:sequence>128 <xs:attribute name="FunctionId" type="xs:anyURI" use="required"/>129 </xs:extension>130 </xs:complexContent>131 </xs:complexType>132 </xs:schema>

Listagem A.1 – Esquema XACML reduzido para o perfil definidos.

1 <?xml version="1.0" encoding="UTF-8"?>2 <XACML xmlns="urn:facs:names:xacml:restrictions:1.0:schema">3 <categories>4 <category>5 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:environment</uri>6 <attributes>7 <attribute>8 <uri>urn:oasis:names:tc:xacml:1.0:environment:current-time</uri>9 <type>http://www.w3.org/2001/XMLSchema#time</type>

10 </attribute>11 <attribute>12 <uri>urn:oasis:names:tc:xacml:1.0:environment:current-date</uri>13 <type>http://www.w3.org/2001/XMLSchema#date</type>14 </attribute>15 <attribute>16 <uri>urn:oasis:names:tc:xacml:1.0:environment:current-dateTime</uri>17 <type>http://www.w3.org/2001/XMLSchema#dateTime</type>18 </attribute>19 <attribute>20 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:sp-entityid</uri>21 <type>http://www.w3.org/2001/XMLSchema#anyURI</type>22 </attribute>23 <attribute>24 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:idp-entityid</uri>25 <type>http://www.w3.org/2001/XMLSchema#anyURI</type>26 </attribute>27 </attributes>28 </category>29 <category>30 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:action</uri>31 <attributes>32 <attribute>33 <uri>urn:oasis:names:tc:xacml:1.0:action:action-id</uri>34 <type>http://www.w3.org/2001/XMLSchema#string</type>


35 <values>36 <value>access</value>37 </values>38 </attribute>39 </attributes>40 </category>41 <category>42 <uri>urn:oasis:names:tc:xacml:1.0:subject-category:access-subject</uri>43 <attributes>44 <attribute>45 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:cn</uri>46 <type>http://www.w3.org/2001/XMLSchema#string</type>47 </attribute>48 <attribute>49 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:sn</uri>50 <type>http://www.w3.org/2001/XMLSchema#string</type>51 </attribute>52 <attribute>53 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:uid</uri>54 <type>http://www.w3.org/2001/XMLSchema#string</type>55 </attribute>56 <attribute>57 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:mail</uri>58 <type>http://www.w3.org/2001/XMLSchema#string</type>59 </attribute>60 <attribute>61 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:eduPersonPrincipalName</uri>62 <type>http://www.w3.org/2001/XMLSchema#string</type>63 </attribute>64 <attribute>65 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:schacCountryOfCitizenship</uri>66 <type>http://www.w3.org/2001/XMLSchema#string</type>67 </attribute>68 <attribute>69 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEduAffiliation</uri>70 <type>http://www.w3.org/2001/XMLSchema#integer</type>71 </attribute>72 <attribute>73 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEduAffiliationType</uri>74 <type>http://www.w3.org/2001/XMLSchema#string</type>75 <values>76 <value>student</value>77 <value>faculty</value>78 <value>employee</value>79 <value>alum</value>80 <value>other</value>81 <value>position</value>82 <value>scholarshipAwardee</value>83 </values>84 </attribute>85 <attribute>86 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEntranceDate</uri>87 <type>http://www.w3.org/2001/XMLSchema#date</type>88 </attribute>89 <attribute>90 <uri>urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brExitDate</uri>91 <type>http://www.w3.org/2001/XMLSchema#date</type>92 </attribute>93 </attributes>94 </category>95 </categories>96 </XACML>

Listagem A.2 – XML das entidades e atributos permitidos no perfil de políticasindependentes de SP.

1 <?xml version="1.0" encoding="UTF-8"?>


2 <XACML xmlns="urn:facs:names:xacml:restrictions:1.0:schema">3 <categories>4 <category>5 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:action</uri>6 <attributes>7 <attribute>8 <uri>urn:oasis:names:tc:xacml:1.0:action:action-id</uri>9 <type>http://www.w3.org/2001/XMLSchema#string</type>

10 <values>11 <value>MANAGE</value>12 <value>CREATE</value>13 </values>14 </attribute>15 </attributes>16 </category>17 <category>18 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:resource</uri>19 <attributes>20 <attribute>21 <uri>urn:oasis:names:tc:xacml:1.0:resource:resource-id</uri>22 <type>http://www.w3.org/2001/XMLSchema#anyURI</type>23 </attribute>24 <attribute>25 <uri>urn:oasis:names:tc:xacml:1.0:resource:resource-name</uri>26 <type>http://www.w3.org/2001/XMLSchema#string</type>27 <values>28 <value>SERVICE_PROVIDERS</value>29 <value>IDENTITY_PROVIDERS</value>30 <value>ACCESS_CONTROL</value>31 <value>USERS</value>32 </values>33 </attribute>34 </attributes>35 </category>36 <category>37 <uri>urn:oasis:names:tc:xacml:1.0:subject-category:access-subject</uri>38 <attributes>39 <attribute>40 <uri>urn:oasis:names:tc:xacml:1.0:subject:subject-id</uri>41 <type>http://www.w3.org/2001/XMLSchema#string</type>42 </attribute>43 <attribute>44 <uri>urn:facs:names:xacml:sp-dependent-policies-profile:1.0:subject:idp-entityid</uri>45 <type>http://www.w3.org/2001/XMLSchema#anyURI</type>46 </attribute>47 <attribute>48 <uri>urn:facs:names:xacml:sp-dependent-policies-profile:1.0:subject:role</uri>49 <type>http://www.w3.org/2001/XMLSchema#string</type>50 <values>51 <value>FACS_ADMIN</value>52 <value>SP_ADMIN</value>53 <value>IDP_ADMIN</value>54 <value>USER</value>55 </values>56 </attribute>57 </attributes>58 </category>59 </categories>60 </XACML>

Listagem A.3 – XML das entidades e atributos permitidos no perfil de políticasdependentes de SP do FACS.

1 <?xml version="1.0" encoding="UTF-8"?>2 <XACML xmlns="urn:facs:names:xacml:restrictions:1.0:schema">3 <categories>4 <category>


5 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:action</uri>6 <attributes>7 <attribute>8 <uri>urn:oasis:names:tc:xacml:1.0:action:action-id</uri>9 <type>http://www.w3.org/2001/XMLSchema#string</type>

10 <values>11 <value>deployVirtualMachine</value>12 <value>createSnapshot</value>13 <value>createTemplate</value>14 </values>15 </attribute>16 </attributes>17 </category>18 <category>19 <uri>urn:oasis:names:tc:xacml:1.0:subject-category:access-subject</uri>20 <attributes>21 <attribute>22 <uri>urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id</uri>23 <type>http://www.w3.org/2001/XMLSchema#string</type>24 </attribute>25 <attribute>26 <uri>urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name</uri>27 <type>http://www.w3.org/2001/XMLSchema#string</type>28 </attribute>29 </attributes>30 </category>31 <category>32 <uri>urn:oasis:names:tc:xacml:3.0:attribute-category:resource</uri>33 <attributes>34 <attribute>35 <uri>urn:oasis:names:tc:xacml:1.0:resource:resource-id</uri>36 <type>http://www.w3.org/2001/XMLSchema#integer</type>37 <values>38 <value>0</value>39 <value>3</value>40 <value>4</value>41 </values>42 </attribute>43 <attribute>44 <uri>urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value</uri>45 <type>http://www.w3.org/2001/XMLSchema#integer</type>46 </attribute>47 <attribute>48 <uri>urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-name</uri>49 <type>http://www.w3.org/2001/XMLSchema#string</type>50 </attribute>51 </attributes>52 </category>53 </categories>54 </XACML>

Listagem A.4 – XML das entidades e atributos permitidos no perfil de políticasdependentes de SP do CloudStack.

82

APÊNDICE B – Políticas XACML utilizadasna avaliação

Esse apêndice apresenta a Listagem das políticas de controle de acesso definidas emXACML utilizadas no cenário apresentando no Capítulo 5. A primeira política representaum política independente de SP, mostrada na Listagem B.1, ela especifica que somenteusuários do IdP Teste4 que tiverem o tipo de afiliação junto a sua instituição definidopara faculty podem acessar o Provedor de Serviço do CloudStack. As demais políticasrepresentam políticas dependentes de SP. Assim, a segunda, mostrada na Listagem B.2,específica que a conta com nome alice só pode criar no máximo 10 máquinas virtuais. Já aterceira, mostrada na Listagem B.3, específica que a conta com nome alice só pode criarno máximo 15 snapshots. Por fim, a quarta, mostrada na Listagem B.4, específica que aconta com nome alice só pode criar no máximo 5 templates.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="facs-sp-independent-policy-for-cloudstack-1"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Política para permitir o acesso somente de usuários com o vínculo do tipo faculty</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">13 https://cloudstack.imd.ufrn.br14 </AttributeValue>15 <AttributeDesignator16 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:sp-entityid"17 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"18 DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false"/>19 </Match>20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">22 https://idp4.imd.ufrn.br/idp/shibboleth23 </AttributeValue>24 <AttributeDesignator25 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:environment:idp-entityid"26 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"27 DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false"/>28 </Match>29 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">30 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>31 <AttributeDesignator32 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"33 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"34 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>35 </Match>36 </AllOf>37 </AnyOf>38 </Target>39 <Rule Effect="Permit" RuleId="Permit-Rule">

APÊNDICE B. Políticas XACML utilizadas na avaliação 83

40 <Target>41 <AnyOf>42 <AllOf>43 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">44 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">faculty</AttributeValue>45 <AttributeDesignator46 AttributeId="urn:facs:names:xacml:sp-independent-policies-profile:1.0:subject:brEduAffiliationType"47 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"48 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>49 </Match>50 </AllOf>51 </AnyOf>52 </Target>53 </Rule>54 <Rule Effect="Deny" RuleId="Deny-Rule"/>55 </Policy>

Listagem B.1 – Política independe de SP definida para o CloudStack em relação ao IdPTeste 4.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="cloudstack-policy-1"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Limita o número de máquinas virtuais que um conta pode criar</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">13 https://idp4.imd.ufrn.br/idp/shibboleth14 </AttributeValue>15 <AttributeDesignator16 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id"17 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"18 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>19 </Match>20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>22 <AttributeDesignator23 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name"24 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"25 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>26 </Match>27 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">28 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">deployVirtualMachine</AttributeValue>29 <AttributeDesignator30 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:action:action-name"31 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"32 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>33 </Match>34 </AllOf>35 </AnyOf>36 </Target>37 <Rule Effect="Permit" RuleId="Rule-1">38 <Target>39 <AnyOf>40 <AllOf>41 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">42 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">0</AttributeValue>43 <AttributeDesignator44 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"45 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"46 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>47 </Match>


48 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal">49 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">10</AttributeValue>50 <AttributeDesignator51 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value"52 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"53 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>54 </Match>55 </AllOf>56 </AnyOf>57 </Target>58 </Rule>59 </Policy>

Listagem B.2 – Política dependente de SP do CloudStack que restringe o número demáquinas virtuais que uma conta pode criar.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="cloudstack-policy-2"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Limita o número de snapshots que uma conta pode criar</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">https://idp.imd.ufrn.br/idp/shibboleth</

AttributeValue>13 <AttributeDesignator14 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id"15 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"16 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>17 </Match>18 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">19 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>20 <AttributeDesignator21 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name"22 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"23 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>24 </Match>25 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">26 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">createSnapshot</AttributeValue>27 <AttributeDesignator28 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:action:action-name"29 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"30 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>31 </Match>32 </AllOf>33 </AnyOf>34 </Target>35 <Rule Effect="Permit" RuleId="Rule-1">36 <Target>37 <AnyOf>38 <AllOf>39 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">40 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">3</AttributeValue>41 <AttributeDesignator42 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"43 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"44 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>45 </Match>46 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal">47 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">15</AttributeValue>48 <AttributeDesignator49 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value"50 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"


51 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>52 </Match>53 </AllOf>54 </AnyOf>55 </Target>56 </Rule>57 </Policy>

Listagem B.3 – Política dependente de SP do CloudStack que restringe o número desnapshots que uma conta pode criar.

1 <?xml version="1.0" encoding="UTF-8"?>2 <Policy3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"4 PolicyId="cloudstack-policy-3"5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"6 Version="1.0">7 <Description>Limita o número de templates que uma conta pode criar</Description>8 <Target>9 <AnyOf>

10 <AllOf>11 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">12 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">13 https://idp.imd.ufrn.br/idp/shibboleth14 </AttributeValue>15 <AttributeDesignator16 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:domain-id"17 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"18 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>19 </Match>20 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">21 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>22 <AttributeDesignator23 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:subject:account-name"24 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"25 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>26 </Match>27 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">28 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">createTemplate</AttributeValue>29 <AttributeDesignator30 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:action:action-name"31 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"32 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>33 </Match>34 </AllOf>35 </AnyOf>36 </Target>37 <Rule Effect="Permit" RuleId="Rule-1">38 <Target>39 <AnyOf>40 <AllOf>41 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-equal">42 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">4</AttributeValue>43 <AttributeDesignator44 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"45 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"46 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>47 </Match>48 <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:integer-less-than-or-equal">49 <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">5</AttributeValue>50 <AttributeDesignator51 AttributeId="urn:cloudstack:names:xacml:sp-dependent-policies-profile:1.0:resource:resource-value"52 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"53 DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true"/>54 </Match>55 </AllOf>56 </AnyOf>


57 </Target>58 </Rule>59 </Policy>

Listagem B.4 – Política dependente de SP do CloudStack que restringe o número detemplates que uma conta pode criar.

uma proposta de controle de acesso como serviço para … · 2019-01-31 · silva, brunno moreira...

Documents