Suporte a organizações virtuais para autenticação
e controle de acesso no CSGrid
Vinicius G. Pinheiro1 , Maria Julia de Lima1 , Renato Maia1 , Noemi Rodriguez2
1
Instituto Tecgraf
PUC-Rio – Rio de Janeiro – RJ – Brasil
2
Departamento de Informática
PUC-Rio – Rio de Janeiro – RJ – Brasil
{vgpinheiro,mjulia,maia}@tecgraf.puc-rio.br, [email protected]
Abstract. Sharing resources located in different administrative domains is a typical need from multi-institutional projects. Such need implies at using Authentication and Authorization (A&A) mechanisms to normalize the access to the
resources by the users. In the EUBrazilCC federation, VOMS (Virtual Organization Membership System) was adopted for this purpose what motivated adaptations on the CSGrid system to give support to virtual organizations for identifying and authenticating users from this federation. In this work, we present
those modifications, how they were implemented and which possibilities they
aggregate to CSGrid and to the project.
Resumo. O compartilhamento de recursos localizados em diferentes domínios
administrativos é uma necessidade típica em projetos multi-institucionais. Tal
necessidade implica no uso de mecanismos de Autenticação e Autorização
(A&A) para padronizar o acesso dos recursos aos usuários. Na federação
EUBrazilCC, o VOMS (Virtual Organization Membership System) foi o serviço
adotado para esse propósito, o que motivou adaptações no sistema CSGrid com
o objetivo de dar suporte a organizações virtuais para identificação e autenticação de usuários dessa federação. Neste trabalho, apresentamos quais foram
essas adaptações, como foram implementadas e quais as possibilidades que elas
agregam ao CSGrid e ao projeto.
1. Introdução
A necessidade de compartilhar recursos computacionais entre usuários de diferentes instituições de pesquisa tem motivado comunidades acadêmicas e científicas a integrarem
seus recursos em federações1 . O projeto EU Brazil Cloud Connect2 tem como um de seus
objetivos criar uma federação de clusters e clouds privadas, incentivando a colaboração de
pesquisadores do Brasil e da Europa. No EUBrazilCC, o CSGrid [de Lima et al. 2005]
é usado como middleware de serviços que oferece uma API de submissão de programas na infraestrutura computacional da federação para computação de alto desempenho.
O sistema é uma das instâncias do CSBase [de Lima et al. 2006, de Lima et al. 2015],
1
2
Aqui estamos nos referindo a federações de recursos, e não a federações de identidade
http://www.eubrazilcloudconnect.eu/
um framework que o Instituto Tecgraf da PUC-Rio vem desenvolvendo há uma década, e é utilizado como parte do middleware para desenvolvimento de portais científicos
mc2 [Gomes et al. 2015], desenvolvido no LNCC.
O EUBrazilCC é um exemplo de uma organização virtual [Foster et al. 2003],
cujos membros e recursos estão espalhados por diferentes instituições e domínios administrativos. Organizações virtuais ainda constituem um desafio para a comunidade acadêmica no que diz respeito a mecanismos de autenticação e autorização. As federações
de identidade [Wangham et al. 2010] vêm padronizando o acesso (web) a serviços disponíveis para toda a comunidade acadêmica ou para todos os membros de uma instituição
que satisfaçam determinado critério, no caso deste critério ser gerenciado pela própria
instituição (por exemplo, serviço disponível para todos os professores da PUC-Rio). No
entanto, a participação de membros em uma organização virtual é iniciada ou cancelada
segundo regras externas às organizações às quais são diretamente ligados. Por isso, os
mecanismos convencionais de A&A de uma federação de identidade não são suficientes.
Os participantes europeus do projeto EUBrazilCC já adotavam o
VOMS [Alfieri et al. 2004] (Virtual Organization Membership Service) como mecanismo de autenticação e controle de acesso a seus recursos em outros projetos de
cooperação, e foi natural que o VOMS fosse eleito como o sistema de controle no
EUBrazilCC também. O sistema VOMS nasceu no âmbito de grades computacionais e é
largamente utilizado nesse contexto.
O CSGrid, por seu lado, já adotava o OpenBus [Maia and Roenick 2015] como
mecanismo de integração com outros sistemas, que oferece um modelo de autenticação
próprio. O OpenBus oferece algumas opções de autenticação, como uso de certificados
digitais ou senhas, e tem possibilidade de ser estendido para se integrar com mecanismos
de autenticação externos como o VOMS. Adicionalmente, o CSGrid adotava um modelo
de autorizações próprio baseado na autenticação do OpenBus e em permissões definidas
pelo administrador do sistema. Para adaptar o CSGrid para uso no EUBrazilCC com autenticação VOMS, exploramos a extensibilidade do modelo de autenticação do OpenBus e
construímos novos mecanismos necessários para permitir integrar essa nova autenticação
com o modelo de autorização próprio do CSGrid.
Neste artigo discutimos as alterações que fizemos no CSGrid para permitir sua integração com mecanismos de autenticação externos, e em particular sua integração com o
VOMS através do OpenBus. Inicialmente nosso objetivo era apenas permitir a integração
do CSGrid com o VOMS, mas ao longo de nosso trabalho optamos por um redesenho que
permite a integração de outros serviços.
O artigo está organizado da seguinte forma. A seção 2 apresenta o sistema CSGrid
e descreve o modelo de autenticação adotado para usuários que utilizam seus serviços
através do barramento OpenBus. A seção 3 descreve as adaptações e extensões feitas
no modelo de autenticação adotado pelo CSGrid para dar suporte a usuários da federação
EUBrazilCC. A seção 4 apresenta trabalhos futuros e reflexões com relação à flexibilidade
da solução e ao potencial de uso do VOMS em outras infraestruturas federadas.
2. CSGrid
O CSGrid é um sistema da família CSBase [de Lima et al. 2006, de Lima et al. 2015] que
oferece um ambiente de integração de aplicações cujos usuários solicitam a execução de
programas em recursos computacionais distribuídos e heterogêneos. Nesta seção apresentamos uma visão geral do sistema CSGrid e sua arquitetura, assim como também o
modelo de autenticação adotado por meio de um barramento OpenBus.
2.1. Visão Geral
O CSGrid possui um repositório destes programas os quais o usuário pode selecionar para
execução em uma das máquinas disponíveis, gerenciadas por um componente da arquitetura chamado SGA. O SGA implementa uma interface que (1) provê informações sobre
os recursos computacionais que gerencia e (2) controla e monitora a submissão de programas executados pelos usuários do CSGrid. Em alguns casos, um SGA é um daemon que
torna uma máquina apta a receber pedidos de execução de comandos e envia para o servidor as propriedades dessa máquina (e.g. memória, CPU) e dos comandos em execução.
Em outros cenários, o SGA pode atuar como um mediador para outros escalonadores de
terceiros como Portable Bach System (PBS)/Torque, Simple Linux Utility for Resource
Management (SLURM), Sun Grid Engine (SGE) e outros.
O CSGrid oferece também uma área de projetos para compartilhamento e organização dos dados de entrada e saída da execução de programas, dando apoio ao trabalho
colaborativo entre os usuários de um mesmo projeto. Todos os recursos do sistema contam também com mecanismos locais de gestão de autenticação e autorização, podendo
assim serem usados por organizações que lidam com dados sensíveis ou sistemas com
propriedade intelectual.
O CSBase, framework sobre o qual o CSGrid foi desenvolvido, já existe há mais
de 10 anos e é utilizado por diferentes sistemas em produção na Petrobras com um número
significativo de usuários. Desde 2011, o CSGrid também é adotado no SINAPAD3 , Sistema Nacional de Processamento de Alto Desempenho, como o middleware que gerencia
seus recursos computacionais.
A arquitetura do CSGrid dá suporte a dois modelos de integração de aplicações
clientes, conforme a ilustração na Figura 1. No primeiro tipo de integração, as aplicações
construídas com o toolkit CSDK (CSBase Development Kit) [Clinio and Almeida 2015]
são instaladas no servidor CSGrid e se tornam automaticamente disponíveis no desktop
padrão do CSGrid. Esse modelo de integração atende especificamente a construção de
aplicações Java, com interfaces gráficas que facilmente são disponibilizadas para usuários
de um sistema CSGrid já instalado. A comunicação com o servidor CSGGrid é baseada
em chamadas remotas de serviços do CSGrid que exportam suas interfaces Java RMI.
As aplicações construídas com o CSDK utilizam autenticação por usuário e senha que,
dependendo da instalação do CSGrid, podem ser validadas em uma base local do próprio
CSGrid ou pelos servidores LDAP configurados.
Um outro conjunto de aplicações externas utiliza o servidor CSGrid através de
um barramento de integração de serviços, o OpenBus. O OpenBus oferece um conjunto
de serviços básicos CORBA4 que dão suporte a construção e integração de aplicações,
independente de linguagem e plataforma. O mc2, desenvolvido pelo LNCC, é um exemplo de sistema que atualmente adota a integração com o CSGrid através do barramento
OpenBus.
3
4
https://www.lncc.br/sinapad
http://www.corba.org
Cenário de integração entre o mc2 e o CSGrid no EUBrazilCC
Aplicações Externas Openbus SDK OpenBus
Aplicações CSGrid CORBA
CSDK Desktop CSGrid CSGrid
Java RMI
SGA SGA SGA
SGA
Nuvens privadas e infraestrutura HPC
Figura 1. Integração de aplicações no CSGrid
Em particular, no trabalho aqui apresentado, estamos interessados em investigar
o suporte a organizações virtuais no CSGrid com aplicações integradas através do barramento OpenBus. Essa arquitetura de integração através da autenticação de usuários no
OpenBus é a solução adotada pelo CSGrid na federação EUBrazilCC. No projeto EUBrazilCC, portais científicos construídos com a plataforma mc2 usam os serviços do CSGrid
para submeter a execução de programas nos recursos computacionais da infraestrutura de
clusters e clouds privadas de instituições no Brasil e na Europa.
2.2. Autenticação pelo OpenBus
No projeto EUBrazilCC, o CSGrid adota o OpenBus como solução de integração com os
portais científicos construídos na plataforma mc2. O OpenBus oferece um barramento
de integração de sistemas por meio de um conjunto de serviços básicos baseados em
CORBA. Essa interface de integração via OpenBus tem por objetivo prover comunicação
eficiente e independente de plataforma, autenticação das partes comunicantes, descoberta
de serviços e governança sobre o acesso e serviços publicados no barramento. O OpenBus
vem sendo desenvolvido e mantido pelo Instituto Tecgraf/PUC-Rio para a Petrobras desde
2006, sendo que nesse período diversos sistemas de E&P (Exploração e Produção) já se
integraram através de barramentos OpenBus.
Os principais serviços publicados pelo servidor CSGrid no barramento OpenBus
são o OpenDreams, o ProjectService e o ServerMonitor. O OpenDreams é um serviço
para submissão, monitoramento e controle de execução remota de programas. O ProjectService é um serviço que oferece funcionalidades para acesso e transferência de dados
utilizados na execução de programas. Os usuários podem compartilhar seus projetos com
outros usuários do CSGrid. O ServerMonitor é o serviço que provê informações sobre
os recursos computacionais disponíveis para execução dos programas, de acordo com as
políticas de acesso configuradas no CSGrid para utilização desses recursos pelos usuários
autenticados.
Toda comunicação feita entre as aplicações e serviços do CSGrid através do OpenBus é realizada através de chamadas de objetos distribuídos usando o padrão CORBA.
Contudo, ao contrário das chamadas de CORBA comuns, nas chamadas feitas através do
barramento, é imposto um rigoroso controle de acesso que só permite chamadas provenientes de sistemas previamente autenticados junto ao barramento. O controle de acesso ao
barramento é assegurado através de credenciais ocultas nas chamadas de objetos CORBA.
Essas credenciais de acesso contém informações de identificação da origem da chamada,
ou mais especificamente o login de acesso do processo que originou a chamada. Todo
login é sempre autenticado em nome de uma entidade, que é responsável por todos os
acessos feitos através daquele login.
Além disso, as credenciais do OpenBus podem incluir múltiplos logins, formando
uma cadeia de logins. Esse suporte é usado para indicar que múltiplas identidades atuam
por trás de uma dada chamada. Por exemplo, quando um sistema faz uma chamada em
nome de outro (delegação) ou como consequência de uma chamada proveniente de outro sistema autenticado com uma entidade diferente. Nesses casos, a credencial inclui
informações do login de todos os sistemas envolvidos. A cadeia de logins do OpenBus
é ordenada, de forma que é possível identificar o login mais imediato que originou a
chamada em que a credencial está contida. Os sistemas que recebem chamadas pelo barramento com credenciais podem inspecionar essa cadeia e obter um identificador único de
cada login participante. Através dos identificadores de login é possível obter informações
sobre um dado login, tal como a entidade de autenticação, ou mesmo outros dados adicionais disponibilizados através de serviços especializados. Com base nessas informações o
CSGrid é capaz de impor seu próprio mecanismo de permissionamento em cada chamada
recebida pelo barramento, baseando-se nas informações de identificação provenientes da
credencial do OpenBus.
Por padrão, o OpenBus permite um conjunto básico de mecanismos de autenticação, tais como autenticação por senha proveniente de um sistema LDAP ou certificado
digital. Contudo o OpenBus também provê a possibilidade de se estender o seu suporte a
autenticação através de plugins denominados validadores de token. Um validador de token tem por objetivo validar uma prova de autenticação externa fornecida ao barramento
no momento da autenticação de um sistema. Uma vez que a prova de autenticação externa
seja validada por um validador de token, o barramento gera um novo login para representar essa autenticação, e o associa permanentemente à identidade da entidade validada pelo
validador de token. O novo login pode então ser utilizado para formar credenciais OpenBus que identifiquem chamadas como provenientes dessa entidade autenticada por um
provedor de identidade externo.
3. Suporte a federação EUBrazilCC no CSGrid
O VOMS foi adotado pelo projeto EUBrazil Cloud Connect como o serviço de autenticação e autorização dos usuários. Essa escolha foi uma opção natural, dado seu uso
em outros projetos de cooperação. Nessa seção, discutimos as adaptações feitas no CSGrid para utilizar o VOMS no controle de acesso das requisições provenientes dos portais
desenvolvidos pelo mc2. Os portais do mc2 se integram ao CSGrid através do barramento OpenBus e, portanto, a extensão desenvolvida para a solução de autenticação com
o VOMS envolve adaptações no suporte ao OpenBus do CSGrid.
3.1. O serviço VOMS
O VOMS (Virtual Organization Membership Service) [Alfieri et al. 2004] é um serviço de
autenticação e autorização (A&A) para organizações virtuais (VOs) originalmente dese-
nhado para uso em grades computacionais. A infraestrutura de autenticação e autorização
tradicionalmente utilizada em grades utiliza o conceito de VOs e certificados de atributo
(AC) para implementar acordos de serviço entre uma VO e os provedores de recursos
computacionais. Esses provedores de recursos aceitam usuários que apresentem certificados de atributo assinados por um intermediário confiável, e utilizam os atributos contidos
nos certificados para definir permissões. O VOMS funciona como uma base de dados
sobre organizações virtuais, emitindo certificados de atributo de curta duração para usuários cadastrados para que esses possam apresentá-los a provedores de recursos. O serviço
ainda dá suporte ao conceito de Single Sign On (SSO), possibilitando que usuários autenticados em um sistema possam ser identificados por outros sistemas sem a necessidade de
novas autenticações. Para que isso seja possível, cada sistema deve estar preparado para
autenticar não somente seus usuários locais como também usuários externos representados por tokens VOMS.
As organizações virtuais possuem administradores que fazem o cadastro de usuários e papéis da organização virtual. Um usuário pode estar cadastrado em várias organizações virtuais, e em cada uma ter papéis específicos. O usuário, ao contactar o serviço
VOMS, apresenta seu certificado de usuário (certificado digital X509 assinado por uma
autoridade certificadora reconhecida pelo VOMS) e informa que organização virtual deseja utilizar. O serviço VOMS então gera (e assina) um certificado de curta validade
(certificado proxy compatível com a RFC 3281) contendo a identificação do usuário e o
certificado de atributo que contém seus atributos na VO desejada. O proxy é usado como
token de autenticação perante provedores de recursos da VO desejada. Além de utilizar o
certificado proxy para autenticação do usuário, o provedor de recursos pode consultar os
atributos constantes no certificado para definir autorizações e direitos. O certificado também pode ser enviado para fazer delegações, isto é, para que o recurso possa se comunicar
com um outro serviço em nome do usuário.
Os atributos VOMS refletem a estrutura de uma VO: os grupos ao qual um usuário
pertence, os papéis de um usuário em cada grupo e atributos genéricos na forma de pares
chave-valor. Esses atributos genéricos podem ser usados para associar outras informações úteis ao membro de uma VO, como por exemplo atributos Shibboleth. Atualmente
os serviços VOMS também permitem utilizar asserções SAML para descrever atributos
VOMS, facilitando a interoperabilidade entre os provedores de serviços.
O código do VOMS é mantido e disponibilizado pela EMI (European Middleware
Intiative). A federação EUBrazilCC utiliza o serviço VOMS hospedado pela Universidade Politécnica de Valência.
3.2. Arquitetura do modelo de A&A com o VOMS no CSGrid
Para dar suporte no CSGrid à autenticação de usuários representados por proxies VOMS,
estendemos o modelo de A&A do CSGrid com a implementação dos seguintes artefatos:
• VOMSTokenValidator: Um validador de token VOMS implementado de acordo
com o modelo de validador de token do OpenBus (vide seção 2.2). Ele possibilita
que sistemas autenticados no barramento gerem chamadas que sejam identificadas
como provenientes de usuários externos.
• VOMSACInfoService: Uma aplicação CORBA que provê uma API simples para
a consulta de informações sobre proxies VOMS como data de expiração, atributos
Figura 2. Autenticação VOMS na infraestrutura EUBrazil Cloud Connect.
dos usuários na forma de FQANs5 (Fully Qualified Attribute Names) etc. Os dados
desse serviço são populados pelo validador de tokens VOMS durante a validação
de um certificado proxy, e esses dados ficam disponíveis para o CSGrid.
Na Figura 2, descrevemos passo a passo como tais artefatos se inserem na arquitetura da solução. Nessa figura, os portais desenvolvidos pela plataforma mc2 servem
como porta de entrada através da qual os usuários da organização virtual EUBrazilCC
tem acesso aos recursos computacionais da infraestrutura federada.
Assumimos que tanto a plataforma mc2 como o sistema CSGrid estejam previamente autenticados junto ao barramento, que é tipicamente feito usando os mecanismos
básicos de autenticação do OpenBus através de certificados digitais gerados para esses
sistemas. Similarmente assumimos que o CSGrid tenha publicado seus serviços no registro de ofertas do barramento de forma que possa ser encontrado pela plataforma mc2 para
submissão de execuções.
Quando um usuário da federação EUBrazilCC (e.g. Pedro) faz acesso a um portal
mc2, ele pode fornecer um certificado proxy VOMS como forma de autenticação (passo
1). A plataforma mc2 então converte esse certificado numa credencial OpenBus através
da operação importChain do barramento (passo 2). Essa operação recebe como parâmetros um token de autenticação e uma identificação do domínio no qual este token deve ser
validado. Nesse caso, o token passado como parâmetro é o proxy VOMS e o domínio é
“voms”. O domínio é uma informação necessária para que o OpenBus saiba qual vali5
FQANs são atributos VOMS que guardam informações dos usuários no formato
“/<vo>/Role=<função>/Capability=<aptidão>”. Um exemplo de FQAN para um usuário cadastrado na
VO “eubrazilcc” com função de administrador seria “/eubrazilcc/Role=administrador/Capability=NULL”.
dador de token deve ser utilizado já que múltiplos validadores podem estar configurados
em uma instância do barramento. Para validar o token no domínio “voms”, o barramento
utiliza um validador de token especializado (VOMSTokenValidator) instalado no barramento OpenBus que atende a integração entre o mc2 e o CSGrid.
O validador VOMSTokenValidator então utiliza a operação validate do serviço
VOMSACInfoService para validar o ceritificado proxy (passo 3). Essa validação consiste
em verificar a assinatura do proxy e do certificado de atributos (AC) contido no proxy
(passo 4). A validação de proxies VOMS requer a configuração de arquivos e diretórios
que contenham informações sobre certificados digitais de autoridades certificadoras e servidores VOMS confiáveis. Sendo assim, tal serviço roda em uma máquina especialmente
configurada para este fim e que não precisa ser necessariamente a mesma máquina que
hospeda os serviços que compõem a infraestrutura do barramento e o validador de tokens
do OpenBus. A validação do certificado proxy extrai o distinguished name (DN6 ) e outras informações que são associadas ao DN (passo 5). O DN é usado como resultado da
operação validate (passo 6) e servirá para identificar a entidade que representa o usuário
Pedro dentro do barramento OpenBus.
Ao receber como resultado da validação a identificação da entidade autenticada
(Pedro), a operação importChain gera uma credencial indicando uma cadeia de logins
com entidade Pedro, que é devolvida para a plataforma mc2 (passo 7). De posse dessa
credencial a plataforma mc2 utiliza a operação joinChain da biblioteca de acesso ao barramento para que todas as chamadas seguintes sejam feitas como extensão dessa credencial
(passo 8). Dessa forma, quando uma chamada é feita para o CSGrid através do barramento, ela é feita com uma credencial contendo uma cadeia de logins com a entidade
do usuário (Pedro) e a entidade da plataforma mc2 (passo 9). O CSGrid, ao receber a
chamada, pode inspecionar a cadeia de logins da credencial através da operação getCallerChain da biblioteca de acesso ao barramento (passo 10). Nesse ponto, o CSGrid é
capaz de identificar não apenas que a chamada ao serviço é proveniente do usuário Pedro,
mas também que a mesma é proveniente de um portal do mc2, pois ambas as entidades
fazem parte da mesma cadeia de logins.
Em seguida, o CSGrid verifica junto ao barramento se o domínio de autenticação
do login do usuário requisitante é “voms”. Note que a informação do domínio é necessária para que o CSGrid mantenha o suporte a requisições de usuários que não tenham se
autenticado com o proxy VOMS. Por exemplo, usuários autenticados no barramento com
o mecanismo padrão de certificados digitais ou com LDAP, também podem ser atendidos
pelo CSGrid. No nosso exemplo, como “Pedro” se autenticou pelo domínio “voms”, o
CSGrid se dirige ao VOMSACInfoService para obter o conjunto de atributos deste usuário na sua VO. A operação getFQANs (passo 11) retorna todos os atributos presentes do
proxy VOMS utilizado na autenticação do usuário. O CSGrid implementa um modelo
de controle de acesso baseado em atributos, que não detalhamos aqui por estar fora do
escopo do trabalho. Vale destacar, que o token VOMS não é necessário ao CSGrid já que
para consultar o VOMSACInfoService o DN do usuário é usado como chave.
6
O distinguished name é uma sequência de atributos no formato chave/valor que identificam um usuário.
O seu formato foi definido no RFC 2459 [Housley et al. 1999]. A sequência C=BR, O=ICPEDU, O=UFF
BrGrid CA, O=PUC-Rio, OU=Tecgraf, CN=Pedro Silva é um exemplo de DN, onde “C” refere-se ao país,
“O” à organização, “OU” à unidade dentro da organização e "“CN” ao nome do usuário.
4. Conclusão e trabalhos futuros
O compartilhamento de recursos localizados em diferentes domínios administrativos é
uma necessidade típica em sistemas ditribuídos que envolvem múltiplas instituições. As
organizações virtuais estabelecem uma forma de agrupamento dos usuários de acordo com
seus papéis no uso desses recursos, independente das políticas administrativas próprias
das suas instituições de origem.
Nesse trabalho, descrevemos uma solução de uso do VOMS para controle de
acesso aos usuários da organização virtual EUBrazilCC no sistema CSGrid. No projeto EUBrazilCC, o CSGrid é um dos componentes utilizados para acesso a infraestrutura
de cloud privada e clusters de alto desempenho das instituições participantes. A solução aqui apresentada se baseia no modelo atual de integração do CSGrid com aplicações
externas através de um barramento de serviços CORBA, o OpenBus. As adaptações e
extensões que fizemos nesse modelo permitem que os portais desenvolvidos com a plataforma mc2 autentiquem e autorizem usuários da federação EUBrasilCC a submeterem
seus programas para execução na infraestrutura de recursos computacionais integrados
com o CSGrid. Essa solução já vem sendo utilizada pelo Laboratório Nacional de Computação Científica (LNCC).
O modelo descrito aqui não atende apenas ao projeto EUBrazilCC mas introduz
flexibilidade para dar suporte a outras federações de usuários. Ele permite a utilização de
diferentes provedores de identidade externos nos acessos a sistemas CSGrid via OpenBus.
Uma preocupação natural é a integração de um ambiente como o descrito neste artigo com
a federação de autenticação CAFe7 . O papel do VOMS é organizar informação sobre
organizações virtuais, que não cabe em provedores de identidade de uma federação. Mas
o usuário não precisa ir além dos serviços da própria federação CAFe para conseguir
o certificado com o qual se autentica perante o VOMS. A federação pode oferecer um
serviço como o descrito por Wangham e outros [Wangham et al. 2012] para geração de
certificados de usuários no formato X509 a partir dos dados mantidos pelos provedores
de identidade.
Além de permitir a autenticação de usuários com proxies VOMS através do OpenBus, o CSGrid está sendo modificado para dar suporte ao login de usuários VOMS diretamente através do seu cliente desktop. Dessa forma, esses usuários terão acesso a um
outro conjunto de aplicações do CSGrid, construídas sobre o modelo de integração que
usa o toolkit CSDK.
O uso do VOMS surgiu e se consolidou nos cenários de projetos de grades computacionais, como o DataGrid [Gagliardi et al. 2002] e outros projetos da EGI8 que utilizam
o Globus Toolkit [Foster and Kesselman 1997]. A experiência adquirida com o VOMS
em projetos de grade da EGI tem motivado explorar o uso do VOMS para federação de
identidades entre provedores de serviços em infraestruturas de nuvens, trazendo novos
cenários de uso e, consequentemente, novos requisitos de A&A. Isso pode ser observado
em trabalhos recentes como a inclusão de autenticação VOMS na plataforma de software
OpenStack [Garcia et al. 2013] e a readequação do seu serviço de identidade Keystone v3
para que este funcione como um servidor VOMS (KeyVOMS) [Lee et al. 2014].
7
8
http://www.rnp.br/servicos/servicos-avancados/cafe
http://www.egi.eu
É também nesse contexto que o trabalho aqui apresentado pretende contribuir. No
projeto EUBrazilCC, não apenas o CSGrid mas outros provedores de serviço participam
e cooperam para atender aos usuários da federação. Em particular, no EUBrazilCC, o
CSGrid foi integrado ao Fogbow [Barros et al. 2015], um middleware para federação de
nuvens privadas que emprestam seus recursos computacionais ociosos e utilizam recursos
ociosos de outras nuvens da federação. O Fogbow também provê suporte ao uso do
VOMS.
Proxies VOMS devem ser usados como credenciais levando em consideração suas
limitações e questões de segurança. Qualquer pessoa de posse de um certificado proxy
pode se fazer passar por outra durante um tempo limitado, tipicamente 12 horas, o que
reduz a janela de tempo para possíveis fraudes. Serviços de autenticação devem ser programados para verificar a validade dos proxies e recusá-los em caso de expiração. Requisitos como delegação de proxies VOMS entre diferentes provedores de serviço, renovação
de proxies em caso de longas interações e flexibilidade no suporte a outras federações de
usuários são alguns exemplos de questões sendo discutidas atualmente no projeto.
Referências
Alfieri, R., Cecchini, R., Ciaschini, V., dell’Agnello, L., Frohner, A., Gianoli, A., Lorentey, K., and Spataro, F. (2004). VOMS, an authorization system for virtual organizations. In Grid Computing, pages 33–40. Springer.
Barros, A., Brasileiro, F., Farias, G., Germano, F., Nóbrega, M., Ribeiro, A. C., Silva, I.,
and Teixeira, L. (2015). Using fogbow to federate private clouds. Salão de Ferramentas
do XXXIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos.
Clinio, A. and Almeida, I. (2015). CSDK: Uma forma de modularização de componentes
do desktop no CSBase. Technical report, Tecgraf/PUC-Rio Institute.
de Lima, M., Ururahy, C., de Moura, A., Melcop, T., Cassino, C., Santos, M., Silvestre,
B., Reis, V., and Cerqueira, R. (2006). CSBase: A framework for building customized
grid environments. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2006. WETICE ’06. 15th IEEE International Workshops on, pages 187–194.
de Lima, M. J., Melcop, T., Cerqueira, R., Cassino, C., Silvestre, B., Nery, M., and
Ururahy, C. (2005). CSGrid: um sistema para integraç ao de aplicações em grades
computacionais. In Salão de Ferramentas do 23o. Simpósio Brasileiro de Redes de
Computadores, 2005, Fortaleza. Anais do 23o. Simpósio Brasileiro de Redes de Computadores, pages 1207–1214, Porto Alegre.
de Lima, M. J., Rodriguez, N., Ururahy, C., Almeida, I., and Clinio, A. (2015). CSBase: 10 years of experience with a framework for batch processing in heterogeneous
computing environments. Technical report, Tecgraf/PUC-Rio Institute.
Foster, I. and Kesselman, C. (1997). Globus: A metacomputing infrastructure toolkit.
International Journal of High Performance Computing Applications, 11(2):115–128.
Foster, I., Kesselman, C., and Tuecke, S. (2003). The anatomy of the grid. Berman et
al.[2], pages 171–197.
Gagliardi, F., Jones, B., Reale, M., and Burke, S. (2002). European Datagrid Project: Experiences of deploying a large scale Testbed for e-Science applications. In Performance
Evaluation of Complex Systems: Techniques and Tools, pages 480–499. Springer.
Garcia, A. L., del Castillo, E. F., and Puel, M. (2013). Identity federation with voms in
cloud infrastructures. 2013 IEEE 5th International Conference on Cloud Computing
Technology and Science, 1:42–48.
Gomes, A. T. A., Bastos, B. F., Medeiros, V., and Moreira, V. M. (2015). Experiences of
the Brazilian national High-Performance Computing Network on the Rapid Prototyping of science gateways. Concurrency and Computation: Practice and Experience,
27(2):271–289.
Housley, R., Ford, W., Polk, W., and Solo, D. (1999). Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459 (Proposed Standard). Obsoleted by
RFC 3280.
Lee, C., Desai, N., and Brethorst, A. (2014). A keystone-based virtual organization management system. In Cloud Computing Technology and Science (CloudCom), 2014
IEEE 6th International Conference on, pages 727–730.
Maia, R. and Roenick, H. (2015). Secure authentication in system integrations with OpenBus. Technical report, Tecgraf/PUC-Rio Institute.
Wangham, M., Mello, E., Böger, D., , Guérios, M., and Fraga, J. (2010). Gerenciamento
de identidades federadas. In Anais do XII Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais, Fortaleza. Minicurso.
Wangham, M., Mello, E., Böger, D., Fraga, J., and Guérios, M. (2012). Geração de certificados digitais a partir da autenticação federada shibboleth. In Anais do XII Simpósio
Brasileiro de Segurança da Informação e de Sistemas Computacionais, Curitiba. In:
In: Workshop de Gestão de Identidades (WGID).