Content uploaded by Emerson Ribeiro de Mello
Author content
All content in this area was uploaded by Emerson Ribeiro de Mello on Sep 18, 2022
Content may be subject to copyright.
Gerac¸ ˜
ao de Certificados Digitais a partir da Autenticac¸ ˜
ao
Federada Shibboleth∗
Michelle S. Wangham1, Emerson Ribeiro de Mello2,
Davi da Silva B¨
oger3, Joni da Silva Fraga3, Marlon Candido Gu´
erios4
1Grupo de Sistemas Embarcados e Distribu´
ıdos–GSED/CTTMAR
Universidade do Vale do Itaja´
ı (UNIVALI) – S˜
ao Jos´
e – SC – Brasil
2Instituto Federal de Santa Catarina – S˜
ao Jos´
e – SC –Brasil
3Departamento de Automac¸˜
ao e Sistemas (DAS)
Universidade Federal de Santa Catarina (UFSC) – Florian´
opolis – SC – Brasil
4Inohaus Consultoria e Desenvolvimento de Sistemas- Florian´
opolis – SC– Brasil
wangham@univali.br, mello@ifsc.edu.br
{dsboger,fraga}@das.ufsc.br, marlonguerios@inohaus.com.br
Resumo. O framework Shibboleth ´
e a infraestrutura de autenticac¸˜
ao e
autorizac¸ ˜
ao mais empregada para constituic¸˜
ao de federac¸ ˜
oes acadˆ
emicas, pos-
sibilitando que usu´
arios, atrav´
es de um navegador web, acessem servic¸os dis-
ponibilizados pela federac¸ ˜
ao usufruindo do conceito de autenticac¸ ˜
ao ´
unica. O
Shibboleth faz uso do padr˜
ao SAML, por´
em, nem todas as aplicac¸ ˜
oes usadas
pela comunidade acadˆ
emica operam com credenciais SAML ou n˜
ao s˜
ao web.
Diversos projetos surgiram para interligar o Shibboleth com a tecnologia de
autenticac¸ ˜
ao comumente usada em grids, as credencias X.509, permitindo as-
sim a convers˜
ao de credenciais SAML em certificados digitais. O presente tra-
balho descreve e compara duas abordagens para gerac¸˜
ao de certificados X.509,
a partir da autenticac¸ ˜
ao federada Shibboleth. Uma abordagem est´
a vinculada
ao provedor de servic¸os e a outra ao provedor de identidades. Por fim, as abor-
dagens propostas s˜
ao comparadas com os projetos relacionados.
Abstract. Shibboleth framework is an authentication and authorization infras-
tructure widely adopted by academic federations. It offers a way for users to
access multiple services with a federated single sign-on framework. Shibboleth
makes use of SAML standard, however some academic distributed applications
do not work with SAML credentials or they are not web applications. There are
several projects to mapping Shibboleth SAML credentials in X.509 credentials,
authentication technology commonly used in grid. This paper describes and
compares two approaches to generate X.509 certificates from the Shibboleth fe-
derated authentication. The first approach is linked to service providers and the
other one to the identity provider. Finally, these approaches are compared with
related projects.
∗Desenvolvido dentro do escopo do projeto “Servic¸os para Transposic¸ ˜
ao de Credenciais de Autenticac¸˜
ao
Federadas”, GT-STCFed, financiado pela RNP.
1. Introduc¸ ˜
ao
Nas atuais redes nacionais de ensino e pesquisa (National Research and Education
Network -NREN)1, a crescente necessidade de compartilhar recursos e servic¸os para
usu´
arios de diferentes instituic¸ ˜
oes que possuam algum tipo de relac¸˜
ao de confianc¸a mo-
tivaram a constituic¸˜
ao de federac¸ ˜
oes acadˆ
emicas [TERENA 2012]. Uma federac¸ ˜
ao ´
e
uma forma de associac¸˜
ao de parceiros de uma rede colaborativa que usa um conjunto
comum de atributos, pr´
aticas e pol´
ıticas para trocar informac¸ ˜
oes e compartilhar servic¸os
de forma segura, possibilitando a cooperac¸˜
ao e transac¸ ˜
oes entre os usu´
arios da federac¸˜
ao
[Carmody et al. 2005]. Estas federac¸ ˜
oes agrupam pessoas do meio acadˆ
emico que v˜
ao
desde alunos, t´
ecnicos administrativos e professores. O conceito de federac¸ ˜
ao acadˆ
emica
visa minimizar as demandas dos provedores e dos usu´
arios de servic¸os disponibilizados
por instituic¸ ˜
oes de ensino e pesquisa no que diz respeito `
a manutenc¸˜
ao de informac¸ ˜
oes
usadas para autenticac¸˜
ao e autorizac¸˜
ao de acesso a esses servic¸os [Moreira et al. 2011].
A noc¸˜
ao de federac¸˜
ao ´
e constru´
ıda a partir do gerenciamento de identidades obtido
com o uso de uma Infraestrutura de Autenticac¸ ˜
ao e Autorizac¸˜
ao (AAI). No contexto das
NRENs, o framework Shibboleth2´
e a infraestrutura mais empregada para constituic¸˜
ao
de federac¸ ˜
oes acadˆ
emicas. As federac¸ ˜
oes Incommon, da rede norte-americana Internet2,
e a CAFe, da Rede Nacional de Ensino e Pesquisa (RNP) do Brasil, s˜
ao exemplos de
federac¸ ˜
oes constru´
ıdas tendo como base este framework.
O projeto Shibboleth comec¸ou em 2000, como uma iniciativa da Internet2, com
o intuito de permitir que usu´
arios de instituic¸ ˜
oes acadˆ
emicas pudessem interagir com
servic¸os providos por outras instituic¸ ˜
oes, bastando que estas fac¸am parte de uma mesma
federac¸˜
ao acadˆ
emica. Em uma federac¸˜
ao acadˆ
emica, uma vez autenticado em sua
instituic¸˜
ao de origem, um usu´
ario pode acessar, atrav´
es de um navegador web, qual-
quer servic¸o da federac¸ ˜
ao sem novas autenticac¸˜
oes, caracterizando o que ´
e chamado
de autenticac¸˜
ao ´
unica web (Web Single Sign-On - Web SSO). O framework Shibboleth
est´
a baseado em padr˜
oes abertos, principal no SAML (Security Assertion Markup Lan-
guage) da OASIS, e fornece um pacote de software, de c´
odigo aberto, para a construc¸ ˜
ao
de aplicac¸ ˜
oes web federadas [Internet2 2012].
Dentro de um dom´
ınio Shibboleth existem dois pap´
eis: provedor de identida-
des (Identity Provider – IdP) e provedor de servic¸os (Service Provider – SP). O pri-
meiro ´
e respons´
avel por autenticar seus usu´
arios, antes que estes possam usufruir dos
servic¸os oferecidos pelo segundo [Shibboleth 2005]. Os IdPs s˜
ao respons´
aveis por man-
ter as informac¸ ˜
oes sobre as pessoas vinculadas a uma instituic¸˜
ao, incluindo dados pes-
soais (nome, data de nascimento, CPF, nomes dos pais, sexo, data de nascimento etc.)
e v´
ınculos internos (data de admiss˜
ao, cargo ocupado, n´
umero de matr´
ıcula, n´
umero
VoIP etc.). Um IdP estabelece seu m´
etodo de autenticac¸˜
ao interno e deve garantir que
cada pessoa da instituic¸˜
ao tenha um identificador ´
unico. Os SPs oferecem servic¸os de
acesso restrito, podendo requisitar informac¸ ˜
oes adicionais sobre os usu´
arios para garantir
o acesso a um determinado recurso, por exemplo, uma p´
agina web para realizar renovac¸˜
ao
de empr´
estimos de livros. Na implementac¸˜
ao do servic¸o, s˜
ao definidos os privil´
egios de
1S˜
ao provedores de servic¸o de Internet especializados para comunidade de ensino e pesquisa dentro de
um pa´
ıs que oferecem servic¸os de conectividade avanc¸ ados e canais dedicados para o desenvolvimento de
projetos de pesquisa e de capacitac¸˜
ao [TERENA 2012]
2http://shibboleth.net
acesso e as informac¸ ˜
oes adicionais que ser˜
ao solicitadas. N˜
ao cabe ao SP manter essas
informac¸ ˜
oes dos usu´
arios, mas apenas solicit´
a-las aos IdPs [Moreira et al. 2011].
Apesar das relac¸ ˜
oes de confianc¸a garantirem que as asserc¸ ˜
oes de seguranc¸a emi-
tidas pelos provedores de identidades ser˜
ao consideradas v´
alidas pelos provedores de
servic¸os, essas n˜
ao indicam a robustez do processo de autenticac¸˜
ao pelo qual o usu´
ario
passou junto ao provedor de identidades. A Federac¸ ˜
ao InCommon possui um programa
para avaliac¸˜
ao do n´
ıvel de garantia (LoA - Level of Assurance) das identidades utilizadas
na federac¸˜
ao. O framework para avaliac¸˜
ao do n´
ıvel de garantia (Identity Assurance As-
sessment Framework)[Federation 2011], define dois perfis - o prata e o bronze - para que
as instituic¸ ˜
oes da federac¸˜
ao possam aderir a fim de proporcionar maior n´
ıvel de garantia
aos provedores de servic¸o. Os perfis definem os requisitos espec´
ıficos que operadores
IdPs)devem cumprir para poderem incluir qualificadores de garantia de identidade In-
Common nas asserc¸ ˜
oes de identidades que estes oferecem aos provedores de servic¸o.
Com o intuito de encorajar que mais usu´
arios, em especial acadˆ
emicos vinculados
`
as redes nacionais de pesquisa e educac¸˜
ao (NREN), utilizem os servic¸os de um Grid ou
de uma cyberinfrastructure3, diversos projetos surgiram tendo como proposta interligar o
framework Shibboleth com o modelo de seguranc¸a comumente utilizado em grid services
e em cyberinfrastructure. Entre estes, destacam-se os projetos da Joint Information Sys-
tems Committee (JISC) - ShibGrid,SHEBANGS eSARoNGS, e os projetos da National
Science Foundation (NSF) - GridShib,CILogon ego.teragrid. O objetivo destes projetos
´
e conceber uma ponte entre as credenciais SAML geradas no processo de autenticac¸ ˜
ao
em um IdP da Federac¸ ˜
ao Shibboleth e os certificados X.509 necess´
arios para autenticac¸˜
ao
de pesquisadores que desejem usufruir de um grid ou de uma cyberinfrastructure.
Este artigo tem por objetivo descrever e comparar duas abordagens para gerac¸˜
ao
de certificados digitais X.509, a partir da autenticac¸ ˜
ao federada Shibboleth. A primeira
abordagem permite que usu´
arios da federac¸˜
ao, atrav´
es de um navegador web, acessem
um servic¸o confi´
avel (SP Shibboleth) para obter um certificado digital utilizando suas
credenciais institucionais (identidade federada). J´
a a segunda abordagem, possibilita que
usu´
arios, atrav´
es de uma aplicac¸˜
ao n˜
ao web, se autentiquem em provedores de identida-
des estendidos, chamados IdP+, para obterem suas credenciais de autenticac¸ ˜
ao traduzidas
para certificados X.509. Para as duas abordagens, os certificados s˜
ao emitidos por Auto-
ridades Certificadoras on-line e possuem curta durac¸˜
ao de vida (short lived credentials),
conforme os requisitos do perfil definido em [TAGPMA 2009].
O artigo est´
a organizado da seguinte forma. Na Sec¸ ˜
ao 2, s˜
ao descritas as
soluc¸ ˜
oes utilizadas para implantac¸˜
ao de autoridades certificadoras on-line, respons´
aveis
pela emiss˜
ao dos certificados digitais. Na Sec¸˜
ao 3, as duas abordagens propostas para
gerac¸˜
ao de certificados s˜
ao descritas e comparadas, bem como a apresentac¸ ˜
ao dos resul-
tados obtidos com a implementac¸˜
ao destas abordagens. Na Sec¸ ˜
ao 4, os projetos relacio-
nados s˜
ao descritos e comparados com as abordagens desenvolvidas. Por fim, na Sec¸ ˜
ao
5, s˜
ao apresentadas as conclus˜
oes.
3Termo usado pela National Science Foundation (NFS) para representar ambientes de pesquisa (recur-
sos) que proveem suporte, armazenamento, gerenciamento e visualizac¸ ˜
ao de dados avanc¸ados, tais como:
supercomputadores, sistemas de alta capacidade de armazenamento em massa, ferramentas de visualizac¸ ˜
ao
interativa escal´
avel, reposit´
orios de dados em larga escala, sistemas de gerenciamento de dados cient´
ıficos
digitalizados, redes de v´
arias granularidades, etc.
2. Sistemas de Gerenciamento de Certificados Digitais
Um Sistema de Gerenciamento de Certificados ´
e um software respons´
avel pela gest˜
ao
do ciclo de vida de certificados digitais, incluindo a emiss˜
ao e revogac¸˜
ao de certificados.
Nas duas abordagens para gerac¸˜
ao de certificados desenvolvidas neste trabalho, pedidos
de emiss˜
ao de certificados (Certificate Signing Request - CSR) devem ser encaminhados,
de forma segura, para uma autoridade certificadora on-line para que esta possa emitir os
certificados dos usu´
arios da federac¸˜
ao Shibboleth. Duas autoridades certificadoras po-
dem ser utilizadas, uma concebida a partir do Sistema de Gerenciamento de Certificados
Digitais (SGCI)4do projeto ICPEdu [RNP 2012] e a outra a partir do MyProxy5.
O sistema de gerenciamento do MyProxy foi o escolhido devido ao seu amplo uso
na comunidade de grid e em cyberinfrastructure. Tanto os projetos do JISC quanto os da
NSF, citados anteriormente, adotam o MyProxy. Possibilitar que os certificados possam
tamb´
em ser emitidos por uma autoridade certificadora da cadeia de certificac¸˜
ao do servic¸o
ICPEdu se mostrou muito interessante para a RNP, pois algumas de suas instituic¸ ˜
oes
usu´
arias fazem uso deste servic¸o, inclusive a pr´
opria RNP.
2.1. MyProxy
MyProxy6´
e um software de c´
odigo aberto para o gerenciamento de credenciais de
seguranc¸a X.509 PKI (Public Key Infrastructure) que provˆ
e um reposit´
orio de creden-
ciais on-line e uma autoridade certificadora on-line, possibilitando aos usu´
arios obterem
credenciais de forma segura, quando e onde for necess´
ario. As funcionalidades de repo-
sit´
orio de credenciais e de autoridade certificadora podem ser combinadas em um servic¸o
ou podem ser usadas separadamente. Usu´
arios executam o comando myproxy-logon
para se autenticar e obter credenciais, incluindo certificados de autoridades certificadoras
(ACs) confi´
aveis e listas de certificados revogados (Certificate Revocation list - CRLs)
[MyProxy 2012].
O uso do reposit´
orio de credenciais MyProxy permite que usu´
arios obtenham
proxy credentials (RFC 38207), sem que estes precisem se preocupar com a gest˜
ao da
chave privada e com o arquivo do certificado. Os usu´
arios podem usar o MyProxy para
delegar credenciais aos servic¸os que atuam em seu nome, por exemplo, um portal de
grid, armazenando as credenciais no reposit´
orio MyProxy e enviando a senha de acesso
do MyProxy para o servic¸o. Os usu´
arios podem ainda usar o MyProxy para renovar suas
credenciais, por exemplo, quando jobs de longa durac¸˜
ao s˜
ao utilizados. O gerenciamento
profissional de servidores MyProxy podem oferecer um ambiente de armazenamento de
chaves privadas mais seguro que os sistemas usados pelos usu´
arios finais. O MyProxy
pode ser configurado para criptografar todas as chaves privadas armazenadas no repo-
sit´
orio com senhas escolhidas pelo usu´
ario, por´
em, de acordo com pol´
ıticas de qualidade
de senhas aplicadas pelos servidores. Usando o protocolo de delegac¸ ˜
ao de proxy creden-
tial, o MyProxy permite aos usu´
arios obter credenciais sem transferir as chaves privadas
destes atrav´
es da rede [MyProxy 2012].
4https://projetos.labsec.ufsc.br/sgci
5http://grid.ncsa.illinois.edu/myproxy/
6Em Julho de 2012, foi lanc¸ada a vers˜
ao MyProxy 5.9
7X.509 Proxy Certificate Profile [Tuecke et al. 2004].
Para os usu´
arios que ainda n˜
ao tem credenciais X.509, a Autoridade Certifica-
dora MyProxy (MyProxy CA) fornece um m ´
etodo conveniente e seguro para obtˆ
e-las.
AMyProxyCA emite certificados de vida curta8, assinados com a chave da autoridade
certificadora configurada, somente diante de pedidos recebidos de usu´
arios autenticados
(Certificate Signing Request - CSR). Usu´
arios executam o comando myproxy-logon
para se autenticar e obter as credenciais da MyProxy CA, sem necessitar armazenar os
certificados e chaves de vida longa no reposit´
orio de credenciais ou em qualquer lugar.
AMyProxy CA atende aos requisitos do perfil Short Lived Credential Services X.509
Public Key Certification Authorities [TAGPMA 2009] da autoridade de gerenciamento
de pol´
ıticas de Grid das Am´
ericas (The Americas Grid Policy Management Authority),
membro da International Grid Trust Federation (IGTF) [MyProxy 2012].
Um conjunto de mecanismos de autenticac¸˜
ao s˜
ao suportados no MyProxy, dentre
estes destacam-se: senha (passphrase), Kerberos, SAML, OpenID, Virtual Organization
Membership Service (VOMS), Simple Authentication and Security Layer (SASL), Plug-
gable Authentication Modules (PAM), Remote Authentication Dial In User Service (RA-
DIUS), Moonshot eOne Time Passwords (OTP). Mecanismos e pol´
ıticas de autorizac¸˜
ao
implantados no servidor MyProxy podem controlar o acesso `
as credenciais e como estas
podem ser usadas [MyProxy 2012].
A funcionalidade da MyProxy CA requer a configurac¸˜
ao do PAM e/ou do SASL
para suportar autenticac¸˜
ao baseada em senha ou via Kerberos para obter certificados. Via
PAM, o MyProxy pode ser configurado para usar um mecanismo de autenticac¸ ˜
ao externo
- como contas locais, um servidor LDAP remoto, ou senhas OTP - em vez de usar creden-
ciais criptografadas por senhas para verificar a identidade. Via SASL, o MyProxy pode
suportar uma variedade maior de protocolos de autenticac¸˜
ao.
2.2. SGCI
O Sistema de Gerenciamento de Certificados Digitais (SGCI) [LabSEC 2012] da Infra-
estrutura de Chaves P´
ublicas para Ensino e Pesquisa (ICPedu) [RNP 2012] ´
e um software
desenvolvido para o ˆ
ambito acadˆ
emico, em uso em diversas universidades e centros de
pesquisa brasileiros, que permite a implantac¸ ˜
ao e o gerenciamento de Autoridades Cer-
tificadoras (AC) para emiss˜
ao de certificados digitais, provendo as funcionalidades ne-
cess´
arias para o gerenciamento de Infraestruturas de Chaves P´
ublicas (ICPs).
Com o SGCI ´
e poss´
ıvel criar Infraestruturas de Chaves P´
ublicas (ICP) completas,
com AC raiz, ACs intermedi´
arias e Autoridades de Registro (AR). Uma AR ´
e respons´
avel
por verificar informac¸ ˜
oes de identidade dos usu´
arios antes de enviar um pedido de emiss˜
ao
de certificado para a AC. Se h´
a uma relac¸˜
ao de confianc¸a entre a AC e a AR, ent˜
ao a AC
pode emitir o certificado para o usu´
ario conforme o pedido da AR [Silv´
erio et al. 2011].
Na vers˜
ao 2.0.09, o SGCI suporta ACs on-line para envio autom´
atico de pedidos de
emiss˜
ao de certificados. Uma AC on-line pode ser de dois tipos: de resposta manual e de
resposta autom´
atica. ACs on-line de resposta manual exigem que um operador verifique a
emiss˜
ao de certificados manualmente. ACs on-line de resposta autom´
atica emitem certifi-
cados para quaisquer requisic¸ ˜
oes vindas de ARs de confianc¸a. A comunicac¸˜
ao entre uma
8Por padr˜
ao, a MyProxy CA emite certificados com validade de doze horas, por´
em, este parˆ
ametro pode
ser configurado no servidor.
9Vers ˜
ao Beta.
AR e uma AC ´
e padronizada pelo Protocolo de Gerenciamento de Certificados (Certifi-
cate Management Protocol - CMP) especificado na RFC 4210 [Adams et al. 2005]. Esse
protocolo estabelece formatos e mecanismos de transporte para mensagens de emiss˜
ao e
revogac¸˜
ao de certificados, bem como emiss˜
ao de LRCs [Silv´
erio et al. 2011].
As mensagens de requisic¸˜
ao e resposta de emiss˜
ao de certificado entre ARs e ACs
s˜
ao especificadas na RFC4210 por um esquema ASN.1. O SGCI 2.0.0 oferece suporte
a um subconjunto do CMP, utilizando como codificac¸ ˜
ao para as mensagens as regras
de codificac¸˜
ao em XML da ASN.1 (XML Encoding Rules - XER) e o transporte das
mensagens CMP ´
e feito sobre o protocolo HTTP (ou HTTPS) [Silv´
erio et al. 2011].
3. Abordagens para Gerac¸˜
ao de Certificados Digitais
No framework Shibboleth [Shibboleth 2005], a troca informac¸ ˜
oes de autenticac¸˜
ao de
usu´
arios entre provedores de identidades e provedores de servic¸os ´
e feita atrav´
es de
asserc¸ ˜
oes SAML. Al´
em disto, o Shibboleth foi concebido exclusivamente para aplicac¸˜
oes
web, de forma que usu´
arios acessam os recursos, dispostos em servidores web (provedores
de servic¸o), atrav´
es de um navegador web.
O fato de algumas aplicac¸ ˜
oes usadas pela comunidade acadˆ
emica, como por exem-
plo grids, n˜
ao serem web ou por necessitarem de credenciais de seguranc¸a em um formato
diferente do SAML, por exemplo certificados X.509, n˜
ao garantem aos usu´
arios todas as
facilidades trazidas com o modelo de gerenciamento de identidades federadas, cuja prin-
cipal implementac¸˜
ao ´
e o Shibboleth. Neste trabalho, s˜
ao descritas duas abordagens desen-
volvidas no contexto do projeto GT-STCFed da RNP que permitem que estas aplicac¸ ˜
oes
possam usufruir da autenticac¸˜
ao federada do Shibboleth.
3.1. Servic¸o Gerador de Certificados Digitais (SGC)
Em alguns grids ecyberinfrastructure, o usu´
ario interage atrav´
es de clientes baseados em
linha de comando, como por exemplo, GSI-OpenSSH, GridFTP, GRAM (Globus resource
allocation manager) e Condor-G. No caso de acesso por console remoto, o usu´
ario dever´
a
fazer uso de um cliente SSH, sendo que o grid exigir´
a uma credencial de autenticac¸˜
ao
para garantir o acesso deste usu´
ario ao console. Por exemplo, um nome de usu´
ario e
senha ou um certificado digital X.509 de curta durac¸˜
ao emitido por uma Autoridade Cer-
tificadora espec´
ıfica. O uso de credencias X.509 ´
e a forma mais recomendada e utilizada
para autenticac¸˜
ao de pesquisadores que desejam usufruir de grids e de cyberinfrastructure
[Basney et al. 2010, Barnett et al. 2011].
A gerac¸˜
ao de certificados digitais de curta durac¸ ˜
ao em ambientes dinˆ
amicos e de
larga escala, conforme o perfil definido em [TAGPMA 2009] s´
o consegue ser operaciona-
lizada atrav´
es Autoridades Certificadoras On-line (AC), como exposto na Sec¸˜
ao 2. A AC
pode possuir uma base de usu´
arios, para quem emitir´
a certificados, ou a AC pode fazer
parte de uma federac¸˜
ao Shibboleth e confiar nas informac¸ ˜
oes fornecidas pelos provedores
de identidades desta federac¸˜
ao. A segunda opc¸˜
ao ´
e ideal para ambientes dinˆ
amicos e de
larga escala e traz mais benef´
ıcios para os usu´
arios, pois estes n˜
ao precisam realizar e
manter cadastros individuais em cada AC (gerenciar m´
ultiplas identidades).
Segundo [Barnett et al. 2011], de forma a contribuir com a interoperabilidade
e usabilidade, os grids e cyberinfrastructure de organizac¸ ˜
oes nacionais, estaduais e
acadˆ
emicas deveriam adotar um ´
unico e aberto sistema de gest˜
ao de identidades para
prover a autenticac¸˜
ao de seus usu´
arios, sendo, neste documento, especificamente reco-
mendado o uso do framework Shibboleth. Com a adoc¸˜
ao de identidades federadas, os
projetos de cyberinfrastructure n˜
ao precisam implantar seus pr´
oprios sistemas de gest˜
ao
de identidades e podem se beneficiar da usabilidade da autenticac¸˜
ao via Shibboleth.
Na abordagem proposta, o Servic¸o Gerador de Certificados (SGC) ´
e uma
aplicac¸˜
ao web, hospedada em um provedor de servic¸os Shibboleth, que tem por obje-
tivo permitir que usu´
arios possam usufruir dos benef´
ıcios da federac¸˜
ao para a emiss˜
ao de
certificados digitais por uma AC on-line. O SGC possui uma relac¸ ˜
ao de confianc¸a com
a AC e esta s´
o aceita requisic¸ ˜
oes para emiss˜
ao de certificados que forem originadas por
este servic¸o. Este requisito, al´
em de aumentar a seguranc¸a, torna o modelo adequado
para ambientes dinˆ
amicos e de larga escala, pois a AC s´
o precisa estabelecer uma ´
unica
relac¸˜
ao de confianc¸a e todos os usu ´
arios da federac¸˜
ao usufruem da mesma. Sendo assim,
o usu´
ario interage com o servic¸o e ´
e este ´
ultimo que envia a requisic¸˜
ao para emiss˜
ao de
certificado. Por fim, o servic¸ o retorna ao usu´
ario o certificado que fora emitido.
O Servic¸o Gerador de Certificados pode utilizar como autoridades certificadoras
on-line, uma AC online de resposta autom´
atica concebida com o software SGSI 2.0 e um
AC on-line do tipo MyProxy. Quando a AC SGSI ´
e utilizada, o SGC assume o papel
de uma AR (autoridade de registro da ICPEdu) e todas as trocas entre o Servic¸o e `
a AC
passam a ser realizadas pelo protocolo CMP, conforme descrito na Sec¸ ˜
ao 2. Vale destacar
que uma relac¸˜
ao de confianc¸a precisa ser estabelecida previamente entre o Gerador de
Certificados e a AC SGSI. Quando o software MyProxy CA ´
e utilizado, o SGC executa
o aplicativo myproxy-logon para solicitar o certificado `
a CA. O Myproxy CA verifica se
o usu´
ario para quem est´
a sendo solicitado a emiss˜
ao de certificados est´
a presente em sua
base de dados (LDAP) e retorna o certificado gerado.
Como explicitado na Sec¸˜
ao 2, a requisic¸ ˜
ao para gerac¸˜
ao de certificados deve ser
assinada com a chave privada correspondente `
a chave p´
ublica que est´
a contida na pr´
opria
requisic¸˜
ao. ´
E desta forma que a AC garante que estar´
a emitindo um certificado para o
detentor da chave privada. Como esta requisic¸ ˜
ao ´
e encaminhada pelo Servic¸o Gerador de
Certificados `
a AC, e n˜
ao pelo usu´
ario, ´
e necess´
ario que: (1) o usu´
ario fornec¸a o Certificate
Signing Request (CSR) ao SGC; ou (2) o pr´
oprio SGC gere o CSR em nome do usu´
ario.
Para a opc¸˜
ao (2), o SGC tamb´
em deve ter acesso ao par de chaves do usu´
ario,
podendo este ter sido encaminhado pelo usu´
ario ou o pr´
oprio SGC deve gerar este par de
chaves. O fato do Servic¸o Gerador de Certificado ser um intermedi´
ario entre o usu´
ario
final e a AC, causa fragilidades no modelo de confianc¸a, pois n˜
ao ´
e poss´
ıvel garantir a
propriedade de seguranc¸a de n˜
ao-rep´
udio por parte do usu´
ario, haja visto que o usu´
ario
pode alegar que o Servic¸o Gerador de Certificados possui completa autonomia para agir
em seu nome, pois teve acesso a sua chave privada, sem que este tenha controle ou mesmo
sem que este possa rastrear tal ato. Diante desta an´
alise, a opc¸ ˜
ao adotada no servic¸o
proposto foi a de o usu´
ario gerar o par de chaves assim´
etricas, montar o CSR localmente
e encaminh´
a-lo ao Servic¸o Gerador de Certificado (opc¸ ˜
ao 1).
Uma das motivac¸ ˜
oes para a criac¸˜
ao do Servic¸o Gerador de Certificados, foi usu-
fruir da usabilidade oferecida aos usu´
arios da federac¸˜
ao no processo de autenticac¸˜
ao.
Seguindo esta linha, o processo para gerac¸ ˜
ao do par de chaves do usu´
ario localmente
tamb´
em deve ser facilitado para o usu´
ario. Definiu-se como requisito que o usu´
ario deve
usar o navegador web para gerar do par de chaves, gerar e encaminhar o CSR e receber
o certificado gerado pela AC. A soluc¸˜
ao tamb´
em deve ser compat´
ıvel com os principais
navegadores web e sistemas operacionais para computadores pessoais.
Diante destes requisitos, duas soluc¸ ˜
oes tecnol´
ogicas foram avaliadas: (1) rotinas
em JavaScript que s˜
ao executadas localmente no navegador do usu´
ario combinadas ao uso
de HTML 5 e (2) uma aplicac¸˜
ao em Java Web Start (JWS), que permite instalar e iniciar
aplicativos Java direto de um navegador web10. Rotinas em Javascripts s˜
ao altamente
dependentes do navegador e do sistema operacional o que demanda o desenvolvimento de
diversas rotinas ou vers˜
oes, bem como mantˆ
e-las. Por estes motivos, a aplicac¸˜
ao JWS, que
oferece portabilidade e uma manutenc¸˜
ao mais simples, mostrou-se como a mais adequada
para o servic¸o proposto.
Grid
Aplicação
não Shibboleth
Aplicação
não Shibboleth
Navegador
Web
Usuário da
Federação Shibboleth
Usuário da
Federação Shibboleth
ICPEdu
ICPEdu
SGCI
IdP
Federação
Shibboleth
Federação
Shibboleth
Gerador de
Certificados
JWS
1
2
3
4
5
6
7
8
Cliente
SSH
SSH
SSH
9
10
Figura 1. Acesso a uma aplicac¸ ˜
ao n˜
ao Shibboleth que requer certificados X.509
A Figura 1 ilustra os passos para que um usu´
ario de uma federac¸˜
ao Shibboleth
acesse um grid, uma aplicac¸ ˜
ao n˜
ao Shibboleth, que exige um certificado X.509 emitido
por uma Autoridade Certificadora (AC) SGCI da ICPedu [RNP 2012]. No passo 1, o
usu´
ario tenta acessar o Servic¸o Gerador de Certificados, que por ser um SP Shibboleth,
exige que o usu´
ario se autentique em um IdP da Federac¸˜
ao. Ap´
os indicar o seu IdP, o na-
vegador do usu´
ario ´
e redirecionado para o IdP para que o usu´
ario proceda a autenticac¸˜
ao
(passo 2). Ap ´
os autenticac¸˜
ao bem sucedida, no passo 3, o navegador do usu´
ario ´
e redire-
cionado para o SGC que apresenta para o usu´
ario o DN (Distinguished Name) que estar´
a
em seu certificado X.509 e informa a URL para download da aplicac¸˜
ao JWS (passo 4).
No passo 5, o usu´
ario fornece a senha que ser´
a usada para proteger a chave privada. Em
seguida, a aplicac¸˜
ao JWS gera o par de chaves, monta o pedido de certificado (CSR) e o
encaminha ao SGC (passo 6). No passo 7, o CSR ´
e encaminhado `
a AC SGSI para que
esta emita o certificado. No passo 8, o certificado gerado ´
e encaminhado para o usu´
ario,
10O software Java Web Start ´
e iniciado automaticamente quando ´
e feito o primeiro download de um
aplicativo Java que utiliza essa tecnologia. O Java Web Start armazena todo o aplicativo localmente, na
mem´
oria cache do computador. Assim, todas as inicializac¸ ˜
oes subsequentes s˜
ao quase instantˆ
aneas, pois
todos os recursos necess´
arios j´
a est˜
ao dispon´
ıveis localmente.
Figura 2. Mapeamento do Distinguished Name (DN) do sujeito do certificado
que deve indicar o caminho em disco no qual o arquivo ser´
a salvo (passo 9). ´
E importante
observar que o usu´
ario receber´
a o certificado no formato PKCS#12, sendo que a chave
privada estar´
a protegida pela senha digitada no passo 5. Por fim, o usu´
ario, atrav´
es de
uma aplicac¸˜
ao cliente11, acessa a grid, fazendo uso do certificado recebido (passo 10).
No Servic¸o Gerador de Certificados, ap ´
os a autenticac¸˜
ao do usu´
ario em seu pro-
vedor de identidades (IdP), os atributos do usu´
ario s˜
ao enviado para o servic¸o atrav´
es de
asserc¸ ˜
oes SAML emitidas pelo IdP. Tais atributos, pertencentes ao conjunto de atributos
comuns da Federac¸˜
ao CAFe12 da RNP [RNP 2009], devem ser mapeados para compor
os campos do Distinguished Name (DN) do sujeito do certificado, conforme indicado na
Figura 2. De forma a tratar os poss´
ıveis homˆ
onimos, a abordagem recomenda o uso do
atributo eduPersonPrincipalName (eppn) ou do atributo mail do esquema brEduPerson
[RNP 2009]. ´
E importante observar que o mapeamento dos atributos da asserc¸˜
ao SAML
para os campos do DN do sujeito podem ser facilmente configurados no SGC. J´
a o Dis-
tinguished Name (DN) do emissor do certificado deve ser configurado nas Autoridades
Certificadoras On-line suportadas no servic¸o proposto, conforme ilustrado na Figura 3.
Figura 3. Mapeamento do Distinguished Name (DN) do emissor do certificado
3.2. IdP+: Provedor de Identidades com Suporte a Gerac¸ ˜
ao de Certificados Digitais
A abordagem apresentada na Sec¸˜
ao 3.1, apesar de permitir aos usu´
arios da federac¸˜
ao
interagirem com aplicac¸ ˜
oes n˜
ao Shibboleth, esta exige que a interac¸ ˜
ao do usu´
ario com
o Servic¸o Gerador de Certificados seja feita atrav´
es de um navegador web. Este tipo
de funcionamento impossibilita que aplicac¸ ˜
oes desktop, que necessitem autenticar seus
usu´
arios, usufruam das facilidades da federac¸˜
ao.
11Aplicac¸ ˜
ao GSI-Putty (www.ngs.ac.uk/research-and-development/gsi-putty)
12http://www.rnp.br/servicos/cafe.html
Na segunda abordagem proposta, o provedor de identidades com suporte a gerac¸˜
ao
de certificados, denominado IdP+, consiste de um IdP com as mesmas habilidades do
Servic¸o Gerador de Certificados, por´
em com funcionalidades adicionais que permitem
que aplicac¸ ˜
oes n˜
ao web usufruam dos benef´
ıcios da autenticac¸˜
ao federada Shibboleth.
Ou seja, o IdP+ pode ser acessado atrav´
es de um navegador web ou n˜
ao.
Visando garantir a interoperabilidade e assim atender uma gama maior de
aplicac¸ ˜
oes, o IdP+ segue a arquitetura orientada a servic¸os e est´
a baseado nas principais
especificac¸ ˜
oes relacionadas aos Servic¸os Web. O IdP+ consiste de um IdP padr˜
ao do fra-
mework Shibboleth acrescido da implementac¸˜
ao do Secure Token Service (STS), definido
pela especificac¸˜
ao WS-Trust [OASIS 2009], do Credential Translation Service (CTS),
respons´
avel por realizar a traduc¸˜
ao de credenciais de diferentes tecnologias e de uma
aplicac¸˜
ao web, utilizada quando um usu´
ario, via um navegador web, solicita a gerac¸˜
ao de
um certificado digital (ver cen´
ario de uso ilustrado na Figura 4).
O Security Token Service (STS) consiste de um Servic¸o Web que tem como
func¸ ˜
oes emitir e validar credenciais de seguranc¸a, de acordo com as especificac¸ ˜
oes WS-
Trust , WS-Security e WS-Policy. ´
E importante ressaltar que o servic¸o STS atua como ga-
teway confi´
avel entre provedores de identidade de uma federac¸˜
ao Shibboleth e aplicac¸ ˜
oes
n˜
ao web. O Credential Translation Service (CTS), por sua vez, trata de aspectos de
traduc¸˜
ao de credenciais entre diferentes tecnologias de seguranc¸a e ´
e sempre invocado
pelo STS quando a aplicac¸˜
ao requer uma credencial de seguranc¸a diferente da usada pela
federac¸˜
ao (p. ex. certificados X.509). A aplicac¸ ˜
ao web ´
e a mesma do Servic¸o Gerador de
Certificados apresentado na Sec¸˜
ao 3.1, por´
em ´
e disponibilizada no mesmo contˆ
einer web
do IdP+ e n˜
ao em um SP separado.
A gerac¸˜
ao de certificados digitais X.509, emitidos por uma AC on-line, a partir das
asserc¸ ˜
oes SAML, segue o mesmo conceito apresentado na Sec¸˜
ao 3.1. A AC, que pode
ser do tipo MyProxy CA ou uma AC on-line de resposta autom´
atica SGSI, deve possuir
relac¸ ˜
oes de confianc¸a com os IdP+ da federac¸ ˜
ao e somente estes poder˜
ao encaminhar
requisic¸ ˜
oes para emiss˜
ao de certificados.
Grid
IdP
STS
CTS
Federação
Shibboleth
Federação
Shibboleth
2
3
1
Navegador
Web
Cliente
SSH
SSH
SSH
Aplicação
não Shibboleth
Aplicação
não Shibboleth
Usuário da
Federação Shibboleth
Usuário da
Federação Shibboleth
IdP+
MyproxyCA
4
5
SGC
Figura 4. Gerac¸ ˜
ao de Credenciais X.509 com o IdP+
A Figura 4 apresenta os passos simplificados para um usu´
ario, atrav´
es de seu na-
vegador web, obter um certificado digital necess´
ario para acessar um grid, a partir de uma
aplicac¸˜
ao web que se encontra em seu IdP+. O cen´
ario ´
e semelhante ao apresentado na
Figura 1. No passo 1, o usu´
ario, tenta acessar a aplicac¸ ˜
ao web para gerac¸˜
ao de certifi-
cados, como n˜
ao est´
a autenticado, este ´
e redirecionado para a p´
agina de autenticac¸˜
ao do
IdP+. Ap´
os autenticac¸˜
ao bem sucedida, a asserc¸ ˜
ao SAML ´
e disponibilizada ao CTS para
que este conduza o processo de traduc¸ ˜
ao de credencial. Este processo segue as mesmas
regras de mapeamento ilustradas nas Figuras 2 e 3. A aplicac¸˜
ao web recebe do CTS o DN
do certificado digital, o apresenta para o usu´
ario e indica a URL para baixar a aplicac¸˜
ao
JWS. Em seguida, a aplicac¸˜
ao web insere o DN do certificado do usu´
ario em quest˜
ao em
uma base de dados LDAP que o MyProxy CA usa para gerar os certificados. De forma se-
melhante a abordagem da Sec¸˜
ao 3.1, a aplicac¸ ˜
ao JWS gera o par de chaves na m´
aquina do
usu´
ario, monta o pedido de certificado (CSR) e reencaminha o pedido ao IdP+ (aplicac¸ ˜
ao
web). No passo 2, o IdP+ encaminha o pedido `
a Autoridade Certificadora, neste exemplo
oMyProxy CA (Ver Sec¸˜
ao 2.1). O MyProxy CA verifica se o usu´
ario para quem est´
a sendo
solicitado a emiss˜
ao de certificados est´
a presente em sua base de dados e retorna o certi-
ficado gerado (passo 3). No passo 4, a aplicac¸˜
ao web do IdP+ disponibiliza o certificado
para que o usu´
ario possa fazer o download em seu computador. Por fim, o usu ´
ario acessa
ogrid usufruindo do certificado recebido (passo 5).
A base LDAP instalada junto ao MyProxy CA foi configurada para aceitar somente
conex˜
oes sob o SSL/TLS. Diferentes IdPs+ ter˜
ao acesso de escrita a essa base, apresen-
tando nome de usu´
ario e senha, e assim foram criadas listas de controle de acesso (Access
Control List – ACL) a fim de evitar que um IdP+ possa ver e/ou modificar as entradas
feitas por outros IdPs+. Foi desenvolvido um servic¸o de configurac¸ ˜
ao13 para permitir
que cada administrador de IdP+, que tenha interesse em prover gerac¸˜
ao de certificados
digitais, possa criar seu nome de usu´
ario e senha nesta base LDAP.
A Figura 5 ilustra um cen´
ario de uso de uma aplicac¸˜
ao n˜
ao web (aplicac¸˜
ao ICE)
solicitando a gerac¸˜
ao de um certificado digital. A aplicac¸ ˜
ao desktop ICE, desenvolvida
pelo projeto MonIP ˆ
E14,´
e usada para visualizac¸˜
ao de dados de monitoramento de redes
do projeto perfSONAR15, o qual est´
a baseado em uma arquitetura orientada a servic¸os. A
aplicac¸˜
ao ICE original realiza a autenticac¸˜
ao de seus usu´
arios de forma isolada, cabendo
aos administradores desta ferramenta gerenciar tal base. A aplicac¸ ˜
ao ICE precisou ser
estendida para que pudesse interagir com o IdP+ e assim permitir a autenticac¸˜
ao federada
de usu´
arios.
Conforme ilustrado na Figura 5, o perfSONAR possui um Servic¸o de Autenticac¸ ˜
ao
(Authentication Service), o qual consiste em um Servic¸o Web que consome asserc¸ ˜
oes
SAMLv1 ou certificados X.509 para garantir a autenticac¸˜
ao e autorizac¸˜
ao dos usu´
arios
para os demais servic¸os de monitoramento. A autenticac¸˜
ao se d´
a pela confianc¸a no emis-
sor da asserc¸˜
ao ou na AC on-line do certificado X.509. No passo 1 da Figura 5, o usu´
ario
faz sua autenticac¸˜
ao junto ao IdP+, atrav´
es da pr´
opria aplicac¸˜
ao ICE, isto ´
e, n˜
ao ´
e feito
uso de navegador web. O IdP+ solicita a uma AC on-line a emiss˜
ao de um certificado
13Este servic¸o de configurac¸ ˜
ao ´
e um SP Shibboleth e somente usu´
arios com atributo de administrador do
IdP+ poder˜
ao acess´
a-lo.
14Um servic¸o da RNP – http://www.monipe.rnp.br
15http://www.perfsonar.net
IdP
Federação
Shibboleth
Federação
Shibboleth
Aplicação
não Shibboleth
Aplicação
não Shibboleth
IdP+
ICE
Desktop
perfSONAR
Usuário da
Federação Shibboleth
Usuário da
Federação Shibboleth
AS
1
2
3
4
CA
confiança
STS
CTS
Figura 5. Gerac¸ ˜
ao de Certificados Digitais atrav´
es da interface STS do IdP+
digital para o usu´
ario e o entrega a aplicac¸˜
ao ICE (passo 2). No passo 3, a aplicac¸ ˜
ao ICE
invoca o servic¸o perfSONAR, j´
a com o certificado digital recebido. Por fim, o AS verifica
se o certificado fora emitido por uma AC online com quem possui relac¸˜
ao de confianc¸a e
verifica se o usu´
ario possui os atributos necess´
arios para garantir o acesso.
De forma semelhante ao cen´
ario de uso da Figura 4, o CTS ´
e usado para que as
asserc¸ ˜
oes SAML, emitidas pelo IdP+, possam ser mapeadas para certificados digitais e ´
e
este componente que interage com a AC on-line para emiss˜
ao do certificado. ´
E impor-
tante destacar que, a aplicac¸ ˜
ao ICE ´
e uma aplicac¸˜
ao desktop que n˜
ao possui mecanismos
para interagir diretamente com o IdP padr˜
ao do Shibboleth. Logo, a aplicac¸˜
ao ICE, para
usufruir da autenticac¸˜
ao federada, interage com o IdP+ via interface de Servic¸o Web do
STS.
3.3. An´
alise das Abordagens Desenvolvidas
As abordagens apresentadas na Sec¸ ˜
oes 3.1 e 3.2 s˜
ao complementares e adequadas para
diferentes necessidades. A disponibilizac¸ ˜
ao do Servic¸o Gerador de Certificados (SGC)
em um provedor de servic¸o ´
e a abordagem mais pr´
oxima do modelo de governanc¸a da
Comunidade Acadˆ
emica Federada (CAFe) da RNP. Nesta abordagem, o usu´
ario fornece
seu nome de usu´
ario e senha atrav´
es da interface web do seu provedor de identidade e o
par de chaves ´
e gerado localmente na m´
aquina do usu´
ario. Na abordagem com o IdP+,
apesar do usu´
ario s´
o fornecer os dados ao seu provedor de identidade, isto pode tamb´
em
ser feito atrav´
es da p´
agina web do provedor de identidade, como atrav´
es de uma invocac¸˜
ao
do Servic¸o Web.
O Servic¸o Gerador de Certificados pode ser disponibilizado por cada uma das
instituic¸ ˜
oes pertencentes a federac¸˜
ao CAFe ou pode ser um Servic¸o da gestora da
federac¸˜
ao (RNP), que pode ser respons´
avel por oferecer este servic¸o a todos os usu´
arios
da federac¸˜
ao, constituindo assim um ´
unico Servic¸o para toda a federac¸ ˜
ao. A vantagem
de centralizar um ´
unico Servic¸o para a federac¸ ˜
ao est´
a no gerenciamento das relac¸ ˜
oes de
confianc¸a com as Autoridades Certificadoras, trazendo ao modelo a habilidade de ope-
rar em ambientes de larga escala. Por outro lado, a centralizac¸ ˜
ao tira a liberdade das
instituic¸ ˜
oes em estabelecer relac¸ ˜
oes de confianc¸a bilaterais com ACs espec´
ıficas e n˜
ao
atrativas para toda a federac¸˜
ao. De qualquer forma, a abordagem apresentada na Sec¸ ˜
ao
3.1 permite que existam um ou mais Servic¸o Gerador de Certificados na federac¸ ˜
ao, aten-
dendo assim ambas as necessidades.
De acordo com as regras de governanc¸a da federac¸ ˜
ao CAFe, uma instituic¸ ˜
ao
para ingressar na federac¸˜
ao precisa disponibilizar um IdP, ou seja, n˜
ao ´
e requisito que
a instituic¸˜
ao tamb´
em disponibilize um provedor de servic¸os (SP). Sendo assim, toda
instituic¸˜
ao participante da CAFe obrigatoriamente possui um IdP, mas n˜
ao necessaria-
mente um SP. Supondo que a instituic¸ ˜
ao tenha interesse em um servic¸o gerador de cer-
tificados, mas a federac¸ ˜
ao n˜
ao oferec¸a tal servic¸o e a instituic¸ ˜
ao n˜
ao tenha interesse em
disponibilizar um SP, a escolha ideal seria a implantac¸ ˜
ao do IdP+.
O fato do IdP+ ser um complemento do IdP, apresenta um n ´
umero menor de re-
quisitos para instalac¸˜
ao, culminando tamb´
em uma menor complexidade para implantac¸˜
ao
e gerenciamento. Por ´
em, para as instituic¸ ˜
oes que j´
a est˜
ao na CAFe e j´
a possuem IdPs em
produc¸˜
ao, estas precisar˜
ao implantar as modificac¸ ˜
oes necess´
arias para ser um IdP+. Esta
abordagem teria como vantagem a permiss˜
ao de estabelecimento de relac¸ ˜
oes de confianc¸a
bilaterais com ACs, por´
em perdendo a habilidade de operar em ambientes de larga escala.
O usu´
ario continua fornecendo suas informac¸ ˜
oes sens´
ıveis somente ao IdP+, o que n˜
ao
fere o modelo de governanc¸a da federac¸ ˜
ao CAFe. Por fim, o IdP+ por possuir um Servic¸o
Web abre a possibilidade para que aplicac¸ ˜
oes desktop possam usufruir das facilidades da
federac¸˜
ao.
4. Trabalhos Relacionados
Diversos projetos surgiram para interligar o Shibboleth com a tecnologia de autenticac¸˜
ao
comumente usada em grids, as credencias X.509. Dentre estes, destacam-se os proje-
tos do Joint Information Systems Committee (JISC) da Gr˜
a-Bretanha, que visam permi-
tir que usu´
arios autenticados por IdPs Shibboleth confi´
aveis obtenham credenciais tem-
por´
arias para acessar recursos do National Grid Service (NGS) da Gr˜
a-Bretanha (Shib-
Grid/Shebangs/Sarongs). O GridShib ´
e outro importante projeto que integra o Shibboleth
ao modelo computacional de grid e foi desenvolvido a partir de uma motivac¸˜
ao dife-
rente dos projetos do JISC. A principal motivac¸˜
ao deste projeto ´
e estender o modelo
de autorizac¸˜
ao do Globus Toolkit para que atributos Shibboleth possam ser utilizados
para autorizac¸˜
ao em grids constru´
ıdos com o Globus. Dentre os projetos mais recentes,
destacam-se o CILogon e o go.teragrid, ambos financiados pela National Science Foun-
dation (NSF). A seguir, tem-se uma descric¸˜
ao a an´
alise destas iniciativas.
4.1. Projeto GridShib
O projeto GridShib foi criado em 2004 com o apoio da National Science Foudation (NSF)
para introduzir um modelo de autorizac¸˜
ao baseado em atributos no Globus toolkit. O
GridShib permite que o Globus Toolkit (GT) e o Shibboleth interoperem. Neste caso, um
par de plug-ins de software, um para o Globus Toolkit e outro para o Shibboleth, permitem
que um GT Grid Service Provider (SP) solicite atributos de um usu´
ario a um provedor de
identidade (IdP) Shibboleth[Scavo and Welch 2007].
O GridShib possui dois modos de operac¸˜
ao: push epull. No modo pull, o cli-
ente ao acessar um grid SP, tamb´
em fornece seu certificado digital X.509. O grid SP
autentica o pedido e extrai o DN (distinguished name) das credenciais X.509 recebi-
das. Se autenticac¸ ˜
ao ocorrer com sucesso, o grid SP solicita mais atributos ao IdP do
pr´
oprio dom´
ınio administrativo do cliente. O IdP, ou mais especificamente, a autoridade
de atributos do IdP, autentica a solicitac¸ ˜
ao de atributos, mapeia o DN para um nome local
utilizando o plugin GridShib for Shibboleth, recupera os atributos para o cliente (conve-
nientemente filtrados pela pol´
ıtica de liberac¸˜
ao de atributos do Shibboleth), formula uma
asserc¸˜
ao de atributos e a envia ao grid SP. O grid SP analisa a asserc¸˜
ao de atributos, ar-
mazena os atributos, toma uma decis˜
ao de controle de acesso, processa a solicitac¸ ˜
ao do
cliente (assumindo que o acesso est´
a concedido) e devolve uma resposta para o cliente
[Scavo and Welch 2007].
No modo push, o pr ´
oprio cliente obt´
em os atributos SAML e os apresenta ao
grid SP no momento da requisic¸˜
ao. Isto ´
e feito atrav´
es de um proxy certificate que em-
bute uma asserc¸˜
ao de atributos SAML. Neste caso, foi desenvolvido no projeto o soft-
ware GridShib SAML Tools que emite asserc¸ ˜
oes SAML e as embute em proxy certificates
[Scavo and Welch 2007]. Deve-se destacar que a forma como o cliente obt´
em os atri-
butos SAML n˜
ao s˜
ao especificadas no GridShib, ou seja, n˜
ao h´
a uma aplicac¸˜
ao cliente
para que usu´
ario se autentique no IdP e receba a asserc¸˜
ao SAML de forma segura. Esta
limitac¸˜
ao ´
e decorrente na inviabilidade de uma aplicac¸˜
ao n˜
ao Web de se autenticar em um
IdP Shibboleth.
4.2. Projetos da Joint Information Systems Committee (JISC)
Com um prop´
osito diferente do GridShib, os projetos conduzidos pelo JISC, permitem
o uso mecanismo de autenticac¸˜
ao federada do Shibboleth para acessar um grid service
ou um grid portal. Nestes projetos, as credenciais de acesso ao grid (X.509 proxy cer-
tificates) s˜
ao geradas dinamicamente. Vale ressaltar que estes projetos, ao contr´
ario do
GridShib, n˜
ao modificam o mecanismo de autenticac¸˜
ao do Shibboleth e nem o grid tool-
kit. Um servic¸o intermedi´
ario, chamado CTS (Credential Translation Service), foi intro-
duzido para traduzir credenciais Shibboleth em credenciais GSI tempor´
arias (X.509 proxy
certificates). Estes certificados s˜
ao chamados de low assurance certificates e assinados
por autoridades certificadoras on-line, as quais geram certificados de autenticac¸ ˜
ao base-
ados em um m´
etodo eletrˆ
onico que n˜
ao necessita de uma identificac¸ ˜
ao fotogr´
afica para
representar um humano e outras burocracias. A durac¸ ˜
ao m´
axima destes certificados ´
e de
um milh˜
ao de segundos [Spence et al. 2006].
OShibGrid, desenvolvido entre fevereiro de 2006 a janeiro de 2007, foi o pri-
meiro projeto do JISC e teve como objetivo apresentar somente um prot´
otipo. O SHE-
BANGS (Shibboleth Enabled Bridge to Access the National Grid Service) surgiu como
uma soluc¸˜
ao mais consolidada para o problema. No desenvolvimento deste projeto, o
seguinte cen´
ario foi considerado: “Um usu ´
ario final, pertencente a uma organizac¸˜
ao que
possui um IdP Shibboleth, deseja acessar alguns recursos ou servic¸os provisionados no
National Grid Service (NGS) da Gr˜
a-Bretanha. Al´
em disso, assume-se que o usu´
ario final
(a) n˜
ao possui um certificado digital do tipo normalmente exigido para acessar o NGS,
(b) n˜
ao tem qualquer treinamento em computac¸˜
ao em grid, (c) n˜
ao tem instalado qualquer
software cliente para acessar o grid, e (d) pertence a uma organizac¸˜
ao virtual (VO- virtual
organization) que ´
e reconhecida pelo NGS e cujos membros herdam direitos para usar
recursos do NGS”.
No projeto SHEBANGS, foi desenvolvido um servic¸o tradutor de credenciais
(CTS- Credential Translation Service) que traduz as credenciais Shibboleth em cre-
denciais X.509 de curta durac¸˜
ao e compat´
ıveis com as credenciais VOMS. O Virtual
Organization Membership Service (VOMS) ´
e um sistema para gerenciar dados de
autorizac¸˜
ao em colaborac¸ ˜
oes multi-institucionais. O servic¸ o fornece uma base de da-
dos de pap´
eis de usu´
ario, suas competˆ
encias e um conjunto de ferramentas para aces-
sar e manipular o banco de dados para gerar as credenciais de Grid para usu´
arios
[Jones and S.Pickles 2007]. No SHEBANGS, o CTS atua como um SP Shibboleth, como
uma AC online e como um cliente de um reposit´
orio de credenciais MyProxy.
No CTS, o mapeamento entre os atributos de identidade em SAML e no-
mes X.500, por exemplo o distinguished name (DN), n˜
ao ´
e uma tarefa trivial
[Jones and S.Pickles 2007]. A especificac¸˜
ao SAML fornece uma s´
erie de esquemas para a
identificac¸˜
ao de indiv´
ıduos, mas a computac¸ ˜
ao em grid n˜
ao lida bem com indiv´
ıduos com
m´
ultiplas identidades. Em grid, um usu´
ario final que possui diferentes nomes ser´
a tratado
como diferentes indiv´
ıduos. Em [Jones and S.Pickles 2007] ´
e apresentado um algoritmo
que descreve o mapeamento para criac¸˜
ao das credenciais.
O n´
ıvel de garantia (Level of Assurance – LoA) permite a um grid service to-
mar decis˜
oes de autenticac¸˜
ao baseado nas garantias oferecidas pelo IdP. Essas garantias
s˜
ao fornecidas nas asserc¸ ˜
oes SAML emitidas pelo IdP. Grid services com alto grau de
seguranc¸a podem exigir somente credenciais assinadas por AC com alto grau de confiabi-
lidade. Por outro lado, alguns grid services que n˜
ao executam aplicac¸ ˜
oes cr´
ıticas, podem
garantir o acesso a um usu´
ario que tenha credencial de autenticac¸˜
ao com um n´
ıvel razoal-
vemente baixo. Por este motivo, o uso de m´
ultiplas AC ´
e a pr´
atica que melhor se adapta
a comunidade de grid [Jones and S.Pickles 2007].
O projeto SHEBANGS foi finalizado em junho de 2007 e o JISC deu in´
ıcio a
um outro projeto chamado SARoNGS (Shibboleth Access for Resources on the National
Grid Service), o qual passou a se ocupar da integrac¸ ˜
ao Shibboleth e infraestruturas ba-
seadas no X.509. O objetivo deste projeto ´
e combinar as vantagens do SHEBANGS e
do ShibGrid, por´
em, ao contr´
ario dos projetos anteriores considerados de demonstrac¸ ˜
ao,
visa oferecer um servic¸o de produc¸ ˜
ao para ser utilizado no NGS. No projeto SARoNGS,
o usu´
ario usufrui da arquitetura desenvolvida para acessar o portal NGS atrav´
es de um
navegador web. Assim como no projeto anterior, o SARoNGS faz uso de um servic¸o inter-
medi´
ario confi´
avel, o CTS, implantado como um SP Shibboleth, para realizar a traduc¸˜
ao
das asserc¸ ˜
oes SAML para o certificados X.509. Por´
em, para emiss˜
ao das credencias tem-
por´
arias X.509, este faz uso de um servidor MyProxy CA modificado, como desenvolvido
no projeto ShibGrid. Al´
em disso, o CTS tamb´
em interage com um servidor VOMS para
obter uma credencial de atributos VOMS 16. Por fim, o SARoNGS delega as credencias
do usu´
ario para o reposit´
orio de credencias MyProxy para prover facilidades no acesso ao
Portal NGS.
4.3. Projeto de Logon Federado para o TeraGrid/XSEDE)
O site https://go.teragrid.org/ permite aos usu´
arios acessarem os recursos do
XSEDE17 (anteriormente TeraGrid) usando o mecanismo de autenticac¸˜
ao federada forne-
cido por sua universidade. Somente os usu´
arios de recursos ativos do projeto XSEDE po-
dem usar este site. O sistema de autenticac¸˜
ao federada do TeraGrid [Basney et al. 2010] ´
e
16Um certificado de atributos X.509 emitido pela servidor VOMS para o sujeito do certificado digital.
17The Extreme Science and Engineering Discovery Environment (XSEDE) ´
e financiado pela NSF e
substitui e amplia o projeto TeraGrid
uma aplicac¸˜
ao web para o servidor Apache HTTPD e que faz uso das funcionalidades de-
senvolvidas no projeto GridShib para converter credenciais Shibboleth em certificados. A
aplicac¸˜
ao web liga um identidade federada de campus a uma identidade TeraGrid/XSEDE
via uma base de dados de ligac¸˜
ao de contas.
O funcionamento consiste dos seguintes passos. Primeiro, o pesquisador visita
o site e seleciona, em uma lista, o provedor de identidade de seu campus e realiza o
processo de autenticac¸˜
ao neste. A aplicac¸ ˜
ao redireciona o navegador para a p´
agina de
login do TeraGrid para que o pesquisador fac¸a o login no sistema e assim ligue as contas
de seu IdP com a sua conta no TeraGrid (esta operac¸˜
ao deve ser feita apenas uma vez).
Ap´
os o login, a aplicac¸ ˜
ao indica ao usu´
ario que este pode fazer o download do certificado
e, atrav´
es de um aplicativo Java Web Start, acessar ao recurso via uma aplicativo desktop
(GSI-SSH terminal applet), ou que este pode acessar o recurso do TeraGrid via User
Portal. Quando o aplicativo Java Web Start ´
e utilizado ´
e este o respons´
avel por gerar o
par de chaves, montar o pedido de certificado, envi´
a-lo para o servidor My Proxy Ca,
receber o certificado da AC on line e fazer o download do certificado na m´
aquina do
usu´
ario [Basney et al. 2010]. Uma vez que o mapeamento entre a instituic¸˜
ao de origem
e identidades TeraGrid estiver completo, o pesquisador pode usar o seu login e senha
institucional para acessar os seus servic¸os digitais do TeraGrid.
4.4. Projeto CILogon
O projeto CILogon, iniciado em setembro de 2009, est´
a sendo desenvolvido pelo Na-
tional Center for Supercomputing Applications (NCSA) da Universidade de Illinois e
oferece um servic¸o online18 , de c ´
odigo aberto, para emiss˜
ao de certificados digitais que
proporciona `
a comunidade de pesquisa da National Science Foundation (NSF) o acesso
seguro a cyberinfrastructure(CI).
O servic¸o CILogon oferece uma ponte entre as credenciais geradas no processo de
autenticac¸˜
ao em um provedor de identidades (IdP) da Federac¸˜
ao Incommon e os certifica-
dos necess´
arios para autenticac¸˜
ao de pesquisadores que desejem usufruir da cyberinfras-
tructure da NSF [CILogon 2012]. Grande parte da abordagem do servic¸o do CILogon foi
demonstrada previamente no sistema de login federado do TeraGrid [Basney et al. 2010].
Tal como acontece com o login federado do TeraGrid, o servic¸o CILongon usa o MyProxy
CA para gerar esses certificados.
Reconhecendo que muitos usu´
ario interessados em usar a cyberinfrastructure da
NSF ainda est˜
ao fora da federac¸˜
ao InCommon, o servic¸o CILogon permite ainda que
certificados sejam gerados a partir da autenticac¸˜
ao em um provedor OpenID, tal como o
Google, PayPal e Verisign.
Para dar suporte aos dois n´
ıveis de garantia (LoA) definidos na Federac¸˜
ao InCom-
mon, o CILogon opera com duas autoridades certificadoras: uma para os membros da
InCommon do n´
ıvel bronze e outra para os membros que atendem o perfil prata. Opera-
dores dos CI est˜
ao aptos a confiar em uma ou em ambas ACs com base em seu n´
ıvel de
garantia (LoA) e no tamanho de sua base de usu´
arios. Visando atender os usu´
arios que
utilizam provedores OpenID, o servic¸o possui ainda a CA CILogon OpenID que fornece
certificados com base na autenticac¸˜
ao OpenID. As ACs se diferem apenas em seus proces-
sos de autenticac¸˜
ao dos sujeitos, na validac¸˜
ao e nomeac¸˜
ao da identidade. Usando contas
18Em setembro de 2010, o servic¸o tornou-se operacional (https://cilogon.org)
do Google, PayPal ou VeriSign, os pesquisadores podem se autenticar no CILogon via
OpenID para obter um certificado CILogon OpenID. Embora este tipo de certificado tem
um n´
ıvel inferior de seguranc¸a, este tamb´
em considerado como v´
alido. O Open Identity
Exchange (OIX) certificou esses provedores OpenID com LoA n´
ıvel 1. Em muitos casos,
este LoA ´
e suficiente para o acesso a uma CI.
O servic¸o CILogon pode entregar uma credencial X.509 para um sistema local do
usu´
ario (via linha de comando) ou para a um portal web do projeto do CI. Neste ´
ultimo
caso, o usu´
ario pode ser redirecionado ao servic¸o CILogon, que ir´
a autentic´
a-lo atrav´
es
da Federac¸˜
ao Incommon. Por fim, ser´
a gerada uma credencial X.509 e encaminhada de
forma segura para o portal do projeto. Essa credencial serve tanto para estabelecer a
identidade do usu´
ario para o portal quanto para ser usada pelo portal para acesso a outros
servic¸os em nome do usu´
ario.
O servic¸o CILogon faz uso do protocolo OAuth19 para coordenar a autenticac¸ ˜
ao
de usu´
arios e para delegar credenciais de usu´
arios para o portal. A interac¸˜
ao entre o
servic¸o CILogon e portal s ´
o´
e poss´
ıvel se o portal integrar o c´
odigo do cliente CILogon
e se houver uma negociac¸˜
ao pr´
evia entre os administradores do servic¸o CILogon e portal
para o estabelecimento dos mecanismos criptogr´
aficos para garantir a troca segura das
mensagens [Barnett et al. 2011].
Um grid ou uma cyberinfrastructure oferece servic¸os que s˜
ao acessados por apli-
cativos que rodam computador do usu´
ario e a autenticac¸˜
ao ocorre atrav´
es de uma cre-
dencial X.509, armazenada no lado do usu´
ario. Neste cen´
ario, a entrega das credenci-
ais (download do certificado) para o computador do usu´
ario ´
e feita exclusivamente pelo
Servic¸o CILogon, conforme os passos resumidos a seguir:
1. Atrav´
es de um navegador web, um usu´
ario acessa o servic¸o (https://
cilogon.org/) e indica o seu provedor de identidade;
2. Assumindo que este usu´
ario ainda n˜
ao tenha se autenticado, este ´
e redirecionado
para o seu IdP;
3. Ap´
os autenticar-se, o usu´
ario ´
e redirecionado para a aplicac¸˜
ao web. Esta aplicac¸˜
ao
extrai da asserc¸˜
ao SAML informac¸ ˜
oes necess´
arias para montar o DN do certi-
ficado do usu´
ario e o apresenta ao usu´
ario solicitando que o mesmo informe a
senha que proteger´
a a chave privada;
4. A aplicac¸˜
ao monta o pedido de certificado (CSR) e atrav´
es do myproxy-logon
envia para o servidor MyProxy CA. Se este servidor, de acordo com suas pol´
ıticas,
ap´
os aceitar o pedido de certificado, gera um par de chaves e assina o certificado
X.509 que cont´
em a chave p´
ublica e o DN do usu´
ario. ´
E feito ent˜
ao o encapsu-
lamento das chaves e certificado em um objeto PKCS12 protegido com a senha
que fora escolhida pelo usu´
ario. Por fim, um link web ´
e disponibilizado para que
o usu´
ario possa baixar o certificado gerado;
5. Com o certificado salvo em sua m´
aquina, o usu´
ario poder´
a utilizar uma aplicac¸˜
ao
de linha de comando (p.ex. GSI-OpenSSH) para acessar a CI.
Assim como no sistema de autenticac¸˜
ao federada do TeraGrid, o CILogon em
suas primeiras vers˜
oes tamb´
em fazia uso do Java Web Start para gerar o par de chaves e
o pedido de certificado diretamente na m´
aquina do usu´
ario. Contudo, na vers˜
ao atual do
CILogon esta funcionalidade n˜
ao ´
e mais oferecida.
19http://oauth.net/
4.5. Comparac¸ ˜
ao com os Projetos Relacionados
A Tabela 1 resume e compara algumas caracter´
ısticas dos projetos mais recentes que
proveem a gerac¸˜
ao de certificados digitais a partir da autenticac¸ ˜
ao federada Shibboleth.
Pode-se observar que todos os projetos utilizam como autoridade certificadora on-line
o MyProxy. As abordagens propostas neste trabalho (SGR e IdP+) oferecem ainda o
suporte a uma AC online SGCI de resposta autom´
atica alinhada ao Servic¸o ICPedu da
RNP. Como o Shibboleth ´
e uma tecnologia baseada na web, desenvolvido para usu´
arios
com navegadores web, todas as soluc¸˜
oes analisadas permitem que os usu´
arios acessem o
servic¸o para gerac¸ ˜
ao de certificados a partir de um navegador e que este servic¸o seja uma
aplicac¸˜
ao web. Em todos os projetos relacionados e na abordagem proposta do SGR, a
aplicac¸˜
ao web encontra-se hospedada em um provedor de servic¸os (SP) Shibboleth.
Caracter´
ısticas Soluc¸ ˜
ao
SARoNGS go.teragrid CILogon SGC IdP+
Suporte a AC on-
line
MyProxy CA MyProxyCA
e SGCI
MyProxyCA
e SGCI
Acesso via nave-
gador web
Sim Sim Sim Sim Sim
Acesso via
aplicac¸˜
ao n˜
ao
web
N˜
ao N˜
ao N˜
ao N˜
ao Sim
Shibboleth SP SP SP SP IdP
Gerac¸˜
ao de par de
chaves e CSR
No CTS Na m´
aquina
do usu´
ario
No servic¸o Na m´
aquina
do usu´
ario
Na m´
aquina
do usu´
ario
Uso de LoA Sim N˜
ao Sim N˜
ao N˜
ao
Integrado com
Portal de Grid
Sim proxy
certificates
N˜
ao Sim proxy
certificates
N˜
ao N˜
ao
Certificados
X.509
Credenciais
tempor´
arias
Credenciais
perfil SLCS
Credenciais
perfil SLCS
Credenciais
perfil SLCS
Credenciais
perfil SLCS
Tabela 1. Comparac¸ ˜
ao dos projetos relacionados com SGC e IdP+
A proposta IdP+, por possuir um Servic¸o Web, abre a possibilidade para que
aplicac¸ ˜
oes desktop possam usufruir das facilidades da autenticac¸˜
ao federada para gerac¸˜
ao
de certificados digitais. ´
E importante ressaltar que a soluc¸˜
ao proposta n˜
ao se limita na
traduc¸˜
ao apenas para certificados X.509, podendo ser estendida para suportar a traduc¸ ˜
ao
para outros tipos de credenciais. Este ´
e a ´
unica soluc¸˜
ao que oferece esta funcionalidade.
Em relac¸˜
ao a gerac¸˜
ao do par de chaves do usu´
ario e da preparac¸˜
ao do pedido
de certificado (CSR), a soluc¸˜
ao do go.teragrid e as abordagens propostas neste trabalho
realizam estas tarefas na m´
aquina do usu´
ario atrav´
es de aplicativos JWS, o que que garante
a propriedade de n˜
ao rep´
udio.
Como a Federac¸˜
ao CAFe da RNP ainda n˜
ao definiu seu framework de avaliac¸˜
ao de
n´
ıvel de garantida de seus provedores de identidades, a possibilidade de oferecer m´
ultiplas
AC on-lines de acordo com o LoA do provedor que emitiu a asserc¸˜
ao SAML ainda n˜
ao ´
e
provida nas abordagens propostas neste trabalho.
Na maioria das soluc¸ ˜
oes analisadas, as ACs on-line emitem credencias de vida
curta conforme o perfil SLCS [TAGPMA 2009]. Em relac¸ ˜
ao a integrac¸˜
ao da soluc¸˜
ao para
gerac¸˜
ao de certificados com portais de acesso a grids e cyberinfrastructure20, apesar de
estarem implementados de formas diferentes, os projetos SARoNGS e CILogon oferecem
esta funcionalidade a seus usu´
arios.
5. Conclus˜
ao
Neste trabalho foram apresentadas duas abordagens para permitir que credenciais SAML,
empregadas em federac¸ ˜
oes acadˆ
emicas e que fazem uso do framework Shibboleth, pos-
sam ser convertidas em outros tipos de credenciais, por exemplo em certificados X.509,
e assim usadas para acessar aplicac¸ ˜
oes acadˆ
emicas espec´
ıficas, como os grids. Dentre
as aplicac¸ ˜
oes distribu´
ıdas que tamb´
em podem se beneficiar das abordagens desenvolvi-
das, destacam-se as ferramentas visualizac¸ ˜
ao e de monitoramento do desempenho de re-
des, por exemplo, as utilizadas na arquitetura perfSONAR, as ferramentas de gerˆ
encia e
configurac¸˜
ao de servic¸os de circuitos de de redes avanc¸adas e as ferramentas utilizadas
nas redes experimentais para Internet para pesquisa em Internet do Futuro.
Cada abordagem buscou atender requisitos de usabilidade ou mesmo de aderˆ
encia
`
as regras das federac¸ ˜
oes e aos protocolos de comunicac¸˜
ao de aplicac¸ ˜
oes que n˜
ao podem
fazer uso direto do framework Shibboleth. O Servic¸o Gerador de Certificados mostrou ser
uma opc¸˜
ao adequada para ambientes dinˆ
amicos e de larga escala, desde que a gerˆ
encia
da federac¸˜
ao opte por oferecer este servic¸o para todos os membros de sua federac¸˜
ao.
O IdP+ tem como vantagens a oferta de uma interface baseada em Servic¸o Web para
integrac¸˜
ao com aplicac¸ ˜
oes n˜
ao web e por ser uma soluc¸˜
ao integrada ao IdP, n˜
ao sendo
assim necess´
ario a oferta de um provedor de servic¸os pela instituic¸ ˜
ao, haja visto que
algumas instituic¸ ˜
oes optam por somente ingressar na federac¸˜
ao com o seu provedor de
identidades.
Referˆ
encias
Adams, C., Farrell, S., Kause, T., and Mononen, T. (2005). Internet X.509 Public Key
Infrastructure Certificate Management Protocol (CMP). IETF RFC 4210.
Barnett, W., Welch, V., Walsh, A., and Stewart, C. A. (2011). A roadmap for
using nsf cyberinfrastructure with incommon. http://www.incommon.org/
nsfroadmap.html.
Basney, J., Fleury, T., and Welch, V. (2010). Federated login to teragrid. In Proceedings
of the 9th Symposium on Identity and Trust on the Internet, IDTRUST ’10, pages 1–11,
New York, NY, USA. ACM.
Carmody, S., Erdos, M., Hazelton, K., Hoehn, W., Morgan, B., Scavo, T., and Wasley, D.
(2005). Incommon technical requirements and information. vol. 2005.
CILogon (2012). Cilogon service. CILogon. http://www.cilogon.org/
service.
Federation, I. (2011). Identity assurance assessment framework. http://www.
incommonfederation.org/docs/assurance/IAAF_V1.1.pdf.
Internet2 (2012). Shibboleth. http://shibboleth.net.
20Possibilitar que o certificado gerado possa ser delegado para um reposit ´
orio de credenciais (proxy
certificates) e possa ser usado no acesso via Portal.
Jones, M. and S.Pickles (2007). Shebangs: Final report. JISC development pro-
grammes. http://www.jisc.ac.uk/media/documents/programmes/
middleware/shebangsfinalreport.pdf.
LabSEC (2012). Sistema de gerenciamento de certificados digitais da infraestrutura
de chaves p´
ulicas para ensino e pesquisa (sgci). https://projetos.labsec.
ufsc.br/sgci.
Moreira, E., Foscarini, E., da Silva Junior, G. C., Aliandrina, L. A. O., Neto, L. P. V.,
and Rossetto, S. (2011). Federac¸ ˜
ao CAFe: Implantac¸ ˜
ao do Provedor de Identidade.
Escola Superior de Redes. RNP.
MyProxy (2012). Credential management service. MyProxy. http://grid.ncsa.
illinois.edu/myproxy/.
OASIS (2009). Ws-trust 1.4. OASIS Standard. http://docs.oasis-open.org/
ws-sx/ws-trust/v1.4/ws-trust.pdf.
RNP (2009). Esquema breduperson - vers˜
ao 1.0. http://www.rnp.br/_arquivo/
servicos/Esquema_brEduPerson.pdf.
RNP (2012). Infraestrutura de chaves p´
ublicas para ensino e pesquisa (icpedu). http:
//www.rnp.br/servicos/icpedu.html.
Scavo, T. and Welch, V. (2007). A grid authorization model for science gateways. In
International Workshop on Grid Computing Environments.
Shibboleth (2005). Shibboleth Architecture.http://shibboleth.internet2.
edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf.
Silv´
erio, A., Kohler, J., and Cust´
odio, R. (2011). An´
alise e implementac¸˜
ao de um proto-
colo de gerenciamento de certificados. In WTICG - SBSeg 2011.
Spence, D., Geddes, N., Jensen, J., M., A. R., Viljoen, Martin, A., Dovey, M., Norman,
M., Tang, K., Trefethen, A., Wallom, D., Allan, R., and Meredith, D. (2006). Shibgrid:
Shibboleth access for the uk national grid service. In Proceedings of the Second IEEE
international Conference on E-Science and Grid Computing.
TAGPMA (2009). Profile for short lived x.509 credential services (slcs) x.509 public
key certification authorities with secured infrastructure. SLCS-2.1b. http://www.
tagpma.org/files/SLCS-2.1b.pdf.
TERENA (2012). Research and education networking faq - general. http:
//www.terena.org/activities/development-support/r+e-faq/
general.html#about.
Tuecke, S., Welch, V., Engert, D., Pearlman, L., and Thompson, M. (2004). X.509 Proxy
Certificate Profile. IETF RFC 3820.
