Modelagem do ACROSS: Um Arcabouc¸o de A&A Baseado em
Pol´ıticas e Atributos para Organizac¸˜oes Virtuais
Edelberto F. Silva1, D´ebora Muchaluat-Saade1 e Natalia C. Fernandes1
1Universidade Federal Fluminense (UFF)
Laborat´orio M´ıdiaCom Niter´oi, RJ – Brasil
Resumo. Ao longo dos ´ultimos anos acompanha-se um crescente interesse, principalmente no ˆambito acadˆemico, das soluc¸˜oes para criac¸˜ao de ambien-tes federados. Tais federac¸˜oes visam desde facilitar o ingresso de usu´arios at´e o compartilhamento de recursos entre as diversas entidades parceiras, formando uma organizac¸˜ao virtual. Neste trabalho, apresentamos a proposta e a mode-lagem do arcabouc¸o ACROSS,Attribute-based access ContROl and diStributed policieS, que tem como objetivo facilitar a gest˜ao de identidade em uma nova organizac¸˜ao virtual. Prop˜oe-se um arcabouc¸o gen´erico que simplifique, prin-cipalmente para usu´arios n˜ao especializados, a autenticac¸˜ao federada e o con-trole de acesso a recursos para a organizac¸˜ao virtual. O ACROSS d´a suporte a configurac¸˜ao de requisitos e pol´ıticas particulares a cada instituic¸˜ao e tamb´em gen´ericos `a organizac¸˜ao virtual, al´em de permitir que funcionalidades comuns `as organizac¸˜oes virtuais, e tamb´em `as federac¸˜oes, envolvendo quest˜oes sobre Autenticac¸˜ao e Autorizac¸˜ao (A&A). Esses podem ser integradas facilmente a uma nova organizac¸˜ao 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 cre-ate federcre-ated environments, especially in the academic environment. The main goal is to facilitate the entry of users in a collaborative environment and re-source 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 faci-litating 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 institu-tion and also generic to the virtual organizainstitu-tion, and allows common functio-nality 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¸˜ao
O termo gest˜ao de identidade (GId) vem sendo usado para descrever os meca-nismos e processos de Autenticac¸˜ao e Autorizac¸˜ao (A&A) utilizados para garantir o uso seguro de recursos arbitr´arios. A comunidade acadˆemica apresenta requisitos especiais de compartilhamento de recursos, dada a necessidade de colaborac¸˜ao e integrac¸˜ao gerada por projetos, intercˆambios, cursos remotos e outras atividades. H´a alguns anos, a comu-nidade acadˆemica vem utilizando identidades federadas, que permitem regular o acesso
a recursos dispon´ıveis para todos os membros de uma instituic¸˜ao ou para toda a comu-nidade, como, por exemplo, reposit´orios de peri´odicos, sem a necessidade de duplicac¸˜ao de informac¸˜oes e de bases de dados. No entanto, h´a tamb´em recursos que devem ser compartilhados apenas por determinados membros de diferentes instituic¸˜oes, como por exemplo os participantes de um projeto interinstitucional. Esses grupos s˜ao muitas vezes chamados de Organizac¸˜oes Virtuais (OV).
Um exemplo pr´atico de uma OV ´e o projeto FIBRE (Future Internet Testbeds Experimentation Between Brazil and Europe) [Sallent et al. 2012] para experimentac¸˜ao e validac¸˜ao de soluc¸˜oes para a Internet do Futuro (IF), que conta com diversas instituic¸˜oes no Brasil e em diversos outros pa´ıses que, juntas, tˆem um interesse em comum. O ob-jetivo principal do FIBRE ´e a interconex˜ao de ambientes de experimentac¸˜ao geografi-camente distribu´ıdas, chamados de testbeds, com a finalidade de oferecer suporte para a experimentac¸˜ao em IF, criando assim um ambiente de testes de larga escala e grande diversidade de equipamentos. Neste ambiente, um pesquisador pode realizar seu expe-rimento alocando recursos de diferentes testbeds em diferentes instituic¸˜oes. Para tanto, ´e necess´ario tratar o compartilhamento de recursos, de tal forma que um pesquisador possa verificar quais s˜ao os recursos dispon´ıveis em todos os testbeds, assim como apli-car soluc¸˜oes de A&A para o uso desses recursos. Nesse caso, ´e preciso garantir que a autenticac¸˜ao de um usu´ario de uma rede de testes sirva como identificac¸˜ao para o uso dos recursos de qualquer outra rede de teste federada, desde que o usu´ario atenda `as pol´ıticas locais de controle de acesso de cada um dos ambientes (instituic¸˜oes/ilhas) envolvidos e `as pol´ıticas globais do projeto (que representa a OV neste cen´ario) como um todo.
Contudo, apesar da forte demanda por organizac¸˜oes virtuais, criar tais organizac¸˜oes apresenta grande complexidade. De fato, al´em de quest˜oes pr´aticas es-pec´ıficas de cada OV, sobre como gerenciar recursos ou estabelecer cooperac¸˜oes, por exemplo, o gerente de uma OV precisa tamb´em ter grande conhecimento na ´area de gest˜ao de identidade para estabelecer formas de autenticac¸˜ao e controle de acesso que atendam a todos os requisitos da OV e tamb´em de cada instituic¸˜ao 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 gest˜ao de identidade complexa.
Para simplificar a criac¸˜ao de OVs gen´ericas, este artigo prop˜oe o arcabouc¸o ACROSS (Attribute-based access ContROl and diStributed policieS), que trata a federac¸˜ao de identidade e o estabelecimento de pol´ıticas de forma fortemente automa-tizada 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 acadˆemicas, e respeita o padr˜ao de arcabouc¸o gen´erico 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¸˜ao de acesso, e deseja acessar um alvo em um dom´ınio espec´ıfico de re-cursos. 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 Deci-sion Functions(ADF), que equivale ao Policy Decision Point (PDP) no ABAC. A ideia principal do arcabouc¸o de autorizac¸˜ao ´e que o AEF garanta que todos os pedidos de acesso passem pelo ADF e o ADF decida sob a autorizac¸˜ao com base em um conjunto de regras
ou pol´ıticas. O arcabouc¸o ACROSS tamb´em se baseia neste padr˜ao.
Figura 1. Arcabouc¸o de controle de acesso do padr˜ao X.812 – ISO/IEC 10181-3. Tradu-zida de [ISO 1996].
O ACROSS trata tanto da autenticac¸˜ao dentro da OV quanto do controle de acesso, atrav´es da especificac¸˜ao de pol´ıticas locais e globais que regem a utilizac¸˜ao de recur-sos. Na parte de autenticac¸˜ao, o ACROSS permite tanto o uso de federac¸˜oes de identi-dade quanto a criac¸˜ao da identiidenti-dade dentro da OV atrav´es da agregac¸˜ao de atributos. O arcabouc¸o garante uma instalac¸˜ao e configurac¸˜ao de todos os servic¸os de forma simpli-ficada para quem quer montar uma OV, criando uma abstrac¸˜ao de detalhes de gest˜ao de identidade que n˜ao interessam diretamente ao respons´avel pela OV. Todos esses passos ser˜ao detalhados na modelagem UML proposta para o arcabouc¸o.
Sendo assim, o artigo est´a organizado como descrito a seguir. A Sec¸˜ao 2 apresenta a proposta do arcabouc¸o e a definic¸˜ao de cada um dos m´odulos envolvidos. A modelagem ´e apresentada na Sec¸˜ao 3, e logo ap´os temos a Sec¸˜ao 4, que compara o ACROSS com outras propostas de gest˜ao de identidade em OVs. O artigo ´e finalizado na Sec¸˜ao 5, que apresenta as considerac¸˜oes finais e trabalhos futuros.
2. Proposta
Nesta sec¸˜ao, s˜ao apresentadas as motivac¸˜oes para esta proposta e a arquitetura geral do ACROSS, com seus m´odulos, vista em um n´ıvel mais alto de abstrac¸˜ao.
2.1. Motivac¸˜ao ´
E interessante ressaltar os pontos a que levaram `a proposta do ACROSS, trac¸ando um hist´orico de outros trabalhos que colaboraram tanto na autenticac¸˜ao quanto na autorizac¸˜ao para OVs. ´E o caso de [Silva et al. 2014], onde foi tratado o problema da integrac¸˜ao da federac¸˜ao de recursos do FIBRE com a federac¸˜ao de identidade CAFe (Co-munidade Acadˆemica Federada), sendo proposta uma soluc¸˜ao de autorizac¸˜ao para o con-trole de acesso aos recursos que pode ser aplicada a uma OV qualquer.
Em [Silva et al. 2015], ´e realizada a validac¸˜ao de um controle de acesso especi-ficamente para o ambiente de IF. Como resultado deste trabalho, a integrac¸˜ao de uma federac¸˜ao de identididade (CAFe) baseada em Shibboleth1 traz outra vantagem, que ´e a de que a gerˆencia de identidade, nesse modelo, disponibiliza atributos de cada usu´ario,
o que permite o uso de esquemas de autorizac¸˜ao baseados em atributos, como o ABAC. Normalmente, em uma OV, ´e necess´ario manter atributos adicionais, al´em daqueles que j´a s˜ao disponibilizados pela instituic¸˜ao de origem do usu´ario, 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 necess´arios somente no contexto da pr´opria OV. Com isso, n˜ao ´e necess´ario que o ambiente de recursos federado mantenha grandes bases de dados com usu´arios e listas de controle de acesso por usu´ario, j´a que os atributos necess´arios para a autenticac¸˜ao podem ser providos pela instituic¸˜ao de origem do usu´ario e os necess´arios para autorizac¸˜ao s˜ao complementados pelo provedor de atributos. Por´em, para a criac¸˜ao de uma OV o processo de entrada de cada instituic¸˜ao ´e algo custoso, em geral. ´E necess´ario, al´em de um corpo t´ecnico especializado para implantac¸˜ao das tecnologias envolvidas, ter tamb´em conhecimento para a elaborac¸˜ao e desenvolvimento de m´etodos de controle de acesso que auxiliem no papel desempenhado por cada instituic¸˜ao. Nota-se que o esforc¸o para a criac¸˜ao da OV e o ingresso de novas instituic¸˜oes a essa organizac¸˜ao pode determinar sua aceitac¸˜ao bem-sucedida ou n˜ao. ´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 con-trole de acesso se integra `a arquitetura de gest˜ao de identidade. Por´em, idealmente, esse modelo deve ser gen´erico, de forma que seja poss´ıvel incorpor´a-lo aos mais diversos cen´arios de OVs, como, por exemplo, testbeds de experimentac¸˜ao para IF e cen´arios de grades computacionais, al´em de ambientes de computac¸˜ao em nuvem. Para tanto, o arcabouc¸o ACROSS ´e proposto. O ACROSS ´e um arcabouc¸o gen´erico para OVs que desejam utilizar recursos de uma federac¸˜ao de identidade baseada em SAML2, realizar o controle de acesso baseado em atributos para seus usu´arios e recursos, al´em de se benefi-ciar de uma integrac¸˜ao a essas funcionalidades de forma facilitada. A Figura 2 mostra os m´odulos principais do arcabouc¸o.
Figura 2. Arcabouc¸o ACROSS e seus m´odulos.
O m´odulo de Federac¸˜ao de Identidade se comunica diretamente com a federac¸˜ao de identidade SAML/Shibboleth. Outro componente importante deste m´odulo ´e o de transposic¸˜ao de credenciais [Silva et al. 2014], que dever´a atender aos requisitos e parti-cularidades da OV. A transposic¸˜ao de credenciais est´a tamb´em ligada ao m´odulo Provedor
de Atributos, uma vez que, para gerar credenciais espec´ıficas ao ambiente da OV, podem ser necess´arios atributos tamb´em espec´ıficos.
O m´odulo de Provedor de Atributos ´e relativamente independente dos demais m´odulos quanto `a instalac¸˜ao e configurac¸˜ao. Este m´odulo dever´a ser capaz de criar uma ´arvore de diret´orios LDAP (Lightweight Directory Access Protocol) 3 para arma-zenamento dos atributos adicionais particulares `a OV. A OV dever´a ter uma forma de se comunicar com esse provedor de atributos adicionais e resgatar tais atributos, que ser˜ao oferecidos atrav´es de uma interface de comunicac¸˜ao via webservices [Erl 2004], facili-tando a comunicac¸˜ao entre o m´odulo e o provedor de servic¸os (Service Provider – SP) da OV.
J´a o m´odulo de Controle de Acesso se baseia no modelo ABAC e permite ao administrador da OV e da instituic¸˜ao configurar as pol´ıticas para o controle de acesso, que ser˜ao tanto no n´ıvel global quanto local `a instituic¸˜ao. Conforme a proposta de [Silva et al. 2015], o administrador da OV ser´a capaz de estabelecer pesos relativos aos atributos dos usu´arios daquela OV e esses pesos ser˜ao respons´aveis por associar cada usu´ario a um n´ıvel, que por sua vez ser´a usado para o controle de acesso considerando pol´ıticas globais e locais. Este subm´odulo, chamado de Controle de N´ıveis de Usu´arios, implementa a proposta validada em [Silva et al. 2015]. Outros dois subm´odulos dever˜ao permitir que os administradores, global e locais, gerenciem suas pol´ıticas de forma sim-plificada, atrav´es de uma interface de gerˆencia. Sabe-se que para cada ambiente de re-cursos distribu´ıdos, h´a uma forma de buscar e alocar esses rere-cursos (geralmente com ar-quivos baseados em XML), que apresentam, por´em, suas particularidades. Dessa forma, o m´odulo de controle de acesso dever´a facilitar o desenvolvimento de wrappers para sua comunicac¸˜ao com a federac¸˜ao de recursos em quest˜ao.
3. Modelagem
O ACROSS foi modelado de acordo com o padr˜ao UML (Unified Modeling Language) 4. A seguir, alguns dos diagramas mais relevantes s˜ao apresentados como ilustrac¸˜ao do desenvolvimento deste arcabouc¸o.
Com a finalidade de mostrar o funcionamento e relac¸˜ao entre as entidades do arcabouc¸o e as federac¸˜oes de identidade e recursos, ´e apresentado o diagrama de ativi-dade do ACROSS pelo usu´ario da OV, exposto pela Figura 3. Nele, observa-se desde os passos da autenticac¸˜ao do usu´ario na OV at´e a alocac¸˜ao de recursos. Naturalmente, o ACROSS ´e utilizado, inicialmente, para a instalac¸˜ao de configurac¸˜ao de todos os m´odulos. O diagrama apresentado mostra a autenticac¸˜ao de um usu´ario e a solicitac¸˜ao de alocac¸˜ao de recursos espec´ıficos em uma OV que ´e baseada no ACROSS.
Os passos no diagrama s˜ao, primeiramente, a autenticac¸˜ao do usu´ario, onde o usu´ario solicita acesso e ´e encaminhado por meio do M´odulo de Federac¸˜ao de Identidade, ao seu provedor de identidade da federac¸˜ao de identidade. O usu´ario, ent˜ao, ´e requisitado pelo seu IdP (Identity Provider – Provedor de Identidade) a enviar suas credenciais. Uma vez feito isso, essas credenciais ser˜ao validadas e seus atributos retornados ao M´odulo de Federac¸˜ao de Identidade, que fica respons´avel por enviar ao M´odulo Provedor de Atribu-tos a requisic¸˜ao dos atribuAtribu-tos adicionais do usu´ario (espec´ıficos da OV), ent˜ao o M´odulo Provedor de Atributos resgatar´a esses atributos adicionais e os agregar´a, enviando-os ao
3https://tools.ietf.org/rfc/rfc4516.txt 4http://www.uml.org/
Figura 3. Diagrama de atividade do usu´ario da OV para utilizac¸˜ao do ACROSS. M´odulo Federac¸˜ao de Identidade. Por sua vez, o M´odulo de Federac¸˜ao de Identidade armazenar´a todos os atributos e permitir´a o acesso do usu´ario. O passo seguinte ´e refe-rente `a requisic¸˜ao da listagem de recursos dispon´ıveis na federac¸˜ao de recursos. Uma vez recuperadas essas informac¸˜oes, a federac¸˜ao de recursos envia esta lista ao usu´ario, que a receber´a e selecionar´a aqueles que deseja reservar. Ent˜ao, o M´odulo Federac¸˜ao de Iden-tidade fica respons´avel por enviar ao M´odulo Controle de Acesso todos os atributos do usu´ario junto com o pedido de recurso a ser alocado. O M´odulo Controle de Acesso ent˜ao realiza a tarefa de classificar este usu´ario em um n´ıvel espec´ıfico, conforme os pesos de seus atributos [Silva et al. 2015], e verificar´a na pol´ıtica global se o pedido do usu´ario ´e permitido, levando em considerac¸˜ao o n´ıvel ao qual ele foi alocado. Caso o usu´ario atenda a todos os requisitos, o pedido do usu´ario ´e enviado a cada ilha da federac¸˜ao de recursos que fac¸a parte do pedido de alocac¸˜ao de recursos do usu´ario, onde a ilha, por sua vez, ir´a verificar a pol´ıtica local de alocac¸˜ao atrav´es do M´odulo Controle de Acesso (local). Caso o usu´ario tamb´em obtenha sucesso nesta verificac¸˜ao, os recursos s˜ao alocados e a atividade ´e finalizada.
3.1. M´odulo Federac¸˜ao de Identidade
O diagrama de sequˆencia para a instalac¸˜ao do M´odulo Federac¸˜ao de Identidade ´e detalhado pela Figura 4, onde h´a trˆes componentes: o “VO Installation”, respons´avel pela instalac¸˜ao e configurac¸˜ao do m´odulo de federac¸˜ao de identidade do arcabouc¸o ACROSS; o “Shibboleth Client”, que dever´a ser configurado como Provedor de Servic¸o (SP – Service Provider); e o componente “Identity Federation”, que representa a federac¸˜ao CAFe/Shibboleth. Neste diagrama, apresentam-se as atividades de instalac¸˜ao dos servic¸os
b´asicos necess´arios a este m´odulo e tamb´em de configurac¸˜ao, realizando desde o suporte a atributos necess´arios para a OV quanto gerando o metadado necess´ario para entrada deste servic¸o na federac¸˜ao de identidade.
Figura 4. Diagrama de sequˆencia para instalac¸˜ao e configurac¸˜ao do m´odulo.
Para este diagrama ´e necess´ario, a princ´ıpio, ter o metadado da federac¸˜ao de iden-tidade, e seguindo o diagrama tem-se: o in´ıcio da instalac¸˜ao pelo administrador da OV, atrav´es do “Start VO Install”, passando pela instalac¸˜ao dos pacotes necess´arios para os servic¸os de servidor web e cliente Shibboleth, onde, para tanto o administrador dever´a preencher algumas informac¸˜oes; em seguida ´e solicitado ao administrador o metadado da federac¸˜ao, que ser´a configurado no cliente shibboleth do m´odulo e ent˜ao gerado o me-tadado da OV, enviado ao administrador; por sua vez, o administrador deve entrar em contato com a federac¸˜ao de identidade para inserir o metadado de sua OV, a fim de ini-ciar efetivamente sua participac¸˜ao naquela federac¸˜ao; logo ap´os realizados tais passos o administrador dever´a selecionar quais atributos, da lista de poss´ıveis atributos, ele neces-sita suportar, e ent˜ao ´e feita a sua configurac¸˜ao e confirmada ao administrador; por fim, o administrador utiliza o m´odulo para realizar sua autenticac¸˜ao na federac¸˜ao de identidade, com o objetivo de validar a configurac¸˜ao realizada, e ent˜ao finaliza a configurac¸˜ao.
O passo citado no diagrama da Figura 4 como “User Authentication Test”, ser´a visto com mais detalhes na Figura 5, assim como a agregac¸˜ao de atributos realizada para um usu´ario que se autentica na OV utilizando o ACROSS.
3.1.1. M´odulo Provedor de Atributos
O M´odulo Provedor de Atributos provˆe um diret´orio adicional para armazena-mento dos atributos espec´ıficos da OV. Este diret´orio ´e uma base LDAP. H´a ainda o agre-gador de atributos, respons´avel pela uni˜ao dos atributos vindos da federac¸˜ao de identidade com os atributos adicionais do provedor de atributos da OV.5
´
E interessante documentar que, durante a configurac¸˜ao do agregador de atributos e a criac¸˜ao das entradas de cada usu´ario no provedor de atribu-tos adicionais, um atributo opaco ´e utilizado como identificador do usu´ario. A entrada no provedor de atributos ter´a 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 usu´ario da OV, dificultando sua associac¸˜ao aos valo-res de atributos adicionais. Como forma de gerac¸˜ao do atributo opaco utilizando o atributo mail6 e um n´umero aleat´orio escolhido para ACROSS, temos:
δ ← Attru(mail) ∪ $salt (1)
AttrU(opaque) ← hash(δ) (2)
A Figura 5 ´e um diagrama UML voltado para a utilizac¸˜ao, que trata do momento da autenticac¸˜ao do usu´ario, onde os atributos adicionais da OV s˜ao recuperados do pro-vedor de atributos (a partir do atributo opaco), agregados e disponibilizados ao servic¸o associado da OV atrav´es do m´odulo A&A do usu´ario (“User A&A”).
Figura 5. Diagrama de sequˆencia do acesso do usu´ario com agregac¸˜ao de atributos.
5Por conta da limitac¸˜ao de espac¸o deste trabalho os diagramas de instalac¸˜ao e configurac¸˜ao para o Agregador de Atributos e o Provedor de Atributos foram suprimidos.
3.1.2. M´odulo de Controle de Acesso
O M´odulo Controle de Acesso ´e configurado pelo administrador da OV em quatro diferentes gerenciadores, referentes `a pontuac¸˜ao (score), n´ıvel (level), o recurso (resource) e a pol´ıtica (pol´ıtica)7. Sucintamente, a configurac¸˜ao da pontuac¸˜ao para cada um dos atri-butos existente na OV, inclusive consultando aqueles do provedor de atriatri-butos adicionais, ´e a primeira a ser realizada. Logo ap´os, o intervalod de pontuac¸˜ao 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 n˜ao ir˜ao se sobrepor). Destaca-se que, para a classificac¸˜ao do usu´ario em certo n´ıvel, ´e levada em considerac¸˜ao a sua pontuac¸˜ao e essa pontuac¸˜ao ´e normalizada, seguindo a proposta validade em [Silva et al. 2015]. J´a para a configurac¸˜ao do recurso, o administrador informa o tipo e uma breve descric¸˜ao daquele recurso.
Figura 6. Configurac¸˜ao de pol´ıticas de acesso.
Todos os registros s˜ao armazenados em arquivos XML e poder˜ao ser consultados posteriormente por outras entidades do ACROSS. A Figura 6 ilustra a configurac¸˜ao da pol´ıtica em si, e, portanto, levar´a em conta tanto o n´ıvel quanto aos tipos de recursos que poder˜ao ser autorizados `aquele n´ıvel. Esta configurac¸˜ao dever´a ser feita para cada uma das pol´ıticas criadas.
A configurac¸˜ao das pol´ıticas ser´a realizada tanto em n´ıvel global da OV como em n´ıvel local, e os demais m´odulos e configurac¸˜oes ser˜ao executados apenas no n´ıvel global pelo administrador da OV.
7Os diagramas para a configurac¸˜ao da pontuac¸˜ao, n´ıvel e recurso foram suprimidos por conta da limitac¸˜ao de espac¸o.
4. Trabalhos Relacionados
Nesta sec¸˜ao s˜ao comparados os trabalhos relacionados ao ACROSS, ainda que estes tratem apenas da autenticac¸˜ao ou apenas do controle de acesso.
4.1. VOMS - Virtual Organization Membership Service
O VOMS [Alfieri 2003] ´e um arcabouc¸o para autenticac¸˜ao e controle de acesso desenvolvido, inicialmente, para o contexto de grade computacional. Essa proposta tem sua autorizac¸˜ao baseada em pap´eis e pol´ıticas, o que pode-se comparar ao ACROSS na utilizac¸˜ao 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¸˜ao, que avalia se o usu´ario tem credenciais v´alidas ou pertence a um certo grupo, e a pol´ıtica local ´e realizada pelo RP (Resource Pro-vider) – respons´avel por oferecer o recurso em si. Para utilizar o VOMS, o usu´ario deve reapresentar suas credenciais ao RP (local) junto com uma autorizac¸˜ao pr´e-concedida pela OV (global). A ideia ´e que o usu´ario, mesmo sendo autorizado pela OV, possa ter seu acesso restringido localmente.
Basicamente, o VOMS ´e baseado em pap´eis, que por sua vez s˜ao expressos por grupos e subgrupos. Pensando na hierarquia de controle de acesso baseado em pap´eis do VOMS, a ideia ´e que haja uma raiz e abaixo dela os v´ertices sejam grupos e subgrupos, que existam como arestas orientadas, herdando regras dos n´ıveis superiores, como em um grafo ac´ıclico. No VOMS, o usu´ario ´e representado por pap´eis (roles) e recursos (capabilities), onde um papel est´a intimamente relacionado ao usu´ario naquele grupo, ou seja, o papel que ele possui dentro daquele grupo. Esse papel ´e utilizado para a tomada de decis˜ao.
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¸˜ao de recursos, a pol´ıtica global valida e classifica o usu´ario conforme seus atributos, atribuindo a ele um n´ıvel espec´ıfico de acordo com a configurac¸˜ao do administrador global da OV. J´a no n´ıvel local, de cada ilha, apenas o n´ıvel de acesso do usu´ario ´e fornecido, uma forma mais geral para tratar a requisic¸˜ao do usu´ario ao recurso. O ACROSS tamb´em mant´em a privacidade dos atributos do usu´ario no n´ıvel local das ilhas, uma vez que apenas um atributo gen´erico, o n´ıvel, ´e enviado para a tomada de decis˜ao na pol´ıtica local, mantendo os valores de atributos, c´alculos e tomadas de decis˜ao centralizados `a federac¸˜ao no n´ıvel global.
O ACROSS trabalha de forma dinˆamica, classificando usu´arios em n´ıveis criados pelo administrador global da OV. Diferentemente do VOMS, o ACROSS permite que se-jam criados, a partir de atributos espec´ıficos suportados pela OV, classificac¸˜oes dinˆamicas de alocac¸˜ao de recursos. A alocac¸˜ao de recursos, assim como realizada pelo VOMS, ´e feita no n´ıvel local.
Outra diferenc¸a entre VOMS e ACROSS ´e que o VOMS prop˜oe um servic¸o de gerˆencia para v´arias OVs distintas no mesmo servic¸o, a partir da gerac¸˜ao de credenciais X.509 do tipo proxy (formato herdado de sua motivac¸˜ao de ser um arcabouc¸o para a gerˆencia de acesso `a grade computacional). O ACROSS deve ser usado individualmente por cada OV que deseja facilitar a gest˜ao de identidade de seus usu´arios, considerando as funcionalidades de autenticac¸˜ao e autorizac¸˜ao, integradas a uma federac¸˜ao 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 gerˆencia de controle de acesso ´e realizada pelo administrador da OV atrav´es do servidor CAS, que funciona de forma intermedi´aria entre o requisitante do acesso e o recurso em si. Seu modelo de autorizac¸˜ao ´e baseado em pap´eis (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 usu´ario apresenta suas credenciais e ´e verificado junto `a base de pol´ıticas global da OV, associando a ele uma certa permiss˜ao conforme seu papel na OV. J´a a pol´ıtica local pode ser vista no acesso, quando a instituic¸˜ao dona do recurso aplica uma pol´ıtica restritiva conforme o papel do usu´ario. Comparado ao ACROSS, o CAS possui pol´ıticas globais e locais claramente mais simples e limitadas, uma vez que se baseia em uma implementac¸˜ao simples do RBAC. Por´em, 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¸˜ao de credenciais. Tamb´em ´e interessante citar a diferenc¸a b´asica entre o CAS e o VOMS, onde no VOMS o usu´ario pertence a um grupo que por sua vez ´e mapeado em um direito somente no dom´ınio do recurso (na instituic¸˜ao, por exemplo). J´a o CAS envia os direitos baseados nos pap´eis diretamente atrav´es 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. An´aloga a uma ICP (Infraestrutura de Chave P´ublica) [ITU-T 2012], o PMI apresenta uma AA (Attribute Authority), respons´avel por emitir certificados de atri-butos X.509 (Attribute Certificates – ACs) [Farrell and Housley 2002] para os usu´arios, e uma AC (Autoridade Certificadora) ´e respons´avel por armazenar a ligac¸˜ao entre a creden-cial do usu´ario, seu DN (Distinguished Name) e os atributos de privil´egios do usu´ario. 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 usu´ario. Em geral, as principais diferenc¸as entre o PERMIS e o ACROSS est˜ao na facilidade de instalac¸˜ao e integrac¸˜ao oferecida pelo ACROSS `a OV. Sabemos que o PERMIS ´e um arcabouc¸o maduro, difundido e bem es-truturado no padr˜ao X.509, assim como o VOMS. Por´em, o PERMIS e tamb´em o VOMS acabam por se tornar um tanto quanto engessados na estrutura de grade computacional principalmente pelo tipo de credencial suportado, al´em de ambos terem como heranc¸a o foco na integrac¸˜ao do Globus Toolkit, o que pode dificultar a adoc¸˜ao deste arcabouc¸o ou exigir um grande esforc¸o de desenvolvimento.
5. Considerac¸˜oes Finais e Trabalhos Futuros
O presente trabalho apresentou tanto a motivac¸˜ao e embasamento te´orico por meio da comparac¸˜ao com trabalhos relacionados de outros arcabouc¸os de controle de acesso
para OV, quanto a arquitetura e alguns diagramas de exemplo utilizados para o desen-volvimento do ACROSS. ´E interessante deixar claro que os assistentes de instalac¸˜ao e configurac¸˜ao de cada um dos m´odulos que est˜ao sendo desenvolvidos, facilitar˜ao a criac¸˜ao de novas OVs e ir˜ao agilizar o ingresso de novas instituic¸˜oes tanto na CAFe como na ades˜ao `a utilizac¸˜ao de conceitos de controle de acesso.
O arcabouc¸o atualmente encontra-se em desenvolvimento, e o pr´oximo passo ser´a sua validac¸˜ao por meio de testes e nos ambientes de experimentac¸˜ao em IF do projeto FIBRE e de nuvem, utilizando OpenStack. Almeja-se ainda a validac¸˜ao da instalac¸˜ao, configurac¸˜ao e utilizac¸˜ao do arcabouc¸o ACROSS por uma OV diferente das pensadas inicialmente, com a finalidade de validar qu˜ao gen´erica esta soluc¸˜ao realmente se tornou.
Referˆencias
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 Authori-zation. 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 Com-puting, 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 intercon-nection – 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: Attribute-Based 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.
