Modelagem do ACROSS: Um Arcabouço de A&A Baseado em
Polı́ticas e Atributos para Organizações Virtuais
Edelberto F. Silva1 , Débora Muchaluat-Saade1 e Natalia C. Fernandes1
1
Universidade Federal Fluminense (UFF)
Laboratório Mı́diaCom
Niterói, RJ – Brasil
Resumo. Ao longo dos últimos anos acompanha-se um crescente interesse,
principalmente no âmbito acadêmico, das soluções para criação de ambientes federados. Tais federações visam desde facilitar o ingresso de usuários até o
compartilhamento de recursos entre as diversas entidades parceiras, formando
uma organização virtual. Neste trabalho, apresentamos a proposta e a modelagem do arcabouço ACROSS, Attribute-based access ContROl and diStributed
policieS, que tem como objetivo facilitar a gestão de identidade em uma nova
organização virtual. Propõe-se um arcabouço genérico que simplifique, principalmente para usuários não especializados, a autenticação federada e o controle de acesso a recursos para a organização virtual. O ACROSS dá suporte a
configuração de requisitos e polı́ticas particulares a cada instituição e também
genéricos à organização virtual, além de permitir que funcionalidades comuns
às organizações virtuais, e também às federações, envolvendo questões sobre
Autenticação e Autorização (A&A). Esses podem ser integradas facilmente a
uma nova organização virtual por meio de uso de um arcabouço de A&A.
Abstract. Over the past few years there is a growing interest for solutions to create federated environments, especially in the academic environment. The main
goal is to facilitate the entry of users in a collaborative environment and resource sharing among various partner entities, creating a virtual organization.
In this work, we present the proposal and modeling of the ACROSS framework,
Attribute-based access ContROl and diStributed policieS, which aims at facilitating the identity management in a new virtual organization. We propose a
generic framework to simplify, especially for non-specialized users, federated
authentication and resource access control for a virtual organization. ACROSS
supports particular configuration of requirements and policies for each institution and also generic to the virtual organization, and allows common functionality to virtual organizations and also to federations, involving issues about
Authentication and Authorization (A&A). They can be easily integrated into a
new virtual organization through use of an A&A framework.
1. Introdução
O termo gestão de identidade (GId) vem sendo usado para descrever os mecanismos e processos de Autenticação e Autorização (A&A) utilizados para garantir o uso
seguro de recursos arbitrários. A comunidade acadêmica apresenta requisitos especiais
de compartilhamento de recursos, dada a necessidade de colaboração e integração gerada
por projetos, intercâmbios, cursos remotos e outras atividades. Há alguns anos, a comunidade acadêmica vem utilizando identidades federadas, que permitem regular o acesso
a recursos disponı́veis para todos os membros de uma instituição ou para toda a comunidade, como, por exemplo, repositórios de periódicos, sem a necessidade de duplicação
de informações e de bases de dados. No entanto, há também recursos que devem ser
compartilhados apenas por determinados membros de diferentes instituições, como por
exemplo os participantes de um projeto interinstitucional. Esses grupos são muitas vezes
chamados de Organizações Virtuais (OV).
Um exemplo prático de uma OV é o projeto FIBRE (Future Internet Testbeds
Experimentation Between Brazil and Europe) [Sallent et al. 2012] para experimentação e
validação de soluções para a Internet do Futuro (IF), que conta com diversas instituições
no Brasil e em diversos outros paı́ses que, juntas, têm um interesse em comum. O objetivo principal do FIBRE é a interconexão de ambientes de experimentação geograficamente distribuı́das, chamados de testbeds, com a finalidade de oferecer suporte para
a experimentação em IF, criando assim um ambiente de testes de larga escala e grande
diversidade de equipamentos. Neste ambiente, um pesquisador pode realizar seu experimento alocando recursos de diferentes testbeds em diferentes instituições. Para tanto,
é necessário tratar o compartilhamento de recursos, de tal forma que um pesquisador
possa verificar quais são os recursos disponı́veis em todos os testbeds, assim como aplicar soluções de A&A para o uso desses recursos. Nesse caso, é preciso garantir que a
autenticação de um usuário de uma rede de testes sirva como identificação para o uso dos
recursos de qualquer outra rede de teste federada, desde que o usuário atenda às polı́ticas
locais de controle de acesso de cada um dos ambientes (instituições/ilhas) envolvidos e às
polı́ticas globais do projeto (que representa a OV neste cenário) como um todo.
Contudo, apesar da forte demanda por organizações virtuais, criar tais
organizações apresenta grande complexidade. De fato, além de questões práticas especı́ficas de cada OV, sobre como gerenciar recursos ou estabelecer cooperações, por
exemplo, o gerente de uma OV precisa também ter grande conhecimento na área de gestão
de identidade para estabelecer formas de autenticação e controle de acesso que atendam
a todos os requisitos da OV e também de cada instituição participante. Uma vez que,
em geral, os potenciais gerentes de OV possuem apenas conhecimento especı́fico sobre
o ambiente que desejam criar, acabam sendo desestimulados a criar a OV devido ao alto
grau de dificuldade para estabelecer uma gestão de identidade complexa.
Para simplificar a criação de OVs genéricas, este artigo propõe o arcabouço
ACROSS (Attribute-based access ContROl and diStributed policieS), que trata a
federação de identidade e o estabelecimento de polı́ticas de forma fortemente automatizada para o gerente da OV. O ACROSS é descrito por meio da modelagem geral da
arquitetura do arcabouço para controle de acesso baseado em polı́ticas e atributos para
OVs acadêmicas, e respeita o padrão de arcabouço genérico para controle de acesso,
o “X.812 — ISO/IEC 10181-3:1996” [ISO 1996], ou simplesmente ISO/IEC 10181-3.
Este modelo, que pode ser visto na Figura 1, mostra o iniciador, aquele que inicia o
contato/requisição de acesso, e deseja acessar um alvo em um domı́nio especı́fico de recursos. Na figura, é possı́vel ver a presença de dois componentes essenciais, o Access
Control Enforcement Functions (AEF), equivalente ao Policy Enforcement Point (PEP)
do ABAC (Attribute-Based Access Control) [Hu et al. 2014], e o Access Control Decision Functions (ADF), que equivale ao Policy Decision Point (PDP) no ABAC. A ideia
principal do arcabouço de autorização é que o AEF garanta que todos os pedidos de acesso
passem pelo ADF e o ADF decida sob a autorização com base em um conjunto de regras
ou polı́ticas. O arcabouço ACROSS também se baseia neste padrão.
Figura 1. Arcabouço de controle de acesso do padrão X.812 – ISO/IEC 10181-3. Traduzida de [ISO 1996].
O ACROSS trata tanto da autenticação dentro da OV quanto do controle de acesso,
através da especificação de polı́ticas locais e globais que regem a utilização de recursos. Na parte de autenticação, o ACROSS permite tanto o uso de federações de identidade quanto a criação da identidade dentro da OV através da agregação de atributos. O
arcabouço garante uma instalação e configuração de todos os serviços de forma simplificada para quem quer montar uma OV, criando uma abstração de detalhes de gestão de
identidade que não interessam diretamente ao responsável pela OV. Todos esses passos
serão detalhados na modelagem UML proposta para o arcabouço.
Sendo assim, o artigo está organizado como descrito a seguir. A Seção 2 apresenta
a proposta do arcabouço e a definição de cada um dos módulos envolvidos. A modelagem
é apresentada na Seção 3, e logo após temos a Seção 4, que compara o ACROSS com
outras propostas de gestão de identidade em OVs. O artigo é finalizado na Seção 5, que
apresenta as considerações finais e trabalhos futuros.
2. Proposta
Nesta seção, são apresentadas as motivações para esta proposta e a arquitetura
geral do ACROSS, com seus módulos, vista em um nı́vel mais alto de abstração.
2.1. Motivação
É interessante ressaltar os pontos a que levaram à proposta do ACROSS, traçando
um histórico de outros trabalhos que colaboraram tanto na autenticação quanto na
autorização para OVs. É o caso de [Silva et al. 2014], onde foi tratado o problema da
integração da federação de recursos do FIBRE com a federação de identidade CAFe (Comunidade Acadêmica Federada), sendo proposta uma solução de autorização para o controle de acesso aos recursos que pode ser aplicada a uma OV qualquer.
Em [Silva et al. 2015], é realizada a validação de um controle de acesso especificamente para o ambiente de IF. Como resultado deste trabalho, a integração de uma
federação de identididade (CAFe) baseada em Shibboleth 1 traz outra vantagem, que é a
de que a gerência de identidade, nesse modelo, disponibiliza atributos de cada usuário,
1
https://shibboleth.net/
o que permite o uso de esquemas de autorização baseados em atributos, como o ABAC.
Normalmente, em uma OV, é necessário manter atributos adicionais, além daqueles que
já são disponibilizados pela instituição de origem do usuário, que atua como provedor
de identidade. Em [Silva et al. 2015], é proposto um provedor de atributos, que pode ser
mantido pela OV, armazenando somente os atributos adicionais necessários somente no
contexto da própria OV. Com isso, não é necessário que o ambiente de recursos federado
mantenha grandes bases de dados com usuários e listas de controle de acesso por usuário,
já que os atributos necessários para a autenticação podem ser providos pela instituição de
origem do usuário e os necessários para autorização são complementados pelo provedor
de atributos. Porém, para a criação de uma OV o processo de entrada de cada instituição
é algo custoso, em geral. É necessário, além de um corpo técnico especializado para
implantação das tecnologias envolvidas, ter também conhecimento para a elaboração e
desenvolvimento de métodos de controle de acesso que auxiliem no papel desempenhado
por cada instituição. Nota-se que o esforço para a criação da OV e o ingresso de novas
instituições a essa organização pode determinar sua aceitação bem-sucedida ou não. É
exatamente este o principal ponto motivador desta proposta.
2.2. Arquitetura do ACROSS
Em um modelo de controle de acesso baseado em polı́ticas, uma camada de controle de acesso se integra à arquitetura de gestão de identidade. Porém, idealmente, esse
modelo deve ser genérico, de forma que seja possı́vel incorporá-lo aos mais diversos
cenários de OVs, como, por exemplo, testbeds de experimentação para IF e cenários
de grades computacionais, além de ambientes de computação em nuvem. Para tanto,
o arcabouço ACROSS é proposto. O ACROSS é um arcabouço genérico para OVs que
desejam utilizar recursos de uma federação de identidade baseada em SAML 2 , realizar o
controle de acesso baseado em atributos para seus usuários e recursos, além de se beneficiar de uma integração a essas funcionalidades de forma facilitada. A Figura 2 mostra os
módulos principais do arcabouço.
Figura 2. Arcabouço ACROSS e seus módulos.
O módulo de Federação de Identidade se comunica diretamente com a federação
de identidade SAML/Shibboleth. Outro componente importante deste módulo é o de
transposição de credenciais [Silva et al. 2014], que deverá atender aos requisitos e particularidades da OV. A transposição de credenciais está também ligada ao módulo Provedor
2
http://saml.xml.org/
de Atributos, uma vez que, para gerar credenciais especı́ficas ao ambiente da OV, podem
ser necessários atributos também especı́ficos.
O módulo de Provedor de Atributos é relativamente independente dos demais
módulos quanto à instalação e configuração. Este módulo deverá ser capaz de criar
uma árvore de diretórios LDAP (Lightweight Directory Access Protocol) 3 para armazenamento dos atributos adicionais particulares à OV. A OV deverá ter uma forma de se
comunicar com esse provedor de atributos adicionais e resgatar tais atributos, que serão
oferecidos através de uma interface de comunicação via webservices [Erl 2004], facilitando a comunicação entre o módulo e o provedor de serviços (Service Provider – SP) da
OV.
Já o módulo de Controle de Acesso se baseia no modelo ABAC e permite ao
administrador da OV e da instituição configurar as polı́ticas para o controle de acesso,
que serão tanto no nı́vel global quanto local à instituição. Conforme a proposta de
[Silva et al. 2015], o administrador da OV será capaz de estabelecer pesos relativos aos
atributos dos usuários daquela OV e esses pesos serão responsáveis por associar cada
usuário a um nı́vel, que por sua vez será usado para o controle de acesso considerando
polı́ticas globais e locais. Este submódulo, chamado de Controle de Nı́veis de Usuários,
implementa a proposta validada em [Silva et al. 2015]. Outros dois submódulos deverão
permitir que os administradores, global e locais, gerenciem suas polı́ticas de forma simplificada, através de uma interface de gerência. Sabe-se que para cada ambiente de recursos distribuı́dos, há uma forma de buscar e alocar esses recursos (geralmente com arquivos baseados em XML), que apresentam, porém, suas particularidades. Dessa forma,
o módulo de controle de acesso deverá facilitar o desenvolvimento de wrappers para sua
comunicação com a federação de recursos em questão.
3. Modelagem
O ACROSS foi modelado de acordo com o padrão UML (Unified Modeling
Language) 4 . A seguir, alguns dos diagramas mais relevantes são apresentados como
ilustração do desenvolvimento deste arcabouço.
Com a finalidade de mostrar o funcionamento e relação entre as entidades do
arcabouço e as federações de identidade e recursos, é apresentado o diagrama de atividade do ACROSS pelo usuário da OV, exposto pela Figura 3. Nele, observa-se desde
os passos da autenticação do usuário na OV até a alocação de recursos. Naturalmente, o
ACROSS é utilizado, inicialmente, para a instalação de configuração de todos os módulos.
O diagrama apresentado mostra a autenticação de um usuário e a solicitação de alocação
de recursos especı́ficos em uma OV que é baseada no ACROSS.
Os passos no diagrama são, primeiramente, a autenticação do usuário, onde o
usuário solicita acesso e é encaminhado por meio do Módulo de Federação de Identidade,
ao seu provedor de identidade da federação de identidade. O usuário, então, é requisitado
pelo seu IdP (Identity Provider – Provedor de Identidade) a enviar suas credenciais. Uma
vez feito isso, essas credenciais serão validadas e seus atributos retornados ao Módulo de
Federação de Identidade, que fica responsável por enviar ao Módulo Provedor de Atributos a requisição dos atributos adicionais do usuário (especı́ficos da OV), então o Módulo
Provedor de Atributos resgatará esses atributos adicionais e os agregará, enviando-os ao
3
4
https://tools.ietf.org/rfc/rfc4516.txt
http://www.uml.org/
Figura 3. Diagrama de atividade do usuário da OV para utilização do ACROSS.
Módulo Federação de Identidade. Por sua vez, o Módulo de Federação de Identidade
armazenará todos os atributos e permitirá o acesso do usuário. O passo seguinte é referente à requisição da listagem de recursos disponı́veis na federação de recursos. Uma vez
recuperadas essas informações, a federação de recursos envia esta lista ao usuário, que a
receberá e selecionará aqueles que deseja reservar. Então, o Módulo Federação de Identidade fica responsável por enviar ao Módulo Controle de Acesso todos os atributos do
usuário junto com o pedido de recurso a ser alocado. O Módulo Controle de Acesso então
realiza a tarefa de classificar este usuário em um nı́vel especı́fico, conforme os pesos de
seus atributos [Silva et al. 2015], e verificará na polı́tica global se o pedido do usuário é
permitido, levando em consideração o nı́vel ao qual ele foi alocado. Caso o usuário atenda
a todos os requisitos, o pedido do usuário é enviado a cada ilha da federação de recursos
que faça parte do pedido de alocação de recursos do usuário, onde a ilha, por sua vez,
irá verificar a polı́tica local de alocação através do Módulo Controle de Acesso (local).
Caso o usuário também obtenha sucesso nesta verificação, os recursos são alocados e a
atividade é finalizada.
3.1. Módulo Federação de Identidade
O diagrama de sequência para a instalação do Módulo Federação de Identidade é
detalhado pela Figura 4, onde há três componentes: o “VO Installation”, responsável pela
instalação e configuração do módulo de federação de identidade do arcabouço ACROSS;
o “Shibboleth Client”, que deverá ser configurado como Provedor de Serviço (SP –
Service Provider); e o componente “Identity Federation”, que representa a federação
CAFe/Shibboleth. Neste diagrama, apresentam-se as atividades de instalação dos serviços
básicos necessários a este módulo e também de configuração, realizando desde o suporte
a atributos necessários para a OV quanto gerando o metadado necessário para entrada
deste serviço na federação de identidade.
Figura 4. Diagrama de sequência para instalação e configuração do módulo.
Para este diagrama é necessário, a princı́pio, ter o metadado da federação de identidade, e seguindo o diagrama tem-se: o inı́cio da instalação pelo administrador da OV,
através do “Start VO Install”, passando pela instalação dos pacotes necessários para os
serviços de servidor web e cliente Shibboleth, onde, para tanto o administrador deverá
preencher algumas informações; em seguida é solicitado ao administrador o metadado da
federação, que será configurado no cliente shibboleth do módulo e então gerado o metadado da OV, enviado ao administrador; por sua vez, o administrador deve entrar em
contato com a federação de identidade para inserir o metadado de sua OV, a fim de iniciar efetivamente sua participação naquela federação; logo após realizados tais passos o
administrador deverá selecionar quais atributos, da lista de possı́veis atributos, ele necessita suportar, e então é feita a sua configuração e confirmada ao administrador; por fim, o
administrador utiliza o módulo para realizar sua autenticação na federação de identidade,
com o objetivo de validar a configuração realizada, e então finaliza a configuração.
O passo citado no diagrama da Figura 4 como “User Authentication Test”, será
visto com mais detalhes na Figura 5, assim como a agregação de atributos realizada para
um usuário que se autentica na OV utilizando o ACROSS.
3.1.1. Módulo Provedor de Atributos
O Módulo Provedor de Atributos provê um diretório adicional para armazenamento dos atributos especı́ficos da OV. Este diretório é uma base LDAP. Há ainda o agregador de atributos, responsável pela união dos atributos vindos da federação de identidade
com os atributos adicionais do provedor de atributos da OV. 5
É interessante documentar que, durante a configuração do agregador de
atributos e a criação das entradas de cada usuário no provedor de atributos adicionais, um atributo opaco é utilizado como identificador do usuário.
A entrada no provedor de atributos terá uma forma similar ao exemplo:
uid=%$OPAQUE ID%,dc=%$ORGANIZATION%,dc=across
O identificador opaco se baseia no trabalho [Silva et al. 2015] e serve como uma
forma de fortalecer a privacidade do usuário da OV, dificultando sua associação aos valores de atributos adicionais. Como forma de geração do atributo opaco utilizando o atributo
mail6 e um número aleatório escolhido para ACROSS, temos:
δ ← Attru (mail) ∪ $salt
(1)
AttrU (opaque) ← hash(δ)
(2)
A Figura 5 é um diagrama UML voltado para a utilização, que trata do momento
da autenticação do usuário, onde os atributos adicionais da OV são recuperados do provedor de atributos (a partir do atributo opaco), agregados e disponibilizados ao serviço
associado da OV através do módulo A&A do usuário (“User A&A”).
Figura 5. Diagrama de sequência do acesso do usuário com agregação de atributos.
5
Por conta da limitação de espaço deste trabalho os diagramas de instalação e configuração para o
Agregador de Atributos e o Provedor de Atributos foram suprimidos.
6
Attr u(mail) é dependente do schema inetOrgPerson.
3.1.2. Módulo de Controle de Acesso
O Módulo Controle de Acesso é configurado pelo administrador da OV em quatro
diferentes gerenciadores, referentes à pontuação (score), nı́vel (level), o recurso (resource)
e a polı́tica (polı́tica)7 . Sucintamente, a configuração da pontuação para cada um dos atributos existente na OV, inclusive consultando aqueles do provedor de atributos adicionais,
é a primeira a ser realizada. Logo após, o intervalod de pontuação para cada nı́vel deve
ser configurado, informando sempre o menor valor para um dado nı́vel, e começando do
nı́vel mais alto (a fim de garantir que intervalos não irão se sobrepor). Destaca-se que,
para a classificação do usuário em certo nı́vel, é levada em consideração a sua pontuação
e essa pontuação é normalizada, seguindo a proposta validade em [Silva et al. 2015]. Já
para a configuração do recurso, o administrador informa o tipo e uma breve descrição
daquele recurso.
Figura 6. Configuração de polı́ticas de acesso.
Todos os registros são armazenados em arquivos XML e poderão ser consultados
posteriormente por outras entidades do ACROSS. A Figura 6 ilustra a configuração da
polı́tica em si, e, portanto, levará em conta tanto o nı́vel quanto aos tipos de recursos que
poderão ser autorizados àquele nı́vel. Esta configuração deverá ser feita para cada uma
das polı́ticas criadas.
A configuração das polı́ticas será realizada tanto em nı́vel global da OV como em
nı́vel local, e os demais módulos e configurações serão executados apenas no nı́vel global
pelo administrador da OV.
7
Os diagramas para a configuração da pontuação, nı́vel e recurso foram suprimidos por conta da
limitação de espaço.
4. Trabalhos Relacionados
Nesta seção são comparados os trabalhos relacionados ao ACROSS, ainda que
estes tratem apenas da autenticação ou apenas do controle de acesso.
4.1. VOMS - Virtual Organization Membership Service
O VOMS [Alfieri 2003] é um arcabouço para autenticação e controle de acesso
desenvolvido, inicialmente, para o contexto de grade computacional. Essa proposta tem
sua autorização baseada em papéis e polı́ticas, o que pode-se comparar ao ACROSS na
utilização de uma polı́tica global e local. No VOMS, a polı́tica global se refere à polı́tica
da OV, que é uma polı́tica geral de autorização, que avalia se o usuário tem credenciais
válidas ou pertence a um certo grupo, e a polı́tica local é realizada pelo RP (Resource Provider) – responsável por oferecer o recurso em si. Para utilizar o VOMS, o usuário deve
reapresentar suas credenciais ao RP (local) junto com uma autorização pré-concedida
pela OV (global). A ideia é que o usuário, mesmo sendo autorizado pela OV, possa ter
seu acesso restringido localmente.
Basicamente, o VOMS é baseado em papéis, que por sua vez são expressos por
grupos e subgrupos. Pensando na hierarquia de controle de acesso baseado em papéis do
VOMS, a ideia é que haja uma raiz e abaixo dela os vértices sejam grupos e subgrupos,
que existam como arestas orientadas, herdando regras dos nı́veis superiores, como em
um grafo acı́clico. No VOMS, o usuário é representado por papéis (roles) e recursos
(capabilities), onde um papel está intimamente relacionado ao usuário naquele grupo, ou
seja, o papel que ele possui dentro daquele grupo. Esse papel é utilizado para a tomada
de decisão.
No ACROSS, as polı́ticas global e local funcionam de forma diferente. Como
para o ACROSS o ambiente da OV é pensado como uma federação de recursos, a polı́tica
global valida e classifica o usuário conforme seus atributos, atribuindo a ele um nı́vel
especı́fico de acordo com a configuração do administrador global da OV. Já no nı́vel local,
de cada ilha, apenas o nı́vel de acesso do usuário é fornecido, uma forma mais geral para
tratar a requisição do usuário ao recurso. O ACROSS também mantém a privacidade dos
atributos do usuário no nı́vel local das ilhas, uma vez que apenas um atributo genérico,
o nı́vel, é enviado para a tomada de decisão na polı́tica local, mantendo os valores de
atributos, cálculos e tomadas de decisão centralizados à federação no nı́vel global.
O ACROSS trabalha de forma dinâmica, classificando usuários em nı́veis criados
pelo administrador global da OV. Diferentemente do VOMS, o ACROSS permite que sejam criados, a partir de atributos especı́ficos suportados pela OV, classificações dinâmicas
de alocação de recursos. A alocação de recursos, assim como realizada pelo VOMS, é
feita no nı́vel local.
Outra diferença entre VOMS e ACROSS é que o VOMS propõe um serviço de
gerência para várias OVs distintas no mesmo serviço, a partir da geração de credenciais
X.509 do tipo proxy (formato herdado de sua motivação de ser um arcabouço para a
gerência de acesso à grade computacional). O ACROSS deve ser usado individualmente
por cada OV que deseja facilitar a gestão de identidade de seus usuários, considerando as
funcionalidades de autenticação e autorização, integradas a uma federação de identidade
baseada em Shibboleth.
4.2. CAS - Community Authorization Service
O CAS (Community Authorization Service) [Pearlman et al. 2002] tem como ideia
principal que um certo nı́vel de controle de acesso a recursos, ou parte das polı́ticas locais,
sejam delegados ao administrador da OV, a fim de permitir que este administrador aplique
polı́ticas gerais da OV no ambiente distribuı́do. Essa gerência de controle de acesso é
realizada pelo administrador da OV através do servidor CAS, que funciona de forma
intermediária entre o requisitante do acesso e o recurso em si. Seu modelo de autorização
é baseado em papéis (RBAC - Role-Based Access Control), associando a qual papel é
permitido que tipo de acesso a qual o recurso.
É possı́vel traçar um paralelo entre polı́tica global e local no CAS, onde o controle
de acesso de nı́vel global existe quando o usuário apresenta suas credenciais e é verificado
junto à base de polı́ticas global da OV, associando a ele uma certa permissão conforme
seu papel na OV. Já a polı́tica local pode ser vista no acesso, quando a instituição dona
do recurso aplica uma polı́tica restritiva conforme o papel do usuário. Comparado ao
ACROSS, o CAS possui polı́ticas globais e locais claramente mais simples e limitadas,
uma vez que se baseia em uma implementação simples do RBAC. Porém, o CAS visa
se integrar ao middleware para grades computacionais, Globus Toolkit [Foster 2005] e
utilizar seus serviços para acesso aos recursos, permitindo gerar credenciais no formato
de certificados X.509 proxy e a delegação de credenciais. Também é interessante citar a
diferença básica entre o CAS e o VOMS, onde no VOMS o usuário pertence a um grupo
que por sua vez é mapeado em um direito somente no domı́nio do recurso (na instituição,
por exemplo). Já o CAS envia os direitos baseados nos papéis diretamente através do
acesso à OV.
4.3. PERMIS - PrivilEge and Role Management Infrastructure Standard
O PERMIS (PrivilEge and Role Management Infrastructure Standard)
[Chadwick et al. 2003] é o que se chama de PMI (Privilege Management Infrastructure),
baseada em X.509. Análoga a uma ICP (Infraestrutura de Chave Pública) [ITU-T 2012],
o PMI apresenta uma AA (Attribute Authority), responsável por emitir certificados de atributos X.509 (Attribute Certificates – ACs) [Farrell and Housley 2002] para os usuários, e
uma AC (Autoridade Certificadora) é responsável por armazenar a ligação entre a credencial do usuário, seu DN (Distinguished Name) e os atributos de privilégios do usuário. A
raiz de confiança do PMI é chamada de SOA (Source of Authority).
Diferentemente do CAS, o PERMIS, assim como o ACROSS, utiliza o ABAC a
partir dos certificados de atributos do usuário. Em geral, as principais diferenças entre
o PERMIS e o ACROSS estão na facilidade de instalação e integração oferecida pelo
ACROSS à OV. Sabemos que o PERMIS é um arcabouço maduro, difundido e bem estruturado no padrão X.509, assim como o VOMS. Porém, o PERMIS e também o VOMS
acabam por se tornar um tanto quanto engessados na estrutura de grade computacional
principalmente pelo tipo de credencial suportado, além de ambos terem como herança o
foco na integração do Globus Toolkit, o que pode dificultar a adoção deste arcabouço ou
exigir um grande esforço de desenvolvimento.
5. Considerações Finais e Trabalhos Futuros
O presente trabalho apresentou tanto a motivação e embasamento teórico por meio
da comparação com trabalhos relacionados de outros arcabouços de controle de acesso
para OV, quanto a arquitetura e alguns diagramas de exemplo utilizados para o desenvolvimento do ACROSS. É interessante deixar claro que os assistentes de instalação e
configuração de cada um dos módulos que estão sendo desenvolvidos, facilitarão a criação
de novas OVs e irão agilizar o ingresso de novas instituições tanto na CAFe como na
adesão à utilização de conceitos de controle de acesso.
O arcabouço atualmente encontra-se em desenvolvimento, e o próximo passo será
sua validação por meio de testes e nos ambientes de experimentação em IF do projeto
FIBRE e de nuvem, utilizando OpenStack. Almeja-se ainda a validação da instalação,
configuração e utilização do arcabouço ACROSS por uma OV diferente das pensadas
inicialmente, com a finalidade de validar quão genérica esta solução realmente se tornou.
Referências
Alfieri, R. e. a. (2003). Managing dynamic user communities in a grid of autonomous
resources. CoRR, cs.DC/0306004.
Chadwick, D., Otenko, A., and Ball, E. (2003). Role-based access control with x.509
attribute certificates. Internet Computing, IEEE, 7(2):62–69.
Erl, T. (2004). Service-Oriented Architecture: A Field Guide to Integrating XML and Web
Services. Prentice Hall PTR, Upper Saddle River, NJ, USA.
Farrell, S. and Housley, R. (2002). An Internet Attribute Certificate Profile for Authorization. RFC 3281 (Proposed Standard).
Foster, I. (2005). Globus toolkit version 4: Software for service-oriented systems. In
Proceedings of the 2005 IFIP International Conference on Network and Parallel Computing, NPC’05, pages 2–13, Berlin, Heidelberg. Springer-Verlag.
Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., and Scarfone,
K. (2014). Guide to attribute based access control (abac) definition and considerations.
NIST Special Publication, 800:162.
ISO (1996). ISO/IEC 10181-3:1996 - information technology – open systems interconnection – security frameworks for open systems: Access control framework.
ITU-T (2012). The directory: Public-key and attribute certificate frameworks. Technical
Report X.509, ITU-T SG17, Geneva, Switzerland.
Pearlman, L., Welch, V., Foster, I., Kesselman, C., and Tuecke, S. (2002). A community
authorization service for group collaboration. In Policies for Distributed Systems and
Networks, 2002. Proceedings. Third International Workshop on, pages 50–59.
Sallent, S., Abelem, A., Machado, I., Bergesio, L., Fdida, S., Rezende, J., Simeonidou, D.,
Salvador, M., Ciuffo, L., Tassiulas, L., and Bermudo, C. (2012). FIBRE project: Brazil
and Europe unite forces and testbeds for the Internet of the future. In Proceedings of
TridentCom 2012.
Silva, E., Fernandes, N. C., and Muchaluat-Saade, D. (2015). ACROSS-FI: AttributeBased Access Control with Distributed Policies for Future Internet Testbeds. In 14th
International Conference on Networking, pages 198–204, Barcelona/Spain.
Silva, E., Fernandes, N. C., Rodriguez, N., and Muchaluat-Saade, D. (2014). Credential
Translations In Future Internet Testbeds Federation. In NOMS/ManFI 2014, Krakow,
Poland.