XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
Controle de Acesso Baseado em Polı́ticas e Atributos para
Federações de Recursos
Edelberto F. Silva1 , Débora Muchaluat-Saade1 e Natalia C. Fernandes1
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 CAFe1 (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
1
http://portal.rnp.br/web/servicos/cafe
470
c
2014
SBC — Soc. Bras. de Computação
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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
2
http://www.fibre-ict.eu/
471
c
2014
SBC — Soc. Bras. de Computação
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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].
2.0.1. 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.
2.0.2. 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 2014.
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.
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 à 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 resources3 .
3
Os resources são semelhantes aos objects, descritos no modelo anterior.
472
c
2014
SBC — Soc. Bras. de Computação
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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 delas4 .
2.1. 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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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 atributos5 .
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 federado6 . 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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
(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.
3.1. 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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
Tabela de Pontuação para Atributos
Atributo
Opção 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 Pontuação para Atributos
Tabela de Pontuação para Atributos
Pontuação
Nı́vel
0 < X ≤ 50
01
50 < X ≤ 100 02
100 < X ≤ 200 03
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 ≤ 5 01
0 ≤ X ≤ 15 02
0 ≤ X ≤ 20 03
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 SWITCH8 , que define
8
https://www.switch.ch/aai/support/tools/vo-concept/
476
c
2014
SBC — Soc. Bras. de Computação
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
também este identificador baseado em outro atributo, também único e fixo do usuário na
federação9 .
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:
δ ← Attru (uid) ∪ Attru (uidN umber)
(1)
AttrU (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 em af 2ec12ce73cc910358ddb400f 4abb74. É interessante utilizar para este método
sempre hash criptográficos mais atuais, como SHA-1, SHA-2, SHA-256, etc, por exemplo10 .
Na Figura 3, vê-se o passo a passo de autenticação do usuário na federação CAFeExpresso 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
9
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinitionExamples
Na validação do modelo do provedor e agregador de atributos, foi utilizado um hash criptográfico
MD-5
10
477
c
2014
SBC — Soc. Bras. de Computação
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
(a) Autenticação sendo realizada pelo usuário(b) Homologação dos atributos padrão advindos do
“esilva@uff”.
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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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
Manager11 – 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):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., 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 2013 - 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 2013.
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