Escolar Documentos
Profissional Documentos
Cultura Documentos
Implantação
do Provedor
de Identidade
Edré Quintão Moreira
Éverton Didoné Foscarini
Gessy Caetano da Silva Junior
Lídia Aparecida O. Alixandrina
Lourival Pereira Vieira Neto
Silvana Rossetto
A RNP – Rede Nacional de Ensino
e Pesquisa – é qualificada como
uma Organização Social (OS),
sendo ligada ao Ministério da
Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Programa Interministerial RNP,
que conta com a participação dos
ministérios da Educação (MEC), da
Saúde (MS) e da Cultura (MinC).
Pioneira no acesso à Internet no
Brasil, a RNP planeja e mantém a
rede Ipê, a rede óptica nacional
acadêmica de alto desempenho.
Com Pontos de Presença nas
27 unidades da federação, a rede
tem mais de 800 instituições
conectadas. São aproximadamente
3,5 milhões de usuários usufruindo
de uma infraestrutura de redes
avançadas para comunicação,
computação e experimentação,
que contribui para a integração
entre o sistema de Ciência e
Tecnologia, Educação Superior,
Saúde e Cultura.
Ministério da
Cultura
Ministério da
Saúde
Ministério da
Educação
Ministério da
Ciência, Tecnologia
e Inovação
Federação CAFe:
Implantação
do Provedor
de Identidade
Rio de Janeiro
Escola Superior de Redes
2014
Copyright © 2014 – Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simões
Edição
Pedro Sangirardi
Revisão
Lincoln da Mata
Revisão Técnica
Lídia Aparecida O. Alixandrina
Edré Quintão Moreira
Versão
1.2.1
(VWHPDWHULDOGLG£WLFRIRLHODERUDGRFRPȴQVHGXFDFLRQDLV6ROLFLWDPRVTXHTXDOTXHUHUURHQFRQ-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail LQIR#HVUUQSEU$5HGH1DFLRQDOGH(QVLQRH
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
SHVVRDVRXEHQVRULJLQDGRVGRXVRGHVWHPDWHULDO
$VPDUFDVUHJLVWUDGDVPHQFLRQDGDVQHVWHPDWHULDOSHUWHQFHPDRVUHVSHFWLYRVWLWXODUHV
Distribuição
Escola Superior de Redes
Rua Lauro Müller, 116 – sala 1103
22290-906 Rio de Janeiro, RJ
KWWSHVUUQSEU
LQIR#HVUUQSEU
%LEOLRJUDȴDS
Ζ6%1
6HJXUDQ©DGH&RPSXWDGRUHV/'$33URWRFRORGHUHGHGHFRPSXWDGRUHV
'LUHWµULRGH6HUYL©RV7HFQRORJLDGHUHGHGHFRPSXWDGRUHVΖ5RVVHWR6LOYDQDΖΖ7¯WXOR
(VWDREUD«GLVWULEX¯GDVREDOLFHQ©D
&''
&UHDWLYH&RPPRQV$WULEXL©¥RH8VR1¥R&RPHUFLDO%UDVLO
Sumário
$PHWRGRORJLDGD(65Ʌix
6REUHRFXUVRɅx
$TXHPVHGHVWLQDɅxi
&RQYHQ©·HVXWLOL]DGDVQHVWHOLYURɅxi
3HUPLVV·HVGHXVRɅxii
6REUHRVDXWRUHVɅxii
ΖQIUDHVWUXWXUDGHDXWHQWLFD©¥RHDXWRUL]D©¥RIHGHUDGDɅ2
)HGHUD©¥RDFDG¬PLFDɅ2
(OHPHQWRVGHXPDIHGHUD©¥RɅ4
&RPSRQHQWHDGLFLRQDOGHXPDIHGHUD©¥RɅ5
3URYHGRUHVGHLGHQWLGDGHɅ5
3URYHGRUHVGHVHUYL©RɅ6
)HGHUD©¥R&$)HɅ7
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ'HPRQVWUDURIXQFLRQDPHQWRGHXPDIHGHUD©¥RɅ11
iii
2. Revisão de LDAP e esquema brEduPerson
5HYLV¥RGHVHUYL©RGHGLUHWµULRH/'$3Ʌ13
/'$3Ʌ14
2SHQ/'$3Ʌ15
0RGHORV/'$3Ʌ15
0RGHORGHLQIRUPD©¥RɅ15
&ODVVHVGHREMHWRVɅ17
$WULEXWRVɅ18
0RGHORGHQRPHVɅ20
0RGHORIXQFLRQDOɅ22
5HSUHVHQWD©¥R/'Ζ)Ʌ24
&RPDQGRVGHVKHOOHIHUUDPHQWDJU£ILFDɅ27
(VTXHPDEU(GX3HUVRQɅ31
0RGHORGHQRPHVSDUDXVRQD)HGHUD©¥R&$)HɅ32
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂΖQVWDODUHFRQILJXUDUXPVHUYL©RGHGLUHWµULR2SHQ/'$3Ʌ35
$WLYLGDGHȂ(GLWDURDUTXLYR/'Ζ)HH[HFXWDUDOWHUD©·HVQRGLUHWµULRɅ37
$WLYLGDGHȂ8WLOL]D©¥RGHIHUUDPHQWDJU£ILFDSDUDDFHVVRDRVHUYLGRU/'$3Ʌ38
0HWDGLUHWµULRɅ39
(Ζ'Ʌ40
(Ζ'HEU(GX3HUVRQɅ42
$FHVVRɅ43
&RQILJXUD©·HVLQLFLDLVɅ44
&RQILJXUD©¥RGHH[WUD©·HVɅ46
'HILQL©¥RGHUHSRVLWµULRVɅ46
([WUD©·HVɅ49
3URFHVVRVɅ55
$JHQGDPHQWRVɅ57
5HVXOWDGRVGHSURFHVVDPHQWRɅ59
iv
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂΖQVWDOD©¥RGH(Ζ'H(Ζ'/'$3Ʌ61
$WLYLGDGHȂ&RQILJXUD©¥RGHXPUHSRVLWµULRɅ63
$WLYLGDGHȂ'HILQL©¥RGHXPDH[WUD©¥RɅ64
$WLYLGDGHȂ'HILQL©¥RGHXPSURFHVVRHVHXDJHQGDPHQWRɅ65
$WLYLGDGHȂ/LPSDURUHSRVLWµULR(Ζ'Ʌ65
([WUD©¥RGHDUTXLYRVWH[WRɅ68
(7&Ʌ69
([WUD©¥RGHGLUHWµULRV/'$3Ʌ70
5HVROX©¥RGHREMHWRVɅ70
3DU¤PHWURVJOREDLVɅ71
ΖPSRUWD©¥RLQFUHPHQWDOɅ72
6FULSWGHFRQYHUV¥RɅ74
6FULSWGHFRQYHUV¥RȂ%HDQ6KHOOɅ74
6FULSWGHFRQYHUV¥RȂ-DYD1DWLYRɅ75
$OJRULWPRVGHXQLILFD©¥RɅ75
:HEVHUYLFHVɅ77
3UREOHPDVFRPXQVɅ78
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ'HILQL©¥RGHXPDH[WUD©¥RGHDUTXLYRWH[WRɅ79
$WLYLGDGHȂΖPSRUWD©¥RGHORJLQHVHQKDɅ83
$WLYLGDGHȂ&DGDVWUDUXPUHSRVLWµULRGHGDGRVGRWLSRȊ'LUHWµULR/'$3ȋɅ86
$WLYLGDGHȂ&ULDUXPDH[WUD©¥RDSDUWLUGHUHSRVLWµULRGRWLSR'LUHWµULR/'$3Ʌ86
v
5. Gestão de pessoas e grupos no EID
*HVW¥RPDQXDOGHSHVVRDVɅ89
&RQFLOLD©¥RGHUHJLVWURVɅ89
&RQFLOLD©¥RGHUHJLVWURVɅ90
3HVTXLVDGHSHVVRDVɅ91
ΖQVHU©¥RGHQRYDVSHVVRDVɅ93
$OWHUD©¥RGHGDGRVYLDLQWHUIDFHɅ94
)RU©DUUHXQLILFD©¥RɅ96
'HVDWLYD©¥RGHSHVVRDVɅ96
*HVW¥RGHJUXSRVɅ97
ΖQVHU©¥RHDWXDOL]D©¥RGHJUXSRVɅ97
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ&RQFLOLD©¥RGHXPUHJLVWURPDQXDOPHQWHɅ99
$WLYLGDGHȂ5HJLVWURVSHQGHQWHVSDUDFRQFLOLD©¥RɅ99
$WLYLGDGHȂΖQVHU©¥RGHXPDQRYDSHVVRDɅ100
$WLYLGDGHȂ'HILQL©¥RGHXPJUXSRɅ100
$UTXLWHWXUDɅ102
;0/GR(Ζ'Ʌ103
;0/GR(Ζ'Ʌ103
;6/7Ʌ104
3URFHVVDPHQWRGR/'Ζ)Ʌ105
&RQILJXUD©¥RHXVRɅ106
$FHVVRɅ106
&RQILJXUD©¥RGHH[SRUWD©¥RɅ108
ΖQLFLDOL]D©¥RGRDJHQWHɅ109
&DGDVWUDPHQWRGRVVHUYLGRUHVɅ110
&DGDVWUDPHQWRGR;6/7Ʌ111
&DGDVWUDPHQWRGR;6/7Ʌ112
'HILQL©¥RGHDJHQGDPHQWRɅ112
9HULILFD©¥RGRORJɅ114
3UREOHPDVFRPXQVɅ115
vi
5RWHLURGH$WLYLGDGHVɅ117
$WLYLGDGHȂ$FHVVHDIHUUDPHQWD(Ζ'/'$3Ʌ117
$WLYLGDGHȂ&RQILJXUD©¥RGRVHUYLGRU/'$3Ʌ117
$WLYLGDGHȂ&RQILJXUD©¥RGHXPDWUDQVIRUPD©¥RɅ117
$WLYLGDGHȂ([HFXWDUWHVWHSDGU¥ROHLWXUDQRGLUHWµULRɅ118
$WLYLGDGHȂ'HILQL©¥RGHXPDJHQGDPHQWRɅ118
$WLYLGDGHȂ'HVDWLYD©¥RHDOWHUD©¥RGHUHJLVWURVQRPHWDGLUHWµULRɅ119
7. Plataforma Shibboleth
ΖQWURGX©¥RɅ121
2TXH«6KLEEROHWK"Ʌ121
&RPSRQHQWHVGR6KLEEROHWKɅ122
3RUTXH6KLEEROHWK"Ʌ122
3URYHGRUGH6HUYL©R63Ʌ125
'6:$<)Ʌ126
0HWDGDWDɅ126
)XQFLRQDPHQWRɅ127
5RWHLURGH$WLYLGDGHVɅ141
$WLYLGDGHȂΖQVWDODUHFRQILJXUDUSURYHGRUGHLGHQWLGDGH6KLEEROHWKɅ141
$WLYLGDGHȂ%DL[DUHLQVWDODUR6KLEEROHWKΖ'3HELEOLRWHFDV-DYDɅ143
$WLYLGDGHȂ&RQILJXUD©¥RGR6KLEEROHWKΖG3Ʌ144
$WLYLGDGHȂ&HUWLILFDGRV66/Ʌ146
&RQȴJXUD©¥RGR$SDFKHɅ152
&RQȴJXUD©¥RGR7RPFDWɅ152
&RQȴJXUD©¥RGR6KLEEROHWKΖG3Ʌ152
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ9DOLGDQGRDLQVWDOD©¥RHWHVWDQGRD)HGHUD©¥RɅ155
vii
9. Implantação de um provedor de identidade a partir de bases de dados relacionais
5RWHLURGHLPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHɅ157
5RWHLURGHDWLYLGDGHVɅ158
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ'HPRQVWUDURIXQFLRQDPHQWRGDDXWHQWLFD©¥RHHQYLRGHDWULEXWRVɅ161
$Q£OLVHGRFHQ£ULRɅ164
$WULEXWRVUHFRPHQGDGRVSHODIHGHUD©¥RɅ164
$WULEXWRVGRHVTXHPDRULJLQDOɅ165
'HILQL©¥RGRVPDSHDPHQWRVɅ166
5HQRPHDUDWULEXWRɅ168
$OWHUDUYDORUGHDWULEXWRɅ169
5RWHLURGH$WLYLGDGHVɅ
$WLYLGDGHȂ5HQRPHDQGRXPDWULEXWRɅ171
$WLYLGDGHȂ$OWHUDQGRRYDORUGHXPDWULEXWRɅ171
$WLYLGDGHȂ0¼OWLSORVDWULEXWRVɅ171
%LEOLRJUDȴDɅ
viii
Escola Superior de Redes
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsável pela disseminação do conhecimento em Tecnologias da Informação e Comuni-
cação (TIC).
A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital
e Governança de TI.
A metodologia da ESR
$ȴORVRȴDSHGDJµJLFDHDPHWRGRORJLDTXHRULHQWDDUHDOL]D©¥RGRVFXUVRVGD(65«
baseada na aprendizagem como construção do conhecimento por meio da resolução de
SUREOHPDVW¯SLFRVGDUHDOLGDGHGRSURȴVVLRQDOHPIRUPD©¥R
$DSUHQGL]DJHP«HQWHQGLGDFRPRDUHVSRVWDGRDOXQRDRGHVDȴRGHVLWXD©·HVSUREOHPD
VHPHOKDQWHV¢VTXHV¥RHQFRQWUDGDVQDSU£WLFDSURȴVVLRQDOTXHV¥RVXSHUDGDVSRUPHLR
de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a reso-
lução do problema, em abordagem orientada ao desenvolvimento de competências.
Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para
as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de
ix
aprendizagem não é considerada uma simples exposição de conceitos e informações.
O instrutor busca incentivar a participação dos alunos continuamente.
Sobre o curso
O curso foi desenvolvido para auxiliar as instituições no processo de implantação de um
provedor de identidade para a Federação Acadêmica Federada (CAFe). O curso tem como
objetivo demonstrar o funcionamento de uma infraestrutura de autenticação e autoriza-
ção federada. Para isso são apresentadas as ferramentas de software disponíveis para a
construção desta infraestrutura, e o modo de integração de uma instituição acadêmica ou
de pesquisa à federação CAFe.
O Capítulo 1 apresenta uma visão geral sobre a motivação e a metodologia adotadas para a
construção de uma federação acadêmica no Brasil.
O Capítulo 2 fará uma revisão sobre serviço de diretórios e protocolo LDAP e apresentará o
HVTXHPDEU(GX3HUVRQGHȴQLGRSDUDXVRFRPDIHGHUD©¥R&$)H
2&DS¯WXORDSUHVHQWDU£DIHUUDPHQWD(Ζ'XPDDSOLFD©¥RZHEFXMDȴQDOLGDGH«DX[LOLDUQR
processo de migração de dados das bases relacionais de uma instituição para um diretório.
2V&DS¯WXORVHWDPE«PGHGLFDGRV¢IHUUDPHQWD(Ζ'PRVWUDU¥RFRPRFRQȴJXUDUHH[H-
FXWDUDVH[WUD©·HVGDVEDVHVGHGDGRVUHODFLRQDLVSDUDRPHWDGLUHWµULRGHȴQLGRSHOR(Ζ'
x
2&DS¯WXORDSUHVHQWDU£DIHUUDPHQWD(Ζ'/'$3FXMDȴQDOLGDGH«OHYDURVGDGRVFRQWLGRV
no metadiretório do EID para o diretório LDAP.
2&DS¯WXORIRFDU£RHVWXGRVREUHDFRQȴJXUD©¥RGHXPSURYHGRUGHLGHQWLGDGHQDSODWD-
forma Shibboleth.
Os Capítulos 9 e 10 serão dedicados a dois casos de uso que revisam todo o conteúdo apre-
sentado, propondo respectivamente:
A quem se destina
O curso se destina aos técnicos das instituições que pretendem aderir à Comunidade Aca-
dêmica Federada (CAFe) e também aos interessados em saber mais sobre LDAP, esquema
brEduPerson, gestão de identidade e Plataforma Shibboleth.
Itálico
ΖQGLFDQRPHVGHDUTXLYRVHUHIHU¬QFLDVELEOLRJU£ȴFDVUHODFLRQDGDVDRORQJRGRWH[WR
Largura constante
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem
RSUHȴ[RGRDPELHQWHHPXVRQR/LQX[«QRUPDOPHQWHRXHQTXDQWRQR:LQGRZV«&?
Conteúdo de slide q
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.
Símbolo w
Indica referência complementar disponível em site ou página na internet.
Símbolo d
Indica um documento como referência complementar.
Símbolo v
Indica um vídeo como referência complementar.
Símbolo s
Indica um arquivo de aúdio como referência complementar.
Símbolo !
Indica um aviso ou precaução a ser considerada.
xi
Símbolo p
ΖQGLFDTXHVWLRQDPHQWRVTXHHVWLPXODPDUHȵH[¥RRXDSUHVHQWDFRQWH¼GRGHDSRLRDR
entendimento do tema em questão.
Símbolo l
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou
mesmo uma observação.
Permissões de uso
Todos os direitos reservados à RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citação: Exemplo de citação: MOREIRA, Edré Quintão et al. Federação CAFe:
Implantação do Provedor de Identidade. Rio de Janeiro: Escola Superior de Redes, RNP, 2014.
Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação:
Escola Superior de Redes RNP
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo
Rio de Janeiro – RJ – 22290-906
E-mail: info@esr.rnp.br
Sobre os autores
Edré Quintão Moreira Bacharel e Mestre em Ciência da Computação pela Universidade
Federal de Minas Gerais. Entre 2000 e 2003 participou da implantação do diretório corpo-
rativo da UFMG.
Possui grande experiência em autenticação federativa com protocolo SAML, tendo atuado
como assistente 1 no Grupo de Trabalho Middleware da RNP de2003 a 2005. Possui grande
H[SHUL¬QFLDFRPDSODWDIRUPD-((WHQGRVHFHUWLȴFDGRHPSURJUDPD©¥R-DYDHP
Em 2009 participou do projeto que deu origem à Federação CAFe. Participou da elaboração
e desenvolvimento do sistema EID. Atualmente é membro do Comitê Técnico da Federação
CAFe e do Comitê Técnico de Gestão de Identidades da RNP. É também arquiteto de software
no Departamento de Ciência da Computação da UFMG.
Gessy Caetano da Silva Junior Formado em Física pela Universidade Federal de Minas
Gerais atuando atualmente como analista de sistemas para o Laboratório de Computação
FLHQW¯ȴFD/&&&(1$3$'GD8)0*3RVVXLJUDQGHH[SHUL¬QFLDFRPSURWRFROR/'$3DGPLQLV-
tração De servidores Linux/Unix, backup e monitoramento de recursos de rede. Em 2009
participou do projeto que deu origem à Federação CAFe.
xii
Lídia Aparecida O. Alixandrina Bacharel em Sistemas de Informação pela PUC Minas.
Atualmente é Analista de Sistemas na UFMG trabalhando na implantação de diretórios
federados no projeto CAFe. Trabalha também no desenvolvimento das ferramentas EID
(Export Import Directory), EID2LDAP, e pCollecta. Experiência em autenticação federativa
com Shibboleth, LDAP, Apache Tomcat, Banco de Dados e Java para Web.
xiii
xiv
1
Introdução à Federação CAFe
objetivos
conceitos
Infraestrutura de autenticação, federação, autorização federada, provedores de identi-
dade, provedores de serviço, Where Are You From (WAYF).
Introdução
Este curso foi desenvolvido no escopo do projeto e-AA: Infraestrutura de Autenticação e
Autorização Eletrônica, idealizado e coordenado pela RNP, com a colaboração das insti-
tuições Cefet-MG, UFC, UFF, UFMG e UFRGS. O projeto teve início em julho de 2007 e sua
meta principal é criar as condições necessárias para a implantação de uma Federação
Acadêmica no Brasil. Uma federação acadêmica envolve instituições de ensino e pesquisa
e permite que as pessoas vinculadas a essas instituições compartilhem informações e
recursos e tenham acesso a serviços restritos, usando o vínculo institucional como critério
básico para esse compartilhamento.
$ȴQDOLGDGHGHVWHFXUVR«FDSDFLWDURSHVVRDOGH7ΖGDVLQVWLWXL©·HVGHHQVLQRHSHVTXLVDQR
Brasil para implantar e gerenciar em suas instituições um Provedor de Identidade (compo-
nente que mantém e gerencia as informações sobre as pessoas vinculadas a uma insti-
tuição) e acoplá-lo à Federação CAFe (Comunidade Acadêmica Federada), criada no escopo
do projeto e-AA.
TXHGHȴQHDWULEXWRVHFODVVHVQHFHVV£ULRVSDUDDUPD]HQDULQIRUPD©·HVHVSHF¯ȴFDVVREUH
pessoas e seus vínculos em instituições brasileiras. Juntamente com o esquema brEduPerson,
serão apresentados os modelos de informação e de nomes propostos para a organização
das informações sobre pessoas em um diretório institucional, o qual servirá de base para a
implantação do provedor de identidade em uma instituição.
1
Infraestrutura de autenticação e autorização federada
1 Motivação: q
1 Disseminação de tecnologias e ferramentas que estimulam o compartilhamento de
recursos, informações e serviços inter-institucionais.
1 'HVDȴRSDUDDVLQVWLWXL©·HV
A parte central do curso incluirá os passos necessários para implantar um provedor de iden-
tidade institucional usando a plataforma Shibboleth e o serviço de diretório LDAP, e o modo
de acoplar esse provedor de identidade à Federação CAFe.
$RȴQDOGRFDS¯WXORVHU£DSUHVHQWDGDXPDYLV¥RJHUDOGRFXUVRGHWDOKDQGRRVWHPDVTXH
serão abordados em cada um dos capítulos.
Federação acadêmica
1 O que é uma Federação? q
2 7LSRGHUHGHGHFRQȴDQ©DTXHSHUPLWHUHGX]LUFRQWUDWRVELODWHUDLVHQWUHXVX£ULRVH
Federação CAFe: Implantação do Provedor de Identidade
provedores de serviços.
2
O cumprimento das etapas de autenticação e autorização como etapas fundamentais para
a disponibilização de um serviço implica, normalmente, a necessidade de manutenção de
bases de dados com registros sobre os possíveis usuários do serviço. A demanda do lado
de quem disponibiliza um serviço é a necessidade de criar e manter suas próprias bases de
dados de usuários. Do outro lado, para quem usa os diferentes serviços disponibilizados, a
demanda é a necessidade de criar e manter contas (ou cadastros) para cada serviço a que se
deseja ter acesso.
O conceito de federação acadêmica visa minimizar as demandas dos provedores e dos usu-
ários de serviços disponibilizados por instituições de ensino e pesquisa no que diz respeito
à manutenção de informações usadas para autenticação e autorização de acesso a esses
serviços. A ideia básica consiste no seguinte: as informações sobre uma pessoa são man-
tidas em uma única base, gerida por sua instituição de vínculo, cabendo a cada instituição
estabelecer seu modelo de gestão de identidade, isto é, de que forma informações sobre
pessoas são mantidas e atualizadas e os métodos de autenticação usados. Os provedores
GHVHUYL©RFRQȴDPQRPRGHORGHJHVW¥RGHLGHQWLGDGHGDVLQVWLWXL©·HVHGLVSRQLELOL]DP
seus serviços para os usuários vinculados a essas instituições, criando assim o princípio de
identidade federada.
&DS¯WXORΖQWURGX©¥R¢)HGHUD©¥R&$)H
Figura 1.1 As Figuras 1.1. e 1.2 ilustram a diferença entre um modelo usual, onde cada serviço deve
Modelo de manter informações sobre seus possíveis usuários, e um modelo onde as informações sobre
DXWHQWLFD©¥R
os usuários são concentradas e mantidas em um único local.
No primeiro caso, a implementação de cada serviço deve prever um módulo adicional para
tratar o registro dos usuários que podem acessá-lo, e cada pessoa precisa ter um cadastro
(login/senha) para cada serviço que deseje acessar. No segundo caso, as informações
sobre as pessoas são mantidas em um único local, tipicamente a instituição com a qual a
pessoa mantém seu vínculo principal, e cada pessoa precisa ter apenas um registro (login/
senha); nesse caso, a implementação dos serviços oferecidos não requer o módulo de
registro de usuários.
3
Figura 1.2
Autenticação
1 Usuário: pessoa vinculada a uma instituição e que deseja acessar um recurso protegido;
4
Figura 1.3
Componentes de
uma federação e
VXDVDVVRFLD©·HV
seguida, passa a interagir com o seu provedor de identidade para fornecer as suas credenciais.
Provedores de identidade
Provedores de identidade implementam a política interna de gestão de identidade de q
uma instituição.
1 Método de autenticação:
2 /RJLQVHQKDFHUWLȴFDGRVHWF
1 ΖGHQWLȴFDGRU¼QLFRSDUDFDGDSHVVRDYLQFXODGD¢LQVWLWXL©¥R
5
Os provedores de identidade são responsáveis por manter as informações sobre as pessoas
vinculadas a uma instituição, incluindo dados pessoais (nome, data de nascimento, CPF,
nomes dos pais, sexo, data de nascimento etc.) e vínculos internos (data de admissão, cargo
ocupado, número de matrícula, número VoIP etc.). O provedor de identidade estabelece seu
método de autenticação interno e deve garantir que cada pessoa da instituição tenha um
LGHQWLȴFDGRU¼QLFR
Provedores de serviço
Provedores de serviço implementam serviços que devem ser disponibilizados para q
pessoas vinculadas às instituições. Requerem:
1 Autenticação:
2 ΖGHQWLȴFD©¥RGRVXVX£ULRVGRVHUYL©R
1 Autorização:
6
A interação entre os elementos (atores) de uma federação é mostrada na Figura 1.4 e segue
os seguintes passos:
Federação CAFe
1 Iniciativa da RNP para criar uma Federação Acadêmica no Brasil. q
2 Projeto iniciado em julho de 2007 envolvendo cinco instituições: UFC, UFMG, UFF,
UFRGS e Cefet-MG.
1 Metodologia adotada:
2 'HVHQYROYHUIHUUDPHQWDVDX[LOLDUHVHGHȴQLUSRO¯WLFDVSDUDDIHGHUD©¥R
&DS¯WXORΖQWURGX©¥R¢)HGHUD©¥R&$)H
No Brasil, os primeiros esforços para a construção de uma federação acadêmica estão resul-
tando na criação da Federação CAFe (Comunidade Acadêmica Federada), cuja meta é con-
gregar todas as universidades e instituições de pesquisa brasileiras. A metodologia adotada
para a construção da infraestrutura básica da federação consiste na utilização de padrões e
soluções de software já disponíveis e adotados por outras federações, e da implementação
e experimentação de ferramentas auxiliares para apoiar a implantação dos provedores de
identidade e de serviço. O projeto de criação da Federação CAFe inclui ainda o estudo, a
proposição, a análise e a validação de políticas para regular o funcionamento da federação
(requisitos mínimos que provedores de identidade e de serviço deverão cumprir).
7
Figura 1.5
Arquitetura básica
proposta para a
)HGHUD©¥R&$)H
A Figura 1.5 mostra a arquitetura básica proposta para a Federação CAFe. Inicialmente, o
componente WAYF será centralizado e mantido pela RNP. Os provedores de serviço poderão
ser implantados nas próprias instituições que compõem a federação (universidades e
instituições de pesquisa) ou poderão ser implantados por membros externos (os quais
atuam apenas como provedores de serviço).
$VSRO¯WLFDVGHȴQLGDVSDUDDRSHUD©¥RGD)HGHUD©¥R&$)HGHYHU¥RHVWDEHOHFHURVFULW«ULRV
para a inclusão de um membro na federação e as obrigações dos provedores de identi-
dade e de serviço, bem como garantir a preservação dos requisitos básicos de privacidade.
A recomendação para os provedores de identidade é a utilização de serviço de diretórios
para a organização das informações sobre as pessoas vinculadas à instituição.
1 Atividades desenvolvidas: q
2 'HȴQL©¥RGRHVTXHPDEU(GX3HUVRQ
1 Atividades em andamento:
2 Microsoft DreamSpark.
2 Atlases.
8
Figura 1.6
(VWDW¯VWLFDVGH
provedores de
VHUYL©RVGD&$)H
w
A listagem dos IdPs
pode ser consultada
em: KWWSSRUWDOUQS
br/web/servicos/
instituicoes-clientes
Figura 1.7
(VWDW¯VWLFDVGH
provedores de
LGHQWLGDGHGD&$)H
3 http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-identidade
3 http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-servico
&DS¯WXORΖQWURGX©¥R¢)HGHUD©¥R&$)H
9
Federação CAFe: Implantação do Provedor de Identidade
10
Roteiro de Atividades 1
Atividade 1.1 – Demonstrar o funcionamento de uma federação
Acesse serviços providos na máquina do instrutor:
3. ΖQIRUPHDVFUHGHQFLDLVGHLGHQWLȴFD©¥R
&DS¯WXORΖQWURGX©¥R¢)HGHUD©¥R&$)H
11
Federação CAFe: Implantação do Provedor de Identidade
12
2
Revisão de LDAP
e esquema brEduPerson
objetivos
conceitos
Protocolo LDAP e Esquema brEduPerson.
1 8QLȴFD©¥RGHLQIRUPD©·HVGHSHVVRDVHVHUYL©RV
1 0HFDQLVPRGHEXVFDȵH[¯YHO
1 Serviço padronizado.
Neste capítulo serão revisados os conceitos gerais sobre diretório com o uso do protocolo &DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
LDAP e a utilização do esquema brEduPerson para criar um modelo de dados mais adequado
para as instituições brasileiras.
Um diretório é uma lista de informações sobre objetos arranjados em uma ordem que
fornece detalhes sobre cada objeto. Exemplos comuns são listas telefônicas e catálogos de
livros. Para a lista telefônica, os objetos listados são pessoas. Os nomes são organizados
em ordem alfabética e endereço e número de telefone são os detalhes fornecidos sobre
cada pessoa.
13
Um banco de dados relacional, por outro lado, precisa suportar aplicações, como aplicações
bancárias e de reservas aéreas, relativamente com grande volume de atualizações.
Diretórios permitem que usuários ou aplicações encontrem recursos que tenham caracterís-
ticas necessárias para uma tarefa em particular. Por exemplo, um diretório de usuários pode
ser utilizado para procurar um endereço de e-mail ou número de fax.
Os termos “páginas brancas” e “páginas amarelas” algumas vezes são utilizados para des-
crever o modo como um diretório é usado. Se o nome de um objeto (pessoa, impressora etc) é
conhecido, suas características (número de telefone, páginas por minuto) podem ser encon-
tradas, em processo similar a procurar um nome nas páginas brancas de uma lista telefô-
nica. Se o nome de um objeto é desconhecido, o diretório pode ser pesquisado por uma lista
de objetos que possuem certas características. Diretórios guardados em um computador
V¥RPXLWRPDLVȵH[¯YHLVTXHXPDOLVWDWHOHI¶QLFDSRLVSRGHPVHUSHVTXLVDGRVSRUFULW«ULRV
HVSHF¯ȴFRVQ¥RDSHQDVSRUXPFRQMXQWRGHFDWHJRULDVSU«GHȴQLGDV
LDAP
1 Lightweight Access Directory Procotol, ou seja, protocolo leve de acesso a diretórios. q
1 (VSHFLȴFDGRLQLFLDOPHQWHHPQD5)&
1 Arquitetura Cliente/Servidor.
2/'$3GHȴQHXPSURWRFRORGHPHQVDJHQVXWLOL]DGRSRUFOLHQWHVHVHUYLGRUHVGHGLUHWµULR
O protocolo utiliza diferentes mensagens, como por exemplo requisição de bind, que pode
ser enviada do cliente ao servidor LDAP no início da conexão, ou operações de busca, utili-
]DGDVSDUDSHVTXLVDUSRUXPDHQWUDGDHVSHF¯ȴFDQRGLUHWµULR
7UDWDVHGHXPSDGU¥RDEHUWRTXHGHȴQHXPP«WRGRSDUDDFHVVDUHDWXDOL]DULQIRUPD©·HV
em um diretório, que tem ganhado ampla aceitação como um método de acesso a diretó-
ULRVGDLQWHUQHWWRUQDQGRVHHVWUDW«JLFRGHQWURGDVLQWUDQHWV/'$3GHȴQHXPSURWRFROR
GHFRPXQLFD©¥RLVWR«GHȴQHRWUDQVSRUWHHRIRUPDWRGDVPHQVDJHQVXWLOL]DGDVSRUXP
FOLHQWHSDUDDFHVVDULQIRUPD©·HVHPXPGLUHWµULRGHWLSR;2/'$3Q¥RGHȴQHRGLUH-
tório; quando as pessoas falam sobre o diretório LDAP, referem-se à informação guardada
Federação CAFe: Implantação do Provedor de Identidade
LDAP foi desenvolvido como uma alternativa leve em relação ao DAP, requerendo recursos
mais leves e o protocolo TCP/IP, mais popular que o protocolo de camadas OSI. LDAP
WDPE«PVLPSOLȴFDDOJXPDVRSHUD©·HV;HRPLWHDVFDUDFWHU¯VWLFDVPDLVH[µWLFDV
14
OpenLDAP
1 Implementação open source de LDAP v3. q
1 Independente de plataforma.
1 &RQȴGHQFLDOLGDGHHLQWHJULGDGHGHGDGRVFRPXVRGRSURWRFROR66/7/6
1 Orientações e continuação.
1 Revelação de esquemas.
O OpenLDAP foi 1 Controles e operações estendidas.
escolhido como
VHUYLGRUGHGLUHWµULR Existem muitas implementações de servidores de diretórios, muitas das quais incompatíveis
para o projeto e-AA,
entre si. Na maioria dos casos, as implementações de servidores são concebidas para servir
sendo instalado através
dos scripts que estão a determinado software e possuem restrições de uso ou características exóticas, como é o
GLVSRQ¯YHLVQDS£JLQD caso do MS Active Directory ou IBM Lotus Domino. O OpenLDAP, implementação mantida
do projeto:
pela Fundação OpenLDAP, é um servidor LDAP de código aberto e de uso geral, ou seja,
http://url.rnp.br?
Procedimentos+de+en não agrega nenhum outro serviço que não tenha relação com a administração do diretório.
trada+na+CAFe Fundado em 1998, o projeto OpenLDAP foi baseado em uma implementação de servidor
LDAP feita pela Universidade de Michigan.
Modelos LDAP
1 Modelos LDAP: q
2 Descrevem as informações que podem ser armazenadas no diretório e o que pode
ser feito com elas.
1 Esquemas LDAP:
2 'HȴQHPDHVWUXWXUDGHXPDHQWUDGDHPXPGLUHWµULRHRVDWULEXWRVTXHSRGHP
ser inseridos nela.
2VTXDWURPRGHORVE£VLFRVGHȴQLGRVSHOR/'$3ΖQIRUPD©¥R1RPHV)XQFLRQDOH6HJXUDQ©D
permitem descrever por completo a operação de um serviço de diretório: que informações
podem ser armazenadas e o que pode ser feito com elas.
2PRGHORGHLQIRUPD©¥RGHȴQHRWLSRGHLQIRUPD©¥RTXHSRGHVHUDUPD]HQDGDHPXPGLUH-
WµULR/'$3HQTXDQWRRPRGHORGH1RPHVGHȴQHFRPRDLQIRUPD©¥RQRGLUHWµULR/'$3SRGH &DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
ser organizada e referenciada. O modelo funcional descreve as operações que podem ser
UHDOL]DGDVQRVGDGRVSUHVHQWHVQRGLUHWµULRHSRUȴPRPRGHORGHVHJXUDQ©DUHFRPHQGDR
uso de autenticação e mecanismos de controle do acesso aos dados.
Modelo de informação
Descreve a estrutura da informação no diretório LDAP. q
1 Unidades básicas de informação são objetos chamados de entradas.
1 Entradas são dispostas em estrutura de árvore chamada Directory Information Tree (DIT).
15
FRPXPDVLQWD[HTXHHVSHFLȴFDRWLSRGHYDORUTXHSRGHVHUJUDYDGR3RUH[HPSORXPD
HQWUDGDGHYHWHUXPDWULEXWRHDVLQWD[HDVVRFLDGDDRWLSRGRDWULEXWRGHYHHVSHFLȴFDURV
YDORUHVSRVV¯YHLVSDUDHVWHDWULEXWR(PDGL©¥RQDGHȴQL©¥RGRVGDGRVTXHSRGHPVHUJXDU-
GDGRVFRPRRVYDORUHVGHXPDWULEXWRXPDVLQWD[HGHDWULEXWRWDPE«PGHȴQHFRPRHVWHV
valores se comportarão durante pesquisas e outras operações. Alguns atributos possuem
apelidos (alias) que podem ser utilizados como os nomes reais dos mesmos. Por exemplo,
commonName e cn representam o mesmo atributo, sendo cn um alias para commonName.
Vínculos podem ser associados com tipos de atributos para limitar o número de valores
que podem ser guardados em um atributo ou para limitar o tamanho total de um valor. Por
exemplo, um atributo que contém uma imagem poderia ser limitado ao tamanho de 10 KB
para prevenir o uso demasiado de espaço de armazenamento; ou um atributo usado para
guardar um número de CPF pode ser limitado a um único valor.
dc=rnp, dc=br
ou=bsa ou=rja
ou=operadores ou=hardware
1 Entradas (Objetos): q
2 Cada entrada possui um nome único (DN).
2 Em geral, toda entrada utiliza uma classe abstrata, pelo menos uma estrutural, e
pode possuir classes auxiliares.
2 3RVVXHPDSHQDVDWULEXWRVGHȴQLGRVQDVFODVVHVGHREMHWRV
1 Classes de objetos:
2 'HȴQHPDWULEXWRVRSFLRQDLVHREULJDWµULRV
Uma classe de objetos (objectclass) é um termo LDAP que denota um tipo de objeto repre-
sentado por uma entrada do diretório ou registro. Alguns tipos de objetos típicos são person,
organization, organizationUnit, domainComponent e groupOfNames. Há também classes de
REMHWRVTXHGHȴQHPUHOD©·HVHQWUHREMHWRVWDOFRPRDFODVVHGHREMHWRtop, que estipula que
um objeto pode ter objetos subordinados a ele, em uma estrutura hierárquica de árvore.
Uma classe de objetos é declarada como abstrata, estrutural ou auxiliar. Uma classe de
objeto abstrata é usada como modelo para criação de outras classes. Uma entrada do
diretório não pode ser instanciada por uma classe de objeto abstrata. Entradas do dire-
tório são instanciadas por classes de objetos estruturais. Uma classe de objetos auxiliar
IRUQHFHXPP«WRGRSDUDHVWHQGHUFODVVHVHVWUXWXUDLVVHPPXGDUDGHȴQL©¥RGRHVTXHPD
desta classe estrutural. Deste modo, uma classe auxiliar não pode ser a única a instanciar
16
uma entrada do diretório. É obrigatório que em uma entrada do diretório haja ao menos
uma classe estrutural.
&ODVVHVGHREMHWRV/'$3GHȴQHPFRQMXQWRVGHDWULEXWRVSDGU·HVTXHV¥ROLVWDGRVFRPR
atributos obrigatórios (MUST) e atributos opcionais (MAY). Diferentes classes podem pres-
crever alguns atributos que se sobrescrevem, ou são redundantes com atributos de outras
FODVVHV0XLWDVFODVVHVGHREMHWRVV¥RGHȴQLGDVHPXPDRUGHPKLHU£UTXLFDRQGHXPD
FODVVH«GLWDKHUGHLUDGHRXWUDFODVVHVXSHULRU&RQVLGHUHRREMHWR/'$3TXH«GHȴQLGR
com as classes de objetos:
1 objectclass: top
1 objectclass: person
1 objectclass: organizationalPerson
1 objectclass: inetOrgPerson
1 objectclass: posixAccount
A ordem mostrada para as classes de objetos acima indica uma relação hierárquica entre
estas classes, mas não necessariamente. A classe top está no topo da hierarquia. Muitas
outras classes que não são subordinadas a nenhuma outra classe têm top como classe supe-
rior. A classe person é subordinada de top e requer que os atributos cn e sn sejam populados,
permitindo vários outros atributos opcionais. A classe organizationalPerson é uma subclasse
de person, portanto uma classe herdeira, assim como a classe inetOrgPerson.
Classes de objetos
objectclass ( <OID da classe de objeto>
[ “OBSOLETE” ]
Como exemplo, a classe posixAccount é subordinada à classe top e requer que os atributos
cn e uid, dentre outros, sejam populados. Perceba que isso se sobrepõe aos requerimentos
para cn da classe personΖVWRVLJQLȴFDTXHWHPRVTXHJXDUGDURDWULEXWRcn duas vezes? Não,
ambas as classes requerem a presença de um atributo cn. Não é possível adicionar atributos
sem valor ou apenas preenchidos com espaço, não havendo restrição em relação ao valor
contido ou existência de uma exclusividade de atributos em relação às classes.
2VP«WRGRVGHGHȴQL©¥RGHFODVVHGHREMHWRVSDUD/'$3YV¥RGHVFULWRVQDV5)&VH
$IRUPDJHQ«ULFDGHGHȴQL©¥RGHFODVVHVGHREMHWRV«PRVWUDGDDEDL[R
17
[ “DESC” <descrição da classe de objeto> ]
[ “OBSOLETE” ]
Cada classe de objeto começa com uma sequência de números delimitados por pontos.
(VWHVQ¼PHURVV¥RUHIHUHQFLDGRVFRPR2Ζ'2EMHFWΖGHQWLȴHU:+63«XPDDEUHYLD©¥RGH
“white space” e apenas indica a necessidade de um espaço. Depois do OID está o nome da
classe (NAME) seguido por uma descrição (DESC). Se a classe é subordinada a outra, a classe
VXSHULRU683«OLVWDGD)LQDOPHQWHDGHȴQL©¥RGDFODVVHGHREMHWRVHVSHFLȴFDRVDWULEXWRV
obrigatórios (MUST) e os opcionais (MAY).
MUST ( sn $ cn )
Atributos
attributetype ( <OID do atributo>
[ “SINGLE-VALUE” ]
[ “COLLECTIVE” ]
[ “NO-USER-MODIFICATION” whsp ]
18
7XGRTXHDFODVVHGHREMHWRVID]«GHȴQLURVDWULEXWRVRXRWLSRGHLWHQVGHGDGRVFRQWLGRV
HPXPWLSRGHREMHWR$GHȴQL©¥RGHDWULEXWRV«LQGHSHQGHQWHGDGHȴQL©¥RGHFODVVHGH
objetos. Alguns exemplos são atributos típicos como cn (common name), sn (surname), given-
Name, mail, uid e userPassword&RPRDVFODVVHVGHREMHWRVRVDWULEXWRVV¥RGHȴQLGRVFRP
OIDs únicos, com cada atributo contendo também um único número OID ligado a ele.
Uma classe de objeto instancia os atributos, permitindo que sejam utilizados de forma con-
VLVWHQWHQDVHQWUDGDVGRGLUHWµULR$GHȴQL©¥RGHDWULEXWRV«LQGHSHQGHQWHGDGHȴQL©¥RGH
uma classe de objetos.
1DGHȴQL©¥RGHXPDWULEXWRK£RS©·HVFRPR6832%62/(7(6Ζ1*/(9$/8(&2//(7Ζ9(
1286(502'Ζ)Ζ&$7Ζ21H86$*($VGHPDLVRS©·HVGHYHPVHUIRUQHFLGDVQDGHȴQL©¥R
0HVPRRXVRGHUHJUDVGHFRPSDUD©¥RGHSHQGHU£GHFDGDGHȴQL©¥R$WULEXWRVFRPDRS©¥R
SINGLE-VALUE não podem ter mais de um valor nas entradas. NO-USER-MODIFICATION é geral-
mente usado em atributos controlados ou de uso exclusivo do servidor do serviço de diretório.
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
O atributo telephoneNumber«GHȴQLGRFRPXP2Ζ'¼QLFRXPQRPHHXPDEUHYHGHVFUL©¥R
O nome é um apelido para o OID. Os valores que podem ser associados a este atributo são
descritos pela sintaxe 1.3.6.1.4.1.1466.115.121.1.50{32}, que aceita números, hífens e espaços
e no máximo até 32 caracteres.
1 A RNP adquiriu o OID 1.3.6.1.4.1.15996, e novos atributos e objetos podem ser nume-
rados a partir dele.
JXLGDGHVHHVWDEHOHFHUXPDSDGURQL]D©¥RSDUDDFRGLȴFD©¥RGHVVHVLGHQWLȴFDGRUHVRV2Ζ'V
são registrados por uma autoridade específica, a IANA (Internet Assigned Numbers Authority).
O sistema de numeração de objetos é hierárquico e a IANA garante que um OID será usado
por um objeto apenas.
Exemplos de sintaxes: q
1 Booleano: 1.3.6.1.4.1.1466.115.121.1.7
1 DN: 1.3.6.1.4.1.1466.115.121.1.12
1 Inteiro: 1.3.6.1.4.1.1466.115.121.1.27
19
1 Áudio: 1.3.6.1.4.1.1466.115.121.1.4 q
1 &HUWLȴFDGR
1 JPEG: 1.3.6.1.4.1.1466.115.121.1.28
$5)&GHȴQHXPFRQMXQWRGHVLQWD[HVTXHSRGHPVHUXVDGDVFRPR/'$3YHDVUHJUDV
SHODVTXDLVRVYDORUHVGRVDWULEXWRVGHȴQLGRVSRUPHLRGHVVDVVLQWD[HVV¥RUHSUHVHQWDGRVSDUD
serem transmitidos via protocolo LDAP. Destacamos alguns exemplos de sintaxes de atributos.
A RFC 2798 descreve um conjunto de regras de casamento para uso com o LDAP-v3.
Três tipos de comparação podem ser usados:
1 Igualdade (equality).
1 Ordenação (ordering).
1 Concatenação (substring).
Modelo de nomes
1 Entradas são nomeadas de acordo com sua posição na DIT. q
2 DNs são formados por Relative Distinguished Names (RDN) com a forma:
Entradas são arranjadas dentro da DIT com base em seus DNs. Um DN é um nome único
Federação CAFe: Implantação do Provedor de Identidade
Cada RDN em um DN corresponde a um ramo em uma DIT saindo da raiz até a entrada do
GLUHWµULR&DGD5'1«GHULYDGRGHDWULEXWRVGHHQWUDGDVGHGLUHWµULR'HIRUPDVLPSOLȴFDGD
um RDN tem a forma <nome do atributo> = <valor>. Um DN é composto de uma sequência
de RDNs separados por vírgulas.
(QWUDGDVHPXPGLUHWµULR/'$3V¥RLGHQWLȴFDGDVSRUVHXVQRPHV&DUDFWHU¯VWLFDVGHVWHVQRPHV
1 Eles têm duas formas, uma representação por cadeias de caracteres e uma URL.
20
Um componente de um nome é chamado de Relative Distinguished Name (RDN), que
representa o ponto dentro da hierarquia do espaço de nomes. RDNs são separados e
FRQFDWHQDGRVXVDQGRXPDY¯UJXOD&DGD5'1«GHXPWLSRGHȴQLGR5'1VSRGHPVHU
multi-valorados: atributo = valor + atributo = valor.
dc=rnp, dc=br
ou=bsa ou=rja
ou=operadores ou=hardware
$VLQWD[HH[DWDSDUDQRPHV«GHȴQLGDQD5)&2VH[HPSORVVHJXLQWHVV¥R'1VY£OLGRV
escritos na forma de string:
cn=Joao Silva,dc=RNP,dc=BR
ou=operadores + ou=funcionarios,ou=BSA,o=RNP
cn=Joao Silva,ou=operadores\,BSA,dc=RNP,dc=br
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
8VDQGRVHEDUUDLQYHUWLGD?WHPVHXPFDUDFWHUHGHHVFDSHSDUDXWLOL]DUY¯UJXODLJXDO
e demais caracteres especiais na formação dos RDNs:
ou=Antes\Depois,o=Teste,c=br
3DUDGHȴQL©¥RPDLVGHWDOKDGDVREUHDIRUPDGHVWULQJGH'1VFRQVXOWHD5)&
ldap://<host>:<porta>/<caminho>,
21
Onde <caminho> tem a forma:
<dn>[?<atributos>[?<escopo>?<filtro>]]]
O <dn> é um nome distinto LDAP (DN) usando a representação em string. O <atributo> indica
os atributos que devem ser retornados da entrada ou entradas. Se for omitido, todos os
atributos serão retornados. O <escopo>HVSHFLȴFDRHVFRSRGDEXVFDDVHUIHLWD2HVFRSR
SRGHVHUXPDHQWUDGDXPQ¯YHOHQWUDGDHȴOKRVLPHGLDWRVRXXPDVXE£UYRUHLQWHLUD
2ȴOWURHVSHFLȴFDRȴOWURGHEXVFDDVHUDSOLFDGR¢VHQWUDGDVGHQWURGRHVFRSRHVSHFLȴFDGR
durante a busca. O formato de URL permite a clientes de internet, por exemplo navegadores
web, terem acesso direto ao protocolo LDAP, e consequentemente ao diretório.
Modelo funcional
Três categorias de operações que podem ser realizadas em LDAPv3: q
1 Autenticação:
2 bind
2 unbind
2 abandon
1 Pesquisa:
2 search
2 compare
1 Atualização:
O modelo funcional LDAP é composto por três categorias de operações que podem ser
feitas contra um servidor LDAPv3:
1 Atualização: Add para adicionar uma entrada, Delete para excluí-la, ModifySDUDPRGLȴF£OD
e ModifyRDNSDUDPRGLȴFDUVHX5'1
1 ComparaçãoDRSHUD©¥RGHFRPSDUD©¥R«XWLOL]DGDSDUDYHULȴFDUDVHQWUDGDVTXH
têm um atributo com determinado valor. Se a entrada tem o valor, a operação Compare
retorna VERDADEIRO; caso contrário, retorna FALSO.
Federação CAFe: Implantação do Provedor de Identidade
Pesquisa: q
1 Base.
1 Escopo.
1 Filtro de busca.
1 Limites.
$RSHUD©¥RPDLVFRPXP«DGHSHVTXLVDEDVWDQWHȵH[¯YHOHFRPDOJXPDVRS©·HVPDLV
complexas, permitindo a um cliente pedir que o servidor LDAP pesquise através de alguma
SRU©¥RGD'Ζ7SURFXUDQGRLQIRUPD©·HVGHDFRUGRFRPRFULW«ULRHVSHFLȴFDGRHOLVWDQGRRV
UHVXOWDGRV1¥RK£GLVWLQ©¥RHQWUHOHUHOLVWDU$SHVTXLVDSRGHVHUPXLWRJHUDORXHVSHF¯ȴFD
22
(ODSHUPLWHHVSHFLȴFDUXPSRQWRGHLQ¯FLRGHQWURGD'Ζ7DSURIXQGLGDGHGDEXVFDRVDWUL-
butos que uma entrada deve ter para ser considerada compatível e os atributos que devem
ser retornados e ainda se os valores destes atributos devem ser retornados ou não.
3DUDUHDOL]DUXPDEXVFDRXSHVTXLVDRVVHJXLQWHVSDU¤PHWURVGHYHPVHUHVSHFLȴFDGRV
1 BaseXP'1TXHGHȴQHRSRQWRGHLQ¯FLRGDEXVFDFKDPDGRGHREMHWREDVH2REMHWR
base é um nó dentro da DIT.
1 EscopoHVSHFLȴFDDSURIXQGLGDGHGDEXVFDLQLFLDGDGRREMHWREDVHGHQWURGD'Ζ7+£WU¬V
escolhas: baseObject, singleLevel e wholeSubtree. Se baseObject«HVSHFLȴFDGRVRPHQWHRREMHWR
base é examinado. Se singleLevel«HVSHFLȴFDGRVRPHQWHDVHQWUDGDVȴOKDVGRREMHWREDVHV¥R
examinadas. Já com wholeSubtree, o objeto base e todos seus descendentes são examinados.
1 Filtro de buscaHVSHFLȴFDRFULW«ULRDRTXDOXPDHQWUDGDGHYHVHHQFDL[DUSDUDTXHVHMD
retornada na pesquisa.
1 Atributos para serem retornados: seleciona os atributos que devem ser retornados das
entradas que se encaixam no critério de busca.
Filtros de busca
Operador Exemplo
& (&(cn=joao)(sn=silva))
| (|(uid=joao)(uid=silva))
! (!(uid=joao))
= gidNumber=100
~= sn~=silv
>= uidNumber>=5000
<= Sn<=silva
Tabela 2.2
Atributo * *
RSHUDGRUYDORU
8PȴOWURGHEXVFDGHȴQHDTXDOFULW«ULRXPDHQWUDGDGHYHVHHQFDL[DUSDUDVHUUHWRUQDGDHP
XPDSHVTXLVD2FRPSRQHQWHE£VLFRGHXPȴOWURGHEXVFD«XPYDORUGHDWULEXWRQDIRUPD
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
)LOWURVGHEXVFDSRGHPVHUFRPELQDGRVFRPRSHUDGRUHVOµJLFRVSDUDIRUPDUȴOWURVPDLV
FRPSOH[RV$VLQWD[HSDUDFRPELQDUȴOWURV«
Operadores:
= 5, igualdade
~= aproximação
=* quaisquer caracteres
23
2SHUD©·HVGHDXWHQWLFD©¥RV¥RXVDGDVSDUDHVWDEHOHFHUHȴQDOL]DUXPDVHVV¥RHQWUHXP
cliente e um servidor LDAP. A sessão pode estar segura em vários níveis, desde uma sessão
DQ¶QLPDLQVHJXUDXPDVHVV¥RDXWHQWLFDGDQDTXDORFOLHQWHLGHQWLȴFDVHSRUIRUQHFHUXPD
senha) até sessão criptografada com mecanismos SASL ou SSL.
1 Bind: inicia uma sessão LDAP entre um cliente e um servidor. Permite ao cliente
LGHQWLȴFDUVHDRVHUYLGRU
Representação LDIF
LDAP Data Interchange Format: q
1 Descrição de conjunto de entradas.
<atributo>: <valor>
<atributo>: <valor>
Uma linha pode ser continuada, começando uma nova linha com um caractere de espaço
ou tabulação:
$WULEXWRVPXOWLYDORUDGRVV¥RHVSHFLȴFDGRVHPOLQKDVVHSDUDGDV
cn: João
6HRYDORUGHXPDWULEXWRFRQW«PXPFDUDFWHUHTXHQ¥RHVWHMDQDFRGLȴFD©¥R86$6&ΖΖ
ou comece com um espaço ou dois-pontos (:), o valor do atributo é seguido por um duplo
GRLVSRQWRVHFRGLȴFDGRHPXPDQRWD©¥RHPEDVH(QWUHWDQWR«VHPSUHSRVV¯YHO
XVDUDFRGLȴFD©¥R87)SDUDVXSRUWDULQWHUQDFLRQDOL]D©¥R
Federação CAFe: Implantação do Provedor de Identidade
<attrdesc>: <attrvalue>
<attrdesc>: <attrvalue>
<attrdesc>:: <base64-encoded-value>
24
<attrdesc>:< <URL> q
...
dn: o=rnp
objectclass: top
objectclass: organization
o: RNP
dn: ou=esr
objectClass: top
objectclass: organizationalUnit
ou: ESR
&RPHVWHWLSRGH/'Ζ)TXDQGRXPDHQWUDGD«PRGLȴFDGDDHQWUDGD«VREUHVFULWDLVWR«
todas as informações da entrada no diretório são substituídas pelas informações no LDIF
quando é feita uma operação de atualização. Os atributos que não existem no LDIF, mas que
existem na entrada do diretório serão apagados quando for realizada a operação de atuali-
zação. As operações com este tipo de LDIF são similares a sobrescrever um arquivo de um
sistema operacional por outro arquivo; as informações do arquivo antigo deixam de existir,
dando lugar a novas informações. Esta estrutura de LDIF é importante ao carregar ou fazer
uma cópia do diretório inteiro e adicionar uma nova entrada.
,dc=rnp,dc=br
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
objectclass: top
objectclass: person
sn: Silva
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
cn:< file:///tmp/arquivo
25
Já um LDIF estruturado em sequências de atualização contém apenas as informações rele-
YDQWHVSDUDDVPRGLȴFD©·HVQHFHVV£ULDVDXPDHQWUDGDGRGLUHWµULR&RPSDUDGRDRWLSR
anterior, onde o foco está em operações realizadas nas entradas como um todo, em um LDIF
RWLSRGHVHTX¬QFLDVGHDWXDOL]D©¥RSHUPLWHUHDOL]DUPRGLȴFD©·HVHPXP¼QLFRDWULEXWRGH
uma entrada. Sua forma básica é:
<operação>: <atributo>
<atributo>: <valor>
<operação>: <atributo>
<atributo>: <valor>
...
Observe que em todos os tipos de LDIF as entradas são separadas por uma linha em branco
e, para um LDIF de sequências de atualização, cada operação em um atributo diferente deve
ser separada por uma linha contendo um hífen (-).
changetype: <[modify|add|delete|modrdn]>
<[modify|add|delete|modrdn]>: <attributetype>
<attrdesc>: <value1>
...
<[modify|add|delete|modrdn]>: <attributetype>
<attrdesc>: <value1>
q
Federação CAFe: Implantação do Provedor de Identidade
<attrdesc>: <value2>
...
changetype: add
objectclass: person
objectclass: inetorgperson
26
cn: Joao q
cn: Joao Silva
sn: Silva
changetype: modify
add: givenName
givenName: jo
givenName: Joao
replace: description
2 0RGLȴFDRVGDGRVQRGLUHWµULRVHMDPRGLȴFDQGRHQWUDGDVRXDGLFLRQDQGRDV
2 5HDOL]DEXVFDVQRGLUHWµULRGHDFRUGRFRPFULW«ULRVHVSHF¯ȴFRV
Os comandos listados fazem parte da distribuição do OpenLDAP. Estes comandos shell são
XWLOL]DGRVFRPDUJXPHQWRVTXHFRQȴJXUDPDRSHUD©¥RTXHVHGHVHMDUHDOL]DUQRGLUHWµULR
O ldapadd é na realidade um ldapmodify com o argumento -a indicando adição de entradas.
Para o ldapadd, os parâmetros mais comuns são um usuário com permissão de escrita, uma
senha e um arquivo LDIF contendo as entradas a serem adicionadas no diretório. No caso do
ldapmodifyRTXHPXGD«TXHRDUTXLYR/'Ζ)FRQW«PRVGDGRVTXHGHYHPVHUPRGLȴFDGRV
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
seja por operação de exclusão ou adição de novos dados, ou apenas através da substituição
de valores de atributos. O ldapdelete também precisa de um usuário com permissões de
escrita, e o arquivo que é passado como parâmetro contém uma lista de DNs que devem ser
H[FOX¯GRVGRGLUHWµULR(VWDOLVWDSRGHVHUSDVVDGDQDOLQKDGHFRPDQGR3RUȴPldapsearch
requer os parâmetros listados anteriormente e o resultado da busca está sujeito a permis-
sões de acesso ao diretório para o usuário utilizado.
-W -f arquivo.ldif
ldapsearch -x -D “cn=admin,dc=esr,dc=rnp,dc=br” –W –b
27
“dc=curso,dc=ldap” uid=00123456 q
ldapdelete –x –D “cn=admin,dc=esr,dc=rnp,dc=br” –W “uid=dijkstra,
ou=people,dc=esr,dc=rnp,dc=br”
1. -x: informa ao comando para utilizar bind simples, não utilizando SASL.
2. -DGHȴQHTXDOVHU£DLGHQWLGDGHXWLOL]DGDSDUDUHDOL]DUDRSHUD©¥R
3. -W: retorna o prompt para que a senha da identidade indicada com o parâmetro -D
seja digitada.
Figura 2.3
)HUUDPHQWDJU£ȴFD
– Apache Directory
6WXGLR
Apache Directory Studio é um cliente LDAP feito em uma plataforma Eclipse e possuindo
uma série de plugins. O ApacheDS é uma ferramenta completa para ser utilizada em qual-
Federação CAFe: Implantação do Provedor de Identidade
quer servidor LDAP. LDAP Browser permite não apenas mostrar os dados como também
FULDUPRGLȴFDUHGLWDUHUHPRYHUHQWUDGDV
A Figura 2.4 mostra a tela inicial do ApacheDS. Para utilizá-lo como cliente LDAP, basta ir ao
PHQX/'$3HFRQȴJXUDUDFRQH[¥RFRPXPVHUYLGRU
28
Figura 2.4
Conexão com o
VHUYLGRU/'$3
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
Figura 2.5
Administrador
GDEDVH/'$3
$WHODPRVWUDGDQD)LJXUDSHUPLWHFRQȴJXUDUDVRS©·HVGHDFHVVRRXVHMDXVX£ULRH
senha de acesso ao servidor LDAP.
29
Figura 2.6
Opções de
navegação
QRGLUHWµULR
Com a opção “Fetch Base DNs” é possível obter o DN da base LDAP apenas consultando o servidor.
Federação CAFe: Implantação do Provedor de Identidade
Figura 2.7
Tela principal
GR$SDFKH'6
30
A Figura 2.7 mostra o ambiente padrão da função browser do ApacheDS, que possibilita navegar
SHORGLUHWµULR/'$3HH[HFXWDUFRPVLPSOLFLGDGHPRGLȴFD©·HVQRVGDGRV3RGHVHSHUFHEHU
DVDEDVGHVFULWDVFRPRȊ/'$3%URZVHUȋȊ(QWU\(GLWRUȋHȊ0RGLȴFDWLRQ/RJVȋTXHV¥R¼WHLVQD
administração de alguns dados e para a visualização de informações no diretório.
Esquema brEduPerson
Esquema proposto para membros de instituições de ensino superior no Brasil, q
com relacionamentos modelados em estrutura hierárquica. Divide-se em:
1 ΖQIRUPD©·HVHVSHF¯ȴFDVVREUHIXQFLRQ£ULRVHDOXQRV
1 brEduPerson
1 EU(GX$ɝOLDWLRQ7\SHEU(QWUDQFH'DWHEU([LW'DWHEU(GX$ɝOLDWLRQ
1 brBiometricData
2HVTXHPDEU(GX3HUVRQGHȴQHTXDWURFODVVHVGHREMHWRV
2 brEduVoIP
3 brEduVoIPalias
3 brEduVoIPtype
3 brEduVoIPadmin
3 brEduVoIPcallforward
3 brEduVoIPaddress
3 brEduVoIPexpiryDate
3 brEduVoIPbalance
3 brEduVoIPcredit
3 brEduVoIPphone
31
Modelo de nomes para uso na Federação CAFe
1 1HFHVVLGDGHGHUHȵHWLUQDEDVHGHGDGRVRIDWRGHXPDPHVPDSHVVRDGHVHPSHQKDU q
diferentes papéis dentro da sua instituição ou possuir mais de um número VoIP, cada
um com suas características, ou armazenar dados biométricos de fontes distintas.
1 Exemplos:
3 Coordenação de curso.
3 Direção de unidade.
$RGHȴQLURPRGHORGHQRPHVDVHUXVDGRHPLQVWLWXL©·HVGHHQVLQRHSHVTXLVD«QHFHVV£ULR
tratar a questão do modelamento de relacionamentos entre conjuntos de informações.
Devemos capturar na base de dados, por exemplo, o fato de uma mesma pessoa poder
desempenhar diferentes papéis dentro da instituição. Exemplos: um aluno matriculado em
mais de um curso, um professor desempenhando diferentes funções, com cada uma delas
associada a uma data de ingresso e de saída, entre outras informações.
Para modelar esses relacionamentos, estudamos algumas alternativas e optamos pelo uso
de uma solução hierárquica, que será descrita a seguir.
Modelo proposto
1 O item principal – pessoa de uma instituição – será tratado como um container abaixo q
do qual aparecerão nós com as informações relacionadas.
2 Telefones VoIP.
2 Fontes biométricas.
Os nós em um diretório LDAP formam uma árvore. Cada nó, independentemente de ser pai
de algum outro nó na árvore, é uma entrada com suas próprias informações (atributos).
O item principal (em nosso exemplo, uma pessoa com inserção em instituição de ensino
e/ou pesquisa) com o qual se deseja relacionar as demais informações, será tratado como
Federação CAFe: Implantação do Provedor de Identidade
Por exemplo, abaixo da entrada que descreve dados básicos de uma pessoa, podemos ter
entradas descrevendo vínculos como professor e aluno.
32
João
Telefone
Vínculo 1 VoIP 1
do João do João
Vínculo 2 Telefone
do João VoIP 2
do João
Figura 2.8
Entradas
Dado biométrico do dedo
descrevendo
polegar esquerdo do João
Y¯QFXORV
Esta solução tem como vantagem o fato de ser mantida a possibilidade de recuperação da
informação em uma única consulta e os tipos originais dos atributos, e de não serem criadas
FODVVHVHDWULEXWRVDUWLȴFLDLV
Como desvantagem, temos uma árvore cuja topologia é ditada por relacionamentos, o que
pode causar confusão por não ser a maneira tradicional de desenhar uma topologia.
Exemplos de entradas:
dn: uid=silvana,ou=people,dc=uff,dc=br
objectClass: person
objectClass: inetOrgPerson
objectClass: brPerson
objectCass: schacPersonalCharacteristics
uid: silvana
brcpf: 12345678900
brpassport: A23456
schacCountryOfCitizenship: Brazil
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
cn: Silvana
userPassword: ******
dn: braff=1,uid=silvana,ou=people,dc=uff,dc=br
objectclass: brEduPerson
braff: 1
brafftype: faculty
brEntranceDate: 20070205
33
dn:braff=2,uid=silvana,ou=people,dc=uff,dc=br
objectclass: brEduPerson
braff: 2
brafftype: student
brEntranceDate: 20070205
brExitDate: 20080330
dn:brvoipphone=1,uid=silvana,ou=people,dc=uff,dc=br
objectclass: brEduVoIP
brvoipphone: 1
brvoipalias: 2346
brEduVoIPtype: pstn
brEduVoIPadmin:uid=admin,ou=people,dc=uff,dc=br
uid=silvana
brcpf:12345678900
brpassaport: A23456
schacCountryOfCitizenship:Brazil Saiba mais
telephoneNumber:+55 22 81389199
cn:Silvana Consulte o documento
“Proposta de Esquema
brEduPerson - Fede-
UD©¥R&$)HȋGLVSRQ¯YHO
EUD QRVLWHGD&$)H
EUYRLSSKRQH
btafftype:faculty brvoipalias:2346
brEntranceDate:20070205 brEduVoIPtype:pstn
EUD
brafftype:student
brEntranceDate:20070205
brExitDate:20080330 Figura 2.9
Federação CAFe: Implantação do Provedor de Identidade
Entradas.
Esquemas: q
1 brEduPerson-20080917-0.0.6.schema
1 schac-20061212-1.3.0.schema
1 RFC 2252
1 RFC 2798
34
Roteiro de Atividades 2
Atividade 2.1 – Instalar e configurar um serviço de diretório OpenLDAP
Execute os comandos passo a passo para a instalação do diretório LDAP na sua máquina
virtual. Para facilitar abra um terminal SSH e copie e cole os comandos.
sudo su -
apt-get update
debconf-set-selections <<-EOF
EOF
4. 3DUHRVHUYL©RGH/'$3«QRUPDOGDUHUURSRLVDLQGDQ¥RIRLFRQȴJXUDGR
/etc/init.d/slapd stop
5. )D]HUDFµSLDGRVDUTXLYRVGHFRQȴJXUD©¥R
cp /opt/treinamento/ldap/slapd /etc/default/slapd
cp /opt/treinamento/ldap/slapd.conf /etc/ldap/slapd.conf
cp /opt/treinamento/ldap/ldap.conf /etc/ldap/ldap.conf
&DS¯WXOR5RWHLURGH$WLYLGDGHV
cp /opt/treinamento/ldap/DB_CONFIG /var/lib/ldap/DB_CONFIG
cp /opt/treinamento/ldap/eduperson.schema /etc/ldap/schema/
eduperson.schema
cp /opt/treinamento/ldap/breduperson.0.0.6.schema /etc/ldap/schema/
breduperson.0.0.6.schema
cp /opt/treinamento/ldap/schac-20061212-1.3.0 /etc/ldap/schema/
schac-20061212-1.3.0
35
6. Após fazer a cópia dos arquivos, deve-se atentar para a necessidade de fazer breves alte-
rações em alguns dos arquivos conforme segue:
dc=instituicao,dc=br
1 /etc/ldap/ldap.conf: deve-se substituir as ocorrências de ${RAIZ_BASE_LDAP} pelo
valor correspondente à raiz da base LDAP.
Exemplo:
:%s/ ${RAIZ_BASE_LDAP}/dc=ufmg,dc=br/g
7. *HUD©¥RGHFHUWLȴFDGR66/SDUD/'$3DQWHVGHH[HFXWDUHVWHFRPDQGRWURTXHDVRFRU-
rências de SUBSTITUIR_IP_MAQUINA pelo IP da sua VM.
&HUWLȴTXHVHGHTXHRDUTXLYR/opt/treinamento/openssl.cnfSRVVXLRVHXΖ3FRQȴJXUDGR
Se o IP que consta no arquivo for diferente, edite trocando para o IP da sua VM.
/etc/init.d/slapd start
9. Carga Inicial de Dados: o LDAP que foi instalado encontra-se vazio, ou seja, não há
nenhum elemento em sua base de dados. Agora faremos a carga inicial de dados na
base LDAP. Para isso, edite o arquivo popula.sh que se encontra no arquivo /opt/treina-
Federação CAFe: Implantação do Provedor de Identidade
vim /opt/treinamento/popula.sh
/etc/init.d/slapd stop
sh /opt/treinamento/popula.sh
/etc/init.d/slapd start
36
11. Execute os seguintes comandos para instalar utilitários para manipulação do LDAP:
/etc/init.d/slapd restart
dn: uid=<LOGIN>,ou=people,dc=<SUA_INSTITUICAO>,dc=br
objectClass: person
objectClass: inetOrgPerson
objectClass: brPerson
objectClass: schacPersonalCharacteristics
uid: <LOGIN>
brcpf: 12345678900
brpassport: A23456
schacCountryOfCitizenship: Brazil
mail: <EMAIL>
cn: <NOME>
sn: <SOBRENOME>
userPassword: <SENHA>
schacGender: 10
- D <DN>HVSHFLȴFDXP'1SDUDUHDOL]DURELQG
-WPRVWUDRSURPSWSDUDGLJLWDUDVHQKDGR'1HVSHFLȴFDGRFRPDRS©¥R-D.
- f <arquivo>HVSHFLȴFDXPDUTXLYR/'Ζ)FXMRVGDGRVVHU¥RDGLFLRQDGRVDRGLUHWµULR
37
3. 9HULȴTXHDLQVHU©¥RGRVGDGRVQRGLUHWµULRVXEVWLWXLQGR/2*Ζ1!H68$BΖ167Ζ78Ζ&$2!
pelo valor associado no item 1.
ldapsearch -x -D “cn=admin,dc=<SUA_INSTITUICAO>,dc=br” –W –b
dc=<SUA_INSTITUICAO>,dc=br “uid=<LOGIN>”
- bHVSHFLȴFDXPDEDVHSDUDFRPH©DUDEXVFDGHYHVHUXP'1GDEDVH/'$3
“uid=<LOGIN>”ȴOWURGHEXVFDTXHVHOHFLRQDDVHQWUDGDVTXHVHHQFDL[DPQRFULW«ULR
HVSHFLȴFDGR
ldapdelete “uid=<LOGIN>,ou=people,dc=<SUA_INSTITUICAO>,dc=br” -x -D
“cn=admin,dc=<SUA_INSTITUICAO>,dc=br” –W
5. 9HULȴTXHDUHPR©¥RGDHQWUDGDUHSHWLQGRRFRPDQGRGRLWHP
4. &RQȴJXUHR'1GDEDVH
1 Clique em “Finish”;
1 Abra o arquivo people.ldif (que se encontra na pasta treinamento da sua área de tra-
balho do Windows) e edite-o trocando <SUA_INSTITUICAO> pela sigla da sua instituição.
Salve o arquivo;
1 Para importar o LDIF, clique na seta verde (Execute LDIF) ao lado do botão “Browse” e
observe a importação das entradas;
1 9HULȴTXHVHDVHQWUDGDVIRUDPLPSRUWDGDV
38
3
Construindo metadiretórios
com EID
objetivos
conceitos
Metadiretórios e Export Import Directory (EID).
'LUHWµULRVTXHSRVVXHPXPEDL[RȵX[RGHSHVVRDVRXSRXFDVGH]HQDVGHFDGDVWURVSRGHP
ser facilmente gerenciados pela inclusão e exclusão manual de registros. Diretórios com muitos
usuários e com comportamento mais dinâmico demandam um esforço maior de manutenção,
o que praticamente inviabiliza seu gerenciamento manual. Este é o caso de diretórios acadê-
micos, onde entram e saem centenas (ou milhares) de pessoas todos os semestres.
(QWUHWDQWRRVSURFHVVRVTXHLPSOLFDPQDPRGLȴFD©¥RGRGLUHWµULRM£H[LVWHPHHPJHUDO
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
2GHVHQYROYLPHQWRGHH[WUDWRUHVSDUDRFHQ£ULRHVSHF¯ȴFRGHXPDRUJDQL]D©¥RSRGHVHU
muito alto, porém a ideia central é sempre a mesma: consolidar os dados para a construção
do diretório. O objetivo do Export Import Directory (EID) é facilitar a integração de dados de
GLYHUVRVVLVWHPDVSDUDFRQVWUXLUXPPHWDGLUHWµULRHSRUȴPXPRXPDLVGLUHWµULRV
Metadiretório
1 Base de dados intermediária para construção do diretório. q
1 0RGHORLQGHSHQGHGRHVTXHPDȴQDOGRGLUHWµULR
39
Um metadiretório é uma junção de esquemas e atributos de diferentes repositórios em uma
visão comum. O metadiretório ideal permite a um administrador fazer alterações em um
repositório e prover a atualização da informação em todos os diretórios ligados a ele.
Figura 3.1
Fluxo de
informações em
XPPHWDGLUHWµULR
$)LJXUDGHPRQVWUDRȵX[RGHLQIRUPD©·HVHPXPPHWDGLUHWµULRRVGDGRVGDVEDVHV
corporativas serão importados para o metadiretório, e do metadiretório os dados podem ser
exportados para o LDAP e serem utilizados para autenticação em um portal, por exemplo.
EID
1 Desenvolvido pelo Grupo São Tomé da UFMG. q
1 Recursos da RNP:
2 GTs diretório.
2 Projeto e-AA.
1 Recursos da SESu/MEC:
2 Projeto PingIFES.
O EID foi desenvolvido pelo Grupo São Tomé da UFMG para ser utilizado no projeto Infra-
HVWUXWXUDGH$XWHQWLFD©¥RbH$XWRUL]D©¥RH$$TXHWHPFRPRREMHWLYRSULQFLSDOLPSODQWDU
um serviço experimental de autenticação e autorização federativa para as instituições de
Federação CAFe: Implantação do Provedor de Identidade
ensino e pesquisa.
1 Extensão do PCollecta.
O EID foi desenvolvido tendo por base a ferramenta PCollecta, uma ferramenta de Extração,
Transformação e Carga (ETL), utilizada pelas instituições de ensino superior para alimen-
WD©¥RGRPRGHORGHGDGRV3LQJΖ)(6GHȴQLGRSHOR0(&2(Ζ'«LQWHJUDGRDRVSURFHVVRV
administrativos já consolidados pelas instituições e possibilita a atualização contínua dos
dados importados das bases corporativas.
40
1 Importação por conexão direta nas bases institucionais. q
1 Exposição dos dados via web services:
O EID pode conectar-se diretamente às bases de dados institucionais, desde que seja possível
utilizar conectores JDBC para bancos relacionais, além de arquivos CSV e diretórios LDAP.
Os dados importados são associados a pessoas, e os registros completos dessas pessoas podem
ser facilmente recuperados utilizando uma interface web service disponibilizada pelo EID.
q
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
1 2EMHWRVSRVVXHPXPLGHQWLȴFDGRUJOREDOFKDPDGR*OREDO8QLTXHΖGHQWLȴHU*8Ζ'
O EID utiliza o conceito de Objeto (EidObject) para representar as informações que arma-
]HQD6¥RFRQVLGHUDGRVREMHWRVSHVVRDVHGHȴQL©·HVGHJUXSRV8PREMHWR«XPDHQWLGDGH
TXHSRVVXLXPLGHQWLȴFDGRU¼QLFRHXPFRQMXQWRGHDWULEXWRVVHQGRDXQLGDGHP¯QLPDGH
armazenamento de informações.
2VDWULEXWRVV¥RPDSHDPHQWRVQRPHYDORURQGHRYDORUSRVVXLXPWLSRRXGRP¯QLRGHȴQLGR
2VQRPHVHRVWLSRVGRVDWULEXWRVV¥RHVSHFLȴFDGRVHPHQWLGDGHVGHQRPLQDGDVFODVVHV
41
$VFODVVHVV¥RGHȴQL©·HVGHDJUXSDPHQWRVGHDWULEXWRV&DGDFODVVHSRGHVHUFRQVLGHUDGD
XPDGHȴQL©¥RGHXPWLSRGHGDGRFRPSRVWR
7RGRREMHWRSRVVXLXPLGHQWLȴFDGRUJOREDOGHQRPLQDGR*8Ζ'JHUDGRDXWRPDWLFDPHQWH
SHODIHUUDPHQWDTXHRLGHQWLȴFDXQLFDPHQWHHPWRGRVLVWHPD(VVHDWULEXWR«GHȴQLGRSRU
uma classe especial denominada EidObject.
Figura 3.3
Estrutura dos
GDGRV
Toda classe criada na aplicação gera uma tabela no banco de dados. A classe EidObject se
relaciona com as demais classes do sistema, denominadas EidClasses. Qualquer classe
GHȴQLGDSHORXVX£ULR«XPDEidClass. Essas classes agregam a um objeto EID seus
DWULEXWRVHVSHF¯ȴFRV
EID e brEduPerson
1 Classes fornecidas pelo grupo e-AA: q
2 ΖGHQWLȴFD©¥R
2 Conta.
2 E-mail.
2 Endereço.
2 Telefone.
Federação CAFe: Implantação do Provedor de Identidade
2 Professor.
2 Técnico.
2 Aluno.
2 Biometria.
1 'HȴQHPRVDWULEXWRVQHFHVV£ULRVSDUDEU(GX3HUVRQ
1 &RQYHUV¥RSU«FRQȴJXUDGDGDVFODVVHVSDUD/'Ζ)
1 2XWUDVFODVVHVSRGHPVHUGHȴQLGDV
2(Ζ'Q¥RHVW£OLPLWDGRDFODVVHVHVSHF¯ȴFDVH[FHWRSHODH[LJ¬QFLDGDVFODVVHVΖGHQWLȴFD©¥R,
Grupo e MembroDeGrupoGHIRUPDTXHFODVVHVSRGHPVHUGHȴQLGDVDFULW«ULRGDRUJDQL-
zação utilizadora.
42
Com o intuito de facilitar a implantação da federação, o grupo e-AA fornece algumas classes
TXHSRGHPVHUXVDGDVSDUDDOLPHQWDUGLUHWµULRV/'$3VHPQHQKXPDFRQȴJXUD©¥RDGLFLRQDO
$UD]¥RGLVVR«TXHM£H[LVWHXPDFRQYHUV¥RSU«FRQȴJXUDGDSDUDDIHUUDPHQWD(Ζ'/'$3
FRPRYHUHPRVDGLDQWH$VFODVVHVIRUQHFLGDVSHORJUXSRH$$GHȴQHPRVDWULEXWRVQHFHVV£-
rios para brEduPerson.
2XWUDVFODVVHVSRGHPVHUGHȴQLGDVSHODSUµSULDRUJDQL]D©¥RSDUDVXSULUVXDVQHFHVVLGDGHV
(VWDVPRGLȴFD©·HVFHUWDPHQWHGHYHU¥RVHUWDPE«PUHȵHWLGDVQDFRQYHUV¥RXWLOL]DGDSHOR
(Ζ'/'$3SDUDTXHDVLQIRUPD©·HVȵXDPDXWRPDWLFDPHQWHSDUDRGLUHWµULR
Acesso
1 Deve existir um ou mais administradores. q
1 Responsabilidades:
2 'HȴQLUFODVVHV
2 'HȴQLUUHSRVLWµULRVGHRULJHP
2 &RQȴJXUDUDVH[WUD©·HV
2 Agendar as extrações.
2 $GPLQLVWUDGRUUHVSRQV£YHOSHODFRQȴJXUD©¥R
8VX£ULRVGHȴQLGRVHPDUTXLYR;0/SDGU¥R
2XVX£ULRDGPLQLVWUDGRUGHYHU£GHȴQLUDVFODVVHVQHFHVV£ULDV¢LQVWLWXL©¥RXWLOL]DGRUDID]HU
DVFRQȴJXUD©·HVQHFHVV£ULDVSDUDDUHDOL]D©¥RGHH[WUD©·HVGHGDGRVGHRXWUDVIRQWHVSDUD
alimentar o metadiretório, além de fazer a gestão manual de pessoas e grupos.
A autenticação do EID pode ser feita com vários tipos de bases de usuários (arquivo XML,
EDQFRUHODFLRQDO/'$3HWFTXHV¥RFRQȴJXUDGDVQRVHUYLGRUGHDSOLFD©¥R7RPFDW
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
Na tela inicial do EID, a grande maioria dos comandos está localizada na parte superior da
tela, que disponibiliza menus e botões. Em algumas telas os botões podem ser encontrados
em outras posições, o que é mais comum nos casos onde a tela demanda a inclusão de uma
lista de itens.
1 O menu &RQȴJXUD©¥RSRVVLELOLWDFRQȴJXUDURVUHSRVLWµULRVH[WUD©·HVSURFHVVRVSDU¤-
PHWURVJOREDLVHDLQGDDRS©¥RGHLPSRUWDUHH[SRUWDUFRQȴJXUD©¥RGHSURFHVVRV
43
1 O menu Administração dá acesso à consulta de mapeamentos dos sistemas e também à
consulta a repositórios de dados cadastrados.
Configurações iniciais
1 Diretório de instalação do EID. q
1 Classes.
2(Ζ'FRPSLODFµGLJR-DYDGLQDPLFDPHQWHSDUDFDGDQRYDFODVVHGHȴQLGD2FµGLJRHDV
classes compiladas são colocados no diretório WEB-INF da aplicação, motivo pelo qual é
QHFHVV£ULRFRQȴJXUDUHVWHFDPLQKRQRVLVWHPD3DUDUHDOL]DUHVWDFRQȴJXUD©¥RDFHVVHR
menu EID e escolha a opção &RQȴJXUD©¥RNesta tela deverá ser informado o caminho para o
diretório WEB-INF do EID, diretório localizado dentro do Tomcat no qual sua aplicação está
sendo executada.
(PVHJXLGDGHYHPVHUGHȴQLGDVDVFODVVHVTXHVHU¥RDOLPHQWDGDVPXLWRHPERUDQRYDV
FODVVHVSRVVDPVHUGHȴQLGDVSRVWHULRUPHQWH
$GLVWULEXL©¥RSDGU¥RM£FRQȴJXUDSUHYLDPHQWHRGLUHWµULRGHLQVWDOD©¥RHDVFODVVHVTXH
serão utilizadas no decorrer do curso.
2(Ζ'FRQȴDQDH[LVW¬QFLDGHWU¬VFODVVHVE£VLFDVSDUDDFRQFLOLD©¥RGHUHJLVWURVHFULD©¥RGH
agrupamentos, que são as seguintes classes:
1 ΖGHQWLȴFD©¥RGDGRVE£VLFRVGHLGHQWLȴFD©¥RSHVVRDO
1 GrupoGHȴQL©¥RGHFULW«ULRVGHDJUXSDPHQWR
Figura 3.4
'HȴQL©¥RGH
FODVVHV
$)LJXUDPRVWUDDWHODGHOLVWDJHPGHFODVVHVGHȴQLGDVQRVLVWHPD1DYHUV¥RDWXDOGR
VLVWHPDDDOWHUD©¥RQDGHȴQL©¥RGHXPDFODVVHQ¥R«VXSRUWDGDSRGHQGRSURGX]LUHUURV
De uma forma geral, todas as telas do sistema apresentam uma caixa de seleção, que é
usada para selecionar registros para exclusão, um comando para visualizar os detalhes
44
de cada registro (representado pela lupa) e um comando para editar os dados do registro
(representado pelo lápis/caderno).
Para a tela de gestão de classes existe ainda o comando de excluir registros. Este comando
promove a exclusão de todos os registros da classe em questão. Um caso especial é o da
classe ΖGHQWLȴFD©¥R, que só pode ser removida após não existirem outras classes preenchidas.
2SDLQHOȊ$OJRULWPRGHGHGXSOLFD©¥RȋGHȴQHDFODVVH-DYDUHVSRQV£YHOSHODGHGXSOLFD©¥R
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
XQLȴFD©¥RMXQ©¥RGHVFDUWHGDVLQVW¤QFLDVGHVVDFODVVH
Este algoritmo pode ser cadastrado via upload ou inserção manual do conteúdo e deve
LPSOHPHQWDUDFODVVHΖ&ODVV8QLȴHU7DPE«P«SRVV¯YHODSHQDVHVSHFLȴFDURQRPHFRPSOHWR
incluindo o caminho da classe caso ela esteja disponível no EID.
Caso não seja informado um algoritmo de deduplicação, o EID utiliza um algoritmo padrão para
ID]HUDPHVFODJHPGRVDWULEXWRVEUXIPJOFFHLGPRGHOXQLȴHU'HIDXOW6LQJOHΖQVWDQFH8QLȴHU
caso a classe permita apenas uma instância por objeto, ou um algoritmo padrão para
DGLFLRQDUDLQVW¤QFLDDXPDOLVWDEUXIPJOFFHLGPRGHOXQLȴHU'HIDXOW0XOWLSOHΖQVWDQFH8QLȴHU
caso a classe permita várias instâncias.
45
Configuração de extrações
Envolve: q
1 Repositórios.
1 ETCs.
1 Processos.
1 Agendamentos.
$FRQȴJXUD©¥RGHH[WUD©·HVSDVVDSHORFDGDVWURGHUHSRVLWµULRVGHȴQL©¥RGHH[WUD©·HV
processos de extrações e agendamento dos processos.
Definição de repositórios
1 Fontes ou destinos de dados. q
1 'HVWLQRȴ[R
2 Bancos relacionais.
2 Arquivos texto.
2 Diretórios LDAP.
$QWHVTXHVHMDPGHȴQLGDVDVH[WUD©·HV«QHFHVV£ULRTXHVHMDPGHȴQLGDVDVIRQWHVGH
dados, considerando que o destino é sempre único: o metadiretório gerenciado pelo EID.
As fontes são os bancos de dados institucionais que o alimentarão, como as bases do RH,
sistema acadêmico de graduação ou pós-graduação, planilhas etc.
O driver JDBC deve estar presente no diretório lib do Tomcat no momento de sua iniciali-
zação para que seja reconhecido. Deve-se ter atenção especial para a versão do driver; con-
Federação CAFe: Implantação do Provedor de Identidade
sulte as instruções do fornecedor do banco para saber a versão mais adequada para uma
determinada versão de banco.
$GHȴQL©¥RGHUHSRVLWµULRV«DFHVVDGDSHORPHQXȊ&RQȴJXUD©¥R5HSRVLWµULRGH'DGRVȋ
46
Figura 3.6
Administração
GHUHSRVLWµULRV
A Figura 3.6 exibe a tela de administração de repositórios, onde é possível exibir, alterar
ou remover repositórios cadastrados no sistema, ou ainda cadastrar novos repositórios.
2UHSRVLWµULR(Ζ'«FRQȴJXUDGRDXWRPDWLFDPHQWHQRURWHLURGHLQVWDOD©¥RIRUQHFLGRSHOR
projeto, e deve sempre ter o nome “Metadiretório” para o correto funcionamento do
VLVWHPD2VUHSRVLWµULRVGDRUJDQL]D©¥RGHYHPVHUFRQȴJXUDGRVQHVVHSRQWRSDUDTXHDV
H[WUD©·HVSRVVDPVHUFRQȴJXUDGDV
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
Figura 3.7
Cadastro de um
UHSRVLWµULRGRWLSR
Banco de Dados
5HODFLRQDO
47
Repositórios, e será apresentada a tela para escolha do tipo de repositório, que pode ser:
Arquivo CSV, Diretório LDAP ou Banco de Dados Relacional. De acordo com a escolha é
exibida a tela para cadastro dos dados de conexão.
A Figura 3.7 exibe os campos para cadastro de um Repositório do tipo Banco de Dados
Relacional.
1 O painel Versão do Banco de Dados pode ser preenchido com o nome da tabela e campo
do banco que contém a sua versão ou ainda com o número de versão diretamente no
campo “Versão” (manual).
1 Após preencher todos os campos obrigatórios é possível testar a conexão com o banco
através do botão Testar Conexão.
Federação CAFe: Implantação do Provedor de Identidade
Figura 3.8
Inclusão de
DUTXLYR&69
Caso o tipo do repositório seja Arquivo CSV, os campos Nome, Descrição e Diretório devem
ser informados de acordo com a Figura 3.8. O campo Diretório deve apontar para o diretório
no servidor local que conterá os arquivos.
48
Figura 3.9
Alteração de
VHUYLGRU/'$3
Caso o tipo do Repositório seja “Diretório LDAP”, os seguintes campos devem ser
informados, de acordo com a Figura 3.9:
1 Host que deve ser informado com o nome ou endereço IP do servidor LDAP;
1 Porta, por padrão a porta de acesso a servidores LDAP é 389 ou 636 para uso de LDAPs (SSL);
$WUDY«VGRERW¥RȊ7HVWDU&RQH[¥Rȋ«SRVV¯YHOYHULȴFDUVHDFRQH[¥RIRLHVWDEHOHFLGD
com sucesso.
Extrações
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
2SUµ[LPRSDVVR«DGHȴQL©¥RGHXPDH[WUD©¥RGHGDGRV
1 &DGDH[WUD©¥RGHȴQHDIRQWHGHGDGRVSURSULDPHQWHGLWDHDUHODFLRQDFRPXPDWDEHOD
de destino;
1 $UHJUDGHFRQYHUV¥RHFRPSDWLELOL]D©¥RGHWLSRWDPE«P«GHȴQLGDDTXLPDSHDQGRRV
campos de entrada nos campos de saída;
1 É possível a utilização de parâmetros globais nas extrações para denotar valores cons-
tantes no momento do processamento da extração.
49
Figura 3.10
Administração
GHH[WUD©·HV
Extrações são conhecidas no sistema como ETC (Extração, Transformação e Carga); a tela
SDUDDGPLQLVWUD©¥RGH([WUD©·HV«DFHVVDGDSHORPHQX&RQȴJXUD©¥R(7&YHU)LJXUD
1 O comando AlterarSHUPLWHHGLWDUXPDH[WUD©¥RM£FRQȴJXUDGDQRVLVWHPD
1 O comando Clonar permite realizar uma cópia da ETC escolhida apenas com os campos
Código e NomeYD]LRVSDUDVHUHPUHGHȴQLGRV
1 É possível ainda excluir uma ETC cadastrada no sistema; para isso, selecione o item que
se deseja excluir e clique no botão Excluir.
Federação CAFe: Implantação do Provedor de Identidade
50
Figura 3.11
&DGDVWURGH(7&
Ao acionar o comando novo é exibida a tela para cadastro de uma ETC (ver Figura 3.11).
O cadastro de ETC é dividido em três partes para facilitar a inserção dos dados: a parte
superior apresenta os campos Código, Nome e Descrição (campos descritivos da extração) e
as abas “Leiaute de Origem” e “Leiaute de Destino” que serão detalhadas a seguir.
1 'HYHGHȴQLUXPΖGHQWLȴFDGRUQLFRΖ8
A aba LeiauteGHRULJHPGRFDGDVWURGH(7&GHȴQHRVFDPSRVTXHVHU¥RH[WUD¯GRVGRUHSRVLWµULR
GHRULJHPTXHSRGHPVHUGHȴQLGRVSRUXP64/RXPDSHDPHQWRGRVFDPSRVGHXPDUTXLYR&69
&DS¯WXOR&RQVWUXLQGRPHWDGLUHWµULRVFRP(Ζ'
1 REULJDWµULDDGHȴQL©¥RGHXPΖGHQWLȴFDGRUQLFRΖ8SDUDRVUHJLVWURVLPSRUWDGRV
(VWHLGHQWLȴFDGRUSRGHVHUFRPSRVWRVHQGRXWLOL]DGRSDUDFRQFLOLD©¥RHUHIHU¬QFLDD
registros previamente importados.
No leiaute de origem (ver Figura 3.12) é escolhido o repositório de onde os dados serão Figura 3.12
extraídos, dependendo do tipo de repositório escolhido (Banco de dados relacional ou /HLDXWHGHRULJHP
1 Separador Campos: indica o caractere utilizado como separador dos campos do arquivo
de texto.
1 &RGLȴFD©¥RGHFDUDFWHUHVXWLOL]DGDSDUDLQWHUSUHWD©¥RFRUUHWDGXUDQWHDOHLWXUDGH
Federação CAFe: Implantação do Provedor de Identidade
arquivos texto.
1 Formato da data.
Quando o Repositório de Origem for Arquivo Texto, o leiaute deverá ser montado manual-
mente, adicionando linhas através do comando Novo.
1 )LOWURGHSHVTXLVDXPȴOWURSDUDDEXVFDGHUHJLVWURV([PDLO
1 Pesquisa de subentradas: a marcação deste campo faz com que os registros sejam
importados da base com todas suas subentradas como registros independentes.
A opção “Nº de registros para pular” pode ser informada com o número de registros que se
deseja descartar na importação.
52
A Opção “Reiniciar Importação Incremental” pode ser usada quando se deseja zerar os
valores da importação incremental de uma determinada ETC.
Figura 3.13 O Leiaute de Origem é exibido após o preenchimento do campo SQL e acionamento do
Detalhes dos comando Leiaute caso o tipo de repositório seja banco de dados relacional, ou pela inserção
campos do leiaute
GHRULJHP dos campos um a um, através do acionamento do comando Novo, caso o repositório seja do
tipo arquivo CSV (ver Figura 3.13).
1 O campo NomeLQGLFDDLGHQWLȴFD©¥RGRFDPSRQDRULJHP(VWHLGHQWLȴFDGRUVHU£
também utilizado para referenciá-lo no mapeamento para o destino.
1 O campo Tipo indica o tipo dos dados. No caso de arquivos texto, o tipo deve ser
sempre texto.
1 Ζ8GHȴQHRVFDPSRVXWLOL]DGRVFRPRLGHQWLȴFDGRUHV¼QLFRVSDUDRUHJLVWUR'HYHPVHU
GHȴQLGRVFRPFDXWHODSDUDHYLWDUHUURVGXUDQWHDLPSRUWD©¥RFRPRFRQFLOLD©¥RLQFRUUHWD
de registros.
1 2FDPSRȊ7LPH6WDPSȋ«XWLOL]DGRSDUDLGHQWLȴFDURFDPSRTXH«UHVSRQV£YHOSHODPDU-
FD©¥RGHDWXDOL]D©¥RGRUHJLVWURQRWHTXHHVWHFDPSRVµȴFDKDELOLWDGRTXDQGRRWLSR«
igual a Inteiro ou Data.
Leiaute de destino
1 Repositório de destino é o metadiretório. q &DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
1 6HPSUHVHU£XPDFODVVHGHȴQLGDSHOR(Ζ'
1 Scripts em Java ou Bean Shell podem ser usados para conversão de dados.
1 2GHVWLQRVHPSUHVHU£XPDWDEHODSUHYLDPHQWHGHȴQLGDSRUXPDFODVVHGR(Ζ'
1 SRVV¯YHOXWLOL]DUVFULSWVGHFRQYHUV¥RPDLVVRȴVWLFDGRVHVFULWRVHP-DYDRX%HDQ6KHOO
para transformação de dados de origem para o destino.
1 1RPRPHQWRGDLPSRUWD©¥RUHJLVWURVTXHM£IRUDPLPSRUWDGRVV¥RLGHQWLȴFDGRVDXWR-
maticamente. Existe a opção da atualização ou não dos dados do registro importado.
1 $DWXDOL]D©¥R«IHLWDFRPEDVHQRLGHQWLȴFDGRU¼QLFRGHȴQLGRΖ8
53
No Leiaute de Destino o repositório selecionado deve ser sempre o metadiretório. Figura 3.14
&RQȴJXUD©·HVGR
A Tabela de Destino é a tabela que será alimentada. É necessário que a tabela da classe Iden- OHLDXWHGHGHVWLQR
WLȴFD©¥R seja a primeira a ser alimentada, pois os demais dados serão vinculados às pessoas
previamente importadas.
1RSDLQHOGHFRQȴJXUD©·HVDYDQ©DGDV«SRVV¯YHOGHȴQLUXP)LOWURGH&RQFLOLD©¥RXPVFULSW
Java que pode ser utilizado para consultar o banco de destino e optar pela importação, atua-
lização ou descarte do registro.
O botão Leiaute constrói a lista de campos disponíveis na tabela de destino, assim como no
leiaute de origem.
Os pontos fundamentais no leiaute de destino estão em Campo Fonte e Script. Figura 3.15
Detalhes dos
Federação CAFe: Implantação do Provedor de Identidade
Diversas ETCs podem carregar a mesma classe, o que é de grande utilidade para
carga de tabelas a partir de repositórios diferentes.
54
Figura 3.16 No Leiaute de Destino para a extração de todas as classes, excetuando-se ΖGHQWLȴFD©¥R, deve
Detalhes dos ser informado o GUID do objeto referenciado no painel Objeto referenciado.
campos do
leiaute de Destino O Campo Fonte (ou resultado do script) deve resolver o valor que foi utilizado como IU para
com objeto
UHIHUHQFLDGR a classe ΖGHQWLȴFD©¥ROutra possibilidade é resolver diretamente o GUID do objeto.
Processos
3URFHVVRVGHȴQHP q
1 Conjunto de extrações a serem executadas.
1 Ordem da execução.
1 2XWUDVFRQȴJXUD©·HVPDLVGHWDOKDGDV
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
Figura 3.17
Tela de
administração de
SURFHVVRV
55
A Figura 3.18 apresenta a tela de administração de processos, que pode ser acessada pelo
PHQXȊ&RQȴJXUD©¥R3URFHVVRVȋ1HOD«SRVV¯YHOYLVXDOL]DURVSURFHVVRVFDGDVWUDGRVQR
sistema, alterá-los ou ainda cadastrar um novo processo.
Figura 3.18
Inclusão de
SURFHVVR
Acionando o botão Novo, a tela de cadastro de processo é exibida (ver Figura 3.18).
1 A opção Modo indica a ação que deve ser tomada caso alguma das ETCs listadas não seja
ȴQDOL]DGDFRPVXFHVVR6HIRUHVFROKLGRInterromper, as ETCs seguintes à causadora do
erro não são processadas. No caso de Não interromper, as ETCs seguintes são proces-
sadas independentemente de haver erro.
1 Número de tentativas indica o número máximo de vezes que o sistema tentará estabelecer
conexão com os repositórios utilizados em cada extração antes de abortar o processamento.
1 Intervalo entre tentativas indica o tempo de espera entre duas tentativas sucessivas.
1 Máximo de erros determina o número máximo de erros que a ETC suporta sem ser abor-
WDGDHFRQVHTXHQWHPHQWHȴQDOL]DUVHXSURFHVVDPHQWRFRPFµGLJRGHHUUR(VWDRS©¥R
é interessante, pois é sabido que existem inconsistências no banco de origem e que os
registros que geram inconsistências devem ser descartados.
56
Agendamentos
'HȴQHPSDUDRSURFHVVR q
1 Horário de importação.
1 Frequência de repetição.
8PDYH]GHȴQLGRRSURFHVVRHOHGHYHVHUDJHQGDGR6µSRGHH[LVWLUXPDJHQGDPHQWRSDUD
cada processo; não é aconselhável que uma mesma ETC participe de processos distintos que
SRVVDPURGDUHPSDUDOHOR8PDJHQGDPHQWRGHSURFHVVRGHȴQLU£RKRU£ULRSDUDH[HFXWDUD
importação e sua frequência de repetição.
Figura 3.19
Pesquisa de
DJHQGDPHQWR
57
Figura 3.20
Inclusão de
DJHQGDPHQWR
Ao acionar o comando Novo, é exibida a tela de “Cadastro de Agendamento de Processo”
(ver Figura 3.20). Nesta tela deve-se escolher o processo a ser agendado e o tipo de repe-
WL©¥RSRVV¯YHOGHȴQLUWDPE«PDSDUWLUGHTXDOLWHP(7&RSURFHVVRGHYHU£LQLFLDUH
terminar, e a data e hora da próxima execução. A caixa “Processar Agora” pode ser marcada
caso o processamento deva ter início imediato.
O campo “Diretório” é usado para salvar resultados de processamentos, e pode ser preen-
chido com um diretório do servidor, onde o sistema salvará os logs do resultado de proces-
samento completo. Este diretório deve estar local e com permissão de escrita.
(PFDVRVRQGHDIRQWHGHGDGRV«PXLWRGHPDQGDGDSRURXWUDVDSOLFD©·HVSRGHVHGHȴQLU
no painel “Horários permitidos para processamento” os horários nos quais a importação é
SHUPLWLGDEDVWDQGRLQIRUPDURVLQWHUYDORVGHLQ¯FLRHȴP
Federação CAFe: Implantação do Provedor de Identidade
58
Resultados de processamento
Figura 3.21
Pesquisa de
resultado de
SURFHVVDPHQWR
&DS¯WXOR5HYLV¥RGH/'$3HHVTXHPDEU(GX3HUVRQ
Figura 3.22
Visualização de
resultado de
SURFHVVDPHQWR
59
Ao acionar o botão Visualizar na tela de “Pesquisa de Resultados de Processamento”, a tela a
seguir é exibida (Figura 3.22). Por esta interface é possível observar detalhes do processa-
PHQWRLQFOXLQGRPHQVDJHQVGHHUURGXUDQWHDLPSRUWD©¥RRTXHSHUPLWHDLGHQWLȴFD©¥RGH
UHJLVWURVFDXVDGRUHVGHSUREOHPDVHGH(7&VFRQȴJXUDGDVLQFRUUHWDPHQWH
60
Roteiro de Atividades 3
Atividade 3.1 – Instalação de EID e EID2LDAP
Instale EID e EID2LDAP na máquina virtual presente em sua estação de trabalho. Conecte-se
com o SSH na VM, TXHM£SRVVXLLQVWDODGRVR7RPFDW-DYDH0\64/)DUHPRVDFRQȴJXUD©¥R
necessária para instalar o EID.
Configurações no Tomcat
TOMCAT6_SECURITY=no
cp /opt/treinamento/mysql-connector-java-5.1.16-bin.jar /usr/share/
java
3. É necessário ainda fazer a criação de alguns links simbólicos para o conector. Para tanto,
execute as linhas de comando a seguir:
4. Sabendo-se que a instalação padrão do Tomcat via apt-get não possui o arquivo
tomcat-dbcp.jar (necessário para algumas aplicações), deve-se baixá-lo e colocá-lo na
pasta lib do Tomcat. Para tanto, execute o comando:
cp /opt/treinamento/tomcat-dbcp.jar /usr/share/tomcat6/lib/
5. Para permitir que um usuário do Tomcat faça login no EID, edite o arquivo /etc/tomcat6/
&DS¯WXOR5RWHLURGH$WLYLGDGHV
tomcat-users.xml, deixando-o como está abaixo. Substitua SENHA_EID pela senha que
será usada ao logar no EID.
<tomcat-users>
<role rolename=”manager”/>
</tomcat-users>
61
6. Inicialize o Tomcat através do seguinte comando:
/etc/init.d/tomcat6 start
7. 3RUȴPSDUDWHVWDUVHRPHVPRHVW£IXQFLRQDQGRFRUUHWDPHQWHDWUDY«VGREURZVHUDFHVVH
o endereço http://ip_do_servidor:8080/HYHULȴTXHVHDPHQVDJHPȊΖWZRUNVȋ«H[LELGD
1. É necessário fazer a criação das bases de dados que serão utilizadas pelo EID e EID2LDAP.
As informações são armazenadas em bases MySQL. Para criar as bases execute a linha de
comando a seguir:
mkdir /opt/eid/
mkdir /opt/eid2ldap/
export JARO_WINKLER_DIR=/opt/eid/lib/
export JAVA_HOME=”/usr/lib/jvm/java-6-openjdk/”
export JRE_HOME=”/usr/lib/jvm/java-6-openjdk/”
export CATALINA_HOME=”/usr/share/tomcat6”
export TOMCAT_HOME=”/usr/share/tomcat6”
62
3. Crie a pasta referenciada pela variável de ambiente JARO_WINKLER_DIR com o comando
a seguir:
mkdir -p $JARO_WINKLER_DIR
cd /opt/eid/WEB-INF/classes/br/ufmg/lcc/eid/model/conciliator
make compile
cp /opt/treinamento/eid.xml /etc/tomcat6/Catalina/localhost
cp /opt/treinamento/eid2ldap.xml /etc/tomcat6/Catalina/localhost
JARO_WINKLER_DIR=/opt/eid/lib
export JARO_WINKLER_DIR
/etc/init.d/tomcat6 restart
1 $FHVVHRPHQXȊ&RQȴJXUD©¥R5HSRVLWµULRGH'DGRVȋHGHȴQDRXVX£ULRHDVHQKDGR
repositório Metadiretório (usuário e senha: root).
1 Em seguida teste a conexão com o banco de dados através de Testar conexão. Salve a
FRQȴJXUD©¥RGDVHQKDFRPRERW¥RSalvar (localizado no canto superior direito).
1 /var/log/tomcat6/catalina.{DATA_ATUAL}.log
1 /var/log/tomca6/localhost.{DATA_ATUAL}.log
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R5HSRVLWµULRGH'DGRVȋ
63
ɅDescrição: Repositório de testes do curso EID.
ɅURL: ao clicar no ícone ao lado do campo é exibida uma janela pop-up com exemplos
de URLs e drivers.
ɅDriver:
ɅUsuário: root
ɅSenha: root
ɅNo painel “Versão do Banco de dados”, insira o valor 1.0 no campo Versão (manual).
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
3. 1DJXLD(7&HVSHFLȴTXH
64
Atividade 3.4 – Definição de um processo e seu agendamento
&ULHXPSURFHVVRTXHLQFOXDDH[WUD©¥RGHȴQLGDDQWHULRUPHQWHHRDJHQGHSDUDVHUH[HFX-
tado de imediato, sem repetições.
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R3URFHVVRȋ
3. Preencha os campos:
ɅNúmero de tentativas: 1
4. No painel Itens de processo, acione o botão Novo e selecione a ETC “Extração de pessoas
do sistema acadêmico”. Clique em Selecionar:
2 Número de erros: 0
5. Acione Salvar.
10. Depois de alguns minutos, acesse o menu “EID/Gestão e pessoas” para visualizar as
pessoas importadas.
65
4. Clique na aba SQL e cole o seguinte SQL:
66
4
Criando extrações no EID
objetivos
conceitos
Extração de arquivos texto, extração de diretórios LDAP, resolução de objeto EID,
parâmetros globais, importação incremental, scripts de conversão, algoritmos
GHXQLȴFD©¥RHweb services.
(VWHFDS¯WXORDSUHVHQWDIXQFLRQDOLGDGHVDYDQ©DGDVTXHSRGHPVHUXWLOL]DGDVQDFRQȴJX-
ração de extrações, como extrações de arquivos texto, uso de parâmetros globais, impor-
tação incremental e uso de scripts de conversão.
O EID é capaz de importar dados de arquivos CSV, além de bancos de dados relacionais.
Arquivos CSV são arquivos separados por ponto-e-vírgula ou tabulação (o Excel exporta
arquivos neste formato). Em algumas situações este recurso é útil, principalmente em casos
onde a informação é mantida em planilhas externas aos sistemas utilizados na organização.
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
67
Figura 4.1
5HSRVLWµULR
1 3HUPLWHDVHOH©¥RGDFRGLȴFD©¥R
1 &RQȴJXUD©¥RGHVHSDUDGRUGHFLPDOHVHSDUDGRUGHFDPSRV
Federação CAFe: Implantação do Provedor de Identidade
Para extrações de arquivos texto, o campo “Arquivo de Origem” deve ser preenchido com o nome
do arquivo do qual os dados serão extraídos. Em servidores Linux/Unix o nome é case sensitive.
SRVV¯YHOHVFROKHUDFRGLȴFD©¥RGHFDUDFWHUHVGRDUTXLYRRULJLQDOOHPEUDQGRVHPSUHTXH
DFRGLȴFD©¥RGREDQFRGR(Ζ'«Ζ62$HVFROKDFRUUHWD«GHVXPDLPSRUW¤QFLDSDUDD
interpretação correta dos caracteres acentuados.
68
ETC
Figura 4.2
Leiaute de origem -
$UTXLYR&69
A Figura 4.2 mostra o leiaute de origem de uma extração em um repositório do tipo arquivo
GHWH[WR&694XDQGRHVWDPRVGHȴQLQGRXPDH[WUD©¥RSDUDDUTXLYRV&69GLIHUHQWHPHQWH
GHEDQFRVUHODFLRQDLVQ¥RVHSRGHGHȴQLUXP64/7DPE«PQ¥R«SRVV¯YHODFRQVWUX©¥R
automática do leiaute, uma vez que não existem metadados que descrevem os campos.
Os nomes de cada campo devem ser informados manualmente, não podendo haver espaço
entre palavras, sempre na forma de caracteres ASCII de a-z, A-Z ou 0-9 (exceto no início do
LGHQWLȴFDGRUVHPDFHQWXD©¥R
O tipo dos campos é sempre texto, podendo ser convertidos para os tipos corretos no
PRPHQWRGDFRQȴJXUD©¥RGRGHVWLQRFRPRXVRGRVVFULSWVGHPDSHDPHQWRRXFRQYHUV¥R
TXHVHU¥RH[SOLFDGRVPDLVDGLDQWH7DPE«PDTXL«SRVV¯YHOGHWHUPLQDUXPLGHQWLȴFDGRU
único, utilizado na conciliação automática.
Caso o arquivo possua algum campo indicador da data de atualização dos registros é possível
utilizar a importação incremental através do campo Time Stamp.
O comando Novo, no painel de Leiaute de Origem de Dados, adiciona novas linhas nesse
SDLQHOSDUDFRQȴJXUD©¥RGHQRYDVFROXQDV
Leiaute de destino: q
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
1 Idêntico ao de bancos de dados relacionais, sua conversão de tipos é feita por scripts
Java ou Bean Shell.
69
Extração de diretórios LDAP
Figura 4.3
/HLDXWHGH2ULJHP
A opção “Nº de registros para pular” pode ser informada com o número de registros que se
deseja descartar na importação.
A opção “Reiniciar Importação Incremental” pode ser usada quando se deseja zerar os
valores da importação incremental de uma determinada ETC.
O painel “Leiaute de origem” deve ser informado manualmente com o nome dos atributos
Federação CAFe: Implantação do Provedor de Identidade
do LDAP que se deseja importar, o tipo de ser texto para todos os atributos.
Resolução de objetos
1 Objetos vinculados via GUID. q
1 Importação deΖGHQWLȴFD©¥R cria os objetos.
Ainda no leiaute de destino, o campo eid_object_guid deve indicar o GUID para vinculação da
instância da classe com o objeto.
$LPSRUWD©¥RGDFODVVHΖGHQWLȴFD©¥RSURPRYHDFULD©¥RGHQRYRVREMHWRVQRPHWDGLUHWµULR
em geral ela é utilizada como referência para a vinculação de instâncias de outras classes ao
objeto criado.
70
$YLQFXOD©¥R«IHLWDSRUXPPDSHDPHQWRFRPRH[HPSOLȴFDGRDVHJXLU
1 Na base de origem, os demais dados da pessoa X (endereço, dados de aluno etc.) certamente
SRVVXLU¥RDOJXPWLSRGHUHODFLRQDPHQWRFRPRUHJLVWURGHLGHQWLȴFD©¥RSRGHQGRID]HUSDUWH
do registro na mesma tabela ou fazer uma referência a ele via chave estrangeira (fk);
Figura 4.4 A Figura 4.4 apresenta o leiaute de destino dos dados, onde o objeto referenciado deve
Leiaute de destino ser informado. Para todas as classes sua informação é obrigatória, com exceção da
GHGDGRV
classe ΖGHQWLȴFD©¥R.
Parâmetros globais
Constantes: q
1 Consultas.
1 Script de conciliação.
1 Script de conversão.
Outra funcionalidade a ser explorada nas extrações está relacionada aos parâmetros
JOREDLV3DU¤PHWURJOREDO«XPPHFDQLVPRXWLOL]DGRSHOR(Ζ'SDUDGHȴQL©¥RGHFRQVWDQWHV
que podem ser utilizadas nas extrações. Ele é utilizado como constante em consultas, scripts
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
71
Figura 4.5
Administração
de Parâmetros
*OREDLV
2VSDU¤PHWURVJOREDLVV¥RGHȴQLGRVQRPHQXȊ&RQȴJXUD©¥R3DU¤PHWURV*OREDLVȋ)LJXUD
7RGRVRVSDU¤PHWURVGHYHPWHUXPQRPHTXHVHUYHFRPRLGHQWLȴFDGRUQ¥RSRGHQGRKDYHU
espaço entre as palavras (ou caracteres especiais) e um valor.
Os parâmetros são sempre tratados como sendo do tipo string. Estes parâmetros funcionam
por substituição; nos pontos onde são referenciados, seu valor é inserido antes do início do
processamento sempre com a sintaxe #{nome_do_parâmetro}.
Vale a pena lembrar que a substituição é direta. Assim, nos casos onde o parâmetro é
tratado como valor numérico, basta colocar #{nome_do_parâmetro} e, onde é tratado como
string, as aspas (simples ou duplas, dependendo do caso) devem ser utilizadas, como em
‘#{nome_do_parâmetro}’.
Abaixo um exemplo de consulta que utiliza parâmetros globais, considerando que o banco
realiza automaticamente a conversão de string para data:
Importação incremental
1 Reimportação com atualização de registros implica em reconciliação e é: q
2 Computacionalmente cara.
2PHWDGLUHWµULRGHYHUHȵHWLURGLQDPLVPRGDRUJDQL]D©¥RΖVVRLPSOLFDQDLPSRUWD©¥RGH
dados não importados anteriormente e também na atualização de outros já importados.
Uma forma de se fazer este processo é selecionar a opção Atualizar registros existentes na
GHȴQL©¥RGD(7&TXHIRU©DFRPTXHWRGRVRVUHJLVWURVLPSRUWDGRVDQWHULRUPHQWHVHMDP
atualizados em uma reimportação. Novos registros são inseridos naturalmente.
72
A consequência da atualização de todos os registros é que o EID é obrigado a trabalhar
novamente sobre todos os objetos afetados, pois não é possível saber, a priori, se o registro
sofreu alterações na origem ou não. Isto pode ser melhorado com o uso de importações
incrementais, que podem alterar o escopo das consultas a cada execução, desde que haja
alguma informação no banco de origem que permita a distinção de registros alterados dos
não alterados (uma coluna com carimbo de tempo, por exemplo).
Figura 4.6
Marcação
de time stamp
Para utilizar importação incremental manual do EID é necessário que a base de origem
tenha algum campo que funcione como carimbo de tempo dos registros atualizados.
1ROHLDXWHGHRULJHPGD(7&HVWHFDPSRGHYHVHULGHQWLȴFDGRFRPDPDUFD©¥RGHtime
stamp, como na Figura 4.6.
O EID armazenará internamente o maior valor já importado e sempre que for executar
novamente a ETC irá atualizar ou inserir apenas os registros alterados ou novos.
Além da importação incremental, o campo “Time Stamp” pode ser útil em processos que
agruparão ETCs dependentes. Quando o campo “Time Stamp” é marcado, o sistema cria
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
SELECT a.*
73
p.DATA_ATUALIZACAO_REGISTRO > #{ETL.Etc de pessoas.INITIAL}
Neste exemplo, o SQL parametrizado impede que registros de alunos referenciando pessoas
ainda não carregadas pela ETC “pessoas” sejam selecionados.
Script de conversão
1 Possibilita o tratamento do dado da origem. q
1 Complementa as possibilidades do SQL.
1 Código Java.
2XWUDIXQFLRQDOLGDGHDVHUH[SORUDGDQDFRQȴJXUD©¥RGHXPD(7&«Rscript de conversão
ou mapeamento. Cada campo do Leiaute de origem pode ser tratado antes de ser inserido no
destino. Este tratamento é feito via código Java, onde pode ser utilizada toda sua funcionali-
dade (como expressões regulares, tratamento de datas etc.). Para utilização de script, o campo
Fonte no Leiaute de destino deve ser deixado em branco; caso seja preenchido, o script não será
executado e o valor do campo Fonte será atribuído ao registro. Pode-se optar por dois tipos de
scripts: Bean Shell ou Jana Nativo. O código do script deve ser inserido acionando-se o comando
Script na linha equivalente ao campo. Caso a escolha seja Bean Shell, deve ser implementado o
método com assinatura public void execute(), onde o valor calculado deve ser colocado na
variável result, e o acesso às variáveis do leiaute de origem é feito apenas pelo seu nome. Caso
utilize Java nativo, não é necessário usar o método, e o acesso às variáveis do leiaute de origem é
feito da mesma forma que o acesso aos parâmetros globais: #{nome_variável}.
}
}
Um exemplo de script para atribuir o valor de uma substring ao campo Senha em Bean Shell
é apresentado a seguir. Para acessar as variáveis do leiaute de origem apenas utilize o nome.
74
Necessário utilizar o método execute().
String result;
result = null;
if (senha != null) {
2FµGLJRH[HPSOLȴFDFRPRSHJDUDSHQDVSDUWHGDVWULQJVHQKDGRUHSRVLWµULRGHRULJHP
para ser o valor atribuído ao resultado no Metadiretório EID. Assim como este script, vários
outros podem ser desenvolvidos de acordo com a necessidade de transformação dos dados.
Alguns destes podem ser encontrados na seção FAQ do Wiki da Federação CAFe.
Em Java Nativo para acessar as variáveis do leiaute de origem é necessário usar #{nome_variável}
e não se usa o método execute().
if (#{senha} != null) {
}else{
result=null;
Algoritmos de unificação
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
2 Instância única.
2 Múltiplas instâncias.
2(Ζ'XVDDOJRULWPRVGHXQLȴFD©¥RSDUDPHVFODULQVW¤QFLDVGHFODVVHVSDUDXPGDGRREMHWR
HVVHDOJRULWPRTXHGHȴQHRVFULW«ULRVSDUDSUHVHUYD©¥RGHXPGDGRDWULEXWRHPGHWUL-
mento de outro ou mesmo o descarte de determinada instância de classe.
75
O EID disponibiliza dois algoritmos padrões: um para conciliação de instâncias únicas, onde
RVDWULEXWRVGHGXDVRXPDLVLQVW¤QFLDVV¥RPHVFODGRVHPXPDLQVW¤QFLDȴQDOHRXWURSDUD
instâncias múltiplas, onde todas as instâncias são preservadas em uma lista.
SHUPLWLGDDGHȴQL©¥RGRDOJRULWPRDVHUXWLOL]DGRSRUFDGDFODVVH1¥RLQIRUPDUHVVHDOJR-
ritmo implica a utilização de um dos algoritmos padrões.
Novas implementações podem ser dadas e disponibilizadas na aplicação EID, com a imple-
mentação da interface Ζ&ODVV8QLȴHU.
Figura 4.7
Algoritmo de
GHGXSOLFD©¥R
Federação CAFe: Implantação do Provedor de Identidade
1D)LJXUDYHPRVRSDLQHOȊ$OJRULWPRGHGHGXSOLFD©¥RȋGDWHODGHGHȴQL©¥RGHFODVVH
1HVWDWHODK£WU¬VPDQHLUDVSDUDLQIRUPDURDOJRULWPRTXHLU£ID]HUDXQLȴFD©¥R
1. ΖQIRUPDQGRRQRPHFRPSOHWRGRDOJRULWPRGHXQLȴFD©¥RQRFDPSRȊ1RPHGD&ODVVHGH
8QLȴFD©¥RȋHVWDRS©¥R«Y£OLGDTXDQGRRDOJRULWPRGHXQLȴFD©¥RM£HVW£GLVSRQ¯YHOFRP-
pilado no classpath do Tomcat: /diretório_tomcat/webapps/eid/WEB-INF/classes/.
2. Através de upload de um arquivo Java, clicando no botão + Arquivo JAVA e logo em seguida
no botão Upload que é exibido; então a classe é carregada e exibida conforme a Figura 4.7.
3. 'LJLWDQGRRXFRODQGRRFRQWH¼GRGRDOJRULWPRQRVFDPSRVHVSHF¯ȴFRV
'HSRLVGHFDGDVWUDURDOJRULWPRGHXQLȴFD©¥RVDOYHDGHȴQL©¥RGHFODVVHV
76
Web services
1 Clientes podem usufruir dos registros conciliados. q
1 Web services possibilitam uma forma mais adequada de acesso aos dados.
1 http://servidor:porta/eid/services/EidService?wsdl
2 'HYHVHUSURWHJLGRFRPȴUHZDOORXDXWHQWLFD©¥R66/
O EID disponibiliza um web service para exportação e consulta de dados, o que facilita
o acesso por aplicações que utilizem tecnologias diversas. O web service serve de base
também para outras ferramentas de exportação. Um exemplo é a ferramenta denominada
EID2LDAP, que exporta os dados do EID para servidores LDAP.
<attribute name=”nomeSolteiro”><![CDATA[]]></attribute>
</attributes>
<attribute name=”email”><![CDATA[zeca@mail.com]]></attribute>
</attributes>
</eid-object>
O uso de web services foi escolhido por abstrair os clientes do modelo de dados do EID.
1 Outra vantagem é a independência de plataformas dos clientes do EID, que podem ser
implementadas em outras linguagens além de Java.
1 2VHUYL©RQ¥RHVW£SURWHJLGRRTXHSRGHVHUIHLWRYLDFRQȴJXUD©¥RGH66/DXWHQWLFDGR
&DS¯WXOR&ULDQGRH[WUD©·HVQR(Ζ'
SDUDD85/HȴUHZDOO
A descrição dos serviços no formato WSDL pode ser acessada pela URL
http://localhost:8080/eid/services/EidService?wsdl, onde localhost deve ser substituído
pelo endereço da máquina onde o EID está instalado. Ao se carregar o EID no Tomcat,
o web service é automaticamente iniciado.
77
Problemas comuns
1 Dados inconsistentes no banco. q
1 Carga da classe Conta.
1 Usuário que sobe o Tomcat deve ter permissão na pasta webapps do EID.
at br.ufmg.lcc.eid.commons.EidException.
eidErrorHandling(EidException.java:46)
at br.ufmg.lcc.eid.model.EidFacade.runConciliator(EidFacade.java:62)
at br.ufmg.lcc.eid.controller.EidServletContextListener$EidThread.
run(EidServletContextListener.java:39)
at java.lang.Thread.run(Thread.java:619)
Essa situação pode ser corrigida utilizando-se o script disponibilizado no site do projeto.
Uma dúvida constante diz respeito à carga da classe Conta, em particular ao campo
algoritmoSenha. Esse campo deve ser preenchido com o algoritmo que foi utilizado para
calcular a senha do usuário, caso não esteja em texto plano (SHA, MD5, CRYPT etc.).
3DUDVHQKDVFRGLȴFDGDVHPEDVHLQGHSHQGHQWHGRDOJRULWPRXWLOL]DGRSDUDRKDVKRYDORU
do campo deve ser base64, e para senhas em texto plano o campo não deve ser alimentado.
78
Roteiro de Atividades 4
Atividade 4.1 – Definição de uma extração de arquivo texto
$EUDXPQDYHJDGRUHDFHVVHR(Ζ'SDUDFRQȴJXUDURUHSRVLWµULR
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R5HSRVLWµULRGH'DGRVȋ
2. $FLRQHRFRPDQGR1RYRSDUDGHȴQLUXPQRYRUHSRVLWµULR
ɅDiretório: /treinamento.
Crie uma extração para carregar a classe ΖGHQWLȴFD©¥Ra partir do arquivo texto
QRYDV3HVVRDV&RP&SIW[W
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
3. Na guia ETCHVSHFLȴTXH
Ʌ&RGLȴFD©¥R&DUDFWHUHV: UTF-8.
ɅAcione o comando Novo deste painel para adicionar novos itens, se necessário.
2UGHPGRVFDPSRVGRDUTXLYRLGHQWLȴFDGRU¼QLFRSDUDRVUHJLVWURVQRPH
completo, sexo, data de nascimento (formato dd/mm/aaaa) e CPF.
79
5. Na guia Leiaute de Destino:
ɅTabela de DestinoLGHQWLȴFD©¥R
6. Crie um script para converter o campo dataNascimento. Deixe o campo Fonte em branco e
preencha o campo Script com o código abaixo:
if (nascimento != null){
result = formatador.parse(nascimento);
&ULHXPSURFHVVRTXHLQFOXDDH[WUD©¥RGHȴQLGDDQWHULRUPHQWHHRDJHQGHSDUDVHU
executado de imediato, sem repetições.
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R3URFHVVRVȋ
3. Preencha os campos:
ɅNúmero de tentativas: 1.
ɅNúmero de erros: 0.
80
5. Acione Salvar.
8. Selecione:
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
3. 1DJXLD(7&HVSHFLȴTXH
SQL:
ɅNo painel Leiaute de Destino dos Dados, mapeie os campos de origem para o destino.
81
6. No campo eid_object_guid:
0RGLȴTXHRSURFHVVR3URFHVVRGHH[WUD©¥R$FDG¬PLFRSDUDLQFOXLUDH[WUD©¥RGHȴQLGD
anteriormente e o agende para ser executado de imediato, sem repetições.
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R3URFHVVRVȋ
ɅNúmero de erros: 0.
4. Acione Salvar.
7. Selecione:
$OWHUHD(7&GHΖGHQWLȴFD©¥RGRDUTXLYR&69
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
82
ɅCrie um script para converter o campo Sexo com o código:
if (sexo != null) {
if (sexo.equals(“masculino”)) {
result = “M”;
} else if (sexo.equals(“feminino”)) {
result = “F”;
Altere o agendamento:
3. Selecione:
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
3. 1DJXLD(7&HVSHFLȴTXH
83
Ʌ&RGLȴFD©¥R&DUDFWHUHV: UTF-8.
3. Crie um script para extrair o campo algoritmoSenha. Utilize o código no campo Script:
if (senha != null) {
if (senha != null) {
result = senha.substring(5);
ɅCampo Fonte: id
84
7. Acione o comando Salvar.
$OWHUHRSURFHVVRGHH[WUD©¥RGHDUTXLYRVWH[WRGHȴQLGRDGLFLRQHDQRYD(7&HDJHQGH
para ser executado de imediato, sem repetições.
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R3URFHVVRVȋ
5. Número de erros: 0.
6. Acione Salvar.
85
Atividade 4.6 – Cadastrar um repositório de dados do tipo “Diretório LDAP”
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R5HSRVLWµULRGH'DGRVȋ
1 Nome1RPHSDUDLGHQWLȴFDUIDFLOPHQWHRUHSRVLWµULR
1 Porta: 389
1 Senha: 1234
1 Versão Protocolo: 3
Atividade 4.7 – Criar uma extração a partir de repositório do tipo Diretório LDAP
Esta atividade irá importar os usuários de teste que foram inseridos no LDAP para o
metadiretório do EID.
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R(7&ȋ
1 Na guia GeralHVSHFLȴTXH
Importe apenas usuários que possuam o atributo CPF informado na base LDAP.
Informe manualmente o nome dos atributos que deverão ser recuperados e importados do
/'$3QRSDLQHOȊOHLDXWHGHRULJHPȋ2WLSRGRVFDPSRVGHYHVHUFRQȴJXUDGRFRPRWH[WRGQFQ
sn, schacDateOfBirth, brPersonCPF, schacGender, brPersonPassPort, schacCountryOfCitizenship.
6HOHFLRQHRFDPSR'1FRPRΖGHQWLȴFDGRU¼QLFRΖ8
86
Na guia Leiaute de Destino:
1 ClasseΖGHQWLȴFDFDR
No painel “Leiaute de Destino dos Dados”, mapeie os campos de origem para o destino:
1 CPF: brPersonCPF.
}
}
Marque para remoção os campos que não serão mapeados e acione o comando Salvar.
87
3. $FHVVHRPHQXȊ&RQȴJXUD©¥R3URFHVVRVȋ
7. Número de erros: 0.
8. Acione Salvar.
88
5
Gestão de pessoas e grupos no EID
objetivos
conceitos
Gestão manual de pessoas e gestão de grupos.
Conciliação de registros
q
&DS¯WXOR*HVW¥RGHSHVVRDVHJUXSRVQR(Ζ'
&RQFLOLD©¥R«RSURFHVVRGHLGHQWLȴFD©¥RGHREMHWRVGXSOLFDGRVSURYHQLHQWHVGHIRQWH
de dados diferentes. Objetos duplicados são registros separados que referenciam uma
mesma entidade real. O principal problema de se ter objetos duplicados é a possível
H[LVW¬QFLDGHDWULEXWRVFRPYDORUHVGLYHUJHQWHV$SµVDLGHQWLȴFD©¥RGHYHVHUIHLWDXPD
UHVROX©¥RGRVFRQȵLWRV
O EID procura conciliar pessoas automaticamente. Ele utiliza o algoritmo Jaro Winkler, que
faz um cálculo baseado em distância entre strings para detectar registros duplicados. Para
realizar esta conciliação ele leva em conta os dados nomeCompleto, nomePai, nomeMae, cpf,
data Nascimento e sexo.
89
Em situações mais adversas, o administrador pode também forçar a conciliação de registros,
selecionando-os diretamente pela interface do sistema.
2 Conciliação é direta.
Essa reconciliação é mais barata que a primeira, dado que o grupo de registros a
serem conciliados já seja conhecido.
Vale observar que uma reimportação desnecessária pode implicar uma maior demora do
(Ζ'HPUHȵHWLUDDOWHUD©¥RQRUHJLVWURFRQVROLGDGR3RUHVWHPRWLYR«DFRQVHOK£YHOTXH
reimportações sejam incrementais, atualizando apenas os registros que tenham sido
realmente alterados na fonte.
Conciliação de registros
Por questões de implementação, os registros importados não são alterados no processo de
conciliação; eles são sempre mantidos no banco, em um estado diferenciado.
Figura 5.1
Conciliação de
UHJLVWURV
FRQFLOLD©¥R«FXVWRVDSRLVH[LJHDYHULȴFD©¥RGHXPJUDQGHFRQMXQWRGHUHJLVWURVGREDQFR
90
Figura 5.2
Interface de
FRQFLOLD©¥R
6HDVXJHVW¥RIRUDFDWDGDR(Ζ'SURPRYHU£DIXV¥RGRVUHJLVWURVHPXP¼QLFRUHJLVWURȴQDO
caso contrário serão gerados registros independentes para cada objeto listado.
de conciliação forçada.
Nesta interface, o comando Adicionar pode ser utilizado para localizar um registro e
adicioná-lo à lista; Remover promove a remoção de um registro da lista; Conciliar coloca o
FRQMXQWRGHUHJLVWURVQDȴODGHFRQFLOLD©¥RHCancelarFDQFHODDGHȴQL©¥RGDFRQFLOLD©¥R
2VUHJLVWURVVHOHFLRQDGRVVHU¥RPHVFODGRVHPXP¼QLFRUHJLVWURȴQDOVHQGRPDQWLGRR
*8Ζ'OH[LFRJUDȴFDPHQWHPHQRU2VGHPDLVVHU¥RGHVFDUWDGRV
Pesquisa de pessoas
1 Localização por valores de atributos de qualquer classe. q
1 Curinga ‘%’ pode ser utilizado.
91
Na pesquisa de pessoas o EID possibilita a pesquisa pelo atributo de qualquer uma de suas
classes. A busca exibe, por padrão, apenas o GUID dos registros. Outras informações podem
ser observadas selecionando-se os atributos das classes de interesse.
Figura 5.4
*HVW¥RGHSHVVRDV
A Figura 5.4 apresenta a tela de gestão de pessoas, que pode ser acessada pelo menu “EID/
Gestão de Pessoas”.
O campo AtributoDSUHVHQWDRVDWULEXWRVGHȴQLGRVSDUDDFODVVHHPTXHVW¥R2YDORU
desejado deve ser informado no campo “Valor do atributo”.
Como exemplo, os critérios a seguir serão usados para retornar a relação de todas as
Federação CAFe: Implantação do Provedor de Identidade
pessoas que tenham nome completo iniciado por José e terminado com Silva:
1 ClasseΖGHQWLȴFD©¥R
1 Atributo: NomeCompleto.
1 Valor: José%Silva.
92
Figura 5.5
$WULEXWRVYLV¯YHLV
Por padrão, o EID exibe apenas o GUID dos objetos encontrados. A Figura 5.5 exibe a aba
“Atributos visíveis”, onde é possível selecionar os atributos que serão exibidos, clicando-se
nas caixas equivalentes aos nomes das classes. Ao marcá-las, o atributo estará visível no
resultado apresentado na parte inferior da tela.
&DS¯WXOR*HVW¥RGHSHVVRDVHJUXSRVQR(Ζ'
93
Figura 5.6
*HVW¥RGHSHVVRDV
A Figura 5.6 apresenta a tela de gestão de pessoas que pode ser acessada pelo menu
“EID/Gestão de Pessoas”.
1 O comando NovoH[LEHDLQWHUIDFHSDUDGHȴQL©¥RGRVGDGRVGDSHVVRD
94
Figura 5.7
Tela de gestão
GHSHVVRDV
Dados de uma pessoa podem ser alterados pelo administrador, muito embora esta não seja
a forma recomendada: o ideal é que a alteração seja feita na fonte. É possível, também,
a atribuição de instâncias de classes a pessoas, opção útil para classes gerenciadas manual-
PHQWHHFRPLQVW¤QFLDVSDUDSRXFRVXVX£ULRVDWULEXWRVGHVHUYL©RVPDLVHVSHF¯ȴFRV
A tela de gestão de pessoas pode ser acessada pelo menu “EID/Gestão de Pessoas”. Deve-se,
SULPHLUDPHQWHORFDOL]DUDSHVVRDTXHWHU£VHXVGDGRVPRGLȴFDGRV(VWDSHVTXLVDSRGHVHU
feita conforme explicado na seção “Pesquisa de registros”.
&DS¯WXOR*HVW¥RGHSHVVRDVHJUXSRVQR(Ζ'
95
Forçar reunificação
Ao ser acionado, o botão 5HXQLȴFDUPDUFDRUHJLVWURFRPRSHQGHQWHSDUDUHXQLȴFD©¥R
Figura 5.8
5HXQLȴFD©¥R
Muitas vezes deseja-se atualizar um registro no LDAP, e para isso foi criado o botão 5HXQLȴFDU,
TXHUHID]DXQLȴFD©¥RSDUDGHWHUPLQDGRUHJLVWURID]HQGRFRPTXHVHXserialNumber seja
LQFUHPHQWDGRHFRQVHTXHQWHPHQWHȴTXHPDUFDGRFRPRDWXDOL]DGRSDUDVHUH[SRUWDGR
novamente para o LDAP.
Desativação de pessoas
1 Pessoas não são removidas, mas marcadas como inativas. q
1 Não são expostas pelo EID, o que elimina complicações em reimportação.
Figura 5.9
Desativação
GHSHVVRDV
Federação CAFe: Implantação do Provedor de Identidade
Registros de pessoas não são removidos, mas marcados como inativos. Essa estratégia
elimina problemas relativos à reimportação de registros, o que poderia ocasionar o
reaparecimento da pessoa.
Registros inativos não são expostos pelo EID, a não ser que sejam requisitados por uma
IXQ©¥RHVSHF¯ȴFD(VWDQGRRVUHJLVWURVLQDWLYRVDVDWXDOL]D©·HVIHLWDVQRVUHJLVWURVRULJL-
QDLVFRQWLQXDPUHȵHWLGDVQRUHJLVWURȴQDO(PFDVRGHUHDWLYD©¥RRVGDGRVGRUHJLVWURM£
UHȵHWHPDVLWXD©¥RDWXDOGRVUHJLVWURVRULJLQDLV
96
A reativação pode ser feita marcando-se o registro e acionando-se o comando Ativar.
Pessoas inativas são localizadas normalmente na interface de pesquisa, porém não disponi-
bilizam função de visualização ou edição.
Gestão de grupos
1 Grupo é um tipo especial de objeto EID. q
1 Realiza gestão automática de membros.
1 &ULW«ULRVGHȴQLGRVFRPRFRQVXOWD+4/
1 Atualizados diariamente.
A ferramenta EID disponibiliza uma forma simples de criar agrupamentos, tanto de pequenos
quanto de grandes grupos (professores da universidade, alunos da disciplina Cálculo 1).
Relacionamentos do grupo com as pessoas e seus atributos são criados, indicando perti-
nência a grupos. A atualização de grupos pode ser forçada via interface.
&DS¯WXOR*HVW¥RGHSHVVRDVHJUXSRVQR(Ζ'
97
Federação CAFe: Implantação do Provedor de Identidade
98
Roteiro de Atividades 5
Atividade 5.1 – Conciliação de um registro manualmente
Selecione registros do banco de dados e force a conciliação:
4. 3UHHQFKDRFDPSRȊ&ODVVHFRPΖGHQWLȴFD©¥Rȋ
8. Volte para a aba Parâmetros e selecione o registro JOSE FILISBINO, marcando-o e clicando
no botão Selecione.
12. Preencha o campo “Valor do atributo” com JOSE FE% e clique em Pesquisar.
14. Volte para a aba “Parâmetros” e selecione o registro JOSE FELISBINO, marcando-o e cli-
cando no botão “Selecione”.
2. H[LELGDXPDOLVWDFRPWRGRVRVUHJLVWURVTXHȴFDUDPSHQGHQWHVSDUDFRQFLOLD©¥R
5. Pesquise por usuários que não são os mesmos, mas estão agrupados para conciliar e
exclua da conciliação clicando no checkbox abaixo da lixeira e acionando o botão Excluir.
99
Atividade 5.3 – Inserção de uma nova pessoa
Faça a inserção manual de uma nova pessoa via interface.
ΖGHQWLȴFD©¥R
1 CPF: 12345678900.
Conta:
1 login: msilva
1 senha: esr
100
6
Alimentação de diretórios
com EID2LDAP
objetivos
conceitos
Mapeamento de dados do metadiretório para diretório LDAP e escalonamento
de atualizações.
Características do EID2LDAP
Este capítulo do curso apresentará a ferramenta EID2LDAP, que busca informações de
diretório armazenadas em um servidor EID e as transfere para servidores LDAP. Além das
características da ferramenta, estudaremos ainda a sua arquitetura (XML do EID, XSLT e
SURFHVVDPHQWR/'Ζ)HDSUHVHQWDUHPRVDVFRQȴJXUD©·HVHDOJXQVH[HPSORVGHXVRGD
ferramenta, além de problemas comuns.
O EID2LDAP é uma ferramenta que acessa o servidor EID via web service, transforma os regis-
tros para o formato LDIF compatível com o servidor LDAP de destino e transfere as informações.
&DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
1 8WLOL]DDPDUFD©¥R;6/7SDUDHVSHFLȴFDUDWUDQVIRUPD©¥RGRVGDGRVSDUDRIRUPDWR
LDAP Data Interchange Format (LDIF).
2 O XSLT é fornecido pelo usuário e deve gerar um LDIF compatível com o esquema
do LDAP de destino.
Assim como o EID, a ferramenta EID2LDAP permite o agendamento periódico das expor-
WD©·HVHPFDGDH[SRUWD©¥RV¥RDWXDOL]DGRVDSHQDVRVUHJLVWURVPRGLȴFDGRVLQVHULGRV
desativados desde a última importação.
101
&RPRDHVWUXWXUDGR/'$3«ȵH[¯YHODRH[SRUWDU«QHFHVV£ULRFRQKHF¬OD2([WHQVLEOH
6W\OHVKHHW/DQJXDJH7UDQVIRUPDWLRQV;6/7LQWURGX]ȵH[LELOLGDGHQR(Ζ'/'$3SHUPLWLQGR
DRXVX£ULRGHȴQLUFRPRVHGDU£RPDSHDPHQWRHQWUHRVGDGRVGR(Ζ'HRIRUPDWRGR/'$3
Logo, para realizar a exportação, três conhecimentos são necessários:
1 2IRUPDWRGR/'$3HVSHF¯ȴFR
1 A linguagem XSLT.
Arquitetura
XSLT
Registros
PRGLȴFDGRVLQVHULGRVDSDJDGRV LDIF
WS EID LDIF
Figura 6.1
LDIF
Arquitetura do
Servidores LDAP (Ζ'/'$3
2. %XVFDUHJLVWURVPRGLȴFDGRVLQVHULGRVGHVDWLYDGRV
O que foi enviado nesse intervalo ao LDAP (antes do erro) não será desfeito,
mas reescrito na próxima iteração.
$VHJXLUVHU¥RGHWDOKDGRVR;0/GR(Ζ'RPRGRGHHVSHFLȴFDUR;6/7HDIRUPDFRPR«
realizada a transformação para LDIF.
102
XML do EID
Contém informações sobre: q
1 Pessoas e seus atributos:
<eid-object type=”person”>....
</eid-object>
1 Grupos:
<eid-object type=”group”>...</eid-object>
1 Membros do grupo:
<member> <eid-object>...</eid-object>....</member>
O XML fornecido pelo EID carrega as informações sobre as pessoas e os grupos. São bus-
cados apenas os objetos novos, alterados ou excluídos.
Não há marcação no XML para indicar o atributo alterado, nem para diferenciar um objeto
novo de um alterado. Sempre é enviado todo o conteúdo do objeto.
XML do EID
<!--Pessoa ou Grupo -->
<attribute name=”nomeCompleto”
key=”03812882698”><![CDATA[ZACARIAS SILVA]]></attribute>
<attribute name=”cpf”><![CDATA[01212222222]]></attribute>
</attributes>
<attribute name=”email”><![CDATA[zeca@mail.com]]></attribute>
</attributes>
</eid-object>
<member>
<eid-object >...</eid-object>
</member>
103
No XML do EID, as várias classes existentes para a pessoa são recuperadas em elementos
attributes e seus atributos dispostos em elementos attribute, contendo nome e valor de
cada um.
XSLT
Transformações necessárias: q
1 Marcação para inserção de pessoas e grupos.
O XSLT controla a transformação do XML no LDIF que será enviado ao LDAP. O LDIF gerado
determina as operações que serão aplicadas no LDAP (Inserção/Exclusão/Alteração).
O XSLT deve tratar os tipos de informações enviadas pelo EID, que são:
1 ΖQVHU©¥RGHSHVVRDVPHPEURVGHJUXSRHJUXSRVFRPRDDOWHUD©¥RQ¥R«HVSHFLȴFDGD
deve ser tratada como inserção);
Inserção de registros:
<xsl:template match=”/”>
<xsl:apply-templates select=”eid-object[@type=’person’
</xsl:template>
changetype: add
objectclass: person
Federação CAFe: Implantação do Provedor de Identidade
</xsl:template>
O XSLT é utilizado para formatar o LDIF que será enviado para o LDAP. De acordo com as
LQIRUPD©·HVFRQWLGDVQRVGDGRVSURYHQLHQWHVGR(Ζ'R;6/7HVSHFLȴFDRPDSHDPHQWR
de cada um dos atributos para os atributos LDAP, bem como a operação a ser feita (Add/
Modify/Delete).
<xsl:template match=”/”>
<xsl:apply-templates select=”eid-object[@type=’person’
104
</xsl:template>
dc=ufmg, dc=br
changetype: delete
</xsl:template>
O XSLT apresentado ilustra o uso do atributo removed com o valor igual a true.
<xsl:template match=”/”>
<xsl:apply-templates select=”eid-object[@type=’group’]”
mode=”group” />
<xsl:apply-templates select=”member”/>
</xsl:template>
changetype: add
objectclass: groupOfNames
</xsl:template>
<xsl:template match=”member”>
</xsl:template>
A marcação <member> não existe no EID, sendo inserida pelo EID2LDAP para agrupar e &DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
indicar os EIDObjects que são membros do grupo.
A marcação <eid-object type=”group”> deve ser gerada para criar o LDIF com o objectclass
groupOfNames.
Processamento do LDIF
1 (QWUDGDVVHPDRSHUD©¥RGHȴQLGD$GG0RGLI\'HOHWHRXFRPDRSHUD©¥R$GGV¥R q
tratadas como operações de adição.
1 6HRUHJLVWURM£H[LVWLUQR/'$3LGHQWLȴFDGRSHOR'1JHUDGRQR/'Ζ)
2 2/'Ζ)«PRGLȴFDGRSDUDDSOLFDURSHUD©·HVGHDOWHUD©¥R
105
1RPRPHQWRGDH[SRUWD©¥RFDVRRUHJLVWURM£H[LVWDQR/'$3LGHQWLȴFDGRSHOR'1JHUDGRQR
/'Ζ)R/'Ζ)«PRGLȴFDGRSDUDDSOLFDURSHUD©·HVGHDOWHUD©¥R0RGLI\QRUHJLVWURGR/'$3
Configuração e uso
1 Acesso: q
2 Tela de login.
2 Tela inicial.
1 &RQȴJXUD©·HV
2 Servidores LDAP.
2 Transformações.
2 Agendamentos.
Acesso
1 Para acessar a aplicação: http://nomeservidor:8080/eid2ldap q
1 nomeservidor: Nome da máquina onde o EID2LDAP foi instalado.
Após a instalação da aplicação, para acessá-la basta abrir um browser e redirecioná-lo para:
http://nomeservidor:8080/eid2ldap. Onde nomeservidor deve ser substituído pelo nome da
máquina onde o EID2LDAP está instalado.
Figura 6.2
7HODGHORJLQ
Federação CAFe: Implantação do Provedor de Identidade
106
$)LJXUDDSUHVHQWDDWHODGHORJLQRVLVWHPDGHȴQHDSHQDVXPSDSHORGHDGPLQLVWUDGRU
Várias pessoas podem desempenhar este papel. A autenticação do usuário é delegada ao
Tomcat, podendo ser feita em arquivo texto, banco de dados, LDAP etc.
Figura 6.3
7HODLQLFLDO
Na tela inicial o EID2LDAP apresenta três menus por onde são acessadas as funcionalidades
do sistema: &RQȴJXUD©¥R, Agendamento, Ajuda e um ícone azul localizado na parte superior
Figura 6.4
0HQXV GLUHLWDGDMDQHODTXHȴQDOL]DDDSOLFD©¥R.
EID &RQȴJXUD©¥RGRHQGHUH©RGRZHEVHUYLFHGR(Ζ'
Menus
&ULD©¥RHDOWHUD©¥RGHDJHQGDPHQWRV
$JHQGDPHQWR6HUYLGRU/'$3
SDUDH[HFX©¥RGDVWUDQVIHU¬QFLDV
9LVXDOL]D©¥RGRORJGHH[HFX©¥R
$JHQGDPHQWR 5HVXOWDGRGRDJHQGDPHQWR HGHVFUL©¥RGRVHUURVHQFRQWUDGRV
$JHQWHJHUHQFLDGRU &RQWUROHGRDJHQWH
GHDJHQGDPHQWR HVFDORQDGRUGHH[HFX©·HV
$MXGD
107
Os menus do EID2LDAP se organizam da seguinte forma:
1 Menu “&RQȴJXUD©¥R6HUYLGRU/'$3ȋWHODGHSHVTXLVDYLVXDOL]D©¥RDOWHUD©¥RHFDGDVWUR
de Servidores LDAP.
1 Menu “&RQȴJXUD©¥R7UDQVIRUPD©¥RȋWHODGHFDGDVWURGRV;6/7VHDVVRFLD©¥RFRPRV
Servidores LDAP.
1 0HQXȊ&RQȴJXUD©¥R(Ζ'ȋWHODSDUDFRQȴJXUD©¥RGRHQGHUH©RGRZHEVHUYLFHGR(Ζ'
Configuração de exportação
Resumo: q
1 Inicialização do agente, se estiver parado.
1 &ULD©¥RGRDJHQGDPHQWRHGHȴQL©¥RGRV/'$3VGHGHVWLQR
1 9HULȴFD©¥RGRORJGHSURFHVVDPHQWR
3DUDFRQȴJXUDUXPDH[SRUWD©¥RGHGDGRVGRVHUYLGRU(Ζ'SDUDXPVHUYLGRU/'$3YLD
EIDLDAP os seguintes passos devem ser executados:
3. $FHVVRDRPHQXȊ&RQȴJXUD©¥R7UDQVIRUPD©¥RȋHFDGDVWUDPHQWRGRV;6/7VHDVVRFLD©¥R
aos respectivos LDAPs para realizar a correta transformação dos dados.
HGHȴQL©¥RGRV/'$3VGHGHVWLQR
108
Inicialização do agente
1 Menu: Agendamento/Agente Gerenciador de Agendamento.
Figura 6.5
Gerenciador de
Agendamentos.
1 0HQX&RQȴJXUD©¥R6HUYLGRU/'$3
&DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
109
Figura 6.6
Administração
GH/'$3
A Figura 6.6 mostra a tela “Administração de LDAP”, que lista todos os LDAPs cadastrados.
O comando NovoDFLRQDDLQWHUIDFHGHGHȴQL©¥RGHXPQRYRVHUYLGRU/'$3RFRPDQGR
Visualizar dá acesso ao registro no modo de visualização e o comando Alterar exibe o registro
no modo de edição.
Figura 6.7
Cadastro do
VHUYLGRU/'$3
110
A tela da Figura 6.7 é exibida após o acionamento do botão Novo na tela “Administração de
/'$3ȋ1HVWDWHODV¥RGHȴQLGRVRVGDGRVQHFHVV£ULRVSDUDRHVWDEHOHFLPHQWRGDFRQH[¥R
com o servidor LDAP.
1 Usuário e SenhaGHȴQHPRVGDGRVGRXVX£ULRGHFRQH[¥R(PUsuárioGHYHVHUHVSHFLȴ-
cado o DN completo, e não apenas o login.
1 Versão do protocolo indica a versão do protocolo LDAP que será utilizada na comunicação.
Cadastramento do XSLT
1 0HQX&RQȴJXUD©¥R7UDQVIRUPD©¥R
Figura 6.8
Administração de
&DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
$UTXLYRV;6/7
A tela da Figura 6.8 apresenta a interface de administração de arquivos XSLT, que lista
todas as transformações cadastradas. Ao acionar o botão Novo a tela de cadastro de
arquivos XSLT é exibida.
111
Cadastramento do XSLT
Figura 6.9
Tela de cadastro
GH;6/7
A Figura 6.9 apresenta a tela de cadastro de XSLT, responsável pelo cadastro do XSLT e
associação com o LDAP.
1 &RPRR;6/7«HVSHF¯ȴFRDRIRUPDGRXVDGRQR/'$3GHYHVHUDVVRFLDGRDR/'$3 q
1 Como vários LDAPs podem ter a mesma estrutura, um mesmo XSLT pode ser cadas-
trado para mais de um LDAP.
Definição de agendamento
1 Menu: Agendamento/Agendamento Servidor LDAP.
Federação CAFe: Implantação do Provedor de Identidade
Figura 6.10
Administração de
DJHQGDPHQWRV
112
A tela de administração de agendamentos permite visualizar e editar os agendamentos
cadastrados no sistema. Ela lista todos os agendamentos cadastrados e o estado dos
mesmos, que pode ser:
1 Finalizado;
1 Aguardando;
1 Em execução.
Figura 6.11
Interface para
cadastro de um
DJHQGDPHQWR
A tela da Figura 6.11 apresenta a interface para cadastro de um agendamento, exibida &DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
quando é acionado o botão Novo da tela de administração de agendamentos.
1 O campo “Intervalo em minutos” somente será utilizado se o tipo de repetição for em minutos.
1 O campo “Próxima Execução” indica a data em que será iniciada a execução do primeiro
agendamento.
1 2V/'$3VDVHUHPDWXDOL]DGRVFRPHVWDFRQȴJXUD©¥RV¥RGHȴQLGRVQRSDLQHOȊ6HUYLGRU/'$3ȋ
113
Verificação do log
1 Menu: Agendamento/Resultado do Agendamento.
Figura 6.12
Tela de resultado
GRSURFHVVDPHQWR
A Figura 6.12 apresenta a tela “Resultado de Agendamento”, que exibe dados sobre os
agendamentos executados ou ainda em execução. Cada execução gera uma entrada.
São informadas as datas de início e término da execução, o número do processamento
que indica quantas vezes o agendamento foi executado e a situação, que pode ser:
1 )Ζ1(6+('([HFX©¥RȴQDOL]DGDFRPVXFHVVR
1 )Ζ1(6+('B(55256([HFX©¥RȴQDOL]DGDFRPHUUR
Federação CAFe: Implantação do Provedor de Identidade
114
Figura 6.13
Tela de visualização
de resultado de
DJHQGDPHQWRV
Problemas comuns
1 Erros de sintaxe: q
2 Em função de dados malformados importados das fontes.
1 Solução: &DS¯WXOR$OLPHQWD©¥RGHGLUHWµULRVFRP(Ζ'/'$3
O LDAP é bastante rígido quanto à sintaxe de alguns atributos, como mail, telephoneNumber
etc. Durante a exportação podem ocorrer erros dessa natureza em função de dados malfor-
mados importados das fontes.
A solução mais adequada é a correção do dado na fonte, seguida por sua reimportação.
Na impossibilidade de fazê-lo, pode-se também utilizar scripts de conversão no leiaute de
destino da ETC, criando-se regras de validação. Algumas regras estão disponibilizadas na
seção FAQ do site do projeto, como validação de e-mail e CPF.
115
Federação CAFe: Implantação do Provedor de Identidade
116
Roteiro de Atividades 6
1. $FHVVHRPHQXȊ&RQȴJXUD©¥R6HUYLGRU/'$3ȋ
3. Altere os dados de conexão para seu servidor LDAP local deixando-os como abaixo:
1 Senha: 1234
1 Versão Protocolo: 3
1 Número de série: -1
1. $FLRQHRPHQXȊ&RQȴJXUD©¥R7UDQVIRUPD©¥Rȋ
5. 1RGHWDOKHȊ6HUYLGRU/'$3ȋRVHUYLGRU/'$3FRQȴJXUDGRQD$WLYLGDGHGHYHHVWDU
&DS¯WXOR5RWHLURGH$WLYLGDGHV
selecionado.
117
Atividade 6.4 – Executar teste padrão: leitura no diretório
([HFXWHRWHVWHSDGU¥RSDUDOHLWXUDQRPHWDGLUHWµULR
1. 9HULȴTXHDFDUJDGDFODVVH&RQWD8WLOL]DQGRXPQDYHJDGRUZHEDFHVVHD85/DVHJXLU
trocando <servidor> pelo endereço do servidor EID:
http://<servidor>:8080/eid/services/EidService/
getGuids?condition=select%20c.eidObject.stringID%20
from%20Conta%20c%20where%20c.eidObject.unifiedDomain%20
%3D%20true%20and%20c.login%20!%3D%20null%20and%20c.
eidObject.serialNumber%20%3E%20(select%20max(e.
serialNumber)- 1000%20from%20EidObject%20e%20where%20e.
unifiedDomain%20%3D%20true)
<ns:getGuidsResponse>
<ns:return>CIVZAGRA-CXJFBAAA</ns:return>
<ns:return>KHWRXWEA-CXJFBAAA</ns:return>
<ns:return>MEMJJEJA-DXJFBAAA</ns:return>
<ns:return>OYFQQYMA-CXJFBAAA</ns:return>
<ns:return>QACXOEDA-DXJFBAAA</ns:return>
<ns:return>QGEDIIFA-BXJFBAAA</ns:return>
</ns:getGuidsResponse>
ɅNo campo “Próxima Execução”, informe data e hora atual, no formato: dd/mm/aaaa
hh:mm.
118
3. Acione o comando Salvar.
4. $JXDUGHDOJXQVPLQXWRVDW«DLPSRUWD©¥RVHUUHDOL]DGDFRPVXFHVVRSDUDYHULȴFDU
acesse o menu “Agendamento/Resultado Agendamento”.
# ldapsearch -x -D “cn=admin,dc=<nome_da_instituição>,dc=br” -W
ɅClasse: Conta
ɅClique em Pesquisar.
3. Selecione o usuário para ser desativado clicando no check box abaixo do ícone de lixeira e
no botão Desativar na barra de menus.
ɅClasse: Conta
6. Clique em Salvar.
8. Clique no botão Alterar e em seguida no botão Salvar forçando com que a exportação seja
executada novamente.
9. $JXDUGHDOJXQVVHJXQGRVDW«DLPSRUWD©¥RVHUUHDOL]DGDFRPVXFHVVRSDUDYHULȴFDU
acesse o menu “Agendamento/Resultado Agendamento”.
10. 2EVHUYHRVGDGRVQR/'$3DWUDY«VGR$SDFKH'LUHFWRU\6WXGLRHYHULȴTXHTXHRusuário1
&DS¯WXOR5RWHLURGH$WLYLGDGHV
foi removido do LDAP, já que foi marcado como Desativado no metadiretório através do
EID. E o registro do usuário2 teve sua data de nascimento alterada para 01/01/1990.
$VDOWHUD©·HVIHLWDVQRPHWDGLUHWµULRIRUDPUHȵHWLGDVQR/'$3DSµVDH[SRUWD©¥RGRV
dados via EID2LDAP.
119
Federação CAFe: Implantação do Provedor de Identidade
120
7
Plataforma Shibboleth
objetivos
conceitos
ΖQVWDOD©¥RGRSURYHGRUGHLGHQWLGDGHFRQȴJXUD©¥RPDQXDOGRSURYHGRU
GHLGHQWLGDGHVROLFLWD©¥RHLQVWDOD©¥RGHFHUWLȴFDGR
Introdução
O que é Shibboleth? q
1 Terminologia:
2 Palavra de origem bíblica que distingue pessoas de um grupo das pessoas de outro.
O termo “shibboleth” denota uma palavra usada para distinguir pessoas de um grupo das
pessoas de outro. A origem deste termo remete ao velho testamento (Juízes, 12: 1-15), onde
ele foi usado para distinguir duas tribos semitas, os gileaditas e os efraimitas, que travaram
uma grande batalha. Os gileaditas, vencedores, bloquearam as passagens do Jordão para
evitar que os efraimitas sobreviventes pudessem escapar. As sentinelas exigiam que todo
passante dissesse “shibboleth”; como os efraimitas não tinham o fonema /x/ em seu dialeto,
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
só conseguiam pronunciar “sibboleth” (com /si/ na primeira sílaba), sendo assim reconhe-
cidos e executados.
O que é Shibboleth?
1 Projeto de middleware da Internet2. q
1 6$0/6HFXULW\$VVHUWLRQ0DUNXS/DQJXDJHSDGU¥RGHȴQLGRSHOD2$6Ζ6
(Organization for the Advancement of Structured Information Standards).
1 Acesso federado.
121
1 Autenticação. q
1 Autorização.
Componentes do Shibboleth
1 Provedor de Identidade (IdP). q
1 Provedor de Serviço (SP).
1 Metadata.
1 Privacidade.
1 Google Apps.
1 Media Wiki.
1 Blackboard.
1 ProQuest.
1 &RQȵXHQFH
1 Microsoft DreamSpark.
122
Federações atuais:
1 CARSI (China).
1 CRU (França).
1 DFN-AAI (Alemanha).
1 DK-AAI (Dinamarca).
1 FEIDE (Noruega).
1 HAKA (Finlândia).
1 InCommon (EUA).
1 MAMS (Austrália).
1 SIR (Espanha).
1 SWAMID (Suécia).
1 SWITCHaai (Suíça).
1 UK Federation (RU).
1 WAYF (Dinamarca).
1 CAFe (Brasil)
1 Dentre outras
1 Web SSO.
1 Atributos.
123
CAS Credenciais
Handle
Service Handle
LDAP
Handle
Attribute
Authority
Atributos
Shibboleth IdP
2 Attribute Authority.
1 CAS:
2 Web SSO.
1 LDAP:
2 Autenticação.
2 Atributos.
Além disso, é importante ressaltar que o Shibboleth IdP pode trabalhar com outros servi-
dores de autenticação e atributos.
124
Provedor de Serviço (SP)
Serviço: q
1 Recurso.
1 Autorização.
Serviço: q
1 Recurso.
1 Autorização.
Apache
Recurso
Handle mod_shib
Handle
shibd
Atributos
Shibboleth SP
Figura 7.2
Arquitetura BD
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
de um provedor
de serviços
1 shibd (daemon).
125
A instalação padrão de um provedor de serviço da federação CAFe é baseada no Shibboleth
Service Provider, que, por sua vez, é composto por dois elementos:
DS/ WAYF
1 De onde você é? q
2 Qual é o seu provedor de identidade?
Metadata
$UTXLYRGHFRQȴJXUD©¥R q
1 SAML Metadata (schema) + Extensões Shibboleth.
2VHUYL©RGH0HWDGDWD«DSHQDVXPDUTXLYRGHFRQȴJXUD©¥RSDGURQL]DGRHFRPSDUWLOKDGR
entre os provedores de identidade e de serviço da federação.
Metadados
1 5HODFLRQDPHQWRGHFRQȴDQ©DHQWUHSURYHGRUHV q
2 &HUWLȴFDGRV
2 Chaves públicas.
Federação CAFe: Implantação do Provedor de Identidade
2 IDs.
2 URLs.
2 Protocolos.
$WUDY«VGHVWHDUTXLYR«HVWDEHOHFLGDDUHOD©¥RGHFRQȴDQ©DHQWUHRVSURYHGRUHVGDIHGH-
UD©¥RXWLOL]DQGRFHUWLȴFDGRVGLJLWDLVRXFKDYHVS¼EOLFDV$O«PGLVVRRDUTXLYRGHPHWD-
dados disponibiliza as informações relevantes para a comunicação entre os provedores,
FRPRLGHQWLȴFDGRUHV85/VHSURWRFRORVXWLOL]DGRV
126
Funcionamento
Fase 1
HTTPS Request/Response
HTTPS Redirect
HTTPS Session
Conexão interna
Conexão virtual
Apache
WAYF
Metadata
Apache
CAS Recurso
Handle mod_shib
Service
LDAP
Attribute
Authority shibd
Shibboleth Shibboleth
IdP SP
Tomcat
Apache BD
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
Host: eaa1.dri.cefetmg.br
127
2. Como o usuário ainda não está autenticado, o servidor web responde com um redirecio-
namento HTTP para o servidor WAYF (http://shibboleth.ufrgs.br). Como o WAYF precisa
saber qual provedor de serviço o usuário está tentando acessar, as informações são
enviadas como parâmetros GET.
Location: http://shibboleth.ufrgs.br/chimarrao/WAYF\
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso\
&target=https://eaa1.dri.cefetmg.br/secure/\
&providerId=https://eaa1.dri.cefetmg.br/shib-sp
GET /chimarrao/WAYF
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso\
&target=https://eaa1.dri.cefetmg.br/secure/\
&providerId=https://eaa1.dri.cefetmg.br/shib-sp HTTP/1.1
Host: shibboleth.ufrgs.br\
3. O WAYF responde ao browser com uma página para o usuário selecionar a sua instituição
de origem.
HTTP/1.x 200 OK
Content-Type: text/html;charset=ISO-8859-1
128
Fase 2
Figura 7.4
Seleção da
instituição de
RULJHP
Na página do WAYF, o usuário seleciona a sua instituição de origem, ou seja, o seu provedor
de identidade. Essa seleção é armazenada por cookies de sessão no browser do usuário.
Figura 7.5
Seleção da
instituição
de origem no
Discovery Service
ou WAYF
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
129
Fase 3
HTTPS Request/Response
HTTPS Redirect
HTTPS Session
Conexão interna
Conexão virtual
Apache
WAYF
Metadata
5
6
7
Apache
CAS Recurso
Handle mod_shib
Service
LDAP
Attribute
Authority shibd
Federação CAFe: Implantação do Provedor de Identidade
Shibboleth Shibboleth
IdP SP
Tomcat
Apache BD
4. O usuário envia a seleção da sua instituição de origem a partir de uma requisição HTTP. Figura 7.6
Autenticação
GET /chimarrao/WAYF\ do usuário na
sua instituição
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso\ GHRULJHP
&target=https://eaa1.dri.cefetmg.br/secure/\
&action=selection\
130
&origin=urn:mace:shibboleth:chimarrao:rnp.br\
&cache=TRUE HTTP/1.1
Host: shibboleth.ufrgs.br
Cookie: JSESSIONID=ABA262C37103B02AB65D16B1D0EB3359
Set-Cookie: edu.internet2.middleware.shibboleth.wayf.
selectedHandleService=\
https://idp-demo.rnp.br/shibboleth-idp/SSO; Path=/
Location: https://idp-demo.rnp.br/shibboleth-idp/SSO\
?target=https://eaa1.dri.cefetmg.br/secure/\
&shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
GET /shibboleth-idp/SSO\
?target=https://eaa1.dri.cefetmg.br/secure/\
&shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
6. Como o usuário ainda não está autenticado, o servidor web, protegendo o acesso ao
Handle Service, redireciona o browser para o sistema de autenticação single sign-on (CAS).
HTTP/1.x 200 OK
Set-Cookie: JSESSIONID=C5766808E41D3C64BFBD3839D6701730;
Location: https://idp-demo.rnp.br/cas/login
?service=https://idp-demo.rnp.br/shibboleth-idp/SSO
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
&target&https://eaa1.dri.cefetmg.br/secure
&providerId=https://eaa1.dri.cefetmg.br/shib-sp
131
GET /cas/login
?service=https://idp-demo.rnp.br/shibboleth-idp/SSO
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
&target=https://eaa1.dri.cefetmg.br/secure
&providerId=https://eaa1.dri.cefetmg.br/shib-sp HTTP/1.1
Host: idp-demo.rnp.br
Cookie: _saml_idp=dXJuOm1hY2U6c3dpdGNoLmNoOlNXSVRDSGFhaTp1bmlnZS5jaA
7. O sistema de autenticação single sign-on envia a página de login para o browser e habilita
os seus cookies.
HTTP/1.x 200 OK
132
Fase 4
HTTPS Request/Response
HTTPS Redirect
HTTPS Session
Conexão interna
Conexão virtual
Apache
WAYF
Metadata
Apache
CAS Recurso
8
8
Credenciais Handle
Handle mod_shib
Service 10
LDAP
Attribute
Authority shibd
Shibboleth Shibboleth
IdP SP
Tomcat
Apache BD
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
Figura 7.7 8. Uma vez que o usuário disponibiliza as suas credenciais – nome de usuário ‘dijkstra’ e
$FHVVRDRUHFXUVR
senha ‘goto’, neste exemplo –, o browser envia uma nova solicitação para o sistema de
autenticação (CAS). O sistema de autenticação, que é independente do Shibboleth, veri-
ȴFDDVFUHGHQFLDLVGRXVX£ULRDWUDY«VGRGLUHWµULR/'$3
/cas/login
?service=https://idp-demo.rnp.br/shibboleth-idp/SSO
&shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
133
&target=https://eaa1.dri.cefetmg.br/secure
&providerId=https://eaa1.dri.cefetmg.br/shib-sp HTTP/1.1
Host: idp-demo.rnp.br
Cookie: cas_pre_s=rcAHSqG62uVW7zGdRxKtnpdIWg7IFiwXihvObdaYa7mFI3qR4
RYfm6F\ [...] hSNjSOxMUT68kuDApIWngwxPfVaggG; cas_g_req=clear
Content-Type: application/x-www-form-urlencoded
Content-Length: 61
username=dijkstra&password=goto<=LT-27-3fKACnZWQlYd8T4Md08p
Set-Cookie: CASTGC=TGC-13-jpZHue4IXosIiVGyy6vrGcj3YOO0H3mRvjcpEqMK0E
U8gFS6RC; Path=/cas;
Location: https://idp-demo.rnp.br/shibboleth-idp/SSO
?shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
&target=https://eaa1.dri.cefetmg.br/secure
&providerId=https://eaa1.dri.cefetmg.br/shib-sp
&ticket=ST-17-lGFPJrLWJva134whvhxZ
Set-Cookie: CASTGC=TGC-13-jpZHue4IXosIiVGyy6vrGcj3YOO0H3mRvjcpEqMK0E
U8gFS6RC; Path=/cas; Secure
GET /shibboleth-idp/SSO\
?target=https://eaa1.dri.cefetmg.br/secure/\
&shire=https://eaa1.dri.cefetmg.br/Shibboleth.sso
Federação CAFe: Implantação do Provedor de Identidade
&ticket=ST-17-lGFPJrLWJva134whvhxZ HTTP/1.1
Host: idp-demo.rnp.br
134
10. Baseado nos cookies, o Shibboleth IdP sabe que o usuário foi devidamente autenticado.
Então, o Handle Service cria um handle para o usuário. Esse handle é embarcado em um
hidden form, que é enviado pelo browser para o provedor de serviço.
<Directory /var/www/secure>
AuthType shibboleth
ShibRequireSession On
require valid-user
</Directory>
HTTP/1.x 200 OK
<noscript>
Host: eaa1.dri.cefetmg.br
Content-Type: application/x-www-form-urlencoded
Content-Length: 16859
135
TARGET=https://eaa1.dri.cefetmg.br/secure/\
VzcG9uc2U%2B
Fase 5
HTTPS Request/Response
HTTPS Redirect
HTTPS Session
Conexão interna
Conexão virtual
Apache
WAYF
Metadata
Apache
CAS Recurso
13
13
13
Handle
Service mod_shib
Federação CAFe: Implantação do Provedor de Identidade
LDAP
11 12 11
Attribute Handle 11
11 shibd
Authority 12 Atributos
11 Shibboleth Shibboleth
IdP SP
Tomcat
Apache BD
Figura 7.8
Solicitação de
DWULEXWRV
136
11. O Shibboleth SP, então, solicita ao provedor de identidade todos os atributos disponíveis
para o usuário associado ao handle recebido no passo anterior.
<samlp:request xmlns:samlp=”urn:oasis:names:tc:SAML:1.0:protocol”
issueinstant=”2004-05-25T22:46:10Z” majorversion=”1”
minorversion=”1” requestid=”aaf2319617732113474afe114412ab72”>
<samlp:attributequery resource=”https://eaa1.dri.cefetmg.br/
secure/”>
<saml:subject xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion”>
<saml:nameidentifier
format=”urn:mace:shibboleth:1.0:nameIdentifier”
namequalifier=”http://idp-demo.rnp.br/shibboleth”>
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:nameidentifier>
</saml:subject>
</samlp:attributequery>
</samlp:request>
12. Após a sessão HTTPS ser estabelecida entre o shibd e o Attribute Authority do Shibboleth
ΖG3R$WWULEXWH$XWKRULW\YHULȴFDDLGHQWLGDGHGR63FRPEDVHQRFHUWLȴFDGRHQYLDGRSHOR
VKLEG8PDYH]TXHR$WWULEXWH$XWKRULW\UHFHEHDVROLFLWD©¥RGHDWULEXWRVHOHYHULȴFD
se o handle é o mesmo gerado pelo Handle Service no passo 10; caso isso seja verdade,
ele sabe a que usuário o handleVHUHIHUH(QW¥RHOHYHULȴFDR$WWULEXWH)LOWHUDUTXLYR
XML responsável pelas regras que determinam quando um atributo de um determinado
XVX£ULRSRGHVHUHQYLDGRSDUDXPGHWHUPLQDGRSURYHGRUGHVHUYL©R$SµVHVWDYHULȴ-
cação, o Attribute Authority envia para o provedor de serviço todos os atributos permi-
tidos de acordo com o arquivo DWWULEXWHȴOWHU[PO.
<samlp:response xmlns:samlp=”urn:oasis:names:tc:SAML:1.0:protocol”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.
w3.org/2001/XMLSchema-instance” inresponseto=”aaf2319617732113474afe
114412ab72” issueinstant=”2004-05-25T22:46:10.940Z” majorversion=”1”
minorversion=”1” responseid=”b07b804c7c29ea1673004f3d6f7928ac”>
<samlp:status>
</samlp:status>
<saml:assertion xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion”
assertionid=”a144e8f3adad594a9649924517abe933”
issueinstant=”2004-05-25T22:46:10.939Z” majorversion=”1”
minorversion=”1”
issuer=”https://idp-demo.rnp.br/shibboleth”>
<saml:conditions notbefore=”2004-05-25T22:46:10.939Z”
137
notonorafter=”2004-05-25T23:16:10.939Z”>
<saml:audiencerestrictioncondition>
<saml:audience>
https://eaa1.dri.cefetmg.br/secure/
</saml:audience>
</saml:audiencerestrictioncondition>
</saml:conditions>
<saml:attributestatement>
<saml:subject>
<saml:nameidentifier
format=”urn:mace:shibboleth:1.0:nameIdentifier”
namequalifier=”https://idp-demo.rnp.br/shibboleth”>
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:nameidentifier>
</saml:subject>
<saml:attribute attributename=“urn:mace:dir:attribute-def:cn”
attributenamespace=”urn:mace:shibboleth:1.0:attributeNamespace:u ri”>
<saml:attributevalue xsi:type=”xsd:anyURI”>
Edsger
</saml:attributevalue>
</saml:attribute>
<saml:attribute attributename=“urn:mace:dir:attribute-def:sn”
attributenamespace=”urn:mace:shibboleth:1.0:attributeNamespace:u ri”>
<saml:attributevalue xsi:type=”xsd:anyURI”>
Federação CAFe: Implantação do Provedor de Identidade
Dijkstra
</saml:attributevalue>
</saml:attribute> [...]
</saml:attributestatement>
</saml:assertion>
</samlp:response>
138
13. Finalmente, o usuário recebe um cookie de sessão Shibboleth e é redirecionado para o
recurso. Os atributos enviados pelo provedor de identidade são disponibilizados para
aplicação web pelo mod_shib, na forma de variáveis de ambiente do servidor web. Desta
forma, o recurso pode usar esses atributos para prover um nível de autorização mais gra-
nular, além de possibilitar funcionalidades extras na aplicação, baseado nestes atributos.
Set-Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad;p
ath=/
Location: https://eaa1.dri.cefetmg.br/secure/
Host: eaa1.dri.cefetmg.br
Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad
Set-Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad;
path=/
Location: https://eaa1.dri.cefetmg.br/secure/
Host: eaa1.dri.cefetmg.br
Cookie: _shibsession_default=b03871b42d188af4062e6fbd777550ad
&DS¯WXOR3ODWDIRUPD6KLEEROHWK
139
HTTPS Request/Response
HTTPS Redirect
HTTPS Session
Conexão interna
Conexão virtual
Apache
WAYF
Metadata
3
4
9
1
5
6 2
Apache
CAS Recurso
8 13
8 13
Credenciais Handle 13
Handle
Service 10
mod_shib
LDAP
11 12 11
Attribute Handle 11
11
Authority 12 Atributos shibd
11 Shibboleth Shibboleth
IdP SP
Federação CAFe: Implantação do Provedor de Identidade
Tomcat
Apache BD
Figura 7.9
Acesso ao recurso
140
Roteiro de Atividades 7
Atividade 7.1 – Instalar e configurar provedor de identidade Shibboleth
Para instalar o Shibboleth, siga os passos abaixo. Java e Tomcat já estão instalados na VM.
Instalar Apache:
apt-get update
1. $VVHJXLQWHVFRQȴJXUD©·HVGHYHPVHUIHLWDVSDUDTXHR7RPFDWH[HFXWHR6KLEEROHWKΖ'3
security.provider.8=sun.security.smartcardio.SunPCSC
security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/
security/nss.cfg
..
security.provider.10=edu.internet2.middleware.shibboleth.
DelegateToApplicationProvider
security.provider.11=org.bouncycastle.jce.provider.
BouncyCastleProvider
2. Edite /etc/tomcat6/server.xmlSDUDGHȴQLUTXHUHFHEHU£FRQH[·HV+7736QDSRUWD
para isso, descomente a seguinte linha (aproximadamente a linha 94 do arquivo original):
<Connector port=”8443”
maxHttpHeaderSize=”8192”
maxSpareThreads=”75”
&DS¯WXOR5RWHLURGH$WLYLGDGHV
scheme=”https”
secure=”true”
clientAuth=”want”
SSLEnabled=”true”
sslProtocol=”TLS”
keystoreType=”PKCS12”
keystoreFile=”/opt/shibboleth-idp/credentials/idp.p12”
141
keystorePass=”changeit”
truststoreFile=”/opt/shibboleth-idp/credentials/idp.p12”
truststorePass=”changeit”
truststoreAlgorithm=”DelegateToApplication”/>
cp /opt/treinamento/idp/idp.xml /etc/tomcat6/Catalina/localhost
<Context docBase=”/opt/shibboleth-idp/war/idp.war”
privileged=”true”
antiResourceLocking=”false”
antiJARLocking=”false”
unpackWAR=”false”
swallowOutput=”true” />
<VirtualHost SUBSTITUIR_IP:443>
ServerName SUBSTITUIR_IP
ServerSignature Off
SSLEngine on
SSLCertificateKeyFile /etc/ssl/private/chave-apache.key
SSLCertificateFile /etc/ssl/certs/certificado-apache.crt
Federação CAFe: Implantação do Provedor de Identidade
DocumentRoot /var/www/vazio/
<Directory /var/www/vazio/>
AllowOverride None
Order deny,allow
</Directory>
142
JkMount /idp/* ajp13_worker
LogLevel warn
ErrorLog /var/log/apache2/error-idp-443.log
</VirtualHost>
cp /opt/treinamento/idp/idp-SSO /etc/apache2/sites-available
cp /opt/treinamento/idp/idp.conf /etc/apache2/conf.d/
Conteúdo do arquivo:
JkShmFile /var/run/apache2/jk-runtime-status
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
7. &RPDQGRVSDUDȴQDOL]DUDFRQȴJXUD©¥RGR$SDFKH
mkdir /var/www/vazio/
a2dissite default
a2ensite idp-SSO
a2enmod ssl
a2enmod jk
8. Reinicie o Apache e o Tomcat e veja se os serviços são iniciados com sucesso. Caso con-
WU£ULRYHULȴTXHRVHUURVLQGLFDGRV
/etc/init.d/apache2 restart
/etc/init.d/tomcat6 restart
export JAVA_HOME=”/usr/lib/jvm/java-6-openjdk/”
cd /root/
143
cp /opt/treinamento/idp/tomcat6-dta-ssl-1.0.0.jar /usr/share/
tomcat6/lib
cp /opt/treinamento/idp/bcprov-jdk16-144.jar /usr/lib/jvm/java-6-
openjdk/jre/lib/
cp /opt/treinamento/idp/shibboleth-identityprovider-2.4.0-bin.zip /root
unzip shibboleth-identityprovider-2.4.0-bin.zip
cd shibboleth-identityprovider-2.4.0/
cp -r endorsed /usr/share/tomcat6/
idp.home=/opt/shibboleth-idp
idp.home.input=/opt/shibboleth-idp
idp.hostname=SUBSTITUIR_IP
idp.hostname.input=SUBSTITUIR_IP
idp.keystore.pass=changeit
EOF
./install.sh
VHJXLQWHFRQȴJXUD©¥R
<!--
<LoginHandler xsi:type=”RemoteUser”>
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:class
es:unspecified</AuthenticationMethod>
</LoginHandler>
-->
144
<LoginHandler xsi:type=”UsernamePassword”
jaasConfigurationLocation=”file:///opt/shibboleth-idp/conf/
login.config”>
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:class
es:PasswordProtectedTransport</AuthenticationMethod>
</LoginHandler>
<metadata:MetadataProvider id=”URLMD”
xsi:type=”metadata:FileBackedHTTPMetadataProvider”
metadataURL=”https://sp.curso.rnp/Shibboleth.sso/Metadata”
backingFile=”/opt/shibboleth-idp/metadata/
sp-metadata.xml”>
<metadata:MetadataFilter xsi:type=”metadata:ChainingFilter”>
<metadata:MetadataFilter xsi:type=”metadata:EntityRole
WhiteList”>
<metadata:RetainedRole>samlmd:SPSSODescriptor</etadata:RetainedRole>
</metadata:MetadataFilter>
</metadata:MetadataFilter>
</metadata:MetadataProvider>
cp /opt/treinamento/idp/attribute-filter.xml /opt/shibboleth-idp/conf
cd /opt/shibboleth-idp/metadata/
cp Metadata sp-metadata.xml
cp /opt/treinamento/idp/attribute-resolver.xml /opt/shibboleth-idp/conf
&DS¯WXOR5RWHLURGH$WLYLGDGHV
5. &RQȴJXUD©¥RGDDXWHQWLFD©¥R/'$3
145
1 SUBSTITUIR_BASE_DN – ramo da árvore que contém os usuários:
“ou=people,dc=SUBSTITUIR _ INSTITUICAO,dc=br”
1 SUBSTITUIR_USUARIO_LEITOR_SHIB – usuário que tem direito de leitura na base LDAP:
(GLWHRDUTXLYRHPȊRSWVKLEEROHWKLGSFRQIORJLQFRQȴJȋSDUDTXHȴTXHFRPR«H[LELGR
DEDL[RRDUTXLYRWDPE«PVHHQFRQWUDHPȊRSWWUHLQDPHQWRLGSORJLQFRQȴJȋHSRGHVHU
copiado para a pasta do conf. do IDP).
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host=”SUBSTITUIR_SERVIDOR_LDAP:389”
base=”SUBSTITUIR_BASE_DN”
ssl=”false”
userField=”uid”
serviceUser=”SUBSTITUIR_USUARIO_LEITOR_SHIB”
serviceCredential=”SUBSTITUIR_SENHA_LEITOR_SHIB”
subtreeSearch=”false”;
};
HOSTNAME_FQDN=SUBSTITUIR_IP
[ req ]
Federação CAFe: Implantação do Provedor de Identidade
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
[ req_distinguished_name ]
countryName_min = 2
countryName_max = 2
146
0.organizationName = Nome da universidade/instituicao
emailAddress_max = 40
commonName_max = 64
commonName_default = $HOSTNAME_FQDN
# Default values for the above, for consistency and less typing.
#------------------------------ ------------------------------
#0.organizationName_default =
# organizationalUnitName_default = CPD
countryName_default = BR
[ usr_cert ]
basicConstraints= CA:FALSE
[ ssl_server ]
basicConstraints= CA:FALSE
nsCertType = server
[ v3_req ]
basicConstraints= CA:FALSE
[ v3_ca ]
basicConstraints= CA:FALSE
EOF
147
2. &HUWLȴFDGRSDUD6KLEEROHWKΖG3
Copie e cole na janela de terminal os comandos seguintes (um a um) de acordo com as
instruções abaixo:
2 &RQȴUPHRFµGLJRGRSD¯V%5
2 Cidade.
2 Departamento da instituição.
2 &RQȴUPHVHRKRVWQDPHHVW£FRUUHWRΖ3GRKRVWTXHVHU£RΖ'3
cd /opt/shibboleth-idp/credentials/
rm -f idp*
openssl req -new -x509 -nodes -days 1095 -sha1 -key idp.key -set_
serial 00 -config openssl.cnf > idp.crt
openssl pkcs12 -export -in idp.crt -inkey idp.key -out idp.p12 -name
idp -caname selfsigned
3. &HUWLȴFDGRSDUD$SDFKH
openssl req -new -x509 -nodes -days 1095 -sha1 -key /etc/ssl/
private/chave-apache.key -set_serial 00 -config openssl.cnf > /etc/
Federação CAFe: Implantação do Provedor de Identidade
ssl/certs/certificado-apache.crt
1 /LVWHRFRQWH¼GRGRDUTXLYRGRFHUWLȴFDGRTXHIRLDXWRDVVLQDGR
cat /opt/shibboleth-idp/credentials/idp.crt
148
1 Copie o conteúdo entre as linhas BEGIN CERTIFICATE e END CERTIFICATE.
$RVXEVWLWXLURFHUWLȴFDGRȴTXHDWHQWRSRLVSRGHRFRUUHUGHIDOWDUDOJXPDSDUWH
GHOH$SµVFRSLDUHFRODUFRQȴUDVHWRGRRFRQWH¼GRIRLFRODGR
<KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
INSIRA_AQUI_O_CONTEUDO_DO_ARQUIVO_DO_CERTIFICADO
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
6. 5HLQLFLHR7RPFDWHR$SDFKHSDUDTXHDVFRQȴJXUD©·HVVHMDPUHFDUUHJDGDV
/etc/init.d/apache2 restart
/etc/init.d/tomcat6 restart
7. $FHVVHRVHJXLQWHHQGHUH©RSDUDYHULȴFDUVHRΖG3HVW£QRDU
KWWSΖ3BGDBP£TXLQDBYLUWXDO!LGSSURȴOH6WDWXV.
9HULȴTXHVHXPDS£JLQDHPEUDQFRFRPDSDODYUD2.«H[LELGD
&DS¯WXOR5RWHLURGH$WLYLGDGHV
149
Federação CAFe: Implantação do Provedor de Identidade
150
8
Provedor de identidade na
plataforma Shibboleth
objetivos
&RKHFHURVSULQFLSDLVSRQWRVGHFRQȴJXUD©¥RGR$SDFKH7RPFDWH6KLEEROHWKΖG3
HWHVWDURDPELHQWHFRQȴJXUDGR
conceitos
Provedor de identidade, plataforma Shibboleth.
Provedor de identidade
Shibboleth
IdP Attribute &HUWLȴFDGRV Shibboleth
Tomcat MOD_ MOD_ 8443
Authority SSL SP
JK SSL
(AA)
&DS¯WXOR3URYHGRUGHLGHQWLGDGHQDSODWDIRUPD6KLEEROHWK
UHVROYHU[PO
DUS[PO Várias
comunicações
LGS[PO
+DQGOH Web
Server 443 browser
(HS)
Apache
LDAP
Figura 8.1
Principais pontos
GHFRQȴJXUD©¥R
151
Configuração do Apache
Virtual Hosts: q
2 AA – Attribute Authority.
1 mod_ssl:
2 &HUWLȴFDGR&KDYHH$XWRULGDGH&HUWLȴFDGRUD
3 ([LJ¬QFLDGRFHUWLȴFDGRGRVKLEGHUHSDVVHSDUDR6KLEEROHWKΖG3
1 mod_ jk:
1DFRQȴJXUD©¥RGR$SDFKHV¥RFULDGRVGRLV9LUWXDO+RVWV
1 AA, porta 8443: responsável pela comunicação entre o Attribute Authorithy e o Provedor
de Serviço.
1 SSO, porta 443: responsável pela comunicação entre o browser do usuário e o Handle
Server e o CAS.
Configuração do Tomcat
Conector AJP 1.3: q
1 Redirecionamento do Apache.
1DFRQȴJXUD©¥RGR7RPFDW«QHFHVV£ULRDSHQDVKDELOLWDURFRQHFWRU$-3UHVSRQV£YHO
pelo redirecionamento das requisições do Apache.
2 /opt/shibboleth-idp/conf/attribute-resolver.xml
2 RSWVKLEEROHWKLGSFRQIDWWULEXWHȴOWHU[PO
2 /opt/shibboleth-idp/metadata/<federação>-metadata.xml
26KLEEROHWKΖG3SRVVXLTXDWURSULQFLSDLVDUTXLYRVSDUDFRQȴJXUD©¥RGRVHUYL©R$WUDY«V
GHVWHVDUTXLYRV«SRVV¯YHOHVSHFLȴFDUGHWDOKDGDPHQWHFRPRRSURYHGRUGHLGHQWLGDGHLU£
atuar na federação. A seguir detalharemos cada um deles.
152
relying-party.xml
1 ΖGHQWLȴFDGRUGRSURYHGRUQDIHGHUD©¥R q
1 &UHGHQFLDLVFHUWLȴFDGRHFKDYH
attribute-resolver.xml
1 Conector para a base de atributos de usuários (LDAP ou SQL). q
1 DataConnectors:
2 'HȴQL©·HVGHDWULEXWRV
1 $WWULEXWH'HȴQLWLRQ
O arquivo attribute-resolver.xml«UHVSRQV£YHOSHODGHȴQL©¥RGDVUHJUDVGHUHVROX©¥RGHDWUL-
EXWRV1HOHV¥RFRQȴJXUDGRVRVSDU¤PHWURVGHDFHVVR¢EDVHGHGDGRVRXDRGLUHWµULRHR
mapeamento dos atributos. O mapeamento pode ser feito diretamente, através da simples
GHFODUD©¥RGRDWULEXWRRXSRGHVHUGHȴQLGRSHORXVX£ULRDWUDY«VGHVFULSWVSHUVRQDOL]DGRV
attribute-filter.xml
Regras de liberação de atributos: q
1 Liberação de atributos por SP.
$3RO¯WLFDGH/LEHUD©¥RGH$WULEXWRV«FRQȴJXUDGDDWUDY«VGRDUTXLYRDWWULEXWHȴOWHU[PO,
RQGH«SRVV¯YHOȴOWUDUDOLEHUD©¥RGHDWULEXWRVGHDFRUGRFRPTXHPRVUHTXLVLWD3RGHVH
por exemplo, liberar todos os atributos caso o requisitante seja um SP membro da Fede-
&DS¯WXOR3URYHGRUGHLGHQWLGDGHQDSODWDIRUPD6KLEEROHWK
ração CAFe, ou ainda liberar ou não determinado atributo para determinado SP.
metadata.xml
1 Disponibilizado pela federação. q
1 Informações relevantes sobre os provedores.
1 &RQȴDQ©D
2 &HUWLȴFDGRV
2 Chaves públicas.
1 Comunicação:
2 Ids.
2 URLs.
2 Protocolos.
153
Federação CAFe: Implantação do Provedor de Identidade
154
Roteiro de Atividades 8
Atividade 8.1 – Validando a instalação e testando a Federação
1. Valide instalação através do aacli.sh. Este script simula a requisição de atributos do IdP
por um SP. Siga os passos abaixo para testar o IdP que acabou de instalar:
cd /opt/shibboleth-idp/bin
Depois de alguns segundos será retornado um trecho de mensagem SAML com os atributos
requeridos, que deve ser semelhante ao seguinte:
<saml2:AttributeValue xmlns:xs=”http://www.w3.org/2001/
XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:type=”xs:string”>Joao</saml2:AttributeValue>
</saml2:Attribute>
<saml2:AttributeValue xmlns:xs=”http://www.w3.org/2001/
XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:type=”xs:string”>00123456@ufmg.br</saml2:AttributeValue>
</saml2:Attribute>
<saml2:AttributeValue xmlns:xs=”http://www.w3.org/2001/
XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:type=”xs:string”>Silva</saml2:AttributeValue>
</saml2:Attribute>
&DS¯WXOR5RWHLURGH$WLYLGDGHV
</saml2:AttributeStatement>
Ʌ2VFHUWLȴFDGRVVHU¥RH[LELGRV9RF¬VHU£UHGLUHFLRQDGRSDUDR:$<)'6RQGH
deverá escolher o seu Provedor de Identidade (IdP) para se autenticar.
155
ɅApós escolher seu próprio IdP, você será redirecionado para se autenticar no IdP
instalado na sua máquina. Informe o UID e senha do usuário que inseriu no LDAP
no segundo capítulo do curso. Caso não se lembre, acesse o Apache Directory
Studio e altere a senha de algum usuário.
ɅApós ser autenticado você visualizará os atributos fornecidos pelo seu IdP para a
aplicação Homologa.
3. 9HULȴTXHQRVORJVGRVLVWHPDDVDVVHU©·HV6$0/WURFDGDVHQWUHΖG3H63
1 $UTXLYRVSDUDFRQȴJXUD©¥RGHQ¯YHLVGHORJ/opt/shibboleth-idp/conf/logging.xml
Federação CAFe: Implantação do Provedor de Identidade
156
9
Implantação de um provedor de
identidade a partir de bases de
dados relacionais
objetivos
conceitos
Provedor de identidade, base de dados relacionais.
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHEDVHVGHGDGRVUHODFLRQDLV
Roteiro de implantação de um provedor de identidade
Metodologia adotada: q
1 Dividir a tarefa de implantação do provedor de identidade em atividades ou
etapas distintas.
1 &RQVWUXLUVFULSWVSDUDDX[LOLDUQDH[HFX©¥RGDVDWLYLGDGHVGHȴQLGDV
1 (ODERUDUWHVWHVLQWHUPHGL£ULRVDRȴQDOGHFDGDDWLYLGDGHHWDSD
157
Roteiro de atividades
1 Instalar o servidor básico padrão. q
1 Instalar o diretório com o esquema brEduPerson.
2URWHLURGHDWLYLGDGHVSURSRVWRSDUWHGDLQVWDOD©¥RHFRQȴJXUD©¥RGRVLVWHPDRSHUDFLRQDO
da máquina que será dedicada ao IdP, e inclui a instalação de um servidor de diretório
onde serão armazenadas as informações dos membros da instituição acessada pelo IdP.
O roteiro segue com a etapa de extração das informações das bases de dados relacionais
GDLQVWLWX©¥RHRDUPD]HQDPHQGRGHVVDVLQIRUPD©·HVQRVHUYLGRUGHGLUHWµULR3RUȴP
RVRIWZDUHGRΖG3«LQVWDODGRHVXDVLQIRUPD©·HVGHFRQȴJXUD©¥RV¥RUHPHWLGDVSDUDR
gerente da federação.
2 &RQȴJXUDURDPELHQWH
ΖQVWDOHR8EXQWX6HUYHUQRUPDOPHQWHH[HFXWDQGRDVFRQȴJXUD©·HVVXJHULGDVQRURWHLUR
GLVSRQ¯YHOQRVLWHGRSURMHWR$SµVDLQVWDOD©¥RGRVLVWHPDRSHUDFLRQDOHDFRQȴJXUD©¥R
básica da máquina, o passo seguinte é a instalação do servidor de diretório LDAP.
Federação CAFe: Implantação do Provedor de Identidade
$VVHJXLQWHVLQVWDOD©·HVHFRQȴJXUD©·HVV¥RHIHWXDGDVQHVVDHWDSD
1 ΖQVWDOD©¥RHFRQȴJXUD©¥RGRVODSGVHUYLGRU/'$3
1 /LEHUD©¥RGDVSRUWDVHQRȴUHZDOO
2 &RQȴJXUDUDVH[WUD©·HV
158
1 Alimentar o diretório a partir do metadiretório: q
2 &RQȴJXUDUDH[SRUWD©¥R
Para utilizar a ferramenta EID é necessário ter acesso às bases de dados da instituição de
onde serão extraídas as informações sobre as pessoas. Essa ferramenta cria uma base de
GDGRV0\VTOLQWHUPHGL£ULDGHQRPLQDGDPHWDGLUHWµULR3DUDFRQȴJXUDUDVH[WUD©·HVHFULDUR
metadiretório os seguintes passos são necessários:
1 ΖGHQWLȴFDUDVEDVHVGHGDGRVTXHVHU¥RXWLOL]DGRVSDUDDOLPHQWDURVLVWHPDEDVHGH
alunos de graduação, base de alunos de pós-graduação, base de recursos humanos etc.);
1 9HULȴFDUDVFODVVHVHDWULEXWRVQHFHVV£ULRVSDUDRHVTXHPDEU(GX3HUVRQFODVVHV(Ζ'
UHFRPHQGDGDVSDUDEU(GX3HUVRQM£Y¬PFRQȴJXUDGDVQDLQVWDOD©¥RYLDURWHLUR
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHEDVHVGHGDGRVUHODFLRQDLV
carrega para o metadiretório as informações sobre as pessoas vinculadas à instituição que
devem ser adicionadas ao diretório LDAP, o qual será acessado pelo IdP. O passo seguinte
consiste em utilizar a ferramenta EID2LDAP para transferir os dados do metadiretório para o
diretório LDAP.
2URWHLURGHLQVWDOD©¥RGLVSRQLELOL]DGRGHȴQH
Uma vez carregado o diretório que será acessado pelo provedor de identidade, o passo
seguinte é a instalação do próprio provedor de identidade. O roteiro recomenda a instalação
do software Shibboleth IdP (versão 2.x), o qual requer os seguintes softwares adicionais:
Tomcat, Apache2 e OpenSSl.
159
O tutorial disponibilizado requer o endereço do servidor LDAP que será acessado pelo IdP e
HIHWXDDVVHJXLQWHVFRQȴJXUD©·HV
1 &RQȴJXUD©¥RGR$SDFKHSDUDXWLOL]DURPµGXORmod_jk;
1 &ULD©¥RGHFHUWLȴFDGRV66/SDUDR$SDFKHHR6KLEEROHWKΖG3
Após a instalação do IdP, o próximo passo do roteiro é a integração do IdP instalado com
uma federação de teste (Federação Chimarrão). Para isso, é necessário enviar para o gerente
dessa federação os metadados gerados na execução das etapas anteriores. Os metadados
servem para informar aos demais participantes da federação quais são os servidores reco-
QKHFLGRVHFRQȴ£YHLV
2URWHLURGHLQVWDOD©¥RGR6KLEEROHWKΖG3ID]DJHUD©¥RGDFKDYHFULSWRJU£ȴFDHGHXPFHUWL-
ȴFDGR66/DXWRDVVLQDGRSDUDRVHUYLGRU$FKDYHS¼EOLFDGHVWHFHUWLȴFDGR«SDUWHLQWHJUDQWH
dos metadados do servidor.
1 ΖQVWDODURFHUWLȴFDGRQDP£TXLQD
1 0LJUDUDVFRQȴJXUD©·HV
'HSRVVHGRFHUWLȴFDGREDVWDPLJUDUDVFRQȴJXUD©·HVQHFHVV£ULDVHHQYLDUDQRYDYHUV¥R
dos metadados para o gerente da Federação CAFe.
Federação CAFe: Implantação do Provedor de Identidade
160
Roteiro de Atividades 9
Atividade 9.1 – Demonstrar o funcionamento da autenticação e envio de atributos
1. Iniciar visualização dos arquivos de log dos provedores de identidade e de serviço:
3 SSH: sp.curso.rnp
3 Senha: sysadmin
161
Federação CAFe: Implantação do Provedor de Identidade
162
10
Implantação de um provedor
de identidade a partir de um
diretório existente
objetivos
&ULD©¥RGHDUTXLYRGHFRQȴJXUD©¥RGR6KLEEROHWKΖG3TXHFRQW«PRPDSHDPHQWR
necessário para utilizar atributos já existentes em uma base LDAP para compartilhar
dados com a federação CAFe.
conceitos
&RQȴJXUD©¥RGR6KLEEROHWKΖG3DQ£OLVHGHXPVFKHPD/'$3HPDSHDPHQWRGHDWULEXWRV
Introdução
q
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHXPGLUHWµULRH[LVWHQWH
Shibboleth-IDP (Identity Provider):
2¼OWLPRFDS¯WXORGRFXUVRDSUHVHQWDU£DVFRQȴJXUD©·HVQHFHVV£ULDVSDUDTXHXPDLQVWL-
WXL©¥RTXHHVW£XWLOL]DQGRXPDEDVH/'$3FRPVFKHPDGHȴQLGRSRVVDFRPSDWLELOL]DUVHFRP
os requisitos da federação CAFe. Serão apresentados os procedimentos necessários para
FULDURDUTXLYRGHFRQȴJXUD©¥RTXHGHȴQHRPDSHDPHQWRUHDOL]DGRSHOR6KLEEROHWKΖ'3
entre o schema LDAP da instituição e os atributos que devem ser compartilhados com os
provedores de serviço da federação.
O Shibboleth-IDP (Identity Provider) faz a busca dos atributos dos usuários na base de
dados e apresenta-os de forma organizada e padronizada para os provedores de serviço
federados. Para executar essa operação ele acessa a base de dados da instituição utilizando
os chamados “conectores”, realizando uma busca dos atributos de determinado usuário e
mapeando-os para que sejam visualizados na federação.
1 Arquivos de texto.
163
Os “conectores” podem fazer essa busca em diversas origens, entre elas bases de dados
relacionais, diretórios LDAP, arquivos texto e ainda conectores personalizados, que podem
VHUGHȴQLGRVFDVRDFDVR
Para efetuar o mapeamento entre uma base LDAP existente e que não utiliza o
schema brEduPerson, utilizaremos operações referentes ao conector LDAP e também
operações personalizadas.
Análise do cenário
1 O objetivo do mapeamento é compatibilizar os requisitos da federação com os atri- q
butos existentes na base LDAP.
1 'HȴQLGRQRDUTXLYRattribute-resolver.xml.
1 Operações básicas:
2 Renomear atributo.
2 0RGLȴFDUYDORUGHDWULEXWR
2 0RGLȴFDUYDORUGHVHTX¬QFLDGHDWULEXWRV
1 eduPersonPrincipalName
1 mail
1 cn
1 sn
1 EU(GX$ɝOLDWLRQ
1 brEntranceDate
1 brExitDate
1 eduPersonPrincipalNameLGHQWLȴFD©¥R¼QLFDGRXVX£ULRQRHVFRSRGDLQVWLWXL©¥R
(código de usuário@dominio_da_instituição).
1 brExitDate: data de saída para cada vínculo. Se houver mais de um vínculo, as datas
GHHQWUDGDGHYHPVHUIRUQHFLGDVQDRUGHPGHȴQLGDHPEU(GX$ɝOLDWLRQ$LQH[LVW¬QFLD
dessa informação indica que o usuário ainda tem vínculo ativo.
164
2VDWULEXWRVOLVWDGRVDFLPDSHUPLWHPTXHFDGDXVX£ULRVHMDLGHQWLȴFDGRFRUUHWDPHQWH
MXQWR¢VXDLQVWLWXL©¥RHTXHVHMDPYHULȴFDGRVRVY¯QFXORVDWLYRVRXLQDWLYRVTXHHOHSRVVXL
Diferentes provedores de serviço poderão requisitar mais ou menos informações sobre um
usuário para permitir o uso de seu serviço.
uid :”00123456”
cn :”JOAO DA SILVA”
sn :”JOAO DA SILVA”
ufrgsDataAfastamento:”01: ”
2VDWULEXWRVM£H[LVWHQWHVQR/'$3GHVXDLQVWLWXL©¥RUHȵHWHPDVQHFHVVLGDGHVSDUDD
LGHQWLȴFD©¥RGHVHXVXVX£ULRVHGHYHPVHUFRPSOHWRVRVXȴFLHQWHSDUDVXSULURVDWULEXWRV
requisitados pela federação CAFe. Segue uma listagem contendo os atributos de um usuário
da UFRGS, com os seus respectivos valores, como se encontra na base LDAP:
dn: uid=00112389,ou=People,dc=ufrgs,dc=br
objectClass: CourierMailAccount
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHXPGLUHWµULRH[LVWHQWH
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ufrgs
gidNumber: 100000
homeDirectory: /export/home/0/0/1/2/3/00123456
uid: 00123456
loginShell: /bin/false
mail: 00123456@ufrgs.br
mailbox: /export/home/0/0/1/2/3/00123456/Maildir
quota: 1048576000S
165
shadowLastChange: 1
shadowMax: 99999
shadowWarning: 7
ufrgsCategoriaFuncional: 02:
ufrgsCategoriaFuncional: 03:
ufrgsCodCurso: 01:
ufrgsCodCurso: 03: 64
ufrgsCodTipoVinculo: 01: 1
ufrgsCodTipoVinculo: 02: 4
ufrgsCodTipoVinculo: 03: 6
ufrgsCurso: 01:
ufrgsDataAfastamento: 01:
ufrgsDataAfastamento: 03:
ufrgsRamal: 5000
userPassword:: e1NTSEF9SGM2VFlwaW
1 0RGLȴFDURYDORUGHVHTX¬QFLDGHDWULEXWRV
166
Analisando esta listagem, é possível fazer o seguinte mapeamento:
1 brEntranceDatePRGLȴFDURYDORUGHȊXIUJV'DWDΖQJUHVVRȋSDUDVHDGHTXDUDRSDGU¥R
“AAAMMDD” e enviar ordenadamente, removendo o índice.
<resolver:DataConnector xsi:type=”dc:RelationalDatabase”
xmlns=”urn:mace:shibboleth:2.0:resolver:dc”
id=”MyDatabase“>
<ApplicationManagedConnection jdbcDriver=”org.hsqldb.jdbcDriver”
jdbcURL=”jdbc:hsqldb:res:/data/database/shibdb”
jdbcUserName=”sa” />
<QueryTemplate>
<![CDATA[
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHXPGLUHWµULRH[LVWHQWH
SELECT * FROM PEOPLE WHERE netid=’${principal}’
]]>
</QueryTemplate>
</resolver:DataConnector>
ldapURL=”ldaps://servidorad.instituicao.br” baseDN=”dc=servidora
d,dc=instituicao,dc=br” principal=”servidorad\usuario”
principalCredential=”senha” searchScope=”SUBTREE”
mergeResults=”true” cacheResults=”false” maxResultSize=”1”
searchTimeLimit=”3000”>
<FilterTemplate>
<![CDATA[
(samAccountName=$requestContext.principalName)
167
]]>
</FilterTemplate>
</resolver:DataConnector>
Renomear atributo
Faz a busca do atributo original na base LDAP e depois renomeia-o.
sourceAttributeID=”cn”>
<resolver:AttributeEncoder xsi:type=”SAML1String”
xmlns=”urn:mace:shibboleth:2.0:attribute:encoder”
name=”urn:mace:dir:attribute-def:cn” />
<resolver:AttributeEncoder xsi:type=”SAML2String”
xmlns=”urn:mace:shibboleth:2.0:attribute:encoder”
</resolver:AttributeDefinition>
1 sourceAttributeID (opcional): indica o nome do atributo origem cujo valor será copiado.
1 <resolver:DependencySRVVXHPXPDWULEXWRUHIFXMRYDORU«RΖ'¼QLFRGDGHȴQL©¥RGH
DWULEXWRRXRFRQHFWRUGHGDGRVGRTXDOGHSHQGHHVWDGHȴQL©¥RGHDWULEXWR
1 KWWSVZLNLVKLEEROHWKQHWFRQȵXHQFHGLVSOD\6+Ζ%5HVROYHU6FULSW$WWULEXWH'HȴQLWLRQ
1 KWWSVZLNLVKLEEROHWKQHWFRQȵXHQFHGLVSOD\6+Ζ%5HVROYHU6FULSW$WWULEXWH'HȴQLWLRQ(
[DPSOHV5HVROYHU6FULSW$WWULEXWH'HȴQLWLRQ([DPSOHVH[
168
Alterar valor de atributo
$DOWHUD©¥RGHYDORUHV«HIHWXDGDDWUDY«VGHFµGLJR-DYDLQVHULGRQDGHȴQL©¥RGHXPDWULEXWR
<resolver:AttributeDefinition xsi:type=”Script”
xmlns=”urn:mace:shibboleth:2.0:resolver:ad” id=“fullName”
sourceAttributeID=“cn”>
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.
attribute.provider);
fullName.getValues().add(cn.getValues().get(0) + “ “ +surName.
getValues().get(0));]]>
</Script>
</resolver:AttributeDefinition>>
$DOWHUD©¥RGRYDORUGHXPDWULEXWRSRGHVHUIHLWDXWLOL]DQGRFµGLJR-DYD6FULSWTXH«GHȴ-
nido no arquivo attribute-resolver.xml. O trecho do programa é armazenado na tag “Script” e
compilado em tempo de execução pelo Shibboleth-IDP, durante a carga do Tomcat.
A resolução de atributos é feita através do Java Naming and Directory Interface (JNDI), que
é a implementação de um conector do LDAP com o Java. É possível buscar qualquer atributo
&DS¯WXORΖPSODQWD©¥RGHXPSURYHGRUGHLGHQWLGDGHDSDUWLUGHXPGLUHWµULRH[LVWHQWH
GDEDVH/'$3SDUDHIHWXDUDPRGLȴFD©¥RGRVHXYDORU2FµGLJRDQWHULRUVHOHFLRQDRV
valores dos atributos cn e sn para concatenar e gerar o valor para um novo atributo criado e
chamado de fullName, que contém o nome completo do usuário.
169
Federação CAFe: Implantação do Provedor de Identidade
170
Roteiro de Atividades 10
Atividade 10.1 – Renomeando um atributo
'HȴQDXPPDSHDPHQWRSDUDRDWULEXWRȊUIF0DLO%R[ȋGLVSRQ¯YHOQRHVTXHPDDEDL[RGH
modo que seu conteúdo seja enviado para a federação com o nome de “mail”.
dn: uid=00123456,ou=People,dc=ufrgs,dc=br
uid: 00123456
cn: JOAO
sn: DA SILVA
rfc822MailBox: 00123456@ufrgs.br
dn: uid=00123456,ou=People,dc=ufrgs,dc=br
uid: 00123456
cn: JOAO
sn: DA SILVA
rfc822MailBox: 00123456@ufrgs.br
dn: uid=00123456,ou=People,dc=ufrgs,dc=br
uid: 00123456
cn: JOAO
sn: DA SILVA
&DS¯WXOR5RWHLURGH$WLYLGDGHV
rfc822MailBox: 00123456@ufrgs.br
171
Federação CAFe: Implantação do Provedor de Identidade
172
Bibliografia
1 3RUWDOGR6KLEEROHWK'RFXPHQWD©¥RW«FQLFDΖQVWDOD©¥RFRQȴJXUD©¥R
básica e avançada do Shibboleth IdP, SP e DS
http://shibboleth.net/
1 3RUWDOGD2DVLVFRQVµUFLRVHPȴQVOXFUDWLYRVTXHLPSXOVLRQDRGHVHQYRO-
vimento de padrões abertos para a sociedade da informação global
https://www.oasis-open.org/committees/tc_home.php?wg_
abbrev=security
%LEOLRJUDȴD
173
Federação CAFe: Implantação do Provedor de Identidade
174
Edré Quintão Moreira é membro do Comitê Técnico da
Federação CAFe e do Comitê Técnico de Gestão de Identi-
dades da RNP e também arquiteto de software no Departa-
mento de Ciência da Computação da UFMG.
ISBN 978-85-63630-48-3
9 788563 630483