Controle de Acesso Baseado em Políticas e Atributos para Federações de Recursos

Transcrição

1 Controle de Acesso Baseado em Políticas e Atributos para Federações de Recursos Edelberto F. Silva 1, Débora Muchaluat-Saade 1 e Natalia C. Fernandes 1 1 Universidade Federal Fluminense (UFF) Laboratório MídiaCom Niterói, RJ Brasil Abstract. Federated authentication methods as a base for accessing resources in virtual organizations is a challenge for the academic community and, therefore, the aim of this work. Issues about maintaining user attributes as well as the use of different access policies must be modeled and evaluated to allow a better management of identities in this environment. This work proposes an architecture for policy-based access control and also implements and validates an attribute provider using the CAFe academic federation (CAFeExpresso) to access the resources of academic virtual organizations. Resumo. A introdução de métodos de autenticação federada como base para o acesso aos recursos de organizações virtuais é de grande interesse para a comunidade acadêmica e, por essa razão, alvo deste trabalho. Questões relacionadas ao armazenamento de atributos de usuários, assim como a utilização de diferentes políticas de acesso devem ser modeladas e avaliadas para permitir uma melhor gestão de identidade nesse ambiente. Este trabalho propõe uma arquitetura para controle de acesso baseado em políticas e implementa e valida a utilização de um provedor de atributos baseado na federação acadêmica CAFe (CAFeExpresso) para o acesso a recursos de organizações virtuais acadêmicas. 1. Introdução Esta pesquisa tem como principal motivação o emprego e a facilitação do ingresso das federações acadêmicas de identidades em ambientes de recursos distribuídos. Sabe-se que diversos são os esforços nesta área, principalmente quando do surgimento da computação em grade (grid) [Foster et al. 2001] e das redes federadas para experimentação em Internet do Futuro [Silva et al. 2013b]. Nesses cenários, os usuários advindos de diferentes instituições acessam os recursos compartilhados para desenvolver pesquisas. Com a evolução do conceito de facilitação de ingresso dos usuários/experimentadores acadêmicos em ambientes de recursos compartilhados e distribuídos, surge então a proposta da criação de federações acadêmicas para auxiliar essa interação. Um exemplo claro de federação acadêmica criada no Brasil e em amplo crescimento e difusão é a CAFe 1 (Comunidade Acadêmica Federada). Sua principal motivação é criar uma federação de A&A (Autenticação e Autorização), ou seja, um ambiente em que as entidades envolvidas (Provedores de Serviço e Provedores de Identidade) participantes confiem uns nos outros, utilizando uma base federada de identidade para facilitar o ingresso aos serviços oferecidos por cada uma das instituições participantes. É a partir desse conceito que este trabalho se motiva, focando na união de federações (acadêmica e de recursos), porém aplicando conceitos e funcionalidades da Gestão de Identidade, GId (Identity Management - IdM) [Silva et al. 2013b]. A GId pode ser entendida como conjunto de processos e tecnologias usados para garantir a identidade c 2014 SBC Soc. Bras. de Computação

2 de uma entidade, garantir a qualidade das informações de identidade (identificadores, credenciais e atributos) e utilizar essas garantias em procedimentos de autenticação, autorização e auditoria [Silva et al. 2013b]. Desta forma, pode-se visualizar um cenário genérico de integração da federação acadêmica CAFe com qualquer federação de recursos conforme a Figura 1. Neste ambiente, há a união das federações com destaque para a autenticação e a autorização, tópicos que este trabalho objetiva tratar e propor soluções. Figura 1. União das federações. Federação CAFe e federação de recursos genérica. Neste trabalho, será proposta uma arquitetura para controle de acesso baseado em políticas e atributos para organizações virtuais acadêmicas. Como estudo de caso, uma organização virtual considerada é uma rede de experimentação de Internet do Futuro. Espera-se, em um futuro próximo, que haja maturidade para propor a adoção da proposta de controle de acesso baseado em políticas pelo projeto FIBRE (Future Internet Testbeds Experimentation Between Brazil and Europe) 2. O controle de acesso baseado em políticas proposto é baseado em um provedor de atributos, que armazena atributos complementares à federação acadêmica CAFe para um dado usuário. Esses atributos complementares são aqueles empregados apenas em um contexto específico, como o de um projeto de experimentação em redes. Nesse ambiente, é necessário pensar em soluções para, por exemplo, realizar o vínculo entre o identificador do usuário na federação acadêmica e no provedor de atributos, a fim de preservar a privacidade do usuário. Este artigo detalha a solução proposta para o provedor de atributos, que foi testada e validada utilizando como ambiente de experimentação o GidLab (Laboratório de Gestão de Identidade) da RNP. Após esta introdução tem-se a Seção 2 com os principais tipos de controle de acesso, assim como a linguagem de definição de políticas XACML extensible Access Control Markup Language [Moses 2005]. Logo após é apresentada a proposta de controle de acesso baseado em políticas e atributos para federações de recursos, na Seção 3. Já na Seção 4 são expostos os resultados para o provedor e agregador de atributos desenvolvido neste trabalho. Finalizando com a Seção 5 com as considerações finais e trabalhos futuros. 2. Controle de Acesso Serão apresentados os modelos de controle de acesso RBAC (Role-based Access Control) [Ferraiolo et al. 2001], ABAC (Attribute-based Access Control) [Hu et al. 2014] e c 2014 SBC Soc. Bras. de Computação

3 PBAC (PBAC - Policy-based Access Control) [Yavatkar et al. 2000], além da linguagem de políticas e trocas de mensagens baseada em XML, o XACML (extensible Access Control Markup Language) [Moses 2005] RBAC Após a larga utilização dos modelos de controle de acesso surge o RBAC (Role-based Access Control). O RBAC foi bastante utilizado, em princípio, no sistema operacional UNIX, com suas bases de dados para controle de acesso de grupos [Ferraiolo et al. 2001]. Na utilização do RBAC hierárquico, os papéis (roles), associam-se a um conjunto de operações que podem ser realizadas por um usuário ou grupo a um ou mais objetos (objects). Modelos de RBAC também podem suportar hierarquia, onde o usuário (subject) de nível inferior de uma árvore herda parte dos direitos que usuários de níveis diretamente superiores a este (pais e filhos na árvore) possuem. O modelo RBAC provê uma flexibilidade maior com relação a regras e aplicação em grupos. Porém, não se mostra tão flexível do ponto de vista do administrador, já que regras geralmente estão associadas diretamente a papéis. Sendo assim, quando um usuário necessita de regras específicas, diferentes daquelas associadas ao papel que ele detém, isso pode dispender bastante esforço administrativo e acrescentar dificuldade na gerência geral das regras existentes ABAC O modelo ABAC (Attribute-based Access Control) [Hu et al. 2014] é, como o nome induz, um controle baseado em atributos. Ao pensar em atributos, tem-se a ideia de uma tupla atributo=valor. No contexto do ABAC, este conceito é empregado tanto para subjects (e.g. usuários), como objects (e.g. recursos). O ABAC não é um padrão tão bem definido como o DAC, MAC ou o RBAC, pois é resultado de diversas propostas que surgiram nos últimos anos na literatura [Jin et al. 2012]. A padronização deste modelo se deu pelo NIST (National Institute of Standards and Technology) [Hu et al. 2014] em O ABAC tem como principal objetivo herdar as melhores práticas dos modelos de controle de acesso anteriores e tratar atributos mutáveis, dinâmicos e específicos de um ambiente. Em [Jin et al. 2012], é proposto um modelo ABAC flexível que possa herdar algumas características dos modelos DAC, MAC e RBAC, ou ainda, utilizar um dos modelos citados independentemente, porém, prevendo a inserção de novos atributos e permitindo um controle de acesso mais granular e escalável PBAC O controle de acesso baseado em políticas (PBAC - Policy-based Access Control) [Yavatkar et al. 2000] herda muito dos conceitos aplicados à qualidade de serviço e percebe-se que pode ser aplicado em conjunto com as ideias nas quais o ABAC se apoia. Porém, o PBAC tem sido encarado mais como uma forma de implementação do modelo ABAC atualmente difundido, com a utilização de diversos atributos para a escolha de políticas específicas. O PBAC também é uma forma de se utilizar pontos de decisão e coleção de atributos específicos aos subjects e resources 3. 3 Os resources são semelhantes aos objects, descritos no modelo anterior. 472 c 2014 SBC Soc. Bras. de Computação

4 Basicamente o modelo de controle de acesso baseado em políticas apresenta quatro entidades com seus papéis bem definidos, sendo eles: Policy Enforcement Point (PEP): entidade do sistema que realiza o controle de acesso, realizando pedidos de decisão e executanto esses pedidos; Policy Decision Point (PDP): entidade que avalia a política e a torna uma decisão de autorização a ser encaminhada ao PEP; Policy Information Point (PIP): entidade que exerce o papel de fonte de atributos e valores para subjects e resources e Policy Administration Point (PAP): entidade que cria (através do administrador) uma política ou um conjunto delas XACML A extensible Access Control Markup Language (XACML) [Moses 2005] é uma linguagem baseada em XML para a definição de políticas de segurança de forma padronizada pela OASIS (Organization for the Advancement of Structured Information Standards), a fim de garantir a interoperabilidade entre sistemas que desejam tratar a autorização. Além de ser uma linguagem para políticas de controle de acesso, a XACML define também um formato para mensagens de pedido e resposta. No padrão XACML, são definidos os formatos de troca de pedidos e respostas entre as entidades PDP e PEP, onde o último efetua realmente o processamento e aplicação da política. Já para garantir a interoperabilidade entre aplicações, o XACML faz uso de uma camada de abstração entre o ambiente de aplicação e o chamado Contexto XACML. Um Contexto XACML nada mais é que a definição XML representando canonicamente as entradas e saídas do PDP. No padrão XACML, é possível tratar políticas com mais flexibilidade utilizando um formato padrão de troca de mensagens, além de aproveitar técnicas de avaliação de políticas que auxiliam na prática do controle de acesso. Por exemplo, o XACML prevê ainda alguns algoritmos de combinação de regras (Rule-combining algorithm) que facilitam a aplicação das regras. Algoritmos de combinação de regras podem definir, por exemplo, que se uma das regras não for atendida, todo o acesso é negado ou vice-versa. Os algoritmos estão bem definidos na documentação disponível em [Moses 2005], assim como o formato das mensagens XACML a serem trocadas e a descrição para políticas. Vale ressaltar que o XACML prevê quatro tipos de retorno ao comparar atributos às políticas criadas. São eles: (1) Permit: aplicação da política de acesso permitido; (2) Deny: aplicação da política de acesso negado; (3) Indeterminate: quando um erro ocorre ou um valor requerido de um atributo não é encontrado e não é possível aplicar política alguma e (4) Not Applicable: a requisição não pode ser respondida (ou não se encaixa) pelo serviço. 3. Proposta de Controle de Acesso Baseado em Políticas e Atributos para Federações de Recursos Em um modelo de controle de acesso baseado em políticas, uma camada de controle de acesso se integra à arquitetura de gestão de identidade inicial exposta na Figura 1. Idealmente, esse modelo deve ser genérico, de forma que seja possível incorporá-lo a ambientes e cenários de organizações virtuais, como testbeds de experimentação para Internet do Futuro e cenários de grid, além de computação em nuvem. 4 Vale ressaltar a presença de tais entidades na padronização do ABAC em 2014, modo enterprise [Hu et al. 2014] 473 c 2014 SBC Soc. Bras. de Computação

5 Na proposta deste trabalho, o controle de acesso baseado em políticas deverá ser integrado a um mecanismo de autorização baseado em um provedor de atributos. O provedor de atributos deverá armazenar os atributos complementares à federação de identidade (por exemplo, CAFe) para um dado usuário. Atributos complementares são aqueles empregados apenas em um contexto específico, como o de um projeto de experimentação em redes. Nesse ambiente é necessário pensar em soluções para, por exemplo, realizar o vínculo entre o identificador do usuário na federação e no provedor de atributos, sendo que esse identificador deve ser o mais opaco quanto possível, a fim de preservar a privacidade do usuário. Este ambiente, onde grupos são formados e têm suas identidades gerenciadas de forma a usufruir de recursos particulares, é conhecido como organização virtual (OV) [Foster et al. 2001]. Na Figura 2, é ilustrada a proposta de integração do mecanismo de autenticação federada, com o mecanismo de autorização baseado em atributos e utilização de políticas de acesso. A figura mostra as entidades da arquitetura proposta envolvidas nas transações de controle de acesso baseado em políticas com a utilização de um provedor de atributos 5. Figura 2. Arquitetura da proposta de controle de acesso baseado em políticas com agregação de atributos. Utilizando como estudo de caso o projeto FIBRE, descrevem-se os passos realizados desde a autenticação federada até a autorização da utilização de recursos controlados pelas políticas de acesso distribuídas, considerando políticas tanto locais quanto globais. Sendo assim, no passo 1, o usuário acessa o provedor de serviço (SP) que o encaminhará (passo 2) à autenticação, seja ela através da CAFe ou do LDAP FIBRE federado 6. Tais etapas são tradicionalmente usadas na criação de uma sessão SAML [OASIS 2005], a partir do acesso do usuário ao SP, redirecionamento por meio do WAYF (Where Are You From) a seu IdP de origem, autenticação e troca de atributos. Já no passo 3, o usuário, após autenticado, requisita a lista de recursos disponíveis à federação de recursos SFA [Peterson et al. 2010]. Neste passo, o SFA é responsável por comunicar-se com o SM 5 Devemos destacar que o provedor de atributos adicionais neste trabalho é um diretório LDAP que armazena apenas os atributos adicionais do usuário. 6 O LDAP FIBRE Federado é um LDAP cuja árvore interliga tanto as instituições brasileiras quanto europeias e suas respectivas ilhas, possibilitando um acesso federado àquele usuário que participa do projeto. 474 c 2014 SBC Soc. Bras. de Computação

6 (Slice Manager) que tem uma visão global de todos os AM (Aggregate Manager) que, por sua vez, tem contato direto com os recursos das ilhas em questão. Sendo assim, os recursos são listados por meio de arquivos do tipo XML, chamado de RSpecs (Resource Specification) [Peterson et al. 2010] e retornam até o usuário no passo 5. A partir desse momento, o usuário poderá requisitar os recursos que deseja. Para verificar se o usuário pode ter acesso aos recursos que está solicitando, os passos adicionais estão relacionados ao controle de acesso baseado em políticas e a agregação de atributos que este trabalho propõe. No passo 6, é enviado, pelo SP ao agregador de atributos (Attribute Aggregator), um atributo opaco, que identifica o usuário no provedor de atributos (Attribute Provider), de tal forma que seja possível recuperar os atributos adicionais da OV sem identificar o usuário diretamente no IdP da federação CAFe. Então, os passos 7 e 8 são responsáveis por recuperar tais atributos e permitir que o agregador de atributos os una aos atributos provenientes da CAFe, complementando o conjunto de atributos do usuário necessários ao acesso solicitado. Com todos os dados necessários, o SP recebe como retorno do agregador de atributos todos os atributos do usuário no ambiente da OV (atributos da CAFe mais atributos adicionais do Provedor de Atributos), no passo 9, e encaminha tanto esses atributos quanto o RSpec (recebido no passo 5) ao PEP no passo 10. O PEP então realiza a conversão dos atributos em uma pontuação de classificação que indicará em qual classe este usuário se encaixa, considerando os valores de seus atributos. Para este passo temos a definição da Seção 3.1, para maiores detalhes. No passo 11, o PEP realiza a conversão dos arquivos RSpec e de pontuação gerado para XACML. No passo 12, o XACML gerado é enviado à ilha do FIBRE (no caso), e, primeiramente, ao PIP, no passo 13, que realizará a associação do XACML com o seu repositório que deve manter atributos adicionais (opcional), os recursos (objects) e dados relativos ao usuário (subject) 7. Sendo assim, no passo 14, as políticas XACML às quais o administrador da ilha previamente cadastrou através do PAP são retornadas ao PDP (passo 15). Neste momento uma política global também é verificada, através do passo 16 e a utilização dos algoritmos de combinação de políticas apresentados pelo próprio XACML [Moses 2005], retornando ao PDP, no passo 17, a decisão tomada. Convertendo ao formato original de RSpec no passo 18 e 19, o PEP entrega ao SP quais recursos o usuário poderá alocar. Na Figura 2, é possível visualizar também, junto ao SP, o LDAP Federado, que é uma base independente da federação CAFe que permite usuários de instituições ainda não participantes da federação CAFe a ter acesso à federação de recursos. Esta base existe atualmente no FIBRE e aparece nesta proposta como forma também de mostrar a generalização quanto a origem dos atributos do usuário Pontuação de Atributos e Recursos Para classificar os usuários e facilitar a implementação de políticas de acesso distribuídas em diversas instituições, este trabalho propõe um mecanismo de pontuação de atributos, cuja soma determina a classe de um usuário. Cada atributo deverá ter uma pontuação atribuída de forma a generalizar a definição de políticas no contexto do controle de acesso baseado em políticas e atributos. Sendo assim, é apresentado um exemplo para utilização no caso da federação de experimentação do FIBRE. 7 Sendo que, no caso deste trabalho, tudo estará vinculado a classes e não a usuários específicos, como forma de deixar mais simples a administração do ambiente de controle de acesso distribuído baseado em políticas 475 c 2014 SBC Soc. Bras. de Computação

7 Tabela de Pontuação para Atributos Atributo Opção Valor Peso Total Parcial breduaffiliationtype student omfadmin TRUE institution uff Total 58 Tabela 1. Tabela de Pontuação para Atributos Tabela de Pontuação para Atributos Pontuação Nível 0 < X < X < X Tabela 2. Tabela de Pontuação para Atributos Imaginemos que, conforme a Tabela 1, o usuário experimentador tem o total de 58 pontos. Esses pontos serão utilizados no momento de alocação de recursos, sendo que um usuário se encontra no nível de acesso conforme a Tabela 2. Um usuário nível 02, seguindo o exemplo utilizado para a Tabela 1, tem então direito de alocar até 15 máquinas virtuais, conforme a Tabela 3, por exemplo no ambiente do testbed OCF do FIBRE. Tabela de Pontuação para Recursos para Máquinas Virtuais VMs Nível 0 X X X Tabela 3. Tabela de Pontuação para Recursos para Máquinas Virtuais 4. Resultados 4.1. Agregação de Atributos para Organizações Virtuais Em [Silva et al. 2013a], foi desenvolvida a parte referente à autenticação destacada na Figura 2, com a integração da federação CAFe à federação de experimentação. Já neste trabalho, são apresentados os resultados de um provedor de atributos com a utilização de um agregador de atributos, permitindo que atributos específicos de uma organização virtual possam ser armazenados separadamente dos atributos advindos da federação acadêmica, considerando como caso de estudo a CAFe. Assim, não é necessário alterar o modelo de armazenamento de atributos da federação. Modelos de agregação de atributos foram estudados com base no trabalho [Chadwick et al. 2010] e optou-se, pelo cenário aqui aplicado, onde a agregação de atributos é implementada com auxílio de um provedor de serviços (Service Provider - SP). Porém, os atributos adicionais armazenados no provedor de atributos não devem identificar o usuário aos quais estão associados. Sendo assim, foi criado um identificador único e opaco, de forma a vincular o usuário da federação acadêmica dentro do provedor de atributos da organização virtual (OV). A ideia base para a utilização de um identificador único e opaco surgiu dos estudos sobre a federação acadêmica SWITCH 8, que define c 2014 SBC Soc. Bras. de Computação

8 também este identificador baseado em outro atributo, também único e fixo do usuário na federação 9. Conforme a Figura 2 da arquitetura proposta, este trabalho implementa os passos do 1 ao 9. Devemos esclarecer que o atributo único e opaco utiliza a combinação de dois atributos comuns e um hash criptográfico, como é possível ver pelas equações: δ Attr u (uid) Attr u (uidnumber) (1) Attr U (opaque) hash(δ) (2) O resultado, por exemplo, para o uid = esilva@uff com uidnumber = 1223 é o valor da operação utilizando-se um hash md5 da concatenação dos dois atributos, resultando emaf2ec12ce73cc910358ddb400f4abb74. É interessante utilizar para este método sempre hash criptográficos mais atuais, como SHA-1, SHA-2, SHA-256, etc, por exemplo 10. Na Figura 3, vê-se o passo a passo de autenticação do usuário na federação CA- FeExpresso disponível no GidLab. Onde primeiramente é mostrada a tela do serviço de homologação dos atributos, logo após direcionado o usuário ao WAYF para a escolha de sua instituição (i.e. IdP1). Feito isso, o usuário insere suas credenciais (i.e. esilva@uff ) e se autentica em sua instituição de origem. (a) Tela inicial de homologação de atributos. (b) Escolha do IdP para autenticação pelo usuário. Figura 3. Passos para a autenticação CAFe. Ainda na Figura 4, vê-se os atributos advindos apenas somente daquele IdP, ou seja, os atributos originais daquele usuário em sua instituição. O que se vê mais à frente é a resposta para a mesma tela de homologação de atributos porém utilizando-se o agregador de atributos e o provedor de atributos para a OV do FIBRE. Na Figura 5, os atributos de homologação (validação do sucesso de autenticação do usuário na CAFe) e também os atributos Attr opaque, Shib-fibre-userEnable e Shib-fibre-omfAdmin aparecem em destaque. Como anteriormente abordado, o Attr opaque foi aquele responsável pela pesquisa possível dos demais dois atributos do usuário contidos no provedor de atributos, neste exemplo. 5. Considerações Finais e Trabalhos Futuros Este trabalho apresentou uma arquitetura de controle de acesso baseado em políticas, assim como a utilização de um provedor de atributos, para organizações virtuais acadêmicas Na validação do modelo do provedor e agregador de atributos, foi utilizado um hash criptográfico MD c 2014 SBC Soc. Bras. de Computação

9 (a) Autenticação sendo realizada pelo usuário(b) Homologação dos atributos padrão advindos do IdP original. Figura 4. Passos para a autenticação CAFe e homologação dos atributos recebidos pelo SP. Figura 5. Homologação com atributos agregados. baseadas em federações de autenticação e autorização. Como resultados são apresentados, dentro da arquitetura proposta e do estudo de caso do projeto FIBRE, um agregador de atributos e o mecanismo de agregação de atributos por meio de um identificador único e opaco. Apesar de usar o FIBRE como estudo de caso, a proposta é genérica e pode ser aplicada em outros tipos de organização virtual onde haja compartilhamento de recursos distribuídos por usuários advindos de diferentes instituições. Como próximos passos, tem-se a criação de políticas XACML. Tais políticas serão aplicadas tanto utilizando RBAC quanto ABAC no modelo de validação do projeto. Como 478 c 2014 SBC Soc. Bras. de Computação

10 exemplo, tem-se como entrada uma solicitação do usuário/experimentador da listagem de recursos. Esta solicitação se dá a federação de recursos (implementada pelo SFA no FIBRE) por meio de um arquivo baseado em XML chamado RSpec, e assim, serão avaliados os atributos e comparados a políticas XACML pré-estabelecidas, armazenadas no PAP. Nesse caso específico, o usuário que envia suas credenciais e é o AM Aggregate Manager 11 do SFA. O SFA recebe as credenciais do usuário e gera um RSpec. O RSpec retornado para o usuário será interceptado pelo controle de acesso baseado em políticas proposto nesse trabalho. Assim, o retorno ao usuário será um RSpec resultante da filtragem (ou não) proporcionada pela política definida com o XACML. 6. Agradecimentos Agradecemos o apoio da RNP através do PGID (Programa de Gestão de Identidade), ao GidLab (Laboratório de Gestão de Identidade) da RNP e à CAPES. Referências Chadwick, D., Inman, G., and Klingenstein, N. (2010). A conceptual model for attribute aggregation. Future Generation Computer Systems, 26(7): Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., and Chandramouli, R. (2001). Proposed nist standard for role-based access control. ACM Trans. Inf. Syst. Secur., 4(3): Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the grid: Enabling scalable virtual organizations. Int. J. High Perform. Comput. Appl., 15(3): Hu, V. C., Ferraiolo, D., Kuhn, R., Friedman, A. R., Lang, A. J., Cogdell, M. M., Schnitzer, A., Sandlin, K., Miller, R., Scarfone, K., Hu, V. C., Ferraiolo, D., Kuhn, R., Friedman, A. R., Lang, A. J., Cogdell, M. M., Schnitzer, A., Sandlin, K., Miller, R., Scarfone, K., and Cybersecurity, S. (2014). Guide to attribute based access control (abac) definition and considerations. Jin, X., Krishnan, R., and Sandhu, R. (2012). A unified attribute-based access control model covering dac, mac and rbac. In Proceedings of the 26th Annual IFIP WG 11.3 Conference on Data and Applications Security and Privacy, DBSec 12, pages 41 55, Berlin, Heidelberg. Springer-Verlag. Moses, T. (2005). extensible Access Control Markup Language TC v2.0 (XACML). OASIS (2005). Security assertion markup language (saml) v2.0. Peterson, L., Ricci, R., Falk, A., and Chase, J. (2010). Slice-based federation architecture. Technical report. Silva, E., Muchaluat-Saade, D., and Fernandes, N. C. (2013a). Transposicão de credenciais para uso de testbeds para a internet do futuro. In SBSeg WGID, Manaus. Silva, E., Muchaluat-Saade, D., Magalhaes, L., Fernandes, N. C., and Rodriguez, N. (2013b). Gestão de identidade em organizacões virtuais. In JAI Yavatkar, R., Pendarakis, D., and Guerin, R. (2000). A framework for policy-based admission control. 11 A entidade que mantém contato direto com os recursos existentes. 479 c 2014 SBC Soc. Bras. de Computação