Controle de Acesso Baseado em Pol´ıticas e Atributos para
Federac¸˜oes de Recursos
Edelberto F. Silva1, D´ebora Muchaluat-Saade1e Natalia C. Fernandes1
1Universidade Federal Fluminense (UFF) – Laborat´orio M´ıdiaCom – Niter´oi, RJ – Brasil
Abstract. Federated authentication methods as a base for accessing resources in virtual organizations is a challenge for the academic community and, the-refore, 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 introduc¸˜ao de m´etodos de autenticac¸˜ao federada como base para o acesso aos recursos de organizac¸˜oes virtuais ´e de grande interesse para a comunidade acadˆemica e, por essa raz˜ao, alvo deste trabalho. Quest˜oes relaci-onadas ao armazenamento de atributos de usu´arios, assim como a utilizac¸˜ao de diferentes pol´ıticas de acesso devem ser modeladas e avaliadas para permitir uma melhor gest˜ao de identidade nesse ambiente. Este trabalho prop˜oe uma ar-quitetura para controle de acesso baseado em pol´ıticas e implementa e valida a utilizac¸˜ao de um provedor de atributos baseado na federac¸˜ao acadˆemica CAFe (CAFeExpresso) para o acesso a recursos de organizac¸˜oes virtuais acadˆemicas.
1. Introduc¸˜ao
Esta pesquisa tem como principal motivac¸˜ao o emprego e a facilitac¸˜ao do ingresso das federac¸˜oes acadˆemicas de identidades em ambientes de recursos distribu´ıdos. Sabe-se que diversos s˜ao os esforc¸os nesta ´area, principalmente quando do surgimento da computac¸˜ao em grade (grid) [Foster et al. 2001] e das redes federadas para experimentac¸˜ao em Inter-net do Futuro [Silva et al. 2013b]. Nesses cen´arios, os usu´arios advindos de diferentes instituic¸˜oes acessam os recursos compartilhados para desenvolver pesquisas.
Com a evoluc¸˜ao do conceito de facilitac¸˜ao de ingresso dos
usu´arios/experimentadores acadˆemicos em ambientes de recursos compartilhados e distribu´ıdos, surge ent˜ao a proposta da criac¸˜ao de federac¸˜oes acadˆemicas para auxiliar essa interac¸˜ao. Um exemplo claro de federac¸˜ao acadˆemica criada no Brasil e em amplo crescimento e difus˜ao ´e a CAFe1 (Comunidade Acadˆemica Federada). Sua principal motivac¸˜ao ´e criar uma federac¸˜ao de A&A (Autenticac¸˜ao e Autorizac¸˜ao), ou seja, um ambiente em que as entidades envolvidas (Provedores de Servic¸o e Provedores de Identidade) participantes confiem uns nos outros, utilizando uma base federada de identidade para facilitar o ingresso aos servic¸os oferecidos por cada uma das instituic¸˜oes participantes. ´E a partir desse conceito que este trabalho se motiva, focando na uni˜ao de federac¸˜oes (acadˆemica e de recursos), por´em aplicando conceitos e funcionalidades da Gest˜ao 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
de uma entidade, garantir a qualidade das informac¸˜oes de identidade (identificadores, credenciais e atributos) e utilizar essas garantias em procedimentos de autenticac¸˜ao, autorizac¸˜ao e auditoria [Silva et al. 2013b].
Desta forma, pode-se visualizar um cen´ario gen´erico de integrac¸˜ao da federac¸˜ao acadˆemica CAFe com qualquer federac¸˜ao de recursos conforme a Figura 1. Neste ambi-ente, h´a a uni˜ao das federac¸˜oes com destaque para a autenticac¸˜ao e a autorizac¸˜ao, t´opicos que este trabalho objetiva tratar e propor soluc¸˜oes.
Figura 1. Uni˜ao das federac¸˜oes. Federac¸˜ao CAFe e federac¸˜ao de recursos gen´erica. Neste trabalho, ser´a proposta uma arquitetura para controle de acesso baseado em pol´ıticas e atributos para organizac¸˜oes virtuais acadˆemicas. Como estudo de caso, uma organizac¸˜ao virtual considerada ´e uma rede de experimentac¸˜ao de Internet do Futuro. Espera-se, em um futuro pr´oximo, que haja maturidade para propor a adoc¸˜ao 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 ´e baseado em um provedor de atributos, que armazena atributos complementares `a federac¸˜ao acadˆemica CAFe para um dado usu´ario. Esses atributos complementares s˜ao aqueles empregados apenas em um contexto espec´ıfico, como o de um projeto de experimentac¸˜ao em redes. Nesse ambiente, ´e necess´ario pensar em soluc¸˜oes para, por exemplo, realizar o v´ınculo entre o identificador do usu´ario na federac¸˜ao acadˆemica e no provedor de atributos, a fim de preservar a privacidade do usu´ario. Este artigo detalha a soluc¸˜ao proposta para o provedor de atributos, que foi testada e validada utilizando como ambiente de experimentac¸˜ao o GidLab (Laborat´orio de Gest˜ao de Identidade) da RNP.
Ap´os esta introduc¸˜ao tem-se a Sec¸˜ao 2 com os principais tipos de controle de acesso, assim como a linguagem de definic¸˜ao de pol´ıticas XACML eXtensible Access Control Markup Language [Moses 2005]. Logo ap´os ´e apresentada a proposta de con-trole de acesso baseado em pol´ıticas e atributos para federac¸˜oes de recursos, na Sec¸˜ao 3. J´a na Sec¸˜ao 4 s˜ao expostos os resultados para o provedor e agregador de atributos desenvolvido neste trabalho. Finalizando com a Sec¸˜ao 5 com as considerac¸˜oes finais e trabalhos futuros.
2. Controle de Acesso
Ser˜ao apresentados os modelos de controle de acesso RBAC (Role-based Access Con-trol) [Ferraiolo et al. 2001], ABAC (Attribute-based Access ConCon-trol) [Hu et al. 2014] e
PBAC (PBAC - Policy-based Access Control) [Yavatkar et al. 2000], al´em da linguagem de pol´ıticas e trocas de mensagens baseada em XML, o XACML (eXtensible Access Con-trol Markup Language) [Moses 2005].
2.0.1. RBAC
Ap´os a larga utilizac¸˜ao 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 utilizac¸˜ao do RBAC hier´arquico, os pap´eis (roles), associam-se a um conjunto de operac¸˜oes que podem ser realizadas por um usu´ario ou grupo a um ou mais objetos (ob-jects). Modelos de RBAC tamb´em podem suportar hierarquia, onde o usu´ario (subject) de n´ıvel inferior de uma ´arvore herda parte dos direitos que usu´arios de n´ıveis diretamente superiores a este (pais e filhos na ´arvore) possuem.
O modelo RBAC provˆe uma flexibilidade maior com relac¸˜ao a regras e aplicac¸˜ao em grupos. Por´em, n˜ao se mostra t˜ao flex´ıvel do ponto de vista do administrador, j´a que regras geralmente est˜ao associadas diretamente a pap´eis. Sendo assim, quando um usu´ario necessita de regras espec´ıficas, diferentes daquelas associadas ao papel que ele det´em, isso pode dispender bastante esforc¸o administrativo e acrescentar dificuldade na gerˆencia geral das regras existentes.
2.0.2. ABAC
O modelo ABAC (Attribute-based Access Control) [Hu et al. 2014] ´e, como o nome in-duz, um controle baseado em atributos. Ao pensar em atributos, tem-se a ideia de uma tupla atributo=valor. No contexto do ABAC, este conceito ´e empregado tanto para sub-jects (e.g. usu´arios), como objects (e.g. recursos). O ABAC n˜ao ´e um padr˜ao t˜ao bem definido como o DAC, MAC ou o RBAC, pois ´e resultado de diversas propostas que surgi-ram nos ´ultimos anos na literatura [Jin et al. 2012]. A padronizac¸˜ao deste modelo se deu pelo NIST (National Institute of Standards and Technology) [Hu et al. 2014] em 2014.
O ABAC tem como principal objetivo herdar as melhores pr´aticas dos modelos de controle de acesso anteriores e tratar atributos mut´aveis, dinˆamicos e espec´ıficos de um ambiente. Em [Jin et al. 2012], ´e proposto um modelo ABAC flex´ıvel que possa her-dar algumas caracter´ısticas dos modelos DAC, MAC e RBAC, ou ainda, utilizar um dos modelos citados independentemente, por´em, prevendo a inserc¸˜ao de novos atributos e permitindo um controle de acesso mais granular e escal´avel.
2.0.3. PBAC
O controle de acesso baseado em pol´ıticas (PBAC - Policy-based Access Control) [Yavatkar et al. 2000] herda muito dos conceitos aplicados `a qualidade de servic¸o e percebe-se que pode ser aplicado em conjunto com as ideias nas quais o ABAC se apoia. Por´em, o PBAC tem sido encarado mais como uma forma de implementac¸˜ao do modelo ABAC atualmente difundido, com a utilizac¸˜ao de diversos atributos para a escolha de pol´ıticas espec´ıficas. O PBAC tamb´em ´e uma forma de se utilizar pontos de decis˜ao e colec¸˜ao de atributos espec´ıficos aos subjects e resources3.
Basicamente o modelo de controle de acesso baseado em pol´ıticas apresenta qua-tro entidades com seus pap´eis bem definidos, sendo eles: Policy Enforcement Point (PEP): entidade do sistema que realiza o controle de acesso, realizando pedidos de decis˜ao e exe-cutanto esses pedidos; Policy Decision Point (PDP): entidade que avalia a pol´ıtica e a torna uma decis˜ao de autorizac¸˜ao a ser encaminhada ao PEP; Policy Information Point (PIP): entidade que exerce o papel de fonte de atributos e valores para subjects e resour-cese Policy Administration Point (PAP): entidade que cria (atrav´es do administrador) uma pol´ıtica ou um conjunto delas4.
2.1. XACML
A eXtensible Access Control Markup Language (XACML) [Moses 2005] ´e uma lingua-gem baseada em XML para a definic¸˜ao de pol´ıticas de seguranc¸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 autorizac¸˜ao.
Al´em de ser uma linguagem para pol´ıticas de controle de acesso, a XACML define tamb´em um formato para mensagens de pedido e resposta. No padr˜ao XACML, s˜ao definidos os formatos de troca de pedidos e respostas entre as entidades PDP e PEP, onde o ´ultimo efetua realmente o processamento e aplicac¸˜ao da pol´ıtica. J´a para garantir a interoperabilidade entre aplicac¸˜oes, o XACML faz uso de uma camada de abstrac¸˜ao entre o ambiente de aplicac¸˜ao e o chamado Contexto XACML. Um Contexto XACML nada mais ´e que a definic¸˜ao XML representando canonicamente as entradas e sa´ıdas do PDP.
No padr˜ao XACML, ´e poss´ıvel tratar pol´ıticas com mais flexibilidade utilizando um formato padr˜ao de troca de mensagens, al´em de aproveitar t´ecnicas de avaliac¸˜ao de pol´ıticas que auxiliam na pr´atica do controle de acesso. Por exemplo, o XACML prevˆe ainda alguns algoritmos de combinac¸˜ao de regras (Rule-combining algorithm) que faci-litam a aplicac¸˜ao das regras. Algoritmos de combinac¸˜ao de regras podem definir, por exemplo, que se uma das regras n˜ao for atendida, todo o acesso ´e negado ou vice-versa. Os algoritmos est˜ao bem definidos na documentac¸˜ao dispon´ıvel em [Moses 2005], assim como o formato das mensagens XACML a serem trocadas e a descric¸˜ao para pol´ıticas. Vale ressaltar que o XACML prevˆe quatro tipos de retorno ao comparar atributos `as pol´ıticas criadas. S˜ao eles: (1) Permit: aplicac¸˜ao da pol´ıtica de acesso permitido; (2) Deny: aplicac¸˜ao da pol´ıtica de acesso negado; (3) Indeterminate: quando um erro ocorre ou um valor requerido de um atributo n˜ao ´e encontrado e n˜ao ´e poss´ıvel aplicar pol´ıtica alguma e (4) Not Applicable: a requisic¸˜ao n˜ao pode ser respondida (ou n˜ao se encaixa) pelo servic¸o.
3. Proposta de Controle de Acesso Baseado em Pol´ıticas e Atributos para
Federac¸˜oes de Recursos
Em um modelo de controle de acesso baseado em pol´ıticas, uma camada de controle de acesso se integra `a arquitetura de gest˜ao de identidade inicial exposta na Figura 1. Idealmente, esse modelo deve ser gen´erico, de forma que seja poss´ıvel incorpor´a-lo a ambientes e cen´arios de organizac¸˜oes virtuais, como testbeds de experimentac¸˜ao para Internet do Futuro e cen´arios de grid, al´em de computac¸˜ao em nuvem.
4Vale ressaltar a presenc¸a de tais entidades na padronizac¸˜ao do ABAC em 2014, modo
Na proposta deste trabalho, o controle de acesso baseado em pol´ıticas dever´a ser integrado a um mecanismo de autorizac¸˜ao baseado em um provedor de atributos. O prove-dor de atributos dever´a armazenar os atributos complementares `a federac¸˜ao de identidade (por exemplo, CAFe) para um dado usu´ario. Atributos complementares s˜ao aqueles em-pregados apenas em um contexto espec´ıfico, como o de um projeto de experimentac¸˜ao em redes. Nesse ambiente ´e necess´ario pensar em soluc¸˜oes para, por exemplo, realizar o v´ınculo entre o identificador do usu´ario na federac¸˜ao e no provedor de atributos, sendo que esse identificador deve ser o mais opaco quanto poss´ıvel, a fim de preservar a pri-vacidade do usu´ario. Este ambiente, onde grupos s˜ao formados e tˆem suas identidades gerenciadas de forma a usufruir de recursos particulares, ´e conhecido como organizac¸˜ao virtual (OV) [Foster et al. 2001].
Na Figura 2, ´e ilustrada a proposta de integrac¸˜ao do mecanismo de autenticac¸˜ao federada, com o mecanismo de autorizac¸˜ao baseado em atributos e utilizac¸˜ao de pol´ıticas de acesso. A figura mostra as entidades da arquitetura proposta envolvidas nas transac¸˜oes de controle de acesso baseado em pol´ıticas com a utilizac¸˜ao de um provedor de atributos5.
Figura 2. Arquitetura da proposta de controle de acesso baseado em pol´ıticas com agregac¸˜ao de atributos.
Utilizando como estudo de caso o projeto FIBRE, descrevem-se os passos realiza-dos desde a autenticac¸˜ao federada at´e a autorizac¸˜ao da utilizac¸˜ao de recursos controlarealiza-dos pelas pol´ıticas de acesso distribu´ıdas, considerando pol´ıticas tanto locais quanto globais. Sendo assim, no passo 1, o usu´ario acessa o provedor de servic¸o (SP) que o encaminhar´a (passo 2) `a autenticac¸˜ao, seja ela atrav´es da CAFe ou do LDAP FIBRE federado6. Tais etapas s˜ao tradicionalmente usadas na criac¸˜ao de uma sess˜ao SAML [OASIS 2005], a partir do acesso do usu´ario ao SP, redirecionamento por meio do WAYF (Where Are You From) a seu IdP de origem, autenticac¸˜ao e troca de atributos. J´a no passo 3, o usu´ario, ap´os autenticado, requisita a lista de recursos dispon´ıveis `a federac¸˜ao de recursos SFA [Peterson et al. 2010]. Neste passo, o SFA ´e respons´avel por comunicar-se com o SM
5Devemos destacar que o provedor de atributos adicionais neste trabalho ´e um diret´orio LDAP que
armazena apenas os atributos adicionais do usu´ario.
6O LDAP FIBRE Federado ´e um LDAP cuja ´arvore interliga tanto as instituic¸˜oes brasileiras quanto
(Slice Manager) que tem uma vis˜ao global de todos os AM (Aggregate Manager) que, por sua vez, tem contato direto com os recursos das ilhas em quest˜ao. Sendo assim, os recursos s˜ao listados por meio de arquivos do tipo XML, chamado de RSpecs (Resource Specification) [Peterson et al. 2010] e retornam at´e o usu´ario no passo 5. A partir desse momento, o usu´ario poder´a requisitar os recursos que deseja. Para verificar se o usu´ario pode ter acesso aos recursos que est´a solicitando, os passos adicionais est˜ao relacionados ao controle de acesso baseado em pol´ıticas e a agregac¸˜ao de atributos que este trabalho prop˜oe. No passo 6, ´e enviado, pelo SP ao agregador de atributos (Attribute Aggregator), um atributo opaco, que identifica o usu´ario no provedor de atributos (Attribute Provider), de tal forma que seja poss´ıvel recuperar os atributos adicionais da OV sem identificar o usu´ario diretamente no IdP da federac¸˜ao CAFe. Ent˜ao, os passos 7 e 8 s˜ao respons´aveis 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´ario necess´arios ao acesso solicitado.
Com todos os dados necess´arios, o SP recebe como retorno do agregador de atri-butos todos os atriatri-butos do usu´ario no ambiente da OV (atriatri-butos da CAFe mais atriatri-butos 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˜ao realiza a convers˜ao dos atributos em uma pontuac¸˜ao de classificac¸˜ao que indicar´a em qual classe este usu´ario se encaixa, considerando os valores de seus atributos. Para este passo temos a definic¸˜ao da Sec¸˜ao 3.1, para maiores detalhes. No passo 11, o PEP realiza a convers˜ao dos arquivos RSpec e de pontuac¸˜ao gerado para XACML. No passo 12, o XACML gerado ´e envi-ado `a ilha do FIBRE (no caso), e, primeiramente, ao PIP, no passo 13, que realizar´a a associac¸˜ao do XACML com o seu reposit´orio que deve manter atributos adicionais (opci-onal), os recursos (objects) e dados relativos ao usu´ario (subject)7. Sendo assim, no passo 14, as pol´ıticas XACML `as quais o administrador da ilha previamente cadastrou atrav´es do PAP s˜ao retornadas ao PDP (passo 15). Neste momento uma pol´ıtica global tamb´em ´e verificada, atrav´es do passo 16 e a utilizac¸˜ao dos algoritmos de combinac¸˜ao de pol´ıticas apresentados pelo pr´oprio XACML [Moses 2005], retornando ao PDP, no passo 17, a de-cis˜ao tomada. Convertendo ao formato original de RSpec no passo 18 e 19, o PEP entrega ao SP quais recursos o usu´ario poder´a alocar.
Na Figura 2, ´e poss´ıvel visualizar tamb´em, junto ao SP, o LDAP Federado, que ´e uma base independente da federac¸˜ao CAFe que permite usu´arios de instituic¸˜oes ainda n˜ao participantes da federac¸˜ao CAFe a ter acesso `a federac¸˜ao de recursos. Esta base existe atualmente no FIBRE e aparece nesta proposta como forma tamb´em de mostrar a generalizac¸˜ao quanto a origem dos atributos do usu´ario.
3.1. Pontuac¸˜ao de Atributos e Recursos
Para classificar os usu´arios e facilitar a implementac¸˜ao de pol´ıticas de acesso distribu´ıdas em diversas instituic¸˜oes, este trabalho prop˜oe um mecanismo de pontuac¸˜ao de atributos, cuja soma determina a classe de um usu´ario. Cada atributo dever´a ter uma pontuac¸˜ao atribu´ıda de forma a generalizar a definic¸˜ao de pol´ıticas no contexto do controle de acesso baseado em pol´ıticas e atributos. Sendo assim, ´e apresentado um exemplo para utilizac¸˜ao no caso da federac¸˜ao de experimentac¸˜ao do FIBRE.
7Sendo que, no caso deste trabalho, tudo estar´a vinculado a classes e n˜ao a usu´arios espec´ıficos, como
forma de deixar mais simples a administrac¸˜ao do ambiente de controle de acesso distribu´ıdo baseado em pol´ıticas
Tabela de Pontuac¸˜ao para Atributos
Atributo Opc¸˜ao Valor Peso Total Parcial
brEduAffiliationType student 10 3 30
omfAdmin TRUE 10 2 20
institution uff 8 1 8
Total 58 Tabela 1. Tabela de Pontuac¸˜ao para Atributos
Tabela de Pontuac¸˜ao para Atributos
Pontuac¸˜ao N´ıvel
0 < X ≤ 50 01 50 < X ≤ 100 02 100 < X ≤ 200 03
Tabela 2. Tabela de Pontuac¸˜ao para Atributos
Imaginemos que, conforme a Tabela 1, o usu´ario experimentador tem o total de 58 pontos. Esses pontos ser˜ao utilizados no momento de alocac¸˜ao de recursos, sendo que um usu´ario se encontra no n´ıvel de acesso conforme a Tabela 2. Um usu´ario n´ıvel 02, seguindo o exemplo utilizado para a Tabela 1, tem ent˜ao direito de alocar at´e 15 m´aquinas virtuais, conforme a Tabela 3, por exemplo no ambiente do testbed OCF do FIBRE.
Tabela de Pontuac¸˜ao para Recursos para M´aquinas Virtuais
VMs N´ıvel
0 ≤ X ≤ 5 01
0 ≤ X ≤ 15 02 0 ≤ X ≤ 20 03
Tabela 3. Tabela de Pontuac¸˜ao para Recursos para M´aquinas Virtuais
4. Resultados
4.1. Agregac¸˜ao de Atributos para Organizac¸˜oes Virtuais
Em [Silva et al. 2013a], foi desenvolvida a parte referente `a autenticac¸˜ao destacada na Fi-gura 2, com a integrac¸˜ao da federac¸˜ao CAFe `a federac¸˜ao de experimentac¸˜ao. J´a neste tra-balho, s˜ao apresentados os resultados de um provedor de atributos com a utilizac¸˜ao de um agregador de atributos, permitindo que atributos espec´ıficos de uma organizac¸˜ao virtual possam ser armazenados separadamente dos atributos advindos da federac¸˜ao acadˆemica, considerando como caso de estudo a CAFe. Assim, n˜ao ´e necess´ario alterar o modelo de armazenamento de atributos da federac¸˜ao.
Modelos de agregac¸˜ao de atributos foram estudados com base no trabalho [Chadwick et al. 2010] e optou-se, pelo cen´ario aqui aplicado, onde a agregac¸˜ao de atri-butos ´e implementada com aux´ılio de um provedor de servic¸os (Service Provider - SP). Por´em, os atributos adicionais armazenados no provedor de atributos n˜ao devem identifi-car o usu´ario aos quais est˜ao associados. Sendo assim, foi criado um identificador ´unico e opaco, de forma a vincular o usu´ario da federac¸˜ao acadˆemica dentro do provedor de atributos da organizac¸˜ao virtual (OV). A ideia base para a utilizac¸˜ao de um identifica-dor ´unico e opaco surgiu dos estudos sobre a federac¸˜ao acadˆemica SWITCH8, que define
tamb´em este identificador baseado em outro atributo, tamb´em ´unico e fixo do usu´ario na federac¸˜ao9.
Conforme a Figura 2 da arquitetura proposta, este trabalho implementa os passos do 1 ao 9. Devemos esclarecer que o atributo ´unico e opaco utiliza a combinac¸˜ao de dois atributos comuns e um hash criptogr´afico, como ´e poss´ıvel ver pelas equac¸˜oes:
δ ← Attru(uid) ∪ Attru(uidN umber) (1)
AttrU(opaque) ← hash(δ) (2)
O resultado, por exemplo, para o uid = esilva@uff com uidNumber = 1223 ´e o valor da operac¸˜ao utilizando-se um hash md5 da concatenac¸˜ao dos dois atributos, resul-tando em af2ec12ce73cc910358ddb400f 4abb74. ´E interessante utilizar para este m´etodo sempre hash criptogr´aficos mais atuais, como SHA-1, SHA-2, SHA-256, etc, por exem-plo10.
Na Figura 3, vˆe-se o passo a passo de autenticac¸˜ao do usu´ario na federac¸˜ao CA-FeExpresso dispon´ıvel no GidLab. Onde primeiramente ´e mostrada a tela do servic¸o de homologac¸˜ao dos atributos, logo ap´os direcionado o usu´ario ao WAYF para a escolha de sua instituic¸˜ao (i.e. IdP1). Feito isso, o usu´ario insere suas credenciais (i.e. “esilva@uff”) e se autentica em sua instituic¸˜ao de origem.
(a) Tela inicial de homologac¸˜ao de atributos. (b) Escolha do IdP para autenticac¸˜ao pelo usu´ario.
Figura 3. Passos para a autenticac¸˜ao CAFe.
Ainda na Figura 4, vˆe-se os atributos advindos apenas somente daquele IdP, ou seja, os atributos originais daquele usu´ario em sua instituic¸˜ao. O que se vˆe mais `a frente ´e a resposta para a mesma tela de homologac¸˜ao de atributos por´em utilizando-se o agrega-dor de atributos e o proveagrega-dor de atributos para a OV do FIBRE. Na Figura 5, os atributos de homologac¸˜ao (validac¸˜ao do sucesso de autenticac¸˜ao do usu´ario na CAFe) e tamb´em os atributos Attr opaque, Shib-fibre-userEnable e Shib-fibre-omfAdmin aparecem em desta-que. Como anteriormente abordado, o Attr opaque foi aquele respons´avel pela pesquisa poss´ıvel dos demais dois atributos do usu´ario contidos no provedor de atributos, neste exemplo.
5. Considerac¸˜oes Finais e Trabalhos Futuros
Este trabalho apresentou uma arquitetura de controle de acesso baseado em pol´ıticas, as-sim como a utilizac¸˜ao de um provedor de atributos, para organizac¸˜oes virtuais acadˆemicas
9https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinitionExamples 10Na validac¸˜ao do modelo do provedor e agregador de atributos, foi utilizado um hash criptogr´afico
(a) Autenticac¸˜ao sendo realizada pelo usu´ario “esilva@uff”.
(b) Homologac¸˜ao dos atributos padr˜ao advindos do IdP original.
Figura 4. Passos para a autenticac¸˜ao CAFe e homologac¸˜ao dos atributos recebidos pelo SP.
Figura 5. Homologac¸˜ao com atributos agregados.
baseadas em federac¸˜oes de autenticac¸˜ao e autorizac¸˜ao. Como resultados s˜ao apresenta-dos, dentro da arquitetura proposta e do estudo de caso do projeto FIBRE, um agregador de atributos e o mecanismo de agregac¸˜ao de atributos por meio de um identificador ´unico e opaco. Apesar de usar o FIBRE como estudo de caso, a proposta ´e gen´erica e pode ser aplicada em outros tipos de organizac¸˜ao virtual onde haja compartilhamento de recursos distribu´ıdos por usu´arios advindos de diferentes instituic¸˜oes.
Como pr´oximos passos, tem-se a criac¸˜ao de pol´ıticas XACML. Tais pol´ıticas ser˜ao aplicadas tanto utilizando RBAC quanto ABAC no modelo de validac¸˜ao do projeto. Como
exemplo, tem-se como entrada uma solicitac¸˜ao do usu´ario/experimentador da listagem de recursos. Esta solicitac¸˜ao se d´a a federac¸˜ao de recursos (implementada pelo SFA no FIBRE) por meio de um arquivo baseado em XML chamado RSpec, e assim, ser˜ao ava-liados os atributos e comparados a pol´ıticas XACML pr´e-estabelecidas, armazenadas no PAP. Nesse caso espec´ıfico, o usu´ario que envia suas credenciais e ´e o AM – Aggregate Manager11– do SFA. O SFA recebe as credenciais do usu´ario e gera um RSpec. O RSpec retornado para o usu´ario ser´a interceptado pelo controle de acesso baseado em pol´ıticas proposto nesse trabalho. Assim, o retorno ao usu´ario ser´a um RSpec resultante da filtra-gem (ou n˜ao) proporcionada pela pol´ıtica definida com o XACML.
6. Agradecimentos
Agradecemos o apoio da RNP atrav´es do PGID (Programa de Gest˜ao de Identidade), ao GidLab (Laborat´orio de Gest˜ao de Identidade) da RNP e `a CAPES.
Referˆencias
Chadwick, D., Inman, G., and Klingenstein, N. (2010). A conceptual model for attribute aggregation. Future Generation Computer Systems, 26(7):1043 – 1052.
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):224–274.
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):200–222. Hu, V. C., Ferraiolo, D., Kuhn, R., Friedman, A. R., Lang, A. J., Cogdell, M. M.,
Sch-nitzer, 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˜ao de credenci-ais para uso de testbeds para a internet do futuro. In SBSeg 2013 - WGID, Manaus. Silva, E., Muchaluat-Saade, D., Magalhaes, L., Fernandes, N. C., and Rodriguez, N.
(2013b). Gest˜ao de identidade em organizac˜oes virtuais. In JAI 2013.
Yavatkar, R., Pendarakis, D., and Guerin, R. (2000). A framework for policy-based ad-mission control.
