Área de redes de computadores e segurança por andré ...siaibib01.univali.br/pdf/andre siqueira de...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APLICAÇÃO PRÁTICA DE UM SISTEMA DE GERENCIAMENTO DE IDENTIDADES
Área de Redes de Computadores e Segurança
por
André Siqueira de Cordova
Carla Merkle Westphall, Dra. Orientadora
Itajaí (SC), dezembro de 2006
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APLICAÇÃO PRÁTICA DE UM SISTEMA DE GERENCIAMENTO DE IDENTIDADES
Área de Redes de Computadores e Segurança
por
André Siqueira de Cordova Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Carla Merkle Westphall, Dra.
Itajaí (SC), dezembro de 2006
ii
DEDICATÓRIA
A meus pais e verdadeiros amigos,
Raulino e Margarete.
Aos meus queridos padrinhos de batismo,
Sérgio e Stela.
iii
AGRADECIMENTOS
A Deus pela vida, saúde e dons concedidos para que eu pudesse alcançar meus objetivos;
Aos meus pais, Raulino e Margarete, e a família pela educação e valores que me ensinaram;
A minha namorada, amiga e companheira Mauren, pela paciência e apoio para realização deste
trabalho;
A minha orientadora Profª. Carla pela motivação, ensinamentos e disponibilidade oferecida;
A banca examinadora, Prof. Gilberto, Prof. Fabrício, Sr. Neto e Sr. Rubens, pelos conselhos,
interesse e pelos elogios; e
A todos os amigos que contribuíram de alguma forma para que eu concluísse este trabalho.
iv
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................vi LISTA DE FIGURAS..............................................................................viii LISTA DE TABELAS ...............................................................................xi RESUMO...................................................................................................xii ABSTRACT..............................................................................................xiii 1 INTRODUÇÃO ......................................................................................1 1.1 PROBLEMATIZAÇÃO................................................................................... 2 1.1.1 Formulação do Problema .............................................................................. 2 1.1.2 Solução Proposta ............................................................................................ 2 1.2 OBJETIVOS ..................................................................................................... 3 1.2.1 Objetivo Geral................................................................................................ 3 1.2.2 Objetivos Específicos...................................................................................... 3 1.3 METODOLOGIA............................................................................................. 3 1.4 ESTRUTURA DO TRABALHO ..................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................6 2.1 CONCEITOS FUNDAMENTAIS SOBRE SEGURANÇA COMPUTACIONAL NA INTERNET ................................................................... 6 2.1.1 Vulnerabilidade.............................................................................................. 7 2.1.2 Ameaça ........................................................................................................... 7 2.1.3 Ataque............................................................................................................. 8 2.1.4 Política de Segurança..................................................................................... 9 2.1.5 Autenticação................................................................................................. 10 2.1.6 Criptografia.................................................................................................. 11 2.1.7 Assinatura Digital ........................................................................................ 12 2.1.8 Certificado Digital........................................................................................ 14 2.1.9 Controle de Acesso ....................................................................................... 14 2.2 GERENCIAMENTO DE IDENTIDADES ................................................... 15 2.2.1 Conceitos Básicos ......................................................................................... 15 2.2.2 Atores............................................................................................................ 16 2.2.3 Aplicações do IMS........................................................................................ 17 2.2.4 Principais Requisitos.................................................................................... 18 2.2.5 Mecanismos .................................................................................................. 19 2.3 SHIBBOLETH................................................................................................ 22 2.3.1 Conceitos Básicos ......................................................................................... 22 2.3.2 Características.............................................................................................. 23 2.3.3 Federação...................................................................................................... 24 2.3.4 Provedor de Identidade ............................................................................... 24
v
2.3.5 WAYF........................................................................................................... 27 2.3.6 Provedor de Serviço ..................................................................................... 27 2.3.7 Segurança ..................................................................................................... 28 2.3.8 Aplicações ..................................................................................................... 29 2.3.9 Sessões........................................................................................................... 29 2.3.10 Funcionamento............................................................................................. 30 2.3.11 Aplicação Prática ......................................................................................... 32 2.3.12 Trabalhos Relacionados............................................................................... 45
3 PROJETO.............................................................................................47 3.1 CENÁRIO DA APLICAÇÃO........................................................................ 47 3.2 COMPONENTES ADICIONAIS .................................................................. 49 3.3 TECNOLOGIAS PARA IMPLEMENTAÇÃO............................................ 52
4 DESENVOLVIMENTO ......................................................................55 4.1 IMPLEMENTAÇÃO DA FEDERAÇÃO ..................................................... 55 4.1.1 Servidor Provedor de Identidade ................................................................ 56 4.1.2 Servidor Provedor de Serviço...................................................................... 83 4.1.3 Servidor WAYF ........................................................................................... 93 4.2 IMPLEMENTAÇÃO DA APLICAÇÃO ...................................................... 98 4.2.1 Funcionamento da Aplicação ...................................................................... 99 4.2.2 Telas da Aplicação ..................................................................................... 100
5 CONSIDERAÇÕES FINAIS ............................................................107
REFERÊNCIAS BIBLIOGRÁFICAS .................................................109
A ARQUIVO DE METADATA ...........................................................114
B LOGS DO SERVIDOR PROVEDOR DE IDENTIDADE............118 B.1. LOG DO APACHE ...................................................................................... 118 B.2. LOG DO SHIBBOLETH ............................................................................. 119 B.3. LOG DO SHIBBOLETH ............................................................................. 119
C LOGS DO SERVIDOR PROVEDOR DE SERVIÇO ...................122 C.1. LOG DO APACHE ...................................................................................... 122 C.2. LOG DO SHIBBOLETH ............................................................................. 122 C.3. LOG DO SHIBBOLETH ............................................................................. 123
D LOG DO SERVIDOR WAYF ..........................................................124 D.1. LOG DO APACHE ...................................................................................... 124
I LISTA DE APLICAÇÕES E SERVIÇOS QUE UTILIZAM O SHIBBOLETH........................................................................................126
II SAML SCHEMA DE CONFIRMAÇÃO DE AUTENTICAÇÃO DO USUÁRIO.........................................................................................130
vi
LISTA DE ABREVIATURAS
AA Attribute Authority AAP Attribute Acceptance Policies AC Autoridade Certificadora ACL Access Control List ACS Assertion Consumer Service ADFS Active Directory Federation Services API Application Programming Interface AR Attribute Requester ARP Attribute Release Policies CGI Common Gateway Interface DDoS Distributed Denial of Service DNS Domain Name System HS Handle Service HTTP HyperText Transfer Protocol IAMSECT Inter-institutional Authorisation Management to Support E-learning with
reference to Clinical Teaching ICPP/ULD Independent Centre for Privacy Protection/Unabhängiges Landeszentrum
Für Datenschutz Schleswig ID Identificador IdP Identity Provider IEEE Institute of Electrical and Electronics Engineers IIS Internet Information Server IMA Identity Management Application IMS Identity Management System IP Internet Protocol JAR Java Archive JDBC Java Database Connectivity JDK Java 2 Standard Edition Development Kit JK Jakarta Tomcat Connector JNDI Java Naming and Directory Interface LDAP Lightweight Directory Access Protocol MAC Media Access Control MACE Middleware Architecture Committee for Education MITM Main In The Middle NDSL National Science Digital Library OASIS Organization for the Advancement of Structured Information Standards PC Personal Computer PDA Personal Digital Assistant PHP Hypertext Preprocessor PKI Public Key Infrastructure PRIME Privacy and Identity Management for Europe RAM Random Access Memory RM Resource Manager RPM Red Hat Package Manager SAML Security Assertion Markup Language ShARPE Shibboleth Attribute Release Policy Editor
vii
SNG Studio Notarile Genghini SP Service Provider SQL Structured Query Language SSL Secure Socket Layer SSO Single Sign-On TCC Trabalho de Conclusão de Curso TCP/IP Transmission Control Protocol/Internet Protocol UFJF Universidade Federal de Juiz de Fora UFMG Universidade Federal de Minas Gerais UFPA Universidade Federal do Pará UFV Universidade Federal de Viçosa UNISC Universidade de Santa Cruz do Sul UNIVALI Universidade do Vale do Itajaí URL Universal Resource Locator WAR Web Archive File WAYF Where Are You From WebISO Web Initial Sign-On XML Extensible Markup Language
viii
LISTA DE FIGURAS
Figura 1. Formas de Ataques em Sistemas.......................................................................................9 Figura 2. Processo de criptografia assimétrica utilizando função hashing.......................................13 Figura 3. Processo de criptografia assimétrica em mensagem recebida ..........................................13 Figura 4. Atores em um IMS – Um Modelo Abstrato.....................................................................16 Figura 5. Uso de credenciais em um IMS.......................................................................................21 Figura 6. Diagrama de Fluxo do Sistema Shibboleth......................................................................31 Figura 7. Requisição ao Recurso Protegido por Shibboleth ............................................................34 Figura 8. Serviço WAYF...............................................................................................................35 Figura 9. Requisição ao Provedor de Identidade ............................................................................36 Figura 10. Pedido para Autenticação no Provedor de Identidade....................................................37 Figura 11. Entrada da Credencial...................................................................................................38 Figura 12. Redirecionando para o Recurso Solicitado ....................................................................39 Figura 13. Recurso Solicitado pelo Usuário ...................................................................................40 Figura 14. Requisição ao Recurso Protegido por Shibboleth ..........................................................41 Figura 15. Conexão Segura no Provedor de Identidade ..................................................................42 Figura 16. Entrada da Credencial...................................................................................................43 Figura 17. Redirecionando para o Recurso Solicitado ....................................................................44 Figura 18. Recurso Protegido por Shibboleth.................................................................................45 Figura 19. Federação InBrazil........................................................................................................48 Figura 20. Ambiente Shibboleth Completo ....................................................................................49 Figura 21. Interação entre Componentes Shibboleth ......................................................................52 Figura 22. Servidores da federação InBrazil...................................................................................56 Figura 23. Infra-estrutura e funcionamento do servidor provedor de identidade .............................58 Figura 24. Procedimento para gerar as chaves privada e pública ....................................................59 Figura 25. Procedimentos de instalação do software Apache .........................................................59 Figura 26. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf ...........................60 Figura 27. Parâmetros alterados no arquivo ssl.conf.......................................................................60 Figura 28. Procedimento de instalação do software PHP................................................................60 Figura 29. Parâmetros do software PHP alterados no arquivo httpd.conf........................................61 Figura 30. Parâmetros do softtware CGI alterados no arquivo httpd.conf .......................................61 Figura 31. Procedimento de instalação do software Tomcat ...........................................................61 Figura 32. Procedimento de instalação do software JDK................................................................62 Figura 33. Procedimentos de instalação do software Ant ...............................................................62 Figura 34. Procedimentos de instalação do software Jakarta Tomcat Connector.............................62 Figura 35. Arquivo workers.properties...........................................................................................63 Figura 36. Parâmetros do software JK adicionados ao arquivo httpd.conf ......................................63 Figura 37. Parâmetros do software JK alterados no arquivo server.xml..........................................63 Figura 38. Procedimento de instalação do software Oracle Berkeley DB .......................................64 Figura 39. Procedimento inicial de instalação do software Shibboleth IdP .....................................64 Figura 40. Procedimento de instalação do software Shibboleth IdP................................................64 Figura 41. Localização dos arquivos de configuração do software Shibboleth IdP .........................64 Figura 42. Localização do arquivo WAR do software Shibboleth IdP ............................................65 Figura 43. Configuração da tag IdPConfig no arquivo idp.xml ......................................................66 Figura 44. Configuração das tags do arquivo idp.xml ....................................................................66 Figura 45. Arquivo arp.site.xml .....................................................................................................67 Figura 46. Configuração das tags do arquivo resolver.xml.............................................................68
ix
Figura 47. Parâmetro adicionado ao arquivo httpd.conf .................................................................68 Figura 48. Parâmetros adicionados ao arquivo ssl.conf ..................................................................68 Figura 49. Instalação do Pubcookie ...............................................................................................69 Figura 50. Arquivo config do Pubcookie .......................................................................................70 Figura 51. Parâmetros do Pubcookie adicionados no arquivo httpd.conf ........................................70 Figura 52. Parâmetro do Pubcookie adicionado ao arquivo ssl.conf ...............................................70 Figura 53. Procedimento de instalação do OpenLDAP...................................................................71 Figura 54. Arquivo slapd.conf do OpenLDAP ...............................................................................72 Figura 55. Arquivo ldap.conf do OpenLDAP.................................................................................72 Figura 56. Arquivo primeironivel.ldif ............................................................................................72 Figura 57. Procedimento de importação do arquivo primeironivel.ldif ...........................................73 Figura 58. Procedimento de instalação do PHPLDAPADMIN.......................................................73 Figura 59. Parâmetros alterados no arquivo config.php..................................................................73 Figura 60. Tela de autenticação do PHPLDAPADMIN..................................................................74 Figura 61. Tela de criação do grupo inbrazil ..................................................................................74 Figura 62. Tela de criação do usuário “andre.cordova” ..................................................................75 Figura 63. Tela de criação dos atributos do usuário “andre.cordova” .............................................76 Figura 64. Procedimento de instalação do ShARPE .......................................................................77 Figura 65. Configurações adicionadas no arquivo resolver.xml......................................................78 Figura 66. Parâmetros do ShARPE adicionados ao arquivo httpd.conf...........................................78 Figura 67. Tela do componente SPDescription ..............................................................................79 Figura 68. Tela de upload do componente ShARPE.......................................................................80 Figura 69. Tela dos contratos do componente ShARPE .................................................................81 Figura 70. Tela do componente Autograph, liberando um atributo .................................................82 Figura 71. Tela do componente Autograph, bloqueando um atributo..............................................83 Figura 72. Infra-estrutura e funcionamento do servidor provedor de serviço ..................................85 Figura 73. Procedimento para gerar as chaves privada e pública ....................................................86 Figura 74. Procedimento de instalação do software Apache ...........................................................86 Figura 75. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf ...........................86 Figura 76. Parâmetros alterados no arquivo ssl.conf.......................................................................86 Figura 77. Procedimento de instalação do software PHP................................................................87 Figura 78. Parâmetros do software PHP alterados no arquivo httpd.conf........................................87 Figura 79. Procedimento de instalação do software MySQL ..........................................................87 Figura 80. Procedimentos de configuração do software MySQL....................................................88 Figura 81. Procedimento de instalação do software Shibboleth SP.................................................88 Figura 82. Localização dos arquivos de configuração do software Shibboleth SP ..........................89 Figura 83. Configuração da tag Host no arquivo shibboleth.xml....................................................89 Figura 84. Configuração da tag Site no arquivo shibboleth.xml .....................................................89 Figura 85. Configuração das tags no arquivo shibboleth.xml .........................................................90 Figura 86. Configuração das tags Path no arquivo shibboleth.xml .................................................90 Figura 87. Arquivo AAP.xml.........................................................................................................91 Figura 88. Parâmetro adicionado ao arquivo httpd.conf .................................................................91 Figura 89. Parâmetro adicionado no arquivo httpd.conf .................................................................92 Figura 90. Parâmetro adicionado no arquivo httpd.conf .................................................................92 Figura 91. Função “verificaFiliacao” do RM da aplicação protegida pelo Shibboleth.....................93 Figura 92. Infra-estrutura e funcionamento do servidor WAYF .....................................................94 Figura 93. Procedimento para gerar as chaves privada e pública ....................................................95 Figura 94. Procedimentos de instalação do software Apache .........................................................95 Figura 95. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf ...........................96
x
Figura 96. Parâmetros alterados no arquivo ssl.conf.......................................................................96 Figura 97. Procedimento de instalação do software PHP................................................................96 Figura 98. Parâmetros do software PHP alterados no arquivo httpd.conf........................................97 Figura 99. Procedimento de instalação do software WAYF ...........................................................97 Figura 100. Variável configurada no arquivo IDProvider.conf.php ................................................98 Figura 101. Variáveis configuradas no arquivo config.php ............................................................98 Figura 102. Tela inicial da Aplicação Básica InBrazil..................................................................101 Figura 103. Tela de Download de documentos.............................................................................101 Figura 104. Tela do componente WAYF SWITCHaai .................................................................102 Figura 105. Tela de autenticação Pubcookie ................................................................................103 Figura 106. Tela de troca de informações de autenticação e autorização ......................................103 Figura 107. Tela de Upload – AuthZ Appl....................................................................................104 Figura 108. Tela de Upload – AuthZ Shib ....................................................................................104 Figura 109. Tela de autenticação Pubcookie ................................................................................105 Figura 110. Tela de troca de informações de autenticação e autorização ......................................105 Figura 111. Tela de Upload .........................................................................................................106 Figura 112. Arquivo inbrazil-metadata.xml .................................................................................117 Figura 113. Arquivo apache_ssl.log.............................................................................................118 Figura 114. Arquivo shib-access.log ............................................................................................119 Figura 115. Arquivo shib-error.log ..............................................................................................121 Figura 116. Arquivo apache_ssl.log.............................................................................................122 Figura 117. Arquivo shibd.log .....................................................................................................122 Figura 118. Arquivo transaction.log.............................................................................................123 Figura 119. Arquivo apache_ssl.log.............................................................................................124
xi
LISTA DE TABELAS
Tabela 1. Softwares do servidor provedor de identidade ................................................................57 Tabela 2. Softwares do servidor provedor de serviço .....................................................................84 Tabela 3. Softwares do servidor WAYF ........................................................................................94
xii
RESUMO
CORDOVA, André Siqueira de. Aplicação Prática de um Sistema de Gerenciamento de Identidades. Itajaí, 2006. 145 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. A identidade digital representa eletronicamente as informações de indivíduos e organizações. Na Internet estas informações tornam-se públicas e podem ser reveladas por indivíduos não autorizados, exceto se empregadas em conjunto com mecanismos de controle e de segurança. O gerenciamento de identidades é um dos sistemas que agrupa estes mecanismos e os aplica nas informações sensíveis dos indivíduos. Por se tratar de uma infra-estrutura complexa, deve ser aplicada com embasamento em pesquisas e estudos que envolvam desde a teoria até a aplicação prática. Através do conhecimento teórico adquirido, será montada uma infra-estrutura completa de gerenciamento de identidades que mostre a sua aplicação e eficiência. O sistema de gerenciamento de identidades escolhido para compor uma parte desta infra-estrutura foi o Shibboleth, um sistema de código livre que fornece componentes e regras para compor o controle das identidades e segurança dos recursos web. Outras ferramentas serão incorporadas ao Shibboleth, tais como, o mecanismo de autenticação Pubcookie e o serviço de diretórios OpenLDAP, a fim de completar a infra-estrutura necessária para aplicação prática do sistema. Palavras-chave: Gerenciamento de Identidades. Segurança. Controle.
xiii
ABSTRACT
Electronically, the digital identity represents the information of individuals and organizations. On the Internet these information could be public and could be show up by not authorized individuals, except if used which security and control mechanisms. The identity management is one of the systems that group these mechanisms and it applies them in the sensible information of the individuals. It the meaning with a complex infrastructure it must be applied with research basement and studies that involve since the theory until the practical application. In such as way, through the theoretical knowledge acquired, to mount a complete infrastructure of management of identity that shows up to this application and efficiency. The system of management of identity was picked out to compose a part of this infrastructure it was Shibboleth, a kind of open source system that supplies to components and rules to compose the control of the identity and security web resource. Other implements will be incorporated on Shibboleth, such as: Pubcookie the mechanism of authentication and the OpenLDAP, the service of directories, to complete the necessary infrastructure for practical application of the system. Keywords: Identity Management. Security. Control.
1 INTRODUÇÃO
O uso de sistemas de gerenciamento de identidades cresce a cada dia e vem ocupando
espaço no mundo dos negócios digitais. As empresas precisam gerenciar acessos às aplicações em
um grande número de sistemas computacionais, sem comprometer a segurança e expor as
informações confidenciais.
Um dos propósitos do sistema de gerenciamento de identidades é controlar as informações
dos usuários de forma segura. Os usuários ao se autenticarem uma única vez no sistema, podem
utilizar vários serviços dentro de um ou vários ambientes parceiros. Estes ambientes precisam estar
protegidos por uma federação. As federações são grupos de organizações que estabelecem a
confiança entre si, para cooperarem nos negócios de forma segura, mantendo responsabilidades
definidas. Certas situações fazem com que uma identidade digital permaneça anônima, ou seja,
verifica-se a identidade de um usuário, mas a única informação que deve ser transferida é a sua
validação (REINERT, 2005).
A identidade digital representa eletronicamente as informações sensíveis de um indivíduo ou
organização (DAMIANI; VIMERCATI e SAMARATI, 2003). Um sistema que gerencia
identidades deve ser confiável.
O Shibboleth é um projeto da Internet2 e do MACE (Middleware Architecture Committee
for Education) e tem como um de seus objetivos a proteção de recursos web através do controle de
acesso (SHIBBOLETH, 2006). Observando dados comparativos entre alguns sistemas de
gerenciamento de identidades, foi escolhido o Shibboleth, um sistema de código livre que tem como
principal função o gerenciamento de acesso a recursos baseado nos atributos dos usuários. Estes
atributos são buscados no site de origem através de componentes da arquitetura do Shibboleth. A
autenticação é feita diretamente na instituição detentora do registro dos usuários. Um serviço da
arquitetura Shibboleth é responsável em verificar se o usuário já está autenticado, solicitando que o
mesmo se autentique caso não esteja (REINERT, 2005).
Outras soluções, além do Shibboleth, já foram propostas para resolver o problema do
gerenciamento de identidades (DAMIANI; VIMERCATI e SAMARATI, 2003). São soluções
baseadas em infra-estruturas de chave pública, modelo Passport da Microsoft (MICROSOFT, 2006)
e o modelo do projeto Liberty (PFITZMANN e WAIDNER, 2003).
2
Este tema de pesquisa possui relevância e importância atual já que faz parte do estado da
arte no assunto de segurança e controle de acesso em sistemas distribuídos, comprovado pelas
publicações na área (BUELL e SANDHU, 2003), (DAMIANI; VIMERCATI e SAMARATI,
2003), (PFITZMANN e WAIDNER, 2003). Na literatura científica, o tema ainda é recente
(ZHANG et al. 2005) e o mercado para produtos de gerência de identidades aumentará
expressivamente nos próximos anos (NETWORKWORLD, 2006).
A utilização dos sistemas de gerenciamento de identidades pode ser observada por meio de
vários aplicativos que suportam a interoperabilidade com o sistema de gerenciamento de
identidades Shibboleth. Como exemplo destes aplicativos pode-se citar: as bibliotecas digitais
ScienceDirect e NSDL (National Science Digital Library), o sistema de e-learning WebAssign, a
ferramenta para escrita colaborativa Twiki e os aplicativos educacionais Blackboard
(SHIBBOLETH, 2006).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
A Internet mudou a forma de uso dos sistemas computacionais - as informações trafegam
em uma rede pública - o que torna possível a revelação destas informações por partes não
autorizadas. Nas informações estão presentes as identidades dos usuários, ou seja, as suas
informações sensíveis que precisam trafegar na rede para que obtenham acesso aos sistemas.
Normalmente, nos sistemas utilizados, cada aplicação precisa ter um mecanismo de
autorização e autenticação para gerenciar o acesso dos usuários. Desta forma, o número de senhas
de acesso aumenta com o crescimento do número das aplicações, o que acaba prejudicando o
controle e a segurança das mesmas. Vale salientar que, quando usuários de uma instituição acessam
recursos de outra instituição, a instituição que está provendo os recursos precisa gerenciar as
identidades de todos os usuários, porém, quando o número de usuários é muito grande, a dificuldade
para gerenciar estas identidades aumenta significativamente.
1.1.2 Solução Proposta
Esta proposta pretende contribuir no processo de implementação de um sistema de
gerenciamento de identidades, visando aumentar a segurança das informações sensíveis dos
3
usuários, bem como minimizar a quantidade de autenticações necessárias para obter acesso aos
sistemas.
Dessa forma, a proposta deste trabalho é a implementação de uma infra-estrutura de
gerenciamento de identidades Shibboleth que além de realizar o gerenciamento das identidades, irá
controlar o acesso aos recursos.
Nesse contexto, propõe-se também o desenvolvimento de uma aplicação que em conjunto
com a infra-estrutura de gerenciamento de identidades, demonstre o funcionamento prático do
sistema Shibboleth.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é a aplicação prática do sistema de gerenciamento de
identidades, designado Shibboleth.
1.2.2 Objetivos Específicos
Os objetivos específicos desse trabalho são:
• Descrever conceitos básicos de segurança computacional na Internet;
• Relatar conceitos de gerenciamento de identidades;
• Relatar pesquisas científicas que estão sendo desenvolvidas nesse assunto;
• Realizar testes com o Shibboleth, instalar e apresentar um exemplo de demonstração;
• Formular a modelagem de um cenário para aplicar o sistema de gerenciamento de
identidades Shibboleth; e
• Documentar e divulgar os resultados do trabalho desenvolvido.
1.3 Metodologia
A metodologia utilizada no desenvolvimento deste projeto foi dividida em três grandes
etapas: (i) estudo; (ii) projeto; e (iii) desenvolvimento.
4
A etapa de estudo foi destinada à pesquisa e interpretação dos conceitos de segurança
computacional na Internet e de gerenciamento de identidades. Na fundamentação teórica a pesquisa
foi realizada em livros na área de segurança computacional e através de artigos publicados pela
IEEE (Institute of Electrical and Electronics Engineers).
Ainda na etapa de estudo foi explanado o sistema de gerenciamento de identidades
Shibboleth, sendo este o sistema foco do estudo. Foram descritas suas características, principais
componentes e seu funcionamento, além da apresentação dos testes iniciais realizados com o
sistema.
Na etapa de projeto é apresentada uma infra-estrutura completa de sistema de gerenciamento
de identidades Shibboleth. Nesta etapa foram realizadas as tarefas:
• Introdução: foram explanados os componentes necessários para a construção de uma
infra-estrutura de gerenciamento de identidades Shibboleth;
• Cenário da Aplicação: para apresentar o cenário de atuação, foi definido o
funcionamento da aplicação a ser modelada e implementada, bem como, as regras e
características da federação;
• Componentes Adicionais: para compor o ambiente completo do sistema Shibboleth
foram explanadas as ferramentas que serão utilizadas para a composição deste ambiente;
e
• Tecnologias para Implementação: foram especificadas as tecnologias necessárias para
implementação do projeto e explicados seus conceitos básicos.
Na etapa de desenvolvimento foi realizada a implementação de uma infra-estrutura completa
do sistema de gerenciamento de identidades Shibboleth. Esta etapa foi dividida em duas partes:
• Implementação da Federação: foram implementados os servidores e softwares
necessários para funcionamento do sistema de gerenciamento de identidades Shibboleth;
e
• Implementação da Aplicação: foi implementada uma aplicação para demonstrar o
funcionamento do sistema de gerenciamento de identidades Shibboleth.
5
1.4 Estrutura do trabalho
Este projeto está estruturado em 5 capítulos: (1) Introdução; (2) Fundamentação Teórica; (3)
Projeto; (4) Desenvolvimento; e (5) Considerações Finais.
O Capítulo 1 (Introdução) destina-se a contextualizar o projeto sucintamente, descrever o
problema encontrado e a solução proposta, expor os objetivos gerais e específicos a serem atingidos
com o trabalho, e a metodologia utilizada para o desenvolvimento do projeto.
O Capítulo 2 (Fundamentação Teórica) apresenta conceitos necessários e relevantes para o
entendimento da segurança computacional na Internet, gerenciamento de identidades, bem como do
Shibboleth.
O Capítulo 3 (Projeto) mostra todos os componentes necessários para a aplicação prática do
sistema de gerenciamento de identidades Shibboleth e especifica as ferramentas que serão
agregadas a este sistema.
O Capítulo 4 (Desenvolvimento) descreve as etapas necessárias para a implementação da
federação Shibboleth e consequentemente da infra-estrutura de sistema de gerenciamento de
identidades Shibboleth. Além de apresentar a implementação da aplicação protegida pelo sistema de
gerenciamento de identidades Shibboleth.
O Capítulo 5 (Considerações Finais) relaciona o projeto com os objetivos especificados,
bem como as dificuldades encontradas no seu desenvolvimento e expõe os resultados obtidos, além
de identificar melhorias a serem realizadas no sistema com o intuito de dar continuidade ao
trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são descritos os principais conceitos envolvidos no gerenciamento de
identidades, tais como, a segurança e controle da identidade, além da aplicação prática do sistema
de gerenciamento de identidades Shibboleth. A Seção 2.1 descreve os tipos de ataques na Internet,
conceitos de vulnerabilidade, autenticação, controle de acesso e o processo de criptografia. A Seção
2.2 descreve os conceitos que envolvem os sistemas de gerenciamento de identidades e suas partes
envolvidas, além de suas aplicações, principais requisitos e mecanismos de funcionamento. A Seção
2.3 destina-se a apresentação do sistema Shibboleth, através da abordagem de suas características,
principais componentes, funcionamento e uma aplicação prática.
2.1 CONCEITOS FUNDAMENTAIS SOBRE SEGURANÇA COMPUTACIONAL NA INTERNET
A Internet mudou a forma como são utilizados os sistemas computacionais. Devido a estas
mudanças os riscos a privacidade e integridade da informação são muitos. Portanto, é muito
importante que mecanismos de segurança de sistemas computacionais sejam projetados de maneira
a prevenir acessos não autorizados aos recursos e dados destes sistemas.
Um computador ou sistema computacional é dito seguro se este atender a três requisitos
básicos: confidencialidade, integridade e disponibilidade. A confidencialidade define que a
informação só está disponível para aqueles devidamente autorizados. A integridade define que a
informação não é destruída ou corrompida. Já a disponibilidade define que os serviços/recursos do
sistema estão disponíveis sempre que forem necessários (CERT.BR, 2005).
Outros autores, Dias (2000), Sandhu e Samarati (1994) defendem que para uma informação
ser considera segura, o sistema que administra ainda deve respeitar:
• Autenticidade: Garante que a informação ou o usuário da mesma é autêntico;
• Não repúdio: Não é possível negar o envio ou recepção de uma informação ou dado;
• Legalidade: Garante a legalidade jurídica da informação e aderência de um sistema à
legislação;
• Privacidade: Garante que determinada informação seja restrita; e
7
• Auditoria: Rastreabilidade dos diversos passos que um processo realizou ou que uma
informação foi submetida, identificando os participantes, os locais e horários de cada
etapa. Consiste no exame do histórico dos eventos dentro de um sistema para determinar
quando e onde ocorreu uma violação de segurança.
2.1.1 Vulnerabilidade
A grande abrangência da Internet pode resultar em problemas como roteamentos incorretos,
falhas de transmissão, adulteração de dados e falhas de componentes físicos em um grande número
de pontos. Sendo assim, a Internet apresenta muitos pontos vulneráveis que podem ser difíceis de
controlar.
Segundo CERT.BR (2005), “vulnerabilidade é definida como uma falha no projeto,
implementação ou configuração de um software ou sistema operacional que, quando explorada por
um atacante, resulta na violação da segurança de um computador”.
As vulnerabilidades podem resultar na ocorrência de determinados incidentes de segurança.
Conforme descrito em CERT.BR (2005), “um incidente de segurança pode ser definido como
qualquer evento adverso, confirmado ou sob suspeita, relacionado à segurança de sistemas
computacionais ou de redes de computadores”. São exemplos de incidentes de segurança:
• Tentativas de ganhar acesso não autorizado a sistemas ou dados;
• Ataques de negação de serviço;
• Uso ou acesso não autorizado a um sistema;
• Modificações em um sistema, sem o conhecimento, instruções ou consentimento prévio
do dono do sistema; e
• Desrespeito à política de segurança de uma empresa ou provedor de acesso.
2.1.2 Ameaça
As ameaças exploram os pontos fracos de um sistema, geralmente relacionados à tecnologia
ou à política de operação. As fraquezas tecnológicas referem-se às deficiências nos produtos de
software e hardware e às falhas no material de comunicação. As fraquezas na política de operação
referem-se às regras definidas para operação dos sistemas de computador. O projeto de um sistema
8
seguro é tão importante quanto uma política de segurança eficiente. A ameaça só é eliminada
quando os dois estão presentes (BERNSTEIN et al. 1997).
A ameaça pode ser definida como qualquer ação, acontecimento ou entidade que possa agir sobre um ativo, processo ou pessoa, através de uma vulnerabilidade e consequentemente gerando um determinado impacto. As ameaças apenas existem se houverem vulnerabilidades, sozinhas pouco fazem (LAUREANO, 2005, p. 15).
Como ressalta Sêmola (2003 apud LAUREANO, 2005), as ameaças podem ser classificadas
quanto a sua intencionalidade e organizadas em grupos. As ameaças naturais são decorrentes de
fenômenos da natureza, como incêndios naturais, enchentes, terremotos e tempestades. As
involuntárias são ameaças inconscientes, quase sempre causadas pelo desconhecimento, mas podem
ser causadas por acidentes, erros e falta de energia. Já as ameaças voluntárias são propositais,
causadas por agentes humanos como crackers, invasores, espiões, ladrões, criadores e
disseminadores de vírus de computador e incendiários.
2.1.3 Ataque
Ataque em um sistema computacional é a tentativa, bem ou mal sucedida, de acesso ou uso
não autorizado a um programa ou computador. Um ataque pode causar diferentes tipos de falhas,
tais como: destruição da informação, modificação ou deturpação, roubo, remoção ou perda,
revelação de informação ou interrupção de serviços (CERT.BR, 2005).
Conforme sustenta Laureano (2005), o fato de um ataque estar acontecendo não significa
que ele terá sucesso. O nível de sucesso depende da vulnerabilidade do sistema ou da eficácia de
contramedidas existentes. As formas possíveis de ataques em sistemas são (Figura 1):
• Interceptação: considera-se interceptação o acesso às informações por entidades não
autorizadas;
• Interrupção: pode ser definida como a interrupção do fluxo normal das mensagens ao
destino;
• Modificação: consiste na modificação de mensagens por entidades não autorizadas; e
• Personificação: considera-se personificação a entidade que acessa as informações ou
transmite mensagens passando-se por uma entidade autêntica.
9
Figura 1. Formas de Ataques em Sistemas
Fonte: Adaptado de Stallings (2002).
Atualmente, são exemplos de ataques que se propagam com frequência na Internet:
• DDoS (Distributed Denial of Service – Negação de Serviço Distribuído): um conjunto
de computadores é utilizado para paralisar serviços ou computadores conectados à
Internet; e
• Engenharia Social ou Pishing: o atacante faz uso da persuasão, muitas vezes prevalece
da ingenuidade ou confiança do usuário para obter informações que podem ser utilizadas
no acesso não autorizado a computadores ou informações.
2.1.4 Política de Segurança
As leis devem ser seguidas para que exista um padrão de conduta considerado adequado às
necessidades da nação e para garantia de seu progresso e harmonia. Da mesma forma deve ocorrer
em uma empresa. São necessárias regras que estabeleçam princípios de como a organização irá
proteger, controlar e monitorar as informações manipuladas pelos sistemas computacionais e redes
de computadores.
A política de segurança atribui direitos e responsabilidades às pessoas que lidam com os
recursos computacionais de uma instituição e com as informações neles armazenados. Ela também
10
define as atribuições de cada um em relação à segurança dos recursos com os quais trabalham, bem
como as penalidades às quais estão sujeitos aqueles que não cumprirem a política (CERT.BR,
2005).
A política de segurança é um mecanismo preventivo de proteção dos dados e processos
importantes de uma organização, define um padrão de segurança a ser seguido pelo corpo técnico,
corpo gerencial e pelos usuários (DIAS, 2000).
Segundo Laureano (2005), uma política de segurança atende a vários propósitos:
• Descreve o que está sendo protegido e por quê;
• Define prioridades sobre o que precisa ser protegido em primeiro lugar e qual o custo;
• Permite estabelecer um acordo explícito com várias partes da empresa em relação ao
valor da segurança;
• Fornece ao departamento de segurança um motivo válido para dizer “não” quando
necessário; e
• Proporciona ao departamento de segurança a autoridade necessária para serem
cumpridos os propósitos.
2.1.5 Autenticação
Os serviços de autenticação são elementos fundamentais em qualquer sistema de segurança
na Internet. As entidades que se comunicam na Internet devem ter alguma forma de verificar com
quem estão trocando informações. Estas entidades podem ser pessoas que operam sistemas
computacionais ou dois computadores que se comunicam através de um processo automático.
A autenticação é o meio para obter a certeza de que o usuário ou o objeto remoto é realmente quem está afirmando ser. É um serviço essencial de segurança, pois uma autenticação confiável assegura o controle de acesso, determina quem está autorizado a ter acesso à informação, permite trilhas de auditoria e assegura a legitimidade do acesso (LAUREANO, 2005, p. 20).
De acordo com Dias (2000), os processos de autenticação estão baseados em três métodos:
• Identificação positiva (o que você sabe): Na qual o requerente demonstra conhecimento
de alguma informação utilizada no processo de autenticação; por exemplo, uma senha;
11
• Identificação proprietária (o que você tem): Na qual o requerente demonstra possuir algo
a ser utilizado no processo de autenticação; como um cartão magnético; e
• Identificação biométrica (o que você é): Na qual o requerente exibe alguma
característica própria, tal como a sua impressão digital.
Uma autenticação não segura está relacionada à solicitação de senhas que não utilizam
método de criptografia. Estas senhas podem se tornar um risco devido à interceptação de terceiros
ou até mesmo do próprio host, - se este for mal intencionado -, que por sua vez terá as informações
necessárias para utilizar a identidade do usuário em qualquer lugar da rede (MICROSOFT
TECHNET, 2004).
2.1.6 Criptografia
Informações que precisam viajar por meio de canais públicos, por exemplo, a Internet,
podem ser protegidos pela criptografia. A criptografia é a transformação de qualquer forma de
informação (texto, vídeo ou gráficos) em uma representação não legível para qualquer pessoa sem
chave de criptografia (ALBERTIN, 2001).
A criptografia caracteriza-se por transformar uma mensagem em uma forma cifrada ou em
um código para que pessoas não autorizadas não tenham acesso à leitura da informação transmitida.
A criptografia faz parte de um campo de estudos que trata de comunicações secretas usadas para:
autenticar a identidade de usuários; autenticar e proteger o sigilo de comunicações pessoais,
transações comerciais e bancárias; e proteger a integridade de transferências eletrônicas de fundos
(CERT.BR, 2005).
Uma mensagem codificada por um método de criptografia deve ser confidencial, ou seja,
somente aquele que envia e aquele que recebe terão acesso ao conteúdo da mensagem. A mensagem
pode ser assinada para garantir que esta não tenha sido modificada e que o remetente seja autêntico
(REINERT, 2005).
Existem dois métodos de criptografia: criptografia simétrica e criptografia assimétrica. A
criptografia simétrica ou de chave única envolve o uso de uma chave tanto para cifrar quanto para
decifrar, isto é, a chave é compartilhada entre a origem e o destino. O ciframento de uma mensagem
baseia-se em dois componentes: um algoritmo e uma chave. Um algoritmo é uma transformação
matemática, ele converte uma mensagem em uma mensagem cifrada e vice-versa. A chave é uma
12
cadeia aleatória de bits utilizada em conjunto com o algoritmo. Cada chave distinta faz com que o
algoritmo trabalhe de forma diferente. Já a criptografia assimétrica ou de chave pública e privada
está baseada no conceito de par de chaves: uma chave privada e uma chave pública. Qualquer uma
delas é utilizada para cifrar uma mensagem e a outra para decifrá-la. As mensagens cifradas com
uma das chaves do par só podem ser decifradas com a outra chave correspondente. A chave privada
deve ser mantida secreta, enquanto a chave pública fica disponível para qualquer interessado. Como
a chave pública está disponível livremente, não há necessidade de compartilhamento de chaves,
como é feito no método simétrico (MAIA, 1999).
2.1.7 Assinatura Digital
Um outro benefício da criptografia assimétrica é a assinatura digital, que permite garantir a
autenticidade de quem envia a mensagem, associada à integridade do seu conteúdo.
A assinatura digital consiste na criação de um código, através da utilização de uma chave
privada, de modo que a pessoa ou entidade que receber uma mensagem contendo este código, possa
verificar se o remetente é mesmo quem diz ser (MAIA, 1999).
Na assinatura digital é inadequado cifrar toda a mensagem ou documento a ser assinado
digitalmente, devido ao tempo gasto na criptografia utilizando chave assimétrica. Neste caso, é
empregada uma função hashing, que gera um valor pequeno (chamado digest ou valor hash), um
resumo de tamanho fixo, derivado da mensagem que se pretende assinar. Assim, a função hashing
oferece agilidade nas assinaturas digitais, além de integridade confiável.
Cifrar um resumo da mensagem com a chave privada do remetente é chamado de assinatura
digital. O remetente irá cifrar um resumo da mensagem com sua chave privada e enviar juntamente
com a mensagem a ser lida (Figura 2). Ao receber a mensagem, o destinatário deverá utilizar a
chave pública do remetente para decifrar o resumo assinado. Além da veracidade do remetente, o
destinatário poderá verificar a integridade da mensagem e neste caso aplicará a função hashing na
mensagem recebida. Se ambos os resumos forem idênticos, o destinatário terá certeza que o
remetente da mensagem foi realmente o esperado e que a mensagem não foi modificada (Figura 3).
13
Figura 2. Processo de criptografia assimétrica utilizando função hashing
Fonte: Adaptado de Maia (1999).
Figura 3. Processo de criptografia assimétrica em mensagem recebida
Fonte: Adaptado de Maia (1999).
14
2.1.8 Certificado Digital
A garantia sobre a veracidade das informações contidas em uma chave pública, é obtida
através do certificado digital.
De acordo com CERT.BR (2005), “o certificado digital é um arquivo eletrônico que contém
dados de uma pessoa ou instituição, utilizados para comprovar sua identidade”. Tais certificados
consistem em chaves públicas assinadas por uma terceira parte confiável, conhecida como AC
(Autoridade Certificadora). A autoridade certificadora faz a emissão destes certificados e garante
que as informações contidas neles sejam válidas.
Segundo CERT.BR (2005), existem diversos tipos de certificados:
• Certificados de AC: utilizados para validar outros certificados; são auto-assinados ou
assinados por outra AC;
• Certificados de servidor: utilizados para identificar um servidor seguro; contém o nome
da organização e o nome DNS (Domain Name System) do servidor;
• Certificados pessoais: contém nome do portador e eventualmente informações como
endereço eletrônico, endereço postal, etc; e
• Certificados de desenvolvedores de software: utilizados para validar assinaturas
associadas a programas.
2.1.9 Controle de Acesso
O controle de acesso é um conjunto de medidas e procedimentos adotados pela organização
ou utilizados pelos softwares. O objetivo é proteger os dados, programas e sistemas contra
tentativas de acesso não autorizadas feitas por usuários ou outros programas (LAUREANO, 2005).
Os mecanismos de controle de acesso fazem o controle das permissões que um determinado
usuário ou objeto tem sobre o sistema. A ACL (Access Control List – Lista de Controle de Acesso)
é o mecanismo que cria uma lista para cada objeto ou recurso do sistema, com a identificação do
usuário ou processo e suas permissões para aquele objeto específico. A capability é o mecanismo
que cria uma lista para cada usuário ou processo, com a identificação do objeto e as permissões que
o usuário ou processo possuem sobre este objeto especifico (LAUREANO, 2005).
15
2.2 GERENCIAMENTO DE IDENTIDADES
Os conceitos de gerenciamento de identidades estudados e descritos nessa seção foram
retirados da fonte Reinert (2005), ICPP/ULD e SNG (2003).
2.2.1 Conceitos Básicos
O gerenciamento de identidades vem ocupando espaço no mundo dos negócios digitais,
proporciona a redução de custos, controle de gerenciamento, eficiência operacional e
principalmente o crescimento dos negócios.
O grande desafio do gerenciamento de identidades é controlar as informações de forma
segura quando o número de usuários for grande e disperso. Com um sistema de gerenciamento de
identidades, os usuários ao se autenticarem uma única vez, conseguem utilizar diferentes tipos de
serviços com regras de proteção distintas.
Nesse contexto, o sistema de gerenciamento de identidades trata da autenticação e
autorização de usuários, bem como da criação de federações entre organizações. Estas federações
são grupos que estabelecem a confiança entre si, para cooperarem nos negócios de forma segura e
manter responsabilidades definidas.
Uma identidade, de um ponto de vista técnico, está relacionada a um ID (Identificador),
pode ser um nome ou uma sequência de números. Alguns exemplos de identificadores: endereço
MAC (Media Access Control); endereço IP (Internet Protocol); e cookies (identifica computadores
ou usuários).
Uma IMA (Identity Management Application – Aplicação de Gerenciamento de
Identidades) tem como objetivo gerenciar o fluxo de dados após autenticação, além disso, pode
ajudar a firmar direitos de privacidade, solicitar políticas de privacidade e requerer acessos.
Um IMS (Identity Management System – Sistema de Gerenciamento de Identidades)
abrange uma infra-estrutura dentro de uma ou entre várias organizações que estabelecem a
confiança entre si para gerenciar identidades. O IMS trabalha com o tratamento de comunicação
anônima e assinaturas digitais para autenticação. Faz o gerenciamento do acesso aos atributos de
uma identidade digital, controla quais atributos serão concedidos para uma organização ou um
usuário. Consiste no gerenciamento de informações pessoais armazenadas em algum banco de
16
dados. Um IMS descreve toda a infra-estrutura necessária para que as aplicações de gerenciamento
de identidades sejam executadas e coordenadas.
2.2.2 Atores
Os atores envolvidos em um sistema de gerenciamento de identidades são:
• Usuário (indivíduo ou empresa): é quem irá utilizar os serviços web. Os usuários
necessitam de anonimato e pseudônimos que devem ser certificados por uma terceira
parte;
• Provedor de Serviço: são parceiros de comunicação que interagem com outras
organizações. Quando usuários acessam determinados serviços na web, os provedores de
serviços precisam suportar o gerenciamento de identidades desses usuários. Por
exemplo, oferecendo informações que podem ser relevantes para a escolha de identidade
dos usuários, assim como políticas de privacidade ou informações do contexto.
• Provedor de IMS: é constituído de terceiras partes (por exemplo, uma infra-estrutura de
chave assimétrica e uma autoridade certificadora) que fornecem serviços certificados
para a autenticação segura dos usuários. A Figura 4 ilustra a interação entre os três
atores:
Figura 4. Atores em um IMS – Um Modelo Abstrato
Fonte: Adaptado de ICPP/ULD e SNG (2003).
17
2.2.3 Aplicações do IMS
O IMS atua em vários ramos de transações eletrônicas. Entre elas, são citados o E-
commerce, E-government e o E-health.
O E-commerce divide-se em alguns subgrupos. Os principais são:
• E-shopping: uma transação de compra e venda é realizada entre um comprador e um
vendedor. O IMS garante o anonimato do comprador, que por sua vez dispõe de
informações sigilosas quando do ato de pagamento da mercadoria, tais como, número de
conta, endereço e cartão de crédito. Para tais transações, o cliente pode utilizar-se de
diferentes pseudônimos: um para a consulta aos produtos; outro para o vendedor
consultar a reputação do comprador para ter certeza que o pagamento será efetuado;
outro para efetuar a transferência de valores; e finalmente um para a entrega do produto.
Quanto à privacidade, é preservado o perfil e o anonimato do cliente. Quanto à lei, são
coletadas evidências digitais necessárias em caso de roubo de identidade, reputação,
garantia e entregas erradas.
• E-auction (leilão eletrônico): abrange os seguintes atores: comprador, leiloeiro e
vendedor. São utilizados quatro pseudônimos. O primeiro relaciona o comprador com o
leiloeiro e possivelmente uma terceira parte que por sua vez, preserva a identidade do
comprador enquanto ele estiver liderando o leilão. O segundo relaciona o comprador
com o vendedor, que poderá consultar a reputação do comprador, porém de forma que o
mesmo continue anônimo. O terceiro e o quarto pseudônimos são idênticos ao E-
shopping. Quanto à privacidade, preserva o perfil e anonimato do cliente/comprador.
Quanto à lei, são coletadas evidências digitais necessárias em caso de roubo de
identidade, reputação, garantia e entregas erradas.
• E-banking: assume que a instituição financeira tem a obrigação de gerenciar o dinheiro
dos clientes e realizar transações financeiras quando solicitadas. O IMS tem como
funcionalidades principais: o gerenciamento de endereços para transações eletrônicas
específicas com históricos correspondentes; manter pseudônimos de clientes que são
suas identificações como cidadão; e duração de contratos (cartão de crédito, seguro e
hipoteca). Quanto à segurança, prevê o roubo de identidade e mau uso, não repúdio e
18
prevenção de endereçamento falso. Em termos de privacidade, protege o perfil dos
usuários.
No E-government, o objetivo do IMS é auxiliar o governo a executar seus procedimentos de
negócio com a ajuda de tecnologias de comunicação através do meio eletrônico. Exemplo de
atuações: declaração de impostos, investigação e casos judiciais.
Já o E-health consiste na preservação dos dados de pacientes no que diz respeito a seus
estados de saúde. Utiliza-se também o conceito de múltiplos pseudônimos durante o processo de
tratamento do paciente, garantindo assim a privacidade de sua identidade.
2.2.4 Principais Requisitos
São requisitos importantes em um IMS: funcionalidade, usabilidade, segurança, privacidade,
aplicação da lei, fidelidade e interoperabilidade.
Quanto à funcionalidade, o IMS auxilia o usuário a controlar sua identidade. Deve informar
o usuário sobre o contexto de uma situação, oferecendo-lhe escolha, caso necessário. É necessário
que uma IMA tenha interfaces para comunicação com parceiros, especialmente em redes digitais.
Isto significa detalhadamente que: uma IMA deve possibilitar a administração de uma identidade
parcial, bem como de dados de uma identidade; uma IMA pode agir como um gateway para a
comunicação digital, ou seja, possibilitar o controle da troca de dados entre os parceiros da
comunicação; e uma IMA deve possuir a capacidade de escolher uma identidade parcial assim que
solicitada ou desejada em um contexto específico.
A usabilidade do ponto de vista do usuário é um dos mais importantes requisitos para
nomear uma IMA. A ISO 9241-11 define usabilidade como a extensão na qual um produto pode ser
usado por determinados usuários para alcançar objetivos específicos com efetividade, eficiência e
satisfação em um contexto de uso específico. A interface do usuário em uma IMA precisa permitir
que este interprete o contexto, a situação e escolha a identidade desejada; gerencie a identidade em
um mundo digital; e trabalhe com diferentes dispositivos, tais como, PCs (Personal Computer),
PDAs (Personal Digital Assistant) e SmartPhones.
Quanto à segurança, um IMS deve ser eficiente contra os ataques em disponibilidade,
integridade e confidencialidade de seus serviços e informações. Isto se torna necessário devido ao
19
grande volume de informações confidenciais existentes dos usuários, que pode causar tentativas de
espionagem, manipulação e roubo de identidades.
A privacidade define que, se uma IMA está localizada na máquina do usuário que possui
controle dos seus dados pessoais e a forma como estes são processados, ela pode apoiar o usuário a
garantir seus direitos de forma on-line. Quando os dados pessoais são armazenados e gerenciados
por um provedor, deverão seguir as normas legais, ou seja, o provedor só poderá processar estes
dados mediante autorização do usuário. Nestas situações em que os provedores de serviços são
responsáveis pelos dados pessoais dos usuários, aplica-se o conceito de segurança multilateral. Este
tipo de segurança é aplicada em ações que envolvam comunicação entre diferentes partes. A
segurança multilateral significa prover segurança para todas as partes envolvidas na comunicação.
Na aplicação da lei, as partes responsáveis estão geralmente interessadas em coletar o
máximo de informações para dar evidências e tornar os procedimentos criminais mais fáceis e
efetivos.
A fidelidade é um pré-requisito para todas as transações onde o usuário confie no provedor
de serviço, até mesmo nos casos onde o usuário tem pleno domínio sobre o hardware, software e
fluxo de dados.
Quanto à interoperabilidade, uma IMA deve implementar interfaces compatíveis com
padrões internacionais, além de oferecer compatibilidade e integração com sistemas existentes.
2.2.5 Mecanismos
Existem mecanismos que são responsáveis pelo funcionamento de um IMS, são eles:
tratamento de comunicação independente e representações de identidades, pseudônimos com
propriedades específicas, recuperação de identidades, funcionalidade de controle de privacidade,
gerenciamento de histórico, detecção de contexto e tratamento de regras.
No tratamento de comunicação independente e representações de identidades, os
componentes de uma identidade parcial podem variar de acordo com as aplicações ou contextos.
Pode ser um identificador, caracterizando um pseudônimo que funciona como um ID único ou um
endereço, através de dados, interesses ou certificados. O usuário deve ter acesso a sua identidade
parcial e principal, para criar, apagar e atualizar dados das identidades. O tratamento da identidade
20
pode ser realizado em quaisquer tipos de computadores. O tipo de dispositivo em que uma IMA é
implementada determina a possibilidade de representação da identidade parcial de um usuário. Para
os procedimentos de configuração da IMA, o usuário pode configurar de acordo com suas
preferências ou se preferir, o sistema oferece modos de aprendizagem que interpretam o
comportamento do usuário.
Em pseudônimos com propriedades específicas, o controle do usuário em relação ao sigilo
de seus dados quando trafegam entre os parceiros de comunicação é o principal conceito do real
gerenciamento de identidades. Isto, realmente é possível com dados autenticados assim que
pseudônimos específicos são utilizados. Um pseudônimo juntamente com os dados ligados a ele
forma uma identidade parcial. Algumas propriedades importantes dos pseudônimos podem ser
citadas: suportar autenticação e autorização, garantir o anonimato do proprietário do pseudônimo e
garantir a propriedade do pseudônimo usando a assinatura digital.
O uso adequado de credenciais impossibilita que o usuário deixe seu “rastro” quando navega
pelos serviços dos parceiros de comunicação, ou seja, o anonimato é garantido enquanto estiverem
usando as credenciais. Por exemplo, um indivíduo pode obter uma credencial conversível de uma
organização utilizando um de seus pseudônimos. Em seguida, pode demonstrar posse desta
credencial à outra organização sem revelar seu primeiro pseudônimo. Sendo assim, uma credencial
pode ser convertida em uma credencial para o uso específico de um pseudônimo corrente.
Neste contexto, se um serviço restrito a usuários autorizados está sendo requisitado por um
usuário que deseja permanecer anônimo, o mesmo precisará mostrar uma credencial para acessar o
serviço. Quando um usuário obtém uma credencial, esta é associada a um novo pseudônimo,
utilizado apenas para aquela transação. A organização (parceira de comunicação) que recebe o
pseudônimo verifica a credencial para obter as informações certificadas. Para verificar uma
credencial, são necessárias algumas informações, por exemplo, uma chave obtida de uma PKI
(Public Key Infrastructure – Infra-Estrutura de Chave Pública). Estas chaves precisam ser
certificadas e publicas no servidor de chaves, de modo que cada possível verificador possa ter
acesso. A Figura 5 mostra as entidades que participam de um sistema de credenciais: autoridade
certificadora, local onde as organizações e os usuários podem obter certificados; servidor de chaves,
onde todas as chaves publicadas podem ser acessadas; e organizações, que são partes que emitem
credenciais para os usuários e publicam chaves no servidor de chaves.
21
Figura 5. Uso de credenciais em um IMS
Fonte: Adaptado de ICPP/ULD e SNG (2003).
A recuperação de identidades é utilizada em casos de perda dos dados da identidade dos
usuários. Os usuários podem confiar em soluções de backup que previnam a perda de dados.
A funcionalidade de controle de privacidade fornece aos usuários informações sobre seus
dados pessoais armazenados em um servidor e permite acesso e controle desses dados.
Em gerenciamento de histórico, uma IMA deve ser capaz de armazenar dados históricos das
transações ocorridas entre as partes envolvidas. Estes dados podem ser utilizados para analisar a
fidelidade entre as partes, ou ainda saber se uma transação foi bem sucedida ou não.
A detecção de contexto ocorre durante uma transação de um usuário com outra parte
envolvida e deve ser capaz de obter informações adicionais, como as propriedades que um novo
pseudônimo deve possuir. Dessa forma, detecções automáticas de contexto servem para ajudar o
usuário a gerenciar sua identidade.
22
No tratamento de regras, uma IMA deve ser capaz de perguntar ao usuário sobre certas
decisões a respeito de sua identidade, porém haverá decisões que a própria aplicação deverá tomar,
de acordo com a detecção de contexto. Estas decisões devem ser suportadas por um tratamento de
regras apropriado para habilitar uma escolha automática.
A evidência digital é utilizada para registrar informações deixadas pelos usuários em suas
transações para que eventualmente possam ser utilizadas como evidência para fins legais.
2.3 SHIBBOLETH
Os conceitos do sistema Shibboleth estudados e descritos nessa seção foram retirados da
fonte Shibboleth (2006) e Twiki (2006).
2.3.1 Conceitos Básicos
O Shibboleth é um software middleware de código aberto que tem como objetivo criar uma
estrutura segura para simplificar o gerenciamento de identidades dos usuários. Fornece mecanismos
para a criação de um sistema de autenticação única ou SSO (Single Sign-On) e permite que as
instituições troquem informações de autorização de acesso único para proteger e compartilhar
recursos on-line.
De acordo com Internet2 (2006), middleware “é a camada de software entre a rede e a
aplicação”.
O Shibboleth é um projeto da Internet2 e do MACE (Middleware Architecture Committee
for Education), uma união de 200 universidades americanas e européias, em conjunto com
indústrias e governo para desenvolver e distribuir aplicações avançadas de rede. A operação do
Shibboleth está em conformidade com a SAML (Security Assertion Markup Language), um
framework baseado na linguagem XML (Extensible Markup Language) que permite a criação e a
troca de informações de segurança entre parceiros on-line.
O anexo I apresenta as aplicações e serviços que utilizam o Shibboleth em suas
implementações. Em ambientes de produção, pode-se citar o Napster, software utilizado para
compartilhar arquivos de áudio e o Sympa, software gerenciador de listas de e-mail.
23
O Shibboleth é um sistema designado para troca de atributos entre domínios, fornece uma
estrutura segura para as instituições transmitirem atributos sobre um browser através de domínios
seguros. Quando um usuário tenta acessar um recurso protegido por Shibboleth, ele é redirecionado
para um serviço que questiona em qual instituição deverá ser feita a autenticação. Se o usuário
ainda não está autenticado, será redirecionado para o sistema de autenticação da instituição
escolhida. Depois de autenticar o usuário, o IdP (Identity Provider – Provedor de Identidade),
localizado na instituição escolhida, irá gerar uma referência temporária para o usuário, conhecida
como handle e envia este para o SP (Service Provider – Provedor de Serviço). O provedor de
serviço poderá usar o handle para perguntar sobre os atributos deste usuário. Baseado nestes
atributos, o provedor de serviço decide se garante ou não o acesso ao recurso. Dessa forma, se
autorizado, o usuário terá acesso ao material requisitado.
2.3.2 Características
Uma das características do sistema Shibboleth é o conceito de identidade federada. Esta
tecnologia permite que as instituições federadas utilizem métodos distintos e próprios de
autenticação e autorização. Além de beneficiar a instituição, o conceito de identidade federada pode
ajudar os usuários, pois reduz o número de senhas que os mesmos precisam lembrar. Usando o
Shibboleth é simplificada a gerência da identidade, tanto para o usuário quanto para os provedores
de serviço.
Na forma atual, os métodos de autenticação de usuário fornecem à aplicação somente um
identificador (por exemplo, um endereço de e-mail) para realizar a autenticação. Esta simples forma
de acesso não é suficiente para os sistemas modernos. Aplicações precisam de informações
adicionais sobre os usuários para realizarem corretas decisões de autorização. Sendo assim, o
sistema Shibboleth fornece atributos dos usuários para as aplicações com a flexibilidade, segurança
e a privacidade requerida em cenários federados.
O Shibboleth permite que os usuários controlem quais as informações serão liberadas e
quem poderá recebê-las. O sistema Shibboleth disponibiliza um caminho para referenciar o usuário
sem revelar a identidade principal. O usuário é conhecido pelo site provedor de serviço somente por
um handle temporário, sendo assim este site pode decidir o que é permitido para o usuário.
24
2.3.3 Federação
A federação Shibboleth provê parte da base confiável requerida para funcionamento da
arquitetura Shibboleth. A federação é um grupo de organizações (universidades, instituições,
provedores de conteúdo, entre outros) que concordam em trocar atributos usando o SAML. As
organizações precisam concordar em um grupo comum de procedimentos técnicos e políticos, tais
como: mecanismos de segurança usados entre os servidores Shibboleth; definição de atributos;
como localizar os servidores de outros participantes; tratamento das informações pessoais que são
confidenciais; e a escolha das organizações que podem participar. Entrar em uma federação não é
explicitamente necessário para operação do Shibboleth, portanto provedores de serviço e
provedores de identidade podem interagir somente com a definição de acordos bilaterais.
Uma federação pode ser criada em uma variedade de formatos e modelos confiáveis, porém
precisa prover certo grupo de serviços para membros da federação. Necessita fornecer um registro
para as aplicações processadas e distribuir informações dos sócios da federação para os sites
provedores de identidade e provedores de serviço. Precisa também distribuir componentes PKI,
necessários para a confiança entre os provedores de identidade e os provedores de serviço.
O ambiente PKI é uma infra-estrutura que provê aos negócios eletrônicos condições de viabilidade a fim de que tenham os mesmos resultados daqueles conferidos aos contratos fora da rede. Tal recurso viabiliza a autenticação oficial e a integridade do documento, assim como sua elaboração e a confidencialidade nas operações e na assinatura digital, garantindo o valor jurídico e precavendo os envolvidos nas negociações da recusa do que foi firmado anteriormente (SILVA, 2004).
Como exemplo de federação pode-se citar a InQueue, uma federação operada pela Internet2.
Esta é destinada a organizações que estão iniciando os trabalhos com o sistema Shibboleth e
confiam em um modelo federado. Além da federação InQueue, outras federações estão em
operação, são elas: HAKA – Finlândia, CRU – França, InCommon – Estados Unidos, SDSS –
Reino Unido e Switch – Suíça.
2.3.4 Provedor de Identidade
O provedor de identidade é o local onde os usuários irão realizar a autenticação, portanto o
IdP mantém credenciais e atributos de usuários e faz o controle destes atributos, liberando-os
somente para as instituições confiáveis.
25
Existem quatro componentes principais no IdP: o HS (Handle Service), o AA (Attribute
Authority), o serviço de diretório e o mecanismo de autenticação. O HS faz a autenticação dos
usuários em conjunto com o mecanismo de autenticação e cria um handle token para o usuário. O
handle token (afirmação de autenticação SAML) é um transportador de credencial que contém um
ID ou handle. O HS é interoperável, pois permite que a instituição escolha o mecanismo de
autenticação desejado. Já o AA funciona da seguinte forma, quando um usuário requisita acesso ao
recurso, o provedor de serviço mostra o handle token para o AA e requisita atributos relativos ao
usuário. O AA aplica políticas de privacidade sobre a liberação destes atributos e permite que o
usuário especifique quais provedores de serviço podem acessá-los. Semelhante ao HS, o AA
permite que a instituição escolha o serviço de diretório desejado. O serviço de diretório será
fornecido pela instituição, sendo o local onde ficarão armazenados os dados dos usuários, ou seja,
os seus atributos. O mecanismo de autenticação não é fornecido pelo sistema Shibboleth. Este
deverá ser obtido através de terceiras partes, tais como, o WebISO (Web Initial Sign-On) ou o
Pubcookie. Estas ferramentas permitem que os usuários façam autenticação utilizando um serviço
central que possibilita a utilização de apenas um usuário e senha.
Do ponto de vista do IdP, o primeiro contato do usuário é o redirecionamento para o HS
(Handle Service), que consulta o mecanismo de autenticação para determinar se o usuário está
autenticado. Caso não esteja, o browser do usuário será questionado sobre a autenticação. Após a
autenticação, será enviado para a URL (Universal Resource Locator) do provedor de serviço, um
handle contendo a afirmação de autenticação. Em seguida, o provedor de serviço envia uma
requisição, contendo o handle do usuário para o AA. O AA consulta o ARP (Attribute Release
Policies) para a entrada de diretório correspondente ao handle. Conforme regras das políticas
consultadas, o IdP libera os atributos para o provedor de serviço.
2.3.4.1 ARP
O AA (Attribute Authority) mantém um grupo de políticas chamado ARP (Attribute Release
Policies), estas políticas administram a liberação de atributos do usuário para provedores de serviço.
Quando um usuário tenta acessar um recurso protegido por Shibboleth, o provedor de serviço deste
recurso pergunta ao IdP sobre todos os atributos do usuário. O AA procura os atributos associados
com o usuário, passa pelas regras do ARP e depois envia para o provedor de serviço somente os
atributos permitidos nesta política.
26
Na origem dos dados, um ARP não pode mudar as informações dos atributos. Os ARPs são
administrativamente mantidos e aplicados a todos os usuários para qual o provedor de identidade é
autoritário. Todos os ARPs são especificados usando a mesma sintaxe e semântica.
Cada ARP é formado de uma ou mais regras que especificam quais atributos e valores
podem ser liberados para o provedor de serviço. A atribuição das regras para os vários provedores
de serviço é flexível e inclui algumas particularidades, tais como: uma regra deve afetar todos os
provedores de serviço (regra padrão); os nomes exatos dos provedores de serviço para qual uma
regra é aplicada; expressão regular no nome do provedor de serviço que deverá ser comparado para
determinar se uma regra é aplicada; e aplicações individuais que podem atingir vários provedores de
serviço.
2.3.4.2 Requisitos
Os requisitos de software para implementação de um provedor de identidade Shibboleth são:
• Um protocolo para serviço de diretório, tais como: LDAP (Lightweight Directory
Access Protocol) ou SQL (Structured Query Language). Shibboleth trabalha com JDBC
(Java Database Conectivity) e JNDI (Java Naming and Directory Interface) que garante
a comunicação com os principais bancos de dados. O AA possui uma API (Application
Programming Interface) Java, o qual permite a utilização de conectores para outros tipos
de fonte de dados;
• Um mecanismo de autenticação para os usuários, preferencialmente um serviço de
autenticação única, por exemplo: WebISO ou Pubcookie;
• Shibboleth pode ser implementado nas plataformas: Windows, Linux, Mac OS X e
Solaris. Além desta variedade, pode funcionar com qualquer plataforma que tenha uma
implementação do Tomcat;
• Um Java servlet container. O sistema Shibboleth é testado massivamente com o Tomcat;
e
• Um servidor web, é recomendado o Apache. O Apache será implementado na frente do
Tomcat para prover serviços de autenticação e controle do fluxo das requisições.
27
2.3.5 WAYF
O serviço WAYF (Where Are You From) é um componente da arquitetura Shibboleth
responsável por permitir um usuário associar-se com uma instituição especificada. Ao solicitar um
recurso, caso o usuário não esteja autenticado, o componente WAYF apresenta ao usuário uma lista
de instituições que fazem parte da federação. Após escolher a instituição, o usuário é redirecionado
para o componente HS e iniciará o processo de autenticação. O serviço WAYF pode ser distribuído
como parte de um provedor de serviço ou como código de terceira parte operado por uma
federação.
2.3.6 Provedor de Serviço
O SP (Service Provider – Provedor de Serviço) é o local onde são armazenados os recursos
acessados pelos usuários. Faz o gerenciamento dos recursos protegidos pelo Shibboleth, validando
os handles enviados pelo provedor de identidade e usando-os para criar um contexto seguro. Ajuda
a aplicação no controle de acesso baseado na informação.
Há três componentes principais no SP: o ACS (Assertion Consumer Service), o AR
(Attribute Requester) e o RM (Resource Manager). O componente ACS fica responsável por
receber mensagens com o objetivo de estabelecer um contexto seguro. O ACS pode ser definido
como um recurso HTTP (HyperText Transfer Protocol) que processa mensagens SAML e retorna
um cookie para o browser, representando a informação extraída da mensagem. O AR é o
responsável por obter e repassar os atributos do usuário para o RM. Já o RM é um componente que
intercepta as requisições aos recursos e toma as decisões de controle de acesso baseadas nos
atributos dos usuários.
Do ponto de vista do SP, um browser irá alcançar o RM com uma requisição ao recurso
protegido por Shibboleth. O RM permite então que o ACS use o WAYF para adquirir o nome do
provedor de identidade do usuário. Após autenticar o usuário, o HS responde com uma afirmação
de autenticação SAML handle, que o ACS entrega para o AR. O AR usa este handle e o endereço
fornecido do provedor de identidade para requisitar todos os atributos que são permitidos saber
sobre o usuário. Após receber os atributos, o AR prepara algumas validações e análises baseadas
nas AAPs (Attribute Acceptance Policies). Estes atributos são entregues ao RM, que é responsável
por usá-los para decidir se garante acesso ao recurso. As AAPs definem as regras dos atributos
28
recebidos do provedor de identidade. São utilizadas pela aplicação para decisões de controle de
acesso e para fornecimento de filtros, determina quem pode afirmar determinada informação.
2.3.6.1 Requisitos
Os requisitos de software para implementação de um provedor de serviço Shibboleth são:
• Um servidor web, recomenda-se o IIS (Internet Information Server) da Microsoft ou o
Apache com suporte a SSL (Secure Socket Layer);
• Aplicações web devem ser modificadas para serem capazes de confiar nos atributos
fornecidos pelo Shibboleth; e
• Na maioria dos casos, esquemas de controle de acesso podem ser simplificados e
reescritos para tirar vantagem do sistema Shibboleth, já que o controle de acesso do
Shibboleth é baseado em atributos.
2.3.7 Segurança
O software e os protocolos do Shibboleth são projetados para fornecer proteção contra
diversos tipos de ataques. Porém, mesmo os mais seguros protocolos podem ser comprometidos se
o ambiente onde trabalham é inseguro. Em vista disso, existem rigorosas precauções de segurança
que devem ser aplicadas no ambiente Shibboleth. A utilização do protocolo SSL é altamente
recomendada para proteção de todos os fluxos do sistema. O SSL deve ser utilizado para interações
com as máquinas dos usuários para prover a cifragem necessária, evitando ataques do tipo MITM
(Man In The Middle). O MITM é um tipo de ataque onde o atacante tem a capacidade de ler e
modificar mensagens trocadas entre dois parceiros, sem que estes saibam que o link foi
comprometido. Outros ataques podem produzir interceptação nas etapas do sistema Shibboleth. A
melhor proteção contra estas interceptações é a proteção do serviço WAYF, em que o provedor de
identidade falso não será usado. Além disso, medidas de segurança devem ser adotadas para
proteger os serviços de diretório, já que estes locais contêm informações sobre os usuários. Sendo
assim, estas informações devem ser trocadas entre os provedores de maneira segura, de modo que
todos os pedidos que o provedor de serviço executa estejam autorizados e que toda informação
fornecida pelo provedor de identidade seja correta.
29
2.3.8 Aplicações
Aplicações Shibboleth são as unidades principais da composição do provedor de serviço.
Uma aplicação representa um grupo de recursos web que operam usando o mesmo tratamento de
atributos e configurações confiáveis, compartilhados em uma sessão comum com o browser do
usuário. Em um estudo de caso, enquanto um usuário navega em uma aplicação A e atinge uma
aplicação B, uma nova sessão é estabelecida, sendo que a autenticação do usuário pode não ser
requerida. Como uma característica do relacionamento entre aplicações e sessões, uma aplicação
geralmente trabalha usando apenas um domínio.
Um único provedor de serviço pode suportar um grande número de aplicações, sendo que
não precisa registrar ou publicar informações sobre cada uma das informações recebidas pelos
provedores de identidade. Isto permite que os provedores de serviço com uma complexa
configuração interna, possam ser tratados como uma única entidade por provedores de identidade,
desde que tenham como propósito a liberação de atributos.
2.3.9 Sessões
Muitas das implementações dos provedores de serviço estão preocupadas com a criação e
posterior manutenção das sessões com o browser. Uma sessão consiste em um cookie passado entre
o browser e o servidor web, associado a um contexto seguro. O contexto contém a informação de
autenticação do usuário, e geralmente um grupo de atributos que compõem a identidade do mesmo.
Cada aplicação mantém sessões distintas com o browser através de cookies separados. O sistema
Shibboleth não suporta funcionalidade de logout, somente o término das sessões individuais da
aplicação por remoção dos respectivos cookies. Entretanto, ainda não há como os provedores de
serviço criarem sessões dos provedores de identidade, por exemplo, um processo de login SSO que
irá expirar. Esta funcionalidade de logout está prevista na versão 2.0 do sistema Shibboleth.
O browser do usuário acessando um recurso protegido por Shibboleth pode ter dois
resultados: estabelecimento de uma standard session e estabelecimento de uma lazy session. O
mecanismo de standard session no qual o Shibboleth protege o recurso em todas as circunstâncias,
resulta no estabelecimento de uma sessão de browser baseada em cookie e em grupo de atributos
gravados para esta aplicação. Já no mecanismo de lazy session, o recurso pode ser acessado sem
prévia autenticação. Isto significa que, a aplicação precisa ser inteligente suficiente para determinar
se a autenticação é necessária, e então construir a própria URL (Universal Resource Locator) para
30
iniciar o redirecionamento do browser para requisitar a autenticação. Este mecanismo é geralmente
útil para proteger uma única URL com diferentes mecanismos de acesso, ou para requerer acesso
somente em casos onde à aplicação julgar necessário.
Independente disso, uma aplicação web protegida por Shibboleth pode ter necessidade de
estabelecer sua própria sessão com o usuário. Esta sessão pode persistir além da sessão do
Shibboleth, e o logout desta sessão, se suportado, não poderá terminar a sessão iniciada. Os
administradores da aplicação devem verificar a expiração de todas as sessões para limitar a
vulnerabilidade aos ataques ou a negligência do usuário.
2.3.10 Funcionamento
O sistema Shibboleth é formado por dois componentes principais: o IdP e o SP. Estes
componentes são distribuídos separadamente, mas trabalham juntos para prover acesso seguro aos
recursos. A Figura 6 apresenta o fluxo durante uma operação completa do Shibboleth, partindo da
situação que o browser do usuário chega ao site provedor de serviço sem uma sessão existente e
sem nenhuma informação sobre seu site provedor de identidade. Os atores principais incluem: o
usuário, ou seja, aquele que deseja usar o recurso web protegido; o site provedor de serviço, local
onde está instalado o software SP; e o site provedor de identidade, local onde está instalado o
software IdP.
31
Figura 6. Diagrama de Fluxo do Sistema Shibboleth
Fonte: Adaptado de Shibboleth (2006).
O usuário navega para o recurso web usando o browser. O recurso web, localizado no site
provedor de serviço, é protegido, então se torna necessário coletar algumas informações sobre o
usuário para decidir se o acesso é permitido (Passo 1). O software Shibboleth redireciona o browser
do usuário para uma página de navegação, chamada WAYF, nesta página é apresentada ao usuário
uma lista de organizações que podem acessar o recurso web protegido (Passo 2 e 3). A partir desta
etapa, o usuário seleciona a sua organização (Passo 4) e o browser é enviado para o web site da
organização escolhida, ou seja, para o componente HS localizado no seu provedor de identidade
(Passo 5). O usuário visualiza a interface web de autenticação da sua organização (Passo 6), onde
serão inseridas as credenciais (Passo 7). Após enviar suas credencias, o componente HS usa o
mecanismo de autenticação local da organização para verificar as credenciais do usuário (Passo 8).
O HS cria um handle para identificar o usuário. Este handle é registrado com o AA de forma que
possa ser mapeado para os atributos do usuário quando a requisição do recurso chegar. O handle é
colocado dentro de um handle token e enviado para o recurso web. Este handle token informa que o
32
usuário está autenticado (Passo 9). O handle token é recebido pelo componente ACS que examina o
handle token para determinar o provedor de identidade que pode fornecer os atributos sobre o
usuário. Após examinar e validar o handle token, o ACS transfere-o para o AR e cria uma sessão
(Passo 10). O AR utiliza o handle token para requisitar ao provedor de identidade, especificamente
ao AA, informações adicionais (atributos) sobre o usuário (Passo 11). No provedor de identidade,
após terem sido comparados e validados o handle token e o handle, foi mapeado a identidade do
usuário, sendo assim o ARP é consultado. Se a liberação dos atributos do usuário for permitida, os
valores dos atributos requisitados são devolvidos (Passo 12). O AA responde com os valores dos
atributos solicitados no formato SAML assertion (Passo 13). O provedor de serviço recebe os
atributos e passa para o RM (Passo 14). O RM utiliza estes atributos para decidir se garante ou não
o acesso ao recurso. Se permitido, carrega o recurso solicitado no browser do usuário (Passo 15).
Outros passos podem ser citados, por exemplo: o WAYF pode criar um cookie no browser
do usuário em que não seja necessária a apresentação da página de seleção da organização; se a
organização do usuário utiliza serviço de autenticação única e o usuário já estiver com uma sessão
de autenticação criada, a interface web de autenticação não precisa ser apresentada; e em muitos
casos o usuário pode ter acesso ao recurso sem visualizar qualquer página intermediária.
2.3.11 Aplicação Prática
Com o intuito de demonstrar o funcionamento básico do sistema Shibboleth foi realizado a
instalação do SP (Provedor de Serviço) e do IdP (Provedor de Identidade). Ambos foram instalados
em sistema operacional Linux, o provedor de identidade utilizando a distribuição Slackware versão
10 e o provedor de serviço à distribuição Fedora Core versão 5. Após realização das instalações, foi
utilizado o sistema TestShib. O TestShib tem como objetivo principal auxiliar nos testes iniciais da
instalação do Shibboleth, interagindo com os provedores que são implementados (TESTSHIB,
2006).
2.3.11.1 Implementação do Provedor de Identidade
Para instalação, configuração e testes do provedor de identidade, chamado “shib-
idp.dalcoquio.com.br”, foram executados as seguintes etapas:
1. Instalação e configuração do sistema operacional Linux Slackware versão 10 kernel
2.4.31;
33
2. Instalação e configuração do servidor web Apache versão 1.3.33 com suporte ao SSL.
Para assinar a chave pública foi utilizada uma autoridade certificadora que não cobrou
pelo serviço. A assinatura da chave pública, chamada de certificado digital, faz parte da
criação do ambiente PKI;
3. Implementação do servlet container Tomcat versão 5.5 e Java 1.5;
4. Instalação do mecanismo de autenticação e do serviço de diretório. Para efeito de testes
iniciais foram implementados serviços simplificados de autenticação e de diretório;
5. Implementação do software Shibboleth IdP versão 1.3c; e
6. Registro do provedor de identidade chamado “shib-idp.dalcoquio.com.br” no sistema
TestShib.
A seguir são mostrados os passos realizados nos testes do provedor de identidade “shib-
idp.dalcoquio.com.br” interagindo com o provedor de serviço do TestShib.
34
Na Figura 7 o processo é iniciado. O usuário faz uma requisição ao recurso desejado
(https://sp.testshib.org), neste caso um recurso protegido por Shibboleth. O recurso é protegido por
um ambiente PKI, portanto para continuar, o usuário precisa confirmar o recebimento do certificado
digital (chave pública).
Figura 7. Requisição ao Recurso Protegido por Shibboleth
35
Após aceitar o certificado digital, o usuário é direcionado ao serviço WAYF que irá
perguntar qual é o seu provedor de identidade, ou seja, o local onde ele fará a autenticação (Figura
8).
Figura 8. Serviço WAYF
36
Após selecionar o seu provedor de identidade, o usuário será novamente requisitado para
aceitação do certificado digital, entretanto agora será o certificado do seu provedor de identidade
(Figura 9).
Figura 9. Requisição ao Provedor de Identidade
37
Depois de aceitar o certificado do seu provedor de identidade, o usuário será encaminhado
ao mecanismo de autenticação, chamado “Dalcoquio – Single Sign-On” onde o usuário informa as
suas credencias (Figura 10).
Figura 10. Pedido para Autenticação no Provedor de Identidade
38
O usuário informa as suas credencias, neste caso digita o seu usuário: myself e senha: myself.
(Figura 11).
Figura 11. Entrada da Credencial
39
Na Figura 12, após aceitação do usuário pelo sistema de autenticação, ocorre o
redirecionamento do browser do usuário para o recurso web solicitado. Neste instante o provedor de
identidade gera o handle. Este será enviado ao provedor de serviço para validar a autenticação do
usuário. Além disso, este handle é utilizado para solicitar informações (atributos) sobre o usuário.
Figura 12. Redirecionando para o Recurso Solicitado
40
Finalmente, após ter feito o controle de acesso baseado nos atributos do usuário, o
gerenciador de recurso concedeu o acesso ao recurso solicitado. Sendo assim, o recurso web é
apresentado ao usuário (Figura 13).
Figura 13. Recurso Solicitado pelo Usuário
2.3.11.2 Implementação do Provedor de Serviço
Para implementação e testes do provedor de serviço chamado “shib-sp.dalcoquio.com.br”,
foram executados os seguintes passos:
1. Instalação e configuração do sistema operacional Linux Fedora Core versão 5 kernel 2.6.15;
2. Instalação e configuração do servidor web Apache versão 1.3.33 com suporte ao SSL.
Para assinar a chave pública foi utilizada uma autoridade certificadora que não cobrou
pelo serviço. A assinatura da chave pública, chamada de certificado digital, faz parte da
criação do ambiente PKI;
3. Implementação do software Shibboleth SP versão 1.3-9; e
41
4. Registro do provedor de serviço chamado “shib-sp.dalcoquio.com.br” no sistema
TestShib.
A seguir são mostrados os passos realizados nos testes do provedor de serviço “shib-
sp.dalcoquio.com.br” interagindo com o provedor de identidade do TestShib.
Na Figura 14 o processo é iniciado. O usuário faz uma requisição ao recurso desejado
(https://shib-sp.dalcoquio.com.br/secure), neste caso um recurso protegido por Shibboleth. O
recurso é protegido por um ambiente PKI, portanto para continuar, o usuário precisa confirmar o
recebimento do certificado digital (chave pública).
Figura 14. Requisição ao Recurso Protegido por Shibboleth
42
O provedor de identidade mostra o seu certificado digital e solicita ao usuário que confirme
o recebimento (Figura 15).
Figura 15. Conexão Segura no Provedor de Identidade
43
O usuário informa as suas credencias, neste caso digita o seu usuário: myself e senha: myself.
(Figura 16).
Figura 16. Entrada da Credencial
44
Na Figura 17, após aceitação do usuário pelo sistema de autenticação, ocorre o
redirecionamento do browser do usuário para o recurso web solicitado. Neste instante o provedor de
identidade gera o handle. Este será enviado ao provedor de serviço para validar a autenticação do
usuário. Além disso, o handle é utilizado para solicitar informações (atributos) sobre o usuário.
Figura 17. Redirecionando para o Recurso Solicitado
45
Finalmente, após ter feito o controle de acesso baseado nos atributos do usuário, o
gerenciador de recurso, concede acesso ao recurso solicitado. Sendo assim, o recurso web é
apresentado ao usuário (Figura 18).
Figura 18. Recurso Protegido por Shibboleth
2.3.12 Trabalhos Relacionados
Durante a execução deste trabalho, algumas iniciativas de pesquisa nesse assunto foram
identificadas.
O projeto IAMSECT (Inter-institutional Authorisation Management to Support E-learning
with reference to Clinical Teaching) localizado em IAMSECT (2006), tem como objetivo
desenvolver, testar e disseminar uma abordagem prática para implementar a autenticação e
autorização para e-learning (sistema de educação à distância) usando o Shibboleth (WHEELER,
2006). O projeto teve como resultado final a adoção do Shibboleth pelas universidades participantes
do projeto, facilitando o controle dos recursos distribuídos no ambiente do e-learning.
46
O projeto PRIME (Privacy and Identity Management for Europe) é um consórcio formado
por várias empresas (IBM, Lufthansa, etc) e instituições da Europa (Universidade de Milano,
Instituto EURECOM, etc), que está sendo desenvolvido e tem cronograma de atividades previstas
de 2004 até 2007 (PRIME, 2006), (HANSEN e KRASEMANN, 2005). O PRIME tem como
objetivo propor a construção de um sistema de gerenciamento de identidades viável, controlado
pelo usuário, levando em consideração também as questões de legislação (CAMENISCH et al.
2005).
O projeto da Universidade Purdue (PURDUE, 2006), tem como objetivo obter soluções para
a segurança e a privacidade da identidade do usuário em uma federação. No artigo (BHARGAV-
SPANTZEL; SQUICCIARINI e BERTINO, 2006), os autores contribuem com um protocolo
criptográfico que deve ser utilizado para a proteção contra o roubo da identidade do usuário.
O Brasil já utiliza o Shibboleth, em instituições como a UFMG (Universidade Federal de
Minas Gerais) (LCC-CENAPAD, 2006), UFV (Universidade Federal de Viçosa), UFPA
(Universidade Federal do Pará), UFJF (Universidade Federal de Juiz de Fora) e UNISC
(Universidade de Santa Cruz do Sul) (FINANCIAR, 2006). Estas instituições podem requisitar
serviços do FINANCIAR, um sistema de busca que disponibiliza para pesquisadores e empresários,
informações sobre fontes financiadoras internacionais e nacionais, para projetos de pesquisa,
desenvolvimento e inovação (FINANCIAR, 2006).
3 PROJETO
Um ambiente completo do sistema Shibboleth é formado por vários componentes que
cooperam entre si para proteger uma aplicação ou recurso. Nem todos estes componentes fazem
parte do escopo do sistema Shibboleth, portanto este projeto tem como proposta a implementação
do: mecanismo de autenticação, serviço de diretório, controle de políticas de segurança e
gerenciador de recurso. Para a demonstração prática do sistema Shibboleth é proposta a
implementação de uma federação Shibboleth (servidor provedor de identidade, servidor provedor de
serviço, servidor WAYF) e a implementação da aplicação.
No sistema Shibboleth é recomendado o uso de uma federação, desta forma será criada uma
federação chamada InBrazil que fornecerá regras de conduta entre os membros da federação, além
do serviço WAYF. O WAYF é responsável por direcionar o usuário para a sua instituição, onde
basicamente o serviço irá checar suas credenciais.
3.1 Cenário da Aplicação
O sistema Shibboleth é uma novidade no Brasil, não existem web sites ou comunidades que
tratem do assunto. A documentação em inglês é bastante expressiva e sofre constantes melhorias.
Em vista disso, propõe-se a criação de um web site que contenha documentos em português sobre o
sistema Shibboleth, com informações referentes a este trabalho, pesquisas realizadas, documentos
utilizados para instalação do ambiente, entre outros.
A criação da federação InBrazil também faz parte do escopo deste trabalho, pois a federação
completa o ambiente do sistema Shibboleth. Esta federação ficará aberta para novos integrantes que
tenham intenção de estudar e se aperfeiçoar no assunto. Os novos membros da federação poderão
utilizar a aplicação que será disponibilizada neste web site, bem como criar novas aplicações que
ficarão disponíveis para a federação InBrazil.
O ambiente Shibboleth somente tem utilidade se existirem aplicações que suportem os
componentes e estejam de acordo com as políticas do Shibboleth. Sendo assim, para demonstrar o
funcionamento prático do sistema Shibboleth fica definida a criação de uma aplicação que tenha
interação com o sistema. Esta aplicação funcionará da seguinte maneira: os usuários que não fazem
parte da federação terão apenas acesso de leitura ao conteúdo protegido; e os usuários já
48
participantes da federação poderão inserir material sobre o assunto, relatando seus estudos e
experiências.
Na Figura 19 demonstra-se o funcionamento da federação InBrazil. Os usuários do IdP
InBrazil ao requisitarem acesso à aplicação (Passo 1), serão direcionados para a página de
autenticação de seu provedor de identidade, neste caso o IdP InBrazil (Passo 2). Após terem sido
autenticados pelo seu provedor de identidade (Passo 3 e 4), o provedor de identidade envia o handle
correspondente a sua autenticação para o provedor de serviço (Passo 5). O provedor de serviço
utiliza este handle para solicitar atributos sobre o usuário ao provedor de identidade (Passo 6). Após
checar as políticas de liberação de atributos correspondentes ao handle, o provedor de identidade
envia estes atributos para o provedor de serviço (Passo 7). O provedor de serviço encaminha os
atributos para o gerenciador de recurso que fará o controle de acesso baseado nos atributos que
recebeu. Se autorizado, a aplicação será apresentada ao usuário (Passo 8). Como o usuário faz parte
de uma federação, ele será autorizado a inserir documentos na aplicação. Já os usuários que ainda
não possuem um IdP terão acesso apenas de leitura ao site, o download de arquivos também será
permitido, mas a área destinada a upload de documentos ficará restrita. Quando constituírem um
IdP próprio e se tornarem membros da federação InBrazil poderão contribuir com documentos das
pesquisas e práticas com o sistema Shibboleth, desta forma terão acesso à área de upload da
aplicação protegida por Shibboleth.
Figura 19. Federação InBrazil
49
3.2 Componentes Adicionais
Os componentes que serão implementados com intuito de viabilizar um ambiente completo
de Shibboleth são: mecanismo de autenticação, serviço de diretório, controle de políticas de
segurança, gerenciador de recurso e o WAYF (Figura 20).
Figura 20. Ambiente Shibboleth Completo
Fonte: Adaptado de Shibboleth (2006).
O mecanismo de autenticação é o componente responsável por checar as credenciais do
usuário e repassar a confirmação de autenticação para o componente HS do provedor de identidade
(SHIBBOLETH, 2006). Neste ambiente Shibboleth será instalado e configurado o componente
Pubcookie. O Pubcookie é um software open source que fornece SSO, ou seja, um mecanismo de
autenticação única para usuários em aplicações web (PUBCOOKIE, 2006).
O processo de autenticação SSO do Pubcookie utiliza quatro componentes: o browser do
usuário, o servidor Apache, o servidor Pubcookie e o serviço de diretório. O servidor Apache
armazena a aplicação que necessita de autenticação e redireciona os usuários não autenticados para
o servidor Pubcookie. O servidor Pubcookie interage com os usuários para solicitar suas credenciais
50
e verifica-as no serviço de diretório. O serviço de diretório mantém as credenciais e atributos dos
usuários. Durante o processo de autenticação do usuário, o servidor Apache e o servidor Pubcookie
liberam cookies para manter informações de autenticação que possibilitam a funcionalidade de
autenticação única. Estes cookies são enviados e armazenados de maneira segura, já que utilizam a
assinatura digital e a criptografia simétrica para fazer a proteção contra alteração e divulgação dos
seus conteúdos (PUBCOOKIE, 2006).
O serviço de diretório fica encarregado de armazenar todas as informações referentes aos
usuários da aplicação (OPENLDAP, 2006). Estas informações são um conjunto de atributos que
definem as características dos usuários. Por exemplo, a especificação EduPerson define uma
padronização para atributos de usuários de ensino superior. O atributo eduPersonAffiliation da
especificação EduPerson define se o usuário é estudante, visitante ou professor (EDUCAUSE,
2006).
No OpenLDAP, entradas de diretórios são organizadas em uma hierarquia de árvore.
Normalmente, esta estrutura reflete limites geográficos e/ou políticos. Entradas representando
países aparecem no topo da árvore. Abaixo dessas estão as entradas representando estados e
organizações nacionais. Abaixo podem estar entradas representando unidades organizacionais,
pessoas, impressoras, documentos, etc. A árvore também pode ser organizada com base em nomes
de domínio (OPENLDAP, 2006). Neste ambiente proposto será instalada e configurada a
ferramenta OpenLDAP, um software open source, interoperável e recomendado pelo Shibboleth
para fornecer um ambiente necessário para o armazenamento dos atributos dos usuários
(OPENLDAP, 2006).
O gerenciamento do serviço de diretório será realizado através da ferramenta
PHPLDAPADMIN, um aplicativo web open source que permite a integração com o OpenLDAP.
Esta integração permite gerenciar, por meio de uma interface web, a hierarquia de árvore presente
no OpenLDAP, facilitando o serviço de criação das organizações e dos usuários. Além disso, o
PHPLDAPAMIN facilita na definição dos atributos que serão utilizados pelos usuários, tais como,
o atributo uid (login do usuário), o atributo userPassword (senha do usuário) e o atributo
eduPersonAffiliation (PHPLDAPADMIN, 2006).
Segundo Sharpe (2006), o mecanismo de controle de políticas de segurança fica encarregado
de auxiliar os usuários e administradores do provedor de identidade a criarem e manterem os
atributos, bem como definirem as regras de acesso e liberação destes atributos. O software que será
51
implementado é o ShARPE (Shibboleth Attribute Release Policy Editor). O ShARPE é composto
de 2 componentes:
• SharpeCore - é o principal componente do ShARPE, fica responsável por acessar e
manipular os arquivos de configuração do provedor de identidade; e
• WebSharpe - responsável por disponibilizar uma interface web para que os usuários e
administradores possam gerenciar os atributos e as regras de liberação de atributos.
O componente WebSharpe é composto de 3 ferramentas: o SPDescription (Service Provider
Description Editor), o ShARPE e o Autograph. O objetivo do SPDescription é permitir que os
administradores do provedor de serviço descrevam os serviços e níveis de serviço fornecidos pelo
provedor de serviço. Além disso, no SPDescription pode ser definida uma lista de atributos
necessários para garantir acesso ao serviço. O ShARPE é responsável pela importação das
informações geradas pelo SPDescription. Estas informações são utilizadas pelos administradores do
provedor de identidade para configurar as regras de liberação dos atributos, necessárias para acessar
um determinado serviço. Finalmente, o Autograph tem como objetivo permitir que os usuários
controlem a liberação de seus atributos (SHARPE, 2006).
O gerenciador de recurso é o componente que faz o controle de acesso ao recurso protegido
por Shibboleth, interceptando as requisições para os recursos e decidindo se concede ou não o
direito de acesso. No shibboleth este componente é limitado, já que fica a cargo da aplicação
examinar e decidir o que fará com os atributos. Portanto, propõe-se adaptar o RM (Resource
Manager – Gerenciador de Recurso) para suportar o controle de acesso da aplicação a ser
desenvolvida (SHIBBOLETH, 2006).
O último componente a ser implementado é o serviço WAYF, este fica responsável por
apresentar ao usuário uma lista de provedores de identidade disponíveis na federação, além disso,
faz o direcionamento do browser do usuário para o mecanismo de autenticação da instituição
selecionada (SHIBBOLETH, 2006).
52
A Figura 21 mostra a interação entre todas as partes do ambiente Shibboleth.
Figura 21. Interação entre Componentes Shibboleth
Fonte: Adaptado de Shibboleth (2006).
3.3 Tecnologias para Implementação
Para o desenvolvimento do projeto serão utilizadas as seguintes tecnologias: PHP, CGI,
XML, SAML, banco de dados MySQL, protocolo LDAP, sistema operacional Linux, OpenSSL e o
sistema Shibboleth.
O PHP (Hypertext Preprocessor) é uma linguagem de programação livre e muito utilizada
para gerar conteúdo dinâmico para sites web. A linguagem pode ser utilizada para desenvolvimento
de pequenos códigos, como também para sistemas que envolvam programação orientada a objetos.
É uma linguagem modularizada, ou seja, seus diversos módulos podem ser agregados a sua
estrutura de acordo com a necessidade do ambiente (PHP, 2006). Esta linguagem foi escolhida
devido a sua facilidade de uso, robustez, conhecimento do desenvolvedor e conectividade com o
banco de dados MySQL e serviço de diretórios LDAP.
O CGI (Common Gateway Interface) é uma tecnologia que permite gerar páginas web
dinâmicas. O programa que utiliza a tecnologia CGI pode ser escrito nas linguagens de
programação Perl, C, Visual Basic, entre outras. O programa CGI é armazenado em um servidor
web e fica aguardando uma requisição que envie os parâmetros necessários para o processamento e
a geração da página web (CGI, 2006). O software Pubcookie utiliza a tecnologia CGI.
Já o XML é uma linguagem de marcação de dados que provê um formato para descrever
dados estruturados. É considerada de grande importância na Internet, pois tem a capacidade de
53
interoperação entre os computadores, já que possui um padrão flexível, aberto e independente de
dispositivo (W3C, 2006). Como alguns documentos de configuração do Shibboleth são baseados
neste formato, torna-se necessário o entendimento desta linguagem.
O SAML é baseado no formato XML, fornece uma forma padronizada para transmitir
informações de autorização e autenticação através de mensagens, chamadas assertions, entre dois
domínios federados. Um dos domínios é o site de origem que autentica os usuários e o outro é o site
destino que controla o acesso aos recursos (TWIKI, 2006).
MySQL é um banco de dados open source, sendo reconhecido pelo seu desempenho,
robustez e também por ser multitarefa e multiusuário. Outra vantagem é sua facilidade de
integração com a linguagem PHP, o que ajuda no desenvolvimento de uma aplicação web
(MYSQL, 2006). Por ser um banco de dados que opera em diferentes tipos de plataformas, tem um
grande número de adeptos, tornando-o um padrão de banco de dados para aplicações web.
O LDAP é um protocolo para acessar serviços de diretórios rodando sobre TCP/IP. O
serviço de diretório é um banco de dados otimizado para ler, navegar e procurar dados. Os
diretórios tendem a conter descritivos, atributos e um suporte sofisticado para filtros. Os serviços de
diretórios geralmente não suportam complicadas transações de registros e grandes volumes de
dados que geralmente são encontradas em sistemas de banco de dados (OPENLDAP, 2006).
Linux é um sistema operacional livre e popular, é composto pelo núcleo ou kernel Linux e
pelas bibliotecas e ferramentas do projeto GNU (LINUX, 2006). Por ser um sistema operacional
livre, atrai vários desenvolvedores e ferramentas que suportam o seu ambiente, tornando-o cada vez
mais interoperável e seguro. Este sistema operacional foi escolhido para o projeto principalmente
pela sua confiabilidade e segurança.
O OpenSSL é uma implementação open source do protocolo SSL (Secure Socket Layer). O
protocolo SSL fornece criptografia dos dados, métodos de autenticação e integridade de mensagens
para transmissão de dados pela Internet. O OpenSSL tem como objetivo principal garantir a
segurança através da criptografia para o estabelecimento de uma conexão segura entre dois
computadores/aplicativos, assegurando a privacidade na conexão, com a utilização da criptografia
assimétrica para negociar uma chave secreta (criptografia simétrica) (OPENSSL, 2006).
O sistema Shibboleth fornece parte da infra-estrutura necessária para implementação do
sistema de gerenciamento de identidades. É o componente principal que precisa estar instalado e
54
configurado para interagir com os componentes adicionais, com a federação e finalmente com a
aplicação.
4 DESENVOLVIMENTO
Esta fase dividiu-se em duas grandes etapas: implementar a federação InBrazil e
implementar a aplicação para demonstração do sistema de gerenciamento de identidades
Shibboleth. As próximas seções detalham as etapas da implementação.
4.1 IMPLEMENTAÇÃO DA FEDERAÇÃO
No Capítulo 2 foi demonstrado o funcionamento básico do sistema Shibboleth utilizando-se
a federação TestShib. Os softwares e servidores utilizados para constituir esta infra-estrutura foram
implementados de maneira simplificada, apenas para demonstração do ambiente de testes. Na etapa
de desenvolvimento foi constituída a federação InBrazil, uma infra-estrutura própria que não utiliza
servidores de terceiras partes. Os softwares que já haviam sido implementados tiveram seus
arquivos de configuração modificados para que a comunicação entre os servidores ficasse adequada
a esta nova federação. Com o intuito de garantir a segurança do ambiente de produção, alguns
softwares tiveram suas versões atualizadas, como é o caso do software Shibboleth SP que foi
atualizado da versão 1.3.9 para a 1.3.11. Novos softwares foram implementados e adicionados com
o intuito de completar a infra-estrutura da federação InBrazil.
A federação InBrazil foi constituída utilizando-se três servidores com sistema operacional
Linux, IPs válidos, domínio registrado no Registro.br e os nomes dos servidores cadastrados em um
servidor DNS. O Registro.br é o órgão responsável pelo cadastramento e publicação dos domínios
brasileiros. Segundo REGISTRO.BR (2006), “o DNS é uma base de dados hierárquica, distribuída
para a resolução de nomes de domínios em endereços IP e vice-versa”. Estas configurações foram
necessárias para que todos os servidores da federação InBrazil possam interagir na Internet
utilizando nomes de domínios, facilitando o serviço de configuração. A Figura 22 ilustra os
servidores da federação InBrazil.
56
Figura 22. Servidores da federação InBrazil
4.1.1 Servidor Provedor de Identidade
O servidor provedor de identidade é o local onde os usuários fazem autenticação e mantêm
armazenados seus atributos. Neste servidor foram instalados os softwares pré-requisitos para o
funcionamento do software Shibboleth IdP e dos componentes adicionais. O software Shibboleth
IdP e os componentes adicionais completam a infra-estrutura deste servidor. A Tabela 1 mostra o
nome e a versão dos softwares implementados no servidor provedor de identidade da federação
InBrazil.
57
Tabela 1. Softwares do servidor provedor de identidade
Nome Versão Ant 1.6.5 Apache 2.0.53 CGI 1.1 JDK (Java 2 Standard Edition Development Kit) 1.5.0 JK (Jakarta Tomcat Connector) 1.2.15 Linux Slackware 10.2 OpenLDAP 2.3.27 OpenSSL 0.9.7g Oracle Berkeley DB 4.2.52 PHP 5.0.3 PHPLDAPADMIN 1.0.1 Pubcookie 3.3.1 ShARPE 0.7.1 Shibboleth IdP 1.3c Tomcat 5.5.17
Com o objetivo de demonstrar os softwares instalados no provedor de identidade, suas
interações e o processo de funcionamento do software Shibboleth IdP, foi elaborada a Figura 23. O
componente HS (Handle Service) e o componente AA (Attribute Authority) do provedor de
identidade são implementados pelo software Shibboleth IdP, portanto são representados pelo
software Shibboleth IdP. O processo Shibboleth inicia no Passo 1, quando uma requisição
HTTPS/GET na porta 443 proveniente do componente WAYF alcança o Apache, mais
especificamente alcança o diretório SSO (Single Sign-On) configurado no Apache. Este diretório
faz parte da configuração do software Shibboleth IdP e está protegido pelo serviço de autenticação
Pubcookie e para acessá-lo é necessária a autenticação do usuário. Em seguida, o Pubcookie
apresenta ao usuário uma página web com os campos necessários para a digitação de seu login e
password (Passo 2 e 3). Após digitar e enviar as suas credenciais, o Pubcookie checa estas no
serviço de diretório OpenLDAP (Passo 4 e 5). Caso as credenciais estejam corretas, o Pubcookie
invoca a mesma requisição HTTPS/GET na porta 443 que havia chegado ao Apache. Neste
momento, esta requisição consegue alcançar o diretório SSO e consequentemente o Shibboleth IdP
(Passo 6). A partir desta etapa, o Shibboleth IdP cria um handle para identificar a autenticação do
usuário. Este handle é assinado digitalmente e enviado no formato SAML/POST na porta 443 ao
provedor de serviço (Passo 7). Após o provedor de serviço ter validado e ter criado uma sessão para
identificar o handle, é estabelecido um canal SSL entre o provedor de serviço e provedor de
identidade para a troca de mensagens SAML. O provedor de serviço envia uma requisição na porta
58
TCP 8443 ao provedor de identidade, mais especificamente ao Shibboleth IdP para solicitar
atributos do usuário autenticado (Passo 8). O Shibboleth IdP examina o ARP (Attribute Release
Policy), criado com o auxílio da ferramenta ShARPE: se a liberação dos atributos for permitida, o
Shibboleth IdP consulta os atributos do usuário, criados com o auxílio da ferramenta
PHPLDAPADMIN, no serviço de diretório OpenLDAP (Passo 9 e 10) e envia-os para o provedor
de serviço (Passo 11).
Figura 23. Infra-estrutura e funcionamento do servidor provedor de identidade
Fonte: Adaptado de Shibboleth (2006).
59
4.1.1.1 Softwares Pré-Requisitos
O primeiro passo adotado para tornar possível o funcionamento do software Shibboleth IdP
e dos componentes adicionais foi a instalação dos seus softwares pré-requisitos. O primeiro
software pré-requisito instalado foi o sistema operacional Linux Slackware. Este ficou responsável
por garantir segurança e confiabilidade ao ambiente do servidor provedor de identidade. Foi
instalado na modalidade expert, ou seja, um método de instalação que possibilita a seleção de todos
os softwares presentes no CD de instalação.
O segundo software instalado foi o OpenSSL, durante o processo de instalação do sistema
operacional Linux Slackware. Para adicionar suporte SSL aos softwares do provedor de identidade
foi necessário gerar as chaves privada e pública. Este procedimento é apresentado na Figura 24.
openssl genrsa -out shib-idp.dalcoquio.com.br.key 2048
openssl req -new -x509 -nodes -sha1 -days 3650 -key \
shib-idp.dalcoquio.com.br.key > shib-idp.dalcoquio.com.br.crt
Figura 24. Procedimento para gerar as chaves privada e pública
O terceiro software instalado foi o Apache, responsável por processar as requisições HTTP
na porta TCP 80 e HTTPS nas portas TCP 443 e TCP 8443, possibilitando o funcionamento dos
softwares: Shibboleth IdP, PHPLDAPADMIN, Pubcookie e ShARPE. Os procedimentos utilizados
para a instalação do software Apache podem ser identificados na Figura 25.
./configure --enable-so \ --enable-mods-shared=most \ --prefix=/etc/apache \ --enable-ssl \ --with-ssl=/usr/include/openssl make make install
Figura 25. Procedimentos de instalação do software Apache
Após a instalação do software Apache, foi necessário configurá-lo para interagir com o
software OpenSSL. Esta configuração exigiu a alteração de dois arquivos: httpd.conf e ssl.conf. No
arquivo httpd.conf foram adicionados os parâmetros conforme mostra a Figura 26.
60
<IfDefine SSL> LoadModule ssl_module modules/mod_ssl.so </IfDefine> <IfModule mod_ssl.c> Include conf/ssl.conf </IfModule>
Figura 26. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf
No arquivo ssl.conf foram alterados alguns parâmetros para que o Apache processe as
requisições HTTPS nas portas TCP 443 e TCP 8443. A Figura 27 apresenta estas alterações.
Listen 443 Listen 8443 <VirtualHost _default_:443> ServerName shib-idp.dalcoquio.com.br:443 ServerAdmin [email protected] SSLCertificateFile /etc/apache/conf/shib-idp.dalcoquio.com.br.crt SSLCertificateKeyFile /etc/apache/conf/shib-idp.dalcoquio.com.br.key </VirtualHost> <VirtualHost _default_:8443> ServerName shib-idp.dalcoquio.com.br:8443 ServerAdmin [email protected] SSLCertificateFile /etc/apache/conf/shib-idp.dalcoquio.com.br.crt SSLCertificateKeyFile /etc/apache/conf/shib-idp.dalcoquio.com.br.key </VirtualHost>
Figura 27. Parâmetros alterados no arquivo ssl.conf
O quarto software instalado foi o PHP, responsável por interpretar as requisições com
extensão PHP do software PHPLDAPADMIN. O procedimento de instalação do software PHP é
apresentado na Figura 28.
./configure --with-apxs2=/etc/apache/bin/apxs \ --prefix=/etc/apache/php5 \ --with-config-file-path=/etc \ --with-ldap \ --with-gettext=/usr/lib/gettext make make install
Figura 28. Procedimento de instalação do software PHP
Após a instalação do software PHP, foi necessário configurá-lo para interagir com o
software Apache. Esta configuração exigiu a alteração de alguns parâmetros do arquivo httpd.conf.
A Figura 29 mostra estas alterações.
61
LoadModule php5_module modules/libphp5.so DirectoryIndex index.html index.html.var index.php AddType application/x-httpd-php .php
Figura 29. Parâmetros do software PHP alterados no arquivo httpd.conf
O quinto software instalado foi o CGI, responsável por interpretar as requisições com
extensão CGI do software Pubcookie. O software CGI foi instalado durante o processo de
instalação do software Apache. Para adicionar suporte CGI ao software Apache foi necessário a
alteração de alguns parâmetros do arquivo httpd.conf. Estas alterações são apresentadas na Figura
30.
LoadModule cgi_module modules/mod_cgi.so Options Indexes FollowSymLinks ExecCGI DirectoryIndex index.html index.html.var index.php index.cgi ScriptAlias /cgi-bin/ "/etc/apache/cgi-bin/" <Directory "/etc/apache/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> AddHandler cgi-script .cgi
Figura 30. Parâmetros do softtware CGI alterados no arquivo httpd.conf
O sexto software instalado e configurado foi o Tomcat, responsável por interpretar as
requisições dos softwares desenvolvidos em Java, ou seja, executar os softwares: Shibboleth IdP e
ShARPE. A instalação e configuração do software Tomcat é simplificada, pois foi necessário
apenas descompactar o seu pacote de instalação. A Figura 31 mostra este procedimento.
tar –zxvf /var/tomcat-5.5.17/apache-tomcat-5.5.17/apache-tomcat-5.5.17.tar.gz
Figura 31. Procedimento de instalação do software Tomcat
O sétimo software instalado foi o JDK. O JDK é um ambiente de desenvolvimento e
execução de aplicações Java, responsável por fornecer ao software Ant, Shibboleth IdP e Tomcat,
ferramentas e bibliotecas necessárias para a sua execução. A instalação e configuração do software
JDK é simplificada, pois o seu pacote de instalação traz os arquivos compilados e prontos para
execução. A Figura 32 apresenta o procedimento de instalação e configuração do software JDK.
62
ksh /var/jdk-1.5.0/jdk-1_5_0_08-linux-i586.bin
Figura 32. Procedimento de instalação do software JDK
O oitavo software instalado foi o Ant. O Ant é uma ferramenta utilizada para automatizar a
construção do software, similar ao tradicional make, mas escrito na linguagem Java. Outra diferença
entre o software Ant e o make deve-se ao fato de que o Ant é independente de plataforma ou
sistema operacional, já que utiliza seus próprios comandos para a construção do software, enquanto
o make utiliza comandos do sistema operacional (ANT, 2006). O software Ant ficou responsável
por fornecer ferramentas para a construção e instalação dos softwares: ShARPE e Shibboleth IdP.
Os procedimentos adotados para a instalação do software Ant são mostrados na Figura 33.
export ANT_HOME=/usr/local/ant export JAVA_HOME=/var/jdk-1.5.0/jdk1.5.0_08 export PATH=$PATH:$ANT_HOME/bin /var/ant-1.6.5/apache-ant-1.6.5/build.sh
Figura 33. Procedimentos de instalação do software Ant
O nono software instalado e configurado foi o Jakarta Tomcat Connector, este ficou
responsável por fazer o controle da comunicação entre o Tomcat e o Apache. Todas as requisições
HTTP e HTTPS são recebidas pelo Apache, sendo que aquelas com código Java são redirecionadas
ao interpretador do Tomcat e as com código HTML, PHP e CGI são tratadas pelo interpretador do
Apache. Os procedimentos de instalação do software Jakarta Tomcat Connector são identificados
na Figura 34.
./configure --with-apxs=/etc/apache/bin/apxs make make install
Figura 34. Procedimentos de instalação do software Jakarta Tomcat Connector
Após a instalação do software JK (Jakarta Tomcat Connector), foi necessário configurá-lo
para interagir com os softwares: Apache e Tomcat. Esta configuração exigiu a alteração de três
arquivos: workers.properties, httpd.conf e server.xml O arquivo workers.properties ficou
configurado conforme apresenta a Figura 35.
63
worker.list= ajp13 workers.tomcat_home=/var/tomcat-5.5.17/apache-tomcat-5.5.17 workers.java_home=/var/jdk-1.5.0/jdk1.5.0_08 ps=/ worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.lbfactor=50 worker.ajp13.cachesize=10 worker.ajp13.cache_timeout=600 worker.ajp13.socket_keepalive=1 worker.ajp13.recycle_timeout=300
Figura 35. Arquivo workers.properties
No arquivo httpd.conf do software Apache foram alterados alguns parâmetros para que o
Apache possa interagir com o software Jakarta Tomcat Connector. A Figura 36 apresenta estas
alterações.
<IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so </IfModule> JkWorkersFile /var/jk-1.2.15/jakarta-tomcat-connectors-1.2.15\src/jk/conf/workers.properties JkLogFile /etc/apache/logs/mod_jk.log JkLogLevel debug
Figura 36. Parâmetros do software JK adicionados ao arquivo httpd.conf
No arquivo server.xml do software Tomcat foi alterado a tag Connector para que o Tomcat
possa interagir com o software Jakarta Tomcat Connector. A Figura 37 apresenta estas alterações.
<Connector port="8009" address="127.0.0.1" tomcatAuthentication="false" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
Figura 37. Parâmetros do software JK alterados no arquivo server.xml
O décimo e último software pré-requisito instalado foi o Oracle Berkeley DB. O Oracle
Berkeley DB é um banco de dados open source que permite alto desempenho e integração com o
software OpenLDAP (ORACLE, 2006). Este ficou responsável por interagir com o software
OpenLDAP para realizar o armazenamento dos atributos dos usuários. O procedimento adotado
para a instalação do software Oracle Berkeley DB é apresentado na Figura 38.
64
cd /var/db-4.2.52/db-4.2.52.NC/build_unix ../dist/configure make make install
Figura 38. Procedimento de instalação do software Oracle Berkeley DB
4.1.1.2 Software Shibboleth IdP
O software Shibboleth IdP é o responsável pela troca de mensagens SAML com o servidor
provedor de serviço e pelo controle da liberação dos atributos dos usuários. Após a instalação dos
softwares pré-requisitos foi possível iniciar a instalação do software Shibboleth IdP. A instalação
inicia com a cópia de alguns arquivos JAR (Java Archive), usados pelo software Shibboleth IdP,
para a pasta do software Tomcat. Este procedimento é apresentado na Figura 39.
cp /var/shibboleth-idp-1.3c-install/endorsed/*.jar /var/tomcat-5.5.17/apache-tomcat-5.5.17/common/endorsed/
Figura 39. Procedimento inicial de instalação do software Shibboleth IdP
O segundo procedimento adotado foi executar o software Ant para construir e instalar o
software Shibboleth IdP. Este procedimento é mostrado na Figura 40.
cd /var/shibboleth-idp-1.3c-install ./ant
Figura 40. Procedimento de instalação do software Shibboleth IdP
Após a instalação, a localização dos arquivos de configuração do software Shibboleth IdP é
apresentada na Figura 41.
/usr/local/shibboleth-idp/etc
Figura 41. Localização dos arquivos de configuração do software Shibboleth IdP
65
Já a localização do arquivo WAR (Web Archive File) do software Shibboleth IdP é
apresentada na Figura 42. O arquivo WAR fica localizado no diretório do software Tomcat e indica
que o software Shibboleth IdP foi agrupado em único arquivo e está instalado.
/var/tomcat-5.5.17/apache-tomcat-5.5.17/webapps
Figura 42. Localização do arquivo WAR do software Shibboleth IdP
O terceiro procedimento adotado foi a criação do arquivo inbrazil-metadata.xml. Este
arquivo é responsável por prover a base de confiança entre os provedores envolvidos na federação
Shibboleth. Por exemplo, quando um provedor de serviço recebe uma requisição de um provedor de
identidade, o provedor de serviço precisa verificar se o provedor de identidade é realmente quem
diz ser. Isto é feito comparando informações da mensagem SAML recebida com informações
contidas no arquivo de metadata. Quando há uma comparação, o provedor de identidade deve
apresentar as credenciais contidas no arquivo de metadata do provedor de serviço. Se as credenciais
coincidirem, a comunicação entre os provedores é estabelecida, caso contrário nenhum atributo será
enviado (SHIBBOLETH, 2006). O Apêndice A apresenta o arquivo de metadata criado para a
federação InBrazil.
O quarto procedimento adotado foi a configuração dos arquivos do software Shibboleth IdP.
Esta configuração exigiu a alteração de cinco arquivos: idp.xml, arp.site.xml, resolver.xml,
httpd.conf e ssl.conf.
O arquivo idp.xml é o local de configuração primária do software Shibboleth IdP. A Figura
43 presenta uma parte do arquivo idp.xml, mais especificamente a tag IdPConfig com os
parâmetros configurados conforme a necessidade da federação InBrazil. No parâmetro AAUrl foi
configurado a URL do AA (Attribute Authority) do provedor de identidade. No parâmetro
resolverConfig foi configurado a localização do arquivo resolver.xml. Em seguida, no parâmetro
defaultRelyingParty foi configurado o endereço da federação InBrazil. Este parâmetro é utilizado
para especificar uma ou mais RelyingParty ou partes confiáveis (servidores, aplicações ou
federações) em que o provedor de identidade confia para estabelecer uma comunicação segura.
Finalmente, no parâmetro providerId foi configurado a URL do provedor de identidade.
66
<IdPConfig xmlns="urn:mace:shibboleth:idp:config:1.0" xmlns:cred="urn:mace:shibboleth:credentials:1.0" xmlns:name="urn:mace:shibboleth:namemapper:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd" AAUrl="https://shib-idp.dalcoquio.com.br:8443/shibboleth-idp/AA" resolverConfig="file:/usr/local/shibboleth-idp/etc/resolver.xml" defaultRelyingParty="urn:mace:dalcoquio.com.br:inbrazil" providerId="https://shib-idp.dalcoquio.com.br/shibboleth/inbrazil/idp">
Figura 43. Configuração da tag IdPConfig no arquivo idp.xml
Após configurar a tag IdPConfig, foram especificados os parâmetros das tags RelyingParty,
FileResolver, Path e MetadaProvider, conforme apresenta a Figura 44. Na tag RelyingParty foi
configurado o parâmetro name com o endereço da federação InBrazil e o parâmetro
signingCredential, este parâmetro referencia as chaves privada e pública que serão utilizadas pelo
provedor de identidade da federação InBrazil. Em seguida, na tag FileResolver foi configurado o
parâmetro Id que referencia o provedor de identidade da federação InBrazil. Nas tags Path foram
configuradas as localizações das chaves privada e pública do provedor de identidade InBrazil.
Finalmente, na tag MetadataProvider parâmetro uri foi especificado a localização do arquivo de
metadata.
<RelyingParty name="urn:mace:dalcoquio.com.br:inbrazil" signingCredential="inbrazil_cred"> <NameID nameMapping="shm"/> </RelyingParty> <Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="inbrazil_cred"> <Key> <Path>file:/etc/apache/conf/shib-idp.dalcoquio.com.br.key</Path> </Key> <Certificate> <Path>file:/etc/apache/conf/shib-idp.dalcoquio.com.br.crt</Path> </Certificate> </FileResolver> </Credentials> <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata "uri="file:/usr/local/shibboleth-idp/etc/inbrazil-metadata.xml"/>
Figura 44. Configuração das tags do arquivo idp.xml
O arquivo arp.site.xml é o local de configuração das ARPs (Attribute Release Policy), ou
seja, das regras de liberação dos atributos dos usuários. A Figura 45 mostra o arquivo arp.site.xml,
67
suas tags e os parâmetros especificados conforme a necessidade da federação InBrazil. Na tag rule
iniciou-se uma nova ARP para a aplicação protegida pelo Shibboleth. Na tag Description foi
especificada uma descrição para identificar a regra. Na tag Requester foi configurada a URL do
servidor provedor de serviço, ou seja, a URL do provedor de serviço que está autorizado a receber
os atributos dos usuários. Em seguida, na tag Attribute foi configurado o parâmetro name que
especifica qual atributo pode ser liberado para o provedor de serviço contido na tag Requester.
Finalmente, a tag AnyValue parâmetro release=”permit” define que todos os valores contidos no
atributo definido na tag Attribute parâmetro name serão liberados.
<?xml version="1.0" encoding="UTF-8"?> <AttributeReleasePolicy xmlns="urn:mace:shibboleth:arp:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd"> <Rule> <Description>Aplicacao Protegida pelo Shibboleth</Description> <Target> <Requester>https://shib- sp.dalcoquio.com.br/shibboleth/inbrazil/sp</Requester> <AnyResource/> </Target> <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation"> <AnyValue release="permit"/> </Attribute> </Rule> </AttributeReleasePolicy>
Figura 45. Arquivo arp.site.xml
O resolver.xml é o arquivo de configuração da conexão do softtware Shibboleth IdP com o
serviço de diretório, bem como da definição dos atributos que serão pesquisados. A Figura 46
apresenta uma parte do arquivo resolver.xml. Na tag SimpleAttributeDefinition foi configurado o
parâmetro id, especificando o atributo que será pesquisado. Na tag DataConnectorDependency foi
configurado o parâmetro requires com o nome do conector de acesso ao serviço de diretório que
será utilizado para pesquisar o atributo definido na tag SimpleAttributeDefinition parâmetro id. Em
seguida, na tag JNDIDirectoryDataConnector iniciou-se a definição do conector de acesso ao
serviço de diretório. No parâmetro id da tag JNDIDirectoryDataConnector foi especificado o nome
do conector de acesso ao serviço de diretório. Na tag Search foi especificado o parâmetro filter com
o filtro da pesquisa, neste caso, o uid (login do usuário). Finalmente, nas tags Property foram
especificados os parâmetros value com as configurações de conexão ao serviço de diretório.
68
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation"> <DataConnectorDependency requires="directory"/> </SimpleAttributeDefinition> <JNDIDirectoryDataConnector id="directory"> <Search filter="uid=%PRINCIPAL%"> <Controls returningObjects="false" searchScope="SUBTREE_SCOPE"/> </Search> <Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <Property name="java.naming.provider.url" value="ldap://shib- idp.dalcoquio.com.br/ou=inbrazil,dc=dalcoquio,dc=com,dc=br"/> <Property name="java.naming.security.principal" value="cn=Manager,dc=dalcoquio,dc=com,dc=br"/> <Property name="java.naming.security.credentials" value="password"/> </JNDIDirectoryDataConnector>
Figura 46. Configuração das tags do arquivo resolver.xml
No arquivo httpd.conf do Apache foi necessário inserir um parâmetro para que o Apache
redirecione as requisições destinadas ao software Shibboleth IdP ao interpretador do Tomcat. Esta
alteração é mostrada na Figura 47.
JkMount /shibboleth-idp/* ajp13
Figura 47. Parâmetro adicionado ao arquivo httpd.conf
Finalmente, o arquivo ssl.conf do software Apache é o local onde são configurados os
parâmetros que controlam as requisições HTTPS. A Figura 48 apresenta os parâmetros adicionados
ao arquivo ssl.conf para que o Apache possa interagir com o software Shibboleth IdP.
<VirtualHost _default_:443> <Location /shibboleth-idp/SSO> require valid-user </Location> </VirtualHost> <VirtualHost _default_:8443> <Location /shibboleth-idp/AA> SSLOptions +StdEnvVars +ExportCertData </Location> </VirtualHost>
Figura 48. Parâmetros adicionados ao arquivo ssl.conf
69
4.1.1.3 Componentes Adicionais
Os componentes adicionais foram instalados com a finalidade de completar a infra-estrutura
do servidor provedor de identidade. Estes componentes adicionais são: o Pubcookie, o OpenLDAP,
o PHPLDAPADMIN e o ShARPE.
O Pubcookie forneceu à infra-estrutura do servidor provedor de identidade um mecanismo
de autenticação única que interage com o serviço de diretórios OpenLDAP para checar as
credencias dos usuários. O Pubcookie utiliza a tecnologia CGI, portanto foi armazenado no servidor
Apache com suporte a tecnologia CGI. Para a correta integração do Pubcookie com os softwares:
Apache, Shibboleth IdP e OpenLDAP, foram seguidas as etapas de instalação conforme mostra a
Figura 49.
./configure --enable-login \ --prefix=/usr/local/pubcookie \ --enable-apache \ --enable-ldap \ --with-apxs=/etc/apache/bin/apxs \ --with-ssl=/usr/include/openssl make make install
Figura 49. Instalação do Pubcookie
A configuração do Pubcookie exigiu a alteração de três arquivos: config, httpd.conf e
ssl.conf. O arquivo config ficou configurado conforme mostra a Figura 50. Nos parâmetros
basic_verifier e ldap_uri foram especificados, respectivamente, o tipo de conexão e o endereço para
conexão ao serviço de diretórios OpenLDAP. Nos parâmetros ssl_key_file, ssl_cert_file,
granting_key_file e granting_cert_file foram especificadas as chaves privada e pública do Apache e
do Pubcookie. Estas configurações tornam-se necessárias para que o Pubcookie possa interagir com
o Apache de forma segura. Em seguida, nos parâmetros login_uri, login_host e enterprise_domain
foram configurados os endereços que serão utilizados para conexão do browser do usuário ao
Pubcookie. No parâmetro keymgt_uri foi configurado a URL e a porta que serão utilizadas pelo
Apache para trocar informações de segurança com o Pubcookie. No parâmetro keyserver_client_list
foi definido o nome do servidor que poderá comunicar de forma segura com o Pubcookie.
Finalmente, nos parâmetros default_l_expire e form_expire_time foram definidos, respectivamente,
o tempo de expiração da sessão de autenticação do usuário e o tempo de expiração da página web
de autenticação.
70
basic_verifier: ldap ldap_uri: ldap://shib-idp.dalcoquio.com.br/ou=inbrazil%2cdc=dalcoquio%2cdc=com%2cdc=br???(uid=%s)?x-BindDN=cn=Manager%2cdc=dalcoquio%2cdc=com%2cdc=br,x-Password=secret ssl_key_file: /etc/apache/conf/shib-idp.dalcoquio.com.br.key ssl_cert_file: /etc/apache/conf/shib-idp.dalcoquio.com.br.crt granting_key_file: /usr/local/pubcookie/keys/pubcookie_granting.key granting_cert_file: /usr/local/pubcookie/keys/pubcookie_granting.crt login_uri: https://shib-idp.dalcoquio.com.br/cgi-bin/login/index.cgi login_host: shib-idp.dalcoquio.com.br enterprise_domain: .dalcoquio.com.br keymgt_uri: https://shib-idp.dalcoquio.com.br:2222 keyserver_client_list: shib-idp.dalcoquio.com.br default_l_expire: 8h form_expire_time: 120
Figura 50. Arquivo config do Pubcookie
No arquivo httpd.conf do Apache foram adicionados alguns parâmetros para que o Apache
possa interagir com o Pubcokie. A Figura 51 apresenta estas alterações.
LoadModule pubcookie_module modules/mod_pubcookie.so <IfModule mod_pubcookie.c> PubcookieAuthTypeNames Pubcookie PubcookieGrantingCertFile /usr/local/pubcookie/keys/pubcookie_granting.crt PubcookieSessionKeyFile /etc/apache/conf/shib-idp.dalcoquio.com.br.key PubcookieSessionCertFile /etc/apache/conf/shib-idp.dalcoquio.com.br.crt PubcookieLogin https://shib-idp.dalcoquio.com.br/cgi-bin/login/index.cgi PubcookieDomain .dalcoquio.com.br PubcookieKeyDir /usr/local/pubcookie/keys/ PubcookieLoginMethod POST PubcookieEncryption AES </IfModule>
Figura 51. Parâmetros do Pubcookie adicionados no arquivo httpd.conf
Finalmente, no aquivo ssl.conf do Apache foi adicionado o parâmetro AuthType com o tipo
de autenticação a ser utilizada para acessar o diretório SSO. A Figura 52 mostra esta alteração.
<VirtualHost _default_:443> <Location /shibboleth-idp/SSO> AuthType Pubcookie require valid-user </Location> </VirtualHost>
Figura 52. Parâmetro do Pubcookie adicionado ao arquivo ssl.conf
O segundo componente adicional instalado foi o OpenLDAP. O OpenLDAP juntamente
com o software Oracle Berkeley DB ficaram responsáveis pelo armazenamento das credenciais e
71
atributos dos usuários. O procedimento adotado para a instalação do OpenLDAP é identificado na
Figura 53.
export CPPFLAGS=-I/usr/local/BerkeleyDB.4.2/include export LDFLAGS=-L/usr/local/BerkeleyDB.4.2/lib ./configure --enable-wrappers \ --enable-monitor \ --enable-spasswd \ --enable-passwd \ --enable-crypt \ --enable-lmpasswd \ --with-threads \ --enable-dynamic make make install
Figura 53. Procedimento de instalação do OpenLDAP
A configuração do OpenLDAP exigiu a criação de dois arquivos: o slapd.conf e o ldap.conf.
O arquivo slapd.conf ficou configurado conforme mostra a Figura 54. No parâmetro include foram
definidas as classes que serão utilizadas pelo OpenLDAP para definir o nome dos atributos dos
usuários, tais como, a classe EduPerson. No parâmetro password-hash foi definido o tipo da função
hashing utilizada para gerar a senha do usuário. Neste caso, a função hashing foi utilizada para
impedir que a senha do usuário seja gravada no formato plaintext (texto claro). Em seguida, no
parâmetro database foi definido o banco de dados utilizado pelo OpenLDAP, neste caso o bdb ou
Oracle Berkeley DB. No parâmetro suffix foi configurado o nome do diretório ou o primeiro nível
na hierarquia do serviço de diretório. Nos parâmetros rootdn e rootpw foram configurados,
respectivamente, o nome do administrador do serviço de diretório e a senha do administrador. No
parâmetro directory foi definido o local de armazenamento da base de dados. Finalmente, no
parâmetro index foram definidos dois índices para agilizar as consultas nos diretórios.
72
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/eduperson.schema password-hash {SSHA} database bdb suffix "dc=dalcoquio,dc=com,dc=br" rootdn "cn=Manager,dc=dalcoquio,dc=com,dc=br" rootpw {SSHA}1UF/Y84HpR5ZGt0VzI0I5GXj9taim4I+ directory /usr/local/var/openldap-data index objectClass,uid eq
Figura 54. Arquivo slapd.conf do OpenLDAP
O arquivo ldap.conf ficou configurado conforme apresenta a Figura 55. No parâmetro base
foi definido o nome do diretório ou o primeiro nível na hierarquia do serviço de diretório. No
parâmetro host foi definido o IP onde se encontra o serviço de diretório. Finalmente, no parâmetro
ssl foi configurado suporte ao protocolo SSL.
base dc=dalcoquio,dc=com,dc=br host 127.0.0.1 ssl yes
Figura 55. Arquivo ldap.conf do OpenLDAP
Após a configuração dos arquivos do OpenLDAP, foi necessário iniciar a criação da
hierarquia ou das entradas no serviço de diretório. Para criar o primeiro nível da hierarquia foi
necessário gerar o arquivo primeironivel.ldif, o conteúdo deste arquivo é apresentado na Figura 56.
No parâmetro dn foi definido o nome da primeira entrada no serviço de diretório. Nos parâmetros
objectClass foram configuradas as classes de atributos utilizadas para definir os atributos deste
primeiro nível. Nos parâmetros o e dc foram definidas descrições para este primeiro nível.
dn: dc=dalcoquio,dc=com,dc=br objectClass: dcObject objectClass: organization o: Federacao InBrazil dc: dalcoquio
Figura 56. Arquivo primeironivel.ldif
Finalmente, após criar o arquivo primeironivel.ldif foi possível importá-lo para o serviço de
diretórios OpenLDAP. A Figura 57 apresenta este procedimento.
73
ldapadd -x -D "cn=Manager,dc=dalcoquio,dc=com,dc=br" -W -f primeironivel.ldif
Figura 57. Procedimento de importação do arquivo primeironivel.ldif
O terceiro componente adicional instalado foi o PHPLDAPADMIN. O PHPLDAPADMIN
faz a interação com o OpenLDAP para fornecer uma interface web de cadastramento das entradas
no serviço de diretório, tais como, cadastramento das organizações, dos grupos e dos usuários. O
PHPLDAPADMIN utiliza a linguagem PHP, portanto foi armazenado no servidor Apache com
suporte a linguagem PHP. O procedimento de instalação do PHPLDAPADMIN é simplificado, já
que foi necessário apenas descompactar o seu pacote de instalação e movê-lo para o diretório do
servidor Apache. A Figura 58 apresenta este procedimento.
tar -zxvf /var/phpldapadmin-1.0.1/phpldapadmin-1.0.1.tar.gz cp –pr /var/phpldapadmin-1.0.1/phpldapadmin-1.0.1 /etc/apache/htdocs/ldap
Figura 58. Procedimento de instalação do PHPLDAPADMIN
Após a instalação do PHPLDAPADMIN, foi necessário configurá-lo para interagir com o
OpenLDAP. Esta configuração exigiu a alteração de algumas variáveis do arquivo config.php. A
Figura 59 apresenta as variáveis alteradas neste arquivo. Estas variáveis foram definidas com as
configurações necessárias para conexão ao serviço de diretório OpenLDAP, tais como, nome do
diretório, nome do administrador do diretório e nome do grupo onde encontram-se os usuários.
$ldapservers->SetValue($i,'server','base',array('dc=dalcoquio,dc=com,dc=br')); $ldapservers->SetValue($i,'login','dn','cn=Manager,dc=dalcoquio,dc=com,dc=br'); $ldapservers-> SetValue($i,'auto_number','search_base','ou=inbrazil,dc=dalcoquio,dc=com,dc=br'); $ldapservers->SetValue($i,'server','name','InBrazil LDAP Server'); $queries[$q]['base'] = 'dc=dalcoquio,dc=com,dc=br';
Figura 59. Parâmetros alterados no arquivo config.php
A Figura 60 apresenta a tela inicial do PHPLDAPADMIN. Nesta tela foi realizada a
autenticação do usuário administrador do diretório, ou seja, do usuário “Manager”.
74
Figura 60. Tela de autenticação do PHPLDAPADMIN
A Figura 61 apresenta a tela do PHPLDAPADMIN para a criação do grupo inbrazil. Este
grupo foi utilizado para armazenar os usuários da federação InBrazil. Na hierarquia do OpenLDAP,
o grupo inbrazil ficou subordinado ao domínio dalcoquio.com.br.
Figura 61. Tela de criação do grupo inbrazil
75
A Figura 62 apresenta a tela do PHPLDAPADMIN para a criação do usuário
“andre.cordova”. Nesta tela foi definido o nome completo do usuário e as classes de atributos que
serão utilizadas para definir os atributos do usuário, dentre elas, a classe EduPerson. Na hierarquia
do OpenLDAP, os usuários da federação InBrazil ficaram subordinados ao grupo inbrazil.
Figura 62. Tela de criação do usuário “andre.cordova”
76
Finalmente, a Figura 63 apresenta a tela de criação dos atributos do usuário
“andre.cordova”. Estes atributos foram definidos com base nas classes de atributos especificadas na
Figura 62. Os atributos criados foram: cn (nome completo do usuário), givenName (primeiro nome
do usuário), sn (segundo nome do usuário), uid (login do usuário), userPassword (senha do
usuário) e eduPersonAffiliation (grupo do usuário).
Figura 63. Tela de criação dos atributos do usuário “andre.cordova”
O quarto e último componente adicional instalado no servidor provedor de identidade foi o
ShARPE. O ShARPE é dividido em dois componentes: o SharpeCore e o WebSharpe. O
componente SharpeCore ficou responsável por acessar e manipular os arquivos resolver.xml e
arp.site.xml do software Shibboleth IdP. Já o componente WebSharpe é composto por três
ferramentas: SPDescription, ShARPE e Autograph. O SPDescription disponibiliza uma interface
web aos administradores do provedor de identidade. Esta interface é utilizada para a criação de um
arquivo XML que contenha as informações necessárias para acesso à aplicação que está instalada
no provedor de serviço. Por exemplo, o nome da aplicação e os atributos necessários para acessar
esta aplicação. O ShARPE ficou responsável por disponibilizar aos administradores do provedor de
identidade uma interface web que faça a importação do arquivo XML gerado pelo SPDescription. A
partir deste arquivo são criados contratos de comunicação que associam os atributos necessários
77
para acessar a aplicação com os atributos dos usuários do provedor de identidade. Finalmente, o
Autograph disponibiliza uma interface web para que os usuários possam fazer o controle da
liberação de seus atributos. Mesmo após a criação de um contrato de comunicação, o usuário pode
cancelar a liberação de um determinado atributo, como conseqüência poderá não ter acesso à
aplicação. Como o ShARPE foi desenvolvido utilizando-se a linguagem Java, o mesmo foi
instalado no servidor Tomcat.
A instalação do ShARPE inicia com a alteração dos arquivos build.xml e extension-
build.xml, ambos encontrados no diretório de instalação do software Shibboleth IdP. Nestes
arquivos foi necessário substituir a tag javac parâmetro source de 1.4 para 1.5. Em seguida, para a
construção e instalação do ShARPE foi utilizado o software Ant, conforme mostra a Figura 64.
cd /var/sharpe-0.7.1/Autograph_ShARPE /var/ant-1.6.5/apache-ant-1.6.5/bin/ant
Figura 64. Procedimento de instalação do ShARPE
Após a instalação do ShARPE, foi necessário configurá-lo para interagir com o Shibboleth
IdP. Esta configuração exigiu a alteração de dois arquivos: idp.xml e httpd.conf. No arquivo
idp.xml do Shibboleth IdP foi necessário excluir a tag ReleasePolicyEngine e substituir pelas tags e
parâmetros mostrados na Figura 65. Esta alteração foi necessária para que o ShARPE possa
manipular os arquivos do Shibboleth IdP que contém as AAPs ou as regras de liberação dos
atributos dos usuários.
78
<ReleasePolicyEngine> <ArpRepository implementation= "au.edu.mq.melcoe.mams.sharpe.shib.aa.arp.provider. MAMSFileSystemArpRepository"> <Path>/usr/local/shibboleth-idp/etc/arps/</Path> <GroupLookup implementation= "au.edu.mq.melcoe.mams.sharpe.shib.aa.arp.group.provider. AttributeResolverGroupLookup"> <UserGroup>urn:mace:dir:attribute-def:eduPersonAffiliation</UserGroup> </GroupLookup> <GroupLookup implementation= "au.edu.mq.melcoe.mams.sharpe.shib.aa.arp.group.provider. PropertyFileGroupLookup" separator="%PRINCIPAL%."> <PropertyFile>/usr/local/shibboleth- idp/etc/sample.grouplookup.properties</PropertyFile> <GroupListing>institutionalGroupList</GroupListing> <GroupListing>groupList</GroupListing> </GroupLookup> </ArpRepository> </ReleasePolicyEngine>
Figura 65. Configurações adicionadas no arquivo resolver.xml
No arquivo httpd.conf do Apache foi necessário inserir alguns parâmetros para que o
Apache redirecione as requisições destinadas aos componentes ShARPE, SPDescription e
Autograph para serem tratadas pelo interpretador do Tomcat. Esta alteração é apresentada na Figura
66.
JkMount /SPDescription/* ajp13 JkMount /ShARPE/* ajp13 JkMount /Autograph/* ajp13
Figura 66. Parâmetros do ShARPE adicionados ao arquivo httpd.conf
79
A Figura 67 apresenta a única tela do componente SPDescription. Nela foi realizada uma
descrição da aplicação protegida pelo Shibboleth, tais como, a URL da aplicação e os atributos
necessários para acessá-la.
Figura 67. Tela do componente SPDescription
80
A Figura 68 apresenta a tela de upload do componente ShARPE. Nela foi realizada a
importação do arquivo XML gerado pelo componente SPDescription.
Figura 68. Tela de upload do componente ShARPE
81
A Figura 69 apresenta a tela dos contratos do componente ShARPE. Nela foi criado um
contrato entre a aplicação protegida pelo Shibboleth e o provedor de identidade. Neste contrato são
apresentados os atributos necessários para acessar a aplicação, bem como os atributos que serão
liberados pelo provedor de identidade.
Figura 69. Tela dos contratos do componente ShARPE
82
A Figura 70 apresenta uma tela do componente Autograph. Nela foi realizada a liberação do
atributo eduPersonAffiliation do usuário “andre.cordova”, este atributo é necessário para acessar a
área de upload da aplicação protegida pelo Shibboleth. Quando o usuário “andre.cordova” acessou
pela primeira vez o componente Autograph foi criado o arquivo arp.user.andre.cordova.xml. Neste
arquivo foram definidas as ARPs ou as regras de liberação dos atributos do usuário. O novo arquivo
atuará como principal nas decisões de liberação dos atributos do usuário “andre.cordova”. O
arquivo arp.site.xml fica como secundário, somente atuará nas decisões de liberação dos atributos
do usuário na falta do arquivo arp.user.andre.cordova.xml.
Figura 70. Tela do componente Autograph, liberando um atributo
83
A Figura 71 apresenta uma tela do componente Autograph. Nela foi realizado o bloqueio do
atributo eduPersonAffiliation do usuário “andre.cordova”. Neste caso o provedor de serviço não
receberá o atributo eduPersonAffiliation do usuário, consequentemente o usuário não terá acesso a
área de upload da aplicação protegida pelo Shibboleth.
Figura 71. Tela do componente Autograph, bloqueando um atributo
4.1.2 Servidor Provedor de Serviço
O servidor provedor de serviço é o local de instalação das aplicações protegidas pelo
Shibboleth. Neste servidor foram instalados os softwares pré-requisitos para o funcionamento do
software Shibboleth SP e do componente adicional RM (Resource Manager – Gerenciador de
Recurso). O software Shibboleth SP e o componente adicional RM completam a infra-estrutura
deste servidor. A Tabela 2 mostra o nome e a versão dos softwares instalados no servidor provedor
de serviço da federação InBrazil.
84
Tabela 2. Softwares do servidor provedor de serviço
Nome Versão Apache 2.2.2 Linux Fedora 5 MySQL 5.0.22 OpenSSL 0.9.8a PHP 5.1.4 Shibboleth SP 1.3.11
Com o objetivo de demonstrar os softwares instalados no provedor de serviço, suas
interações e o processo de funcionamento do software Shibboleth SP, foi elaborada a Figura 72. O
software Shibboleth SP foi dividido em dois componentes: Shibboleth SP module e Shibboleth SP
daemon. O primeiro componente fica instalado no servidor Apache e o segundo componente é
executado em background, como um processo do sistema operacional Linux Fedora. O componente
ACS (Assertion Consumer Service) foi implementado pelo Shibboleth SP module e o componente
AR (Attribute Requester) foi implementado pelo Shibboleth SP daemon. O processo Shibboleth
inicia no Passo 1, quando uma requisição HTTPS/GET na porta 443 do browser do usuário alcança
o componente Shibboleth SP module, mais especificamente o diretório onde está instalada a
aplicação protegida pelo Shibboleth. Como este diretório está protegido pelo Shibboleth, para
acessá-lo é necessário que o usuário esteja autenticado e que um ou mais dos seus atributos sejam
liberados ao provedor de serviço. Neste caso, como o usuário não está autenticado, o mesmo será
redirecionado ao componente WAYF (Passo 2). Após o usuário: selecionar o seu provedor de
identidade; ser redirecionado para o provedor de identidade escolhido; realizar autenticação; e o
Shibboleth IdP ter criado um handle para identificar a autenticação do usuário, este handle é
recebido pelo provedor de serviço (Passo 3). O handle é recebido no formato SAML/POST na porta
443. Em seguida, o componente Shibboleth SP module verifica a assinatura digital do handle e cria
uma sessão para identificá-lo. Através desta sessão o componente shibboleth SP daemon requisita
ao provedor de identidade pela porta TCP 8443 os atributos do usuário necessários para acessar a
aplicação (Passo 4). Esta solicitação e recebimento de atributos são realizados através de mensagens
SAML protegidas por um canal SSL. Caso a liberação dos atributos do usuário for permitida no
provedor de identidade, o provedor de serviço recebe os atributos. Estes atributos passam pelas
AAPs (Attribute Acceptance Police) ou pelas regras de aceitação de atributos. Se forem aceitos, são
repassados ao componente Shibboleth SP module. Este componente executa o primeiro nível do
controle de acesso. Caso o componente Shibboleth SP module autorize o acesso ao diretório, os
85
atributos são repassados ao RM (Resource Manager – Gerenciador de Recurso). O RM utiliza estes
atributos para fazer o segundo nível do controle de acesso e finalmente decidir quais funções da
aplicação o usuário poderá visualizar (Passo 5). A aplicação é apresentada ao usuário (Passo 6).
Figura 72. Infra-estrutura e funcionamento do servidor provedor de serviço
Fonte: Adaptado de Shibboleth (2006).
4.1.2.1 Softwares Pré-Requisitos
O primeiro passo adotado para tornar possível o funcionamento do software Shibboleth SP e
do componente adicional RM foi a instalação dos seus softwares pré-requisitos. O primeiro
software pré-requisito instalado foi o sistema operacional Linux Fedora, este ficou responsável por
garantir segurança e confiabilidade ao ambiente do servidor provedor de serviço.
O segundo software implementado foi o OpenSSL, foi instalado durante o processo de
instalação do sistema operacional Linux Fedora. Para adicionar suporte SSL aos softwares do
provedor de serviço foi necessário gerar as chaves privada e pública Este procedimento é
apresentado na Figura 73.
86
openssl genrsa -out shib-sp.dalcoquio.com.br.key 2048
openssl req -new -x509 -nodes -sha1 -days 3650 -key \
shib-sp.dalcoquio.com.br.key > shib-sp.dalcoquio.com.br.crt
Figura 73. Procedimento para gerar as chaves privada e pública
O terceiro software instalado foi o Apache, este ficou responsável por processar as
requisições HTTP na porta TCP 80 e HTTPS na porta TCP 443, possibilitando o funcionamento
dos softwares: Shibboleth SP module, RM e da aplicação protegida pelo Shibboleth. O
procedimento utilizado para a instalação do software Apache pode ser identificado na Figura 74. O
yum é uma ferramenta utilizada para instalar, atualizar e remover pacotes e suas dependências em
sistemas que suportam arquivos RPM (Red Hat Package Manager).
yum -y install httpd
Figura 74. Procedimento de instalação do software Apache
Após a instalação do software Apache, foi necessário configurá-lo para interagir com o
software OpenSSL. Esta configuração exigiu a alteração de dois arquivos: httpd.conf e ssl.conf. No
arquivo httpd.conf foram adicionados os parâmetros conforme mostra a Figura 75.
LoadModule ssl_module modules/mod_ssl.so Include conf.d/ssl.conf
Figura 75. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf
No arquivo ssl.conf foram alterados alguns parâmetros para que o Apache processe as
requisições HTTPS na porta TCP 443. A Figura 76 apresenta estas alterações.
Listen 443 <VirtualHost _default_:443> DocumentRoot "/var/www/html" ServerName shib-sp.dalcoquio.com.br:443 SSLCertificateFile /etc/pki/tls/certs/shib-sp.dalcoquio.com.br.crt SSLCertificateKeyFile /etc/pki/tls/private/shib-sp.dalcoquio.com.br.key </VirtualHost>
Figura 76. Parâmetros alterados no arquivo ssl.conf
87
O quarto software instalado foi o PHP, este ficou responsável por interpretar as requisições
com extensão PHP do componente RM e da aplicação protegida pelo Shibboleth. O procedimento
de instalação do software PHP é apresentado na Figura 77. No comando de instalação do software
PHP foi adicionado o parâmetro php-mysql, este é necessário para que o PHP compile as bibliotecas
para acesso ao banco de dados MySQL. Estas bibliotecas serão utililizadas no desenvolvimento da
aplicação protegida pelo Shibboleth.
yum -y install php php-mysql
Figura 77. Procedimento de instalação do software PHP
Após a instalação do software PHP, foi necessário configurá-lo para interagir com o
software Apache. Esta configuração exigiu a alteração de alguns parâmetros do arquivo httpd.conf.
A Figura 78 mostra estas alterações.
LoadModule php5_module modules/libphp5.so AddHandler php5-script .php AddType text/html .php DirectoryIndex index.html index.html.var index.php
Figura 78. Parâmetros do software PHP alterados no arquivo httpd.conf
O quinto e último software pré-requisito instalado foi o MySQL. O MySQL ficou
responsável por interagir com a aplicação protegida pelo Shibboleth, servindo como banco de dados
para armazenamento dos documentos enviados pelos usuários da federação InBrazil. O
procedimento adotado para a instalação do software MySQL é apresentado na Figura 79.
yum -y install mysql mysql-server
Figura 79. Procedimento de instalação do software MySQL
Após a instalação do software MySQL, foi necessário criar a senha do usuário administrador
do banco de dados e um banco de dados para armazenar os registros gerados pela aplicação
protegida pelo Shibboleth. Estes procedimentos são apresentados na Figura 80.
88
mysqladmin -u root password newpassword mysqladmin -u root -p create upload
Figura 80. Procedimentos de configuração do software MySQL
4.1.2.2 Software Shibboleth SP
O software Shibboleth SP é o responsável pela proteção da aplicação instalada no servidor
provedor de serviço. Esta proteção é realizada através das informações de autenticação e
autorização recebidas do provedor de identidade. Após a instalação dos softwares pré-requisitos foi
possível iniciar a instalação do software Shibboleth SP. A instalação do software Shibboleth SP foi
feita através de pacotes no formato RPM. O procedimento de instalação é apresentado na Figura 81.
rpm -ivh log4cpp-0.3.5rc1-1.i386.rpm rpm -ivh log4cpp-debuginfo-0.3.5rc1-1.i386.rpm rpm -ivh log4cpp-devel-0.3.5rc1-1.i386.rpm rpm -ivh log4cpp-docs-0.3.5rc1-1.i386.rpm rpm -ivh xerces-c-2.6.1-2.i386.rpm rpm -ivh xerces-c-debuginfo-2.6.1-2.i386.rpm rpm -ivh xerces-c-devel-2.6.1-2.i386.rpm rpm -ivh xerces-c-doc-2.6.1-2.i386.rpm rpm -ivh xerces-c-samples-2.6.1-2.i386.rpm rpm -ivh xml-security-c-1.2.0-2.i386.rpm rpm -ivh xml-security-c-debuginfo-1.2.0-2.i386.rpm rpm -ivh xml-security-c-devel-1.2.0-2.i386.rpm rpm -ivh xml-security-c-docs-1.2.0-2.i386.rpm rpm -ivh opensaml-1.1-6.i386.rpm rpm -ivh opensaml-debuginfo-1.1-6.i386.rpm rpm -ivh opensaml-devel-1.1-6.i386.rpm rpm -ivh shibboleth-1.3-11.i386.rpm rpm -ivh shibboleth-debuginfo-1.3-11.i386.rpm rpm -ivh shibboleth-devel-1.3-11.i386.rpm rpm -ivh shibboleth-selinux-policy-targeted-1.3-9.i386.rpm
Figura 81. Procedimento de instalação do software Shibboleth SP
89
A localização dos arquivos de configuração do software Shibboleth SP é apresentada na
Figura 82.
/usr/local/shibboleth-sp/etc/shibboleth/
Figura 82. Localização dos arquivos de configuração do software Shibboleth SP
A configuração do software Shibboleth SP foi realizada através da alteração de três
arquivos: shibboleth.xml, AAP.xml e httpd.conf. O arquivo shibboleth.xml é o local de
configuração primária do software Shibboleth SP. A Figura 83 apresenta uma parte do arquivo
shibboleth.xml, mais especificamente a tag Host parâmetro name com o nome do servidor provedor
de serviço InBrazil.
<RequestMapProvider type="edu.internet2.middleware. shibboleth.sp.provider.NativeRequestMapProvider"> <RequestMap applicationId="default"> <Host name="shib-sp.dalcoquio.com.br"> <Path name="secure" authType="shibboleth" requireSession="true" exportAssertion="true"> </Path> </Host> </RequestMap> </RequestMapProvider>
Figura 83. Configuração da tag Host no arquivo shibboleth.xml
Após configurar a tag Host, foi configurado a tag Site, conforme mostra a Figura 84. Na tag
Site foi difinido o parâmetro name com o nome do servidor provedor de serviço InBrazil. Esta tag é
utilizada para definir a tag Alias. Esta tag é responsável por especificar outros nomes para o
servidor provedor de serviço, como no caso da federação InBrazil esta configuração não foi
necessária, a tag Alias foi comentada.
<ISAPI normalizeRequest="true"> <Site id="1" name="shib-sp.dalcoquio.com.br"> <!-- <Alias>example.dalcoquio.com.br</Alias> --> </Site> </ISAPI>
Figura 84. Configuração da tag Site no arquivo shibboleth.xml
90
Após configurar a tag Site, foram especificados os parâmetros das tags Applications,
SessionInitiator, MetadataProvider e saml:Audience, conforme apresenta a Figura 85. Na tag
Applications foi configurado o parâmetro providerId com a URL do servidor provedor de serviço
InBrazil. O parâmetro homeURL referencia a URL inicial do servidor provedor de serviço InBrazil.
Em seguida, na tag SessionInitiator foi configurado o parâmetro Id que referencia a federação
InBrazil. Nos parâmetros Location e wayfURL foram configuradas as URLs do servidor WAYF
InBrazil. Na tag MetadataProvider parâmetro uri foi configurada a localização do arquivo inbrazil-
metadata.xml. O arquivo inbrazil-metadata.xml foi criado na configuração do software Shibboleth
IdP e precisa ser copiado para o provedor de serviço InBrazil, pois é utilizado por ambos os
provedores. Finalmente, na tag saml:Audience foi configurado o endereço da federação InBrazil.
<Applications id="default" providerId="https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp" homeURL="https://shib-sp.dalcoquio.com.br" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <SessionInitiator id="InBrazil" Location="/WAYF/wayf.dalcoquio.com.br" Binding="urn:mace:shibboleth:sp:1.3:SessionInit" wayfURL="https://wayf.dalcoquio.com.br/WAYF.php" wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/> <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata" uri="/usr/local/shibboleth-sp/etc/shibboleth/inbrazil-metadata.xml"/> <saml:Audience>urn:mace:dalcoquio.com.br:inbrazil</saml:Audience>
Figura 85. Configuração das tags no arquivo shibboleth.xml
Nas tags Path foram configuradas as localizações das chaves privada e pública do provedor
de serviço InBrazil. Este procedimento é apresentado na Figura 86.
<CredentialsProvider type="edu.internet2.middleware.shibboleth.common.Credentials"> <Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="defcreds"> <Key> <Path>/etc/pki/tls/private/shib-sp-dal.key</Path> </Key> <Certificate> <Path>/etc/pki/tls/certs/shib-sp-dal.crt</Path> </Certificate> </FileResolver> </Credentials> </CredentialsProvider>
Figura 86. Configuração das tags Path no arquivo shibboleth.xml
91
O arquivo AAP.xml é o local de configuração das AAPs, ou seja, das regras de aceitação
dos atributos dos usuários provenientes do provedor de identidade. A Figura 87 apresenta o arquivo
AAP.xml, suas tags e os parâmetros especificados conforme a necessidade da federação InBrazil.
Na tag AttributeRule iniciou-se uma nova AAP. No parâmetro Name foi configurado o nome do
atributo que será aceito pelo provedor de serviço. Em seguida, na tag SiteRule parâmetro Name foi
configurado a URL do provedor de identidade que está autorizado a enviar o atributo especificado
na tag AttributeRule parâmetro Name para o provedor de serviço.
<AttributeAcceptancePolicy xmlns="urn:mace:shibboleth:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:1.0 /usr/local/shibboleth-sp/share/xml/shibboleth/shibboleth.xsd"> <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonAffiliation" CaseSensitive="false" Header="Shib-EP-Affiliation" Alias="affiliation"> <SiteRule Name="https://shib-idp.dalcoquio.com.br/shibboleth/inbrazil/idp"> <AnyValue/> </SiteRule> </AttributeRule> </AttributeAcceptancePolicy>
Figura 87. Arquivo AAP.xml
Finalmente, no arquivo httpd.conf do Apache foi inserido um parâmetro para que o Apache
instale o componente Shibboleth SP module. Esta alteração é mostrada na Figura 88. O arquivo
shib.conf foi criado na instalação do software Shibboleth SP e não precisou ser alterado.
Include conf.d/shib.conf
Figura 88. Parâmetro adicionado ao arquivo httpd.conf
4.1.2.3 Componentes Adicionais
O componente adicional implementado foi o RM (Resource Manager – Gerenciador de
Recurso), este ficou responsável por interceptar as requisições destinadas à aplicação protegida pelo
Shibboleth e realizar as decisões de controle de acesso baseadas nos atributos dos usuários.
O componente RM foi implementado em duas partes: a primeira parte no componente
Shibboleth SP module e a segunda parte na aplicação protegida pelo Shibboleth. No componente
Shibboleth SP module, o RM foi configurado para interceptar as requisições ao diretório onde se
92
encontra a aplicação protegida pelo Shibboleth e somente autorizar o acesso aos usuários
autenticados ou aos usuários autenticados com o atributo eduPersonAffiliation definido com o valor
“estudante” ou “professor”. Para que o componente Shibboleth SP module faça apenas a
autenticação dos usuários e repasse as decisões de controle de acesso para o RM da aplicação
protegida pelo Shibboleth, foi necessário configurar o arquivo httpd.conf do Apache com o
parâmetro “require valid-user”, esta alteração é mostrada na Figura 89. Para que o componente
Shibboleth SP module faça a autenticação dos usuários e as decisões de controle de acesso, foi
necessário configurar o arquivo httpd.conf do Apache com o parâmetro “require affiliation
estudante professor”, esta alteração é apresentada na Figura 90.
<Location /inbrazil/appl/protected_appl> AuthType shibboleth ShibRequireSession On require valid-user </Location>
Figura 89. Parâmetro adicionado no arquivo httpd.conf
<Location /inbrazil/appl/protected_shib> AuthType shibboleth ShibRequireSession On require affiliation estudante professor </Location>
Figura 90. Parâmetro adicionado no arquivo httpd.conf
Na aplicação protegida pelo Shibboleth, o RM foi implementado como uma função. Esta
função recebe os atributos dos usuários e faz as decisões de controle de acesso baseadas no atributo
eduPersonAffiliation. Se o usuário possuir o atributo eduPersonAffiliation definido com o valor
“estudante” ou “professor” terá acesso a aplicação protegida pelo Shibboleth, caso contrário, não
terá acesso.
A comunicação do RM implementado na aplicação protegida pelo Shibboleth com o
software Shibboleth ocorre através da variável global $_SERVER do PHP. Segundo PHP (2006), “a
variável $_SERVER é um array contendo informações como headers, caminhos e localizações dos
scripts PHP”. O Shibboleth disponibiliza os atributos dos usuários nesta variável global do PHP. O
arquivo AAP.xml do Shibboleth controla esta interface com a variável global $_SERVER e mapeia
os atributos dos usuários para headers names. Por exemplo, na federação InBrazil o atributo
eduPersonAffiliation foi mapeado para o header name “HTTP_SHIB_EP_AFFILIATION”. Sendo
93
assim, o componente RM implementado na aplicação protegida pelo Shibboleth consegue acessar
os atributos dos usuários e fazer as decisões de controle de acesso.
A implementação do RM da aplicação protegida pelo Shibboleth é mostrada na Figura 91.
Nesta função, implementada na linguagem PHP, é utilizada a função foreach para verificar o
conteúdo do array $_SERVER (KATHOLIEKE UNIVERSITEIT LEUVEN, 2006). Em seguida, é
verificado o conteúdo do header name “HTTP_SHIB_EP_AFFILIATION”, caso ele possua o valor
“estudante” ou “professor” a variável $authz recebe “TRUE”, isto quer dizer que o usuário terá
acesso à aplicação protegida pelo Shibboleth. Caso contrário a variável $authz recebe “FALSE” e
consequentemente o usuário não terá acesso à aplicação protegida pelo Shibboleth.
function verificaFiliacao() {
$authz = "";
foreach($_SERVER as $chave => $conteudo) {
if ($chave == "HTTP_SHIB_EP_AFFILIATION") {
if ($conteudo == "estudante" || $conteudo == "professor") {
$authz = "TRUE";
}
elseif ($authz != "TRUE") {
$authz = "FALSE";
}
}
}
return $authz;
}
Figura 91. Função “verificaFiliacao” do RM da aplicação protegida pelo Shibboleth
4.1.3 Servidor WAYF
O servidor WAYF é o local de instalação do software WAYF, este é responsável por:
apresentar aos usuários uma relação com os provedores de identidade disponíveis para realizar
autenticação; e redirecioná-los para o provedor de identidade selecionado. Neste servidor foram
instalados os softwares pré-requisitos para o funcionamento do software WAYF. O software
WAYF completa a infra-estrutura deste servidor. A Tabela 3 mostra o nome e a versão dos
softwares implementados no servidor WAYF da federação InBrazil.
94
Tabela 3. Softwares do servidor WAYF
Nome Versão Apache 2.0.59 Linux Slackware 10.2 OpenSSL 0.9.7g PHP 5.0.3 WAYF SWITCHaai 1.5
Com o objetivo de demonstrar os softwares instalados no servidor WAYF, suas interações e
o processo de funcionamento do software WAYF, foi elaborada a Figura 92. O processo Shibboleth
inicia no Passo 1, quando uma requisição HTTPS/GET na porta 443 proveniente do provedor de
serviço alcança o Apache, mais especificamente alcança o software WAYF. O software WAYF
apresenta ao usuário uma página web contendo os provedores de identidade disponíveis na
federação (Passo 2). Após o usuário selecionar o seu provedor de identidade (Passo 3), o software
WAYF envia uma requisição HTTPS/POST na porta 443 para o provedor de identidade selecionado
pelo usuário, levando como parâmetros algumas informações referentes ao provedor de serviço
(Passo 4).
Figura 92. Infra-estrutura e funcionamento do servidor WAYF
Fonte: Adaptado de Shibboleth (2006).
95
4.1.3.1 Softwares Pré-Requisitos
O primeiro passo adotado para tornar possível o funcionamento do software WAYF foi a
instalação dos seus softwares pré-requisitos. O primeiro software pré-requisito instalado foi o
sistema operacional Linux Slackware, responsável por garantir segurança e confiabilidade ao
ambiente do servidor WAYF. Este software foi instalado na modalidade expert, ou seja, um método
de instalação que possibilita a seleção de todos os softwares presentes no CD de instalação.
O segundo software implementado foi o OpenSSL, instalado durante o processo de
instalação do sistema operacional Linux Slackware. Para adicionar suporte SSL aos softwares do
servidor WAYF foi necessário gerar as chaves privada e pública. Este procedimento é apresentado
na Figura 93.
openssl genrsa -out wayf.dalcoquio.com.br.key 2048
openssl req -new -x509 -nodes -sha1 -days 3650 -key \
wayf.dalcoquio.com.br.key > wayf.dalcoquio.com.br.crt
Figura 93. Procedimento para gerar as chaves privada e pública
O terceiro software instalado foi o Apache, este ficou responsável por processar as
requisições HTTP na porta TCP 80 e HTTPS na porta TCP 443, possibilitando o funcionamento do
software WAYF. Os procedimentos utilizados para a instalação do software Apache podem ser
identificados na Figura 94.
./configure --enable-so \ --enable-mods-shared=most \ --prefix=/etc/apache \ --enable-ssl \ --with-ssl=/usr/include/openssl make make install
Figura 94. Procedimentos de instalação do software Apache
Após a instalação do software Apache, foi necessário configurá-lo para interagir com o
software OpenSSL. Esta configuração exigiu a alteração de dois arquivos: httpd.conf e ssl.conf. No
arquivo httpd.conf foram adicionados os parâmetros conforme mostra a Figura 95.
96
<IfDefine SSL> LoadModule ssl_module modules/mod_ssl.so </IfDefine> <IfModule mod_ssl.c> Include conf/ssl.conf </IfModule>
Figura 95. Parâmetros do software OpenSSL adicionados ao arquivo httpd.conf
No arquivo ssl.conf foram alterados alguns parâmetros para que o Apache processe as
requisições HTTPS na porta TCP 443. A Figura 96 apresenta estas alterações.
Listen 443 <VirtualHost _default_:443> DocumentRoot "/etc/apache/htdocs" ServerName wayf.dalcoquio.com.br:443 SSLCertificateFile /etc/apache/conf/wayf.dalcoquio.com.br.crt SSLCertificateKeyFile /etc/apache/conf/wayf.dalcoquio.com.br.key </VirtualHost>
Figura 96. Parâmetros alterados no arquivo ssl.conf
O quarto e último software pré-requisito instalado foi o PHP, este ficou responsável por
interpretar as requisições com extensão PHP do software WAYF. O procedimento de instalação do
software PHP é apresentado na Figura 97.
./configure --with-apxs2=/etc/apache/bin/apxs \ --prefix=/etc/apache/php5 \ --with-config-file-path=/etc \ --with-gettext=/usr/lib/gettext make make install
Figura 97. Procedimento de instalação do software PHP
Após a instalação do software PHP, foi necessário configurá-lo para interagir com o
software Apache. Esta configuração exigiu a alteração de alguns parâmetros do arquivo httpd.conf.
A Figura 98 mostra estas alterações.
97
LoadModule php5_module modules/libphp5.so DirectoryIndex index.html index.html.var index.php AddType application/x-httpd-php .php
Figura 98. Parâmetros do software PHP alterados no arquivo httpd.conf
4.1.3.2 Software WAYF
O software Shibboleth WAYF é o responsável por apresentar ao usuário uma lista com os
provedores de identidade disponíveis na federação e por redirecioná-los para o provedor de
identidade selecionado. Após a instalação dos softwares pré-requisitos foi possível iniciar a
instalação do software WAYF.
Atualmente, existem dois softwares WAYF disponíveis no site do Shibboleh, o WAYF
desenvolvido por terceiros e o WAYF desenvolvido pela equipe do Shibboleth. Para a federação
InBrazil foi utilizado o software WAYF de terceiros chamado SWITCHaai, já que o mesmo tem
suporte a múltiplas linguagens e foi desenvolvido na linguagem PHP, o que facilita o serviço de
instalação e configuração (SWITCH, 2006). Como o software WAYF foi desenvolvido em PHP, o
mesmo ficou instalado no servidor Apache que possui suporte a linguagem PHP.
O procedimento de instalação do software WAYF é simplificado, já que foi necessário
apenas copiar o seu pacote de instalação para o diretório do servidor Apache e descompactá-lo. A
Figura 99 apresenta este procedimento.
cp wayf-1.5.tar.gz /etc/apache/htdocs tar –zxvf /etc/apache/htdocs/wayf-1.5.tar.gz
Figura 99. Procedimento de instalação do software WAYF
Após a instalação do software WAYF, foi necessário configurá-lo para interagir com o
provedor de identidade. Esta configuração exigiu a alteração de algumas variáveis de dois arquivos:
IDProvider.conf.php e config.php. A Figura 100 apresenta as variáveis alteradas no arquivo
IDProvider.conf.php. A variável $IDProviders é um array que recebeu os parâmetros: URL da
página de autenticação do usuário no provedor de identidade e uma descrição para o provedor de
identidade.
98
<?php $IDProviders["urn:mace:dalcoquio.com.br:inbrazil:dalcoquio.com.br"]["SSO"] = "https://shib-idp.dalcoquio.com.br/shibboleth-idp/SSO"; $IDProviders["urn:mace:dalcoquio.com.br:inbrazil:dalcoquio.com.br"]["Name"] = "InBrazil IdP"; ?>
Figura 100. Variável configurada no arquivo IDProvider.conf.php
As variáveis do arquivo config.php foram definidas conforme apresenta a Figura 101. Na
variável $commonDomain foi configurado o domínio utilizado pela federação InBrazil. Em seguida,
na variável $RelyingParty foi definido o endereço da federação InBrazil.
$commonDomain = '.dalcoquio.com.br'; $RelyingParty = 'urn:mace:dalcoquio.com.br:inbrazil';
Figura 101. Variáveis configuradas no arquivo config.php
4.2 IMPLEMENTAÇÃO DA APLICAÇÃO
A aplicação foi implementada com o objetivo de demonstrar o funcionamento do sistema de
gerenciamento de identidades Shibboleth e da federação InBrazil, apresentando principalmente os
serviços de autenticação e autorização providos pelo Shibboleth e pela federação InBrazil. Esta
aplicação recebeu o nome de Aplicação Básica InBrazil e foi desenvolvida utilizando-se a
linguagem PHP.
A Aplicação Básica InBrazil foi dividida em duas áreas: Download de documentos e
Upload. Na área de Download de documentos qualquer usuário tem acesso (usuário da federação
InBrazil ou visitante), pois não é necessária autenticação para acessar esta área. A área destinada a
Upload foi dividida em duas subáreas: Upload – AuthZ Appl e Upload – AuthZ Shib. Nestas
subáreas somente os usuários autenticados e autorizados terão acesso para fazer upload de
documentos. Para fazer as decisões de controle de acesso foi utilizado o atributo
eduPersonAffiliation que precisa estar definido com o valor “estudante” ou “professor” para
permitir que o usuário faça upload de documentos.
Na subárea Upload – AuthZ Appl, a autenticação do usuário é gerenciada pelo componente
Shibboleth SP module e as decisões de controle de acesso repassadas ao componente RM que foi
99
implementado na Aplicação Básica InBrazil. Já na subárea Upload – AuthZ Shib, tanto a
autenticação como as decisões de controle de acesso são gerenciadas pelo componente Shibboleth
SP module.
4.2.1 Funcionamento da Aplicação
Para demonstrar o funcionamento da área de Upload da Aplicação Básica InBrazil foi
cadastrado o usuário “teste”, com o atributo eduPersonAffiliation definido com o valor “visitante” e
o usuário “andre.cordova”, com o atributo eduPersonAffiliation definido com o valor “estudante”.
No primeiro caso, autenticando com o usuário “teste”, o usuário não terá acesso à área de
upload de documentos. Na subárea Upload – AuthZ Appl, as decisões de controle de acesso são
realizadas pelo componente RM implementado na Aplicação Básica InBrazil, logo o usuário irá
visualizar a página de acesso não autorizado da Aplicação Básica InBrazil. Na subárea Upload –
AuthZ Shib, as decisões de controle de acesso são gerenciadas pelo componente Shibboleth SP
module, portanto o usuário visualizará a página de acesso não autorizado do Shibboleth.
No segundo caso, autenticando com o usuário “andre.cordova”, o usuário terá acesso ao
upload de documentos, já que está autenticado e autorizado. A autorização foi permitida ao usuário,
pois baseado no valor de seu atributo eduPersonAffiliation, tanto o componente Shibboleth SP
module, quanto o componente RM implementado na Aplicação Básica InBrazil permitiram o acesso
ao conteúdo protegido.
O processo de proteção da Aplicação Básica InBrazil, autenticação, autorização e de
controle da liberação dos atributos dos usuários pode ser visualizado através dos arquivos de log
gerados por alguns softwares instalados nos servidores da federação InBrazil. No servidor provedor
de identidade foi gerado três arquivos de log. Estes arquivos foram identificados como:
apache_ssl.log, shib-access.log e shib-error.log. No arquivo apache_ssl.log (exibido no Apêndice
B.1), pode-se identificar as requisições HTTPS/GET e HTTPS/POST que chegam, respectivamente,
ao Apache e ao Pubcookie, bem como a requisição HTTPS/POST para envio dos atributos do
usuário ao provedor de serviço. Já no arquivo shib-access.log (apresentado no Apêndice B.2), é
possível visualizar a confirmação de autenticação do usuário que é enviada ao provedor de serviço,
bem como o nome do atributo que foi liberado ao provedor de serviço. No arquivo shib-error.log
(exibido no Apêndice B.3), pode-se verificar a criação da mensagem SAML que contém o handle
de confirmação da autenticação do usuário. Ainda no arquivo shib-error.log é possível visualizar: a
100
requisição na porta 8443 para solicitar atributos do usuário; a verificação das credenciais do
provedor de serviço que enviou a requisição de atributos; a busca do atributo solicitado no serviço
de diretório; checagem das regras de liberação deste atributo; e envio do atributo ao provedor de
serviço.
No servidor provedor de serviço foi gerado três arquivos de log. Estes arquivos foram
identificados como: apache_ssl.log, shibd.log e transaction.log. No arquivo apache_ssl.log
(apresentado no Apêndice C.1), pode-se identificar as requisições HTTPS/GET de tentativa e
acesso a Aplicação Básica InBrazil, bem como da mensagem, no formato SAML/POST, que chega
ao provedor de serviço com a confirmação de autenticação do usuário. Já no arquivo shibd.log
(exibido no Apêndice C.2), pode-se visualizar a criação da sessão que é utilizada para identificar o
handle que é recebido do provedor de identidade. Ainda neste arquivo é possível identificar a
mensagem SAML enviada ao provedor de identidade para solicitar atributos do usuário. No arquivo
transaction.log (exibido no Apêndice C.3), pode-se identificar, principalmente, o nome do atributo
que foi liberado pelo provedor de identidade e aceito pelo provedor de serviço.
Finalmente, no servidor WAYF foi gerado apenas um arquivo de log. Este arquivo foi
identificado como: apache_ssl.log. No arquivo apache_ssl.log (apresentado no Apêndice D.1),
pode-se identificar a requisição HTTPS/GET proveniente do provedor de serviço e a requisição
HTTPS/POST destinada ao provedor de identidade.
As mensagens SAML utilizadas para confirmar a autenticação do usuário são construídas
através do SAML schema apresentado no Anexo II.
4.2.2 Telas da Aplicação
Esta seção apresentará as telas da aplicação, descrevendo a interface da aplicação com o
usuário e o conjunto das telas da Aplicação Básica InBrazil. Serão apresentados dois exemplos: o
primeiro exemplo utilizando o usuário “teste” para autenticar no provedor de identidade e o
segundo exemplo utilizando o usuário “andre.cordova” para autenticar no provedor de identidade.
101
O primeiro exemplo inicia com a Figura 102 que apresenta a tela inicial da Aplicação Básica
InBrazil. Nela o usuário pode escolher qual das áreas deseja acessar: Download de documentos ou
Upload.
Figura 102. Tela inicial da Aplicação Básica InBrazil
Ao selecionar a área de Download de documentos, o usuário irá visualizar a tela conforme
mostra a Figura 103.
Figura 103. Tela de Download de documentos
102
Caso o usuário selecione a área de Upload, o mesmo será redirecionado para o serviço
WAYF SWITCHaai, conforme mostra a Figura 104. Nesta tela o usuário irá selecionar o seu
provedor de identidade, neste exemplo, o provedor de identidade “InBrazil IdP”.
Figura 104. Tela do componente WAYF SWITCHaai
103
Após selecionar o provedor de identidade “InBrazil IdP”, o usuário será redirecionado para a
página de autenticação, gerada pelo Pubcookie, do provedor de identidade InBrazil, conforme
apresenta a Figura 105. Para realizar a autenticação o usuário deverá digitar as suas credencias,
neste exemplo, login “teste” e password “teste”.
Figura 105. Tela de autenticação Pubcookie
Após o usuário ter realizado a sua autenticação, o provedor de identidade e o provedor de
serviço trocam informações de autenticação e autorização, conforme mostra a Figura 106.
Figura 106. Tela de troca de informações de autenticação e autorização
104
Como o usuário que está tentando acesso a subárea Upload – AuthZ Appl é o usuário “teste”
e o mesmo não possui autorização para acessar esta subárea, será apresentada a tela de acesso não
autorizado da Aplicação Básica InBrazil, conforme mostra a Figura 107. Esta tela foi gerada pela
Aplicação Básica InBrazil, já que as decisões de controle de acesso foram feitas pelo componente
RM implementado na Aplicação Básica InBrazil.
Figura 107. Tela de Upload – AuthZ Appl
Caso o usuário “teste” selecione a subárea Upload – AuthZ Shib, será apresentada a tela
conforme mostra a Figura 108. Esta tela foi montada pelo software Shibboleth SP, já que as
decisões de controle de acesso foram gerenciadas pelo componente Shibboleth SP module.
Figura 108. Tela de Upload – AuthZ Shib
105
O segundo exemplo inicia supondo que o usuário “andre.cordova” tentou acesso a área de
Upload da Aplicação Básica InBrazil e foi redirecionado para o componente WAYF. Em seguida,
selecionou o provedor de identidade “InBrazil IdP” e foi redirecionado para a página de
autenticação, gerada pelo Pubcookie, do provedor de identidade InBrazil. A página de autenticação
do provedor de identidade InBrazil é apresentada na Figura 109. Neste exemplo, o usuário irá
digitar as suas credenciais para realizar a autenticação, ou seja, login “andre.cordova” e password
“inbrazil”.
Figura 109. Tela de autenticação Pubcookie
Após o usuário ter feito a sua autenticação, o provedor de identidade e o provedor de serviço
trocam informações de autenticação e autorização, conforme mostra a Figura 110.
Figura 110. Tela de troca de informações de autenticação e autorização
106
Como o usuário que está tentando acesso a área de Upload é o usuário “andre.cordova” e o
mesmo possui autorização para acessar esta área, será apresentada a tela conforme mostra a Figura
111. Tanto a página gerada com base nas decisões de controle de acesso do RM implementado na
Aplicação Básica InBrazil, quanto a página gerada com base nas decisões de controle de acesso do
componente Shibboleth SP module permitem que o usuário faça upload de documentos.
Figura 111. Tela de Upload
Através dos testes realizados na Aplicação Básica InBrazil foi possível demonstrar o
funcionamento da federação InBrazil, bem como os processos existentes em uma infra-estrutura do
sistema Shibboleth com o objetivo de controlar o acesso a aplicações e proteger as informações dos
usuários.
5 CONSIDERAÇÕES FINAIS
O conteúdo teórico pesquisado para o desenvolvimento deste trabalho retrata a importância
de um sistema de gerenciamento de identidades, tanto para proteger as informações sensíveis dos
usuários quanto para melhorar o nível de controle das identidades por parte dos administradores.
O sistema de gerenciamento de identidades Shibboleth além de realizar o controle e a
segurança das identidades permite a proteção de aplicações web através da utilização de
mecanismos de autenticação e autorização. Estas funcionalidades foram demonstradas pela
implementação da federação InBrazil e da Aplicação Básica InBrazil que formaram um ambiente
completo do sistema Shibboleth.
A implementação da federação InBrazil foi realizada em servidores com o hardware
dimensionado para atender poucas requisições, no máximo 40 requisições de login por minuto. Em
um ambiente de produção, que necessite de uma maior quantidade de requisições, recomenda-se o
uso de hardware compatível, por exemplo, processador Xeon ou Opteron, 2GB de memória RAM
(Random Access Memory) e placa de rede gigabit ethernet. Para aumentar a performance e a
disponibilidade deste ambiente é recomendada a utilização de múltiplos servidores com recursos de
balanceamento de carga.
Em países desenvolvidos, o emprego da gerência das identidades é bastante difundido em
universidades, principalmente em sistemas de gerenciamento de conhecimento e e-learning. Para
utilização destes sistemas, os usuários possuem uma única credencial protegida e controlada por um
sistema de gerenciamento de identidades. Sendo assim, este trabalho fica como iniciativa para que
universidades do Brasil apliquem este conceito em seus sistemas.
Este trabalho colabora para a criação de documentação em português sobre gerenciamento
de identidades, já que no Brasil o assunto é pouco explorado e a maior parte da documentação
utilizada para realizar este trabalho foi escrita na língua inglesa.
Como idéia para trabalhos futuros, fica a continuação dos estudos sobre o sistema de
gerenciamento de identidades Shibboleth. O enfoque deste estudo seria a programação, com o
objetivo de desenvolver novas funcionalidades ao sistema Shibboleth e a federação InBrazil. Uma
funcionalidade desejável seria criar uma interface web onde provedores de identidade e provedores
de serviço pudessem ingressar na federação InBrazil de uma maneira simplificada. Neste caso, o
108
administrador do provedor de identidade ou provedor de serviço poderia realizar um cadastro na
interface web e os arquivos de configuração da federação InBrazil, principalmente o arquivo de
metadata, seria alterado e gerado automaticamente através dos dados que foram digitados pelo
administrador. Deste modo, o serviço de configuração de novos provedores de identidade ou
serviço ingressantes na federação InBrazil seria simplificado.
O uso comercial do sistema de gerenciamento de identidades Shibboleth pode ser
identificado na utilização do Shibboleth pelos softwares educacionais Blackboard e na
interoperabilidade do sistema Shibboleth com o Windows 2003 Server R2 da Microsoft. Neste caso,
um site que utilize o serviço ADFS (Active Directory Federation Services) da Microsoft poderá
participar de uma federação Shibboleth para trocar informações de autenticação e autorização.
A modelagem da Aplicação Básica InBrazil não foi necessária, já que as funcionalidades
desta aplicação são extremamente simples e possuem o intuito apenas de demonstrar o
funcionamento do sistema Shibboleth. O foco deste trabalho é a aplicação prática de um sistema de
gerenciamento de identidades Shibboleth e não uma aplicação complexa que necessite da
modelagem de sofware.
Uma das dificuldades encontradas para o desenvolvimento deste trabalho foi o serviço de
configuração e integração de todos os softwares pré-requisitos para possibilitar o funcionamento do
sistema Shibboleth. Este serviço exigiu conhecimentos de administração de sistemas operacionais e
redes, já que além da configuração dos softwares pré-requisitos foi necessário registrar todos os
servidores em um domínio para que pudessem se comunicar pela Internet.
Considerando os objetivos deste trabalho, pode-se analisar que estes foram cumpridos, tendo
em vista que foram realizados estudos e descritos conceitos referentes à segurança, gerenciamento
de identidades e sistema Shibboleth. Finalmente, foi realizada a implementação da federação
InBrazil e da Aplicação Básica InBrazil para demonstração prática do sistema de gerenciamento de
identidades Shibboleth.
REFERÊNCIAS BIBLIOGRÁFICAS
ALBERTIN, Alberto Luiz. Comércio eletrônico: modelo, aspectos e contribuições de sua aplicação. 3. ed. São Paulo: Atlas, 2001.
ANT. Apache Ant User Manual. Disponível em: <http://ant.apache.org/manual/index.html>. Acesso em: 02 nov. 2006.
BERNSTEIN, T. et al. Segurança na Internet. Rio de Janeiro: Campus, 1997.
BHARGAV-SPANTZEL, A.; SQUICCIARINI, A. C.; BERTINO, E. Establishing and protecting digital identity in federation systems. Journal of Computer Security (invited paper), IOSPress, To Appear, 2006. Disponível em: <http://homes.cerias.purdue.edu/~bhargav/IdM/jcssubmitColor.pdf>. Acesso em: 01 jun. 2006.
BUEL, Duncan A.; SANDHU, Ravi. Identity management. IEEE Internet Computing, USA, v. 7, n. 6, p. 26-28, Nov.-Dec. 2003.
CAMENISCH, J. et al. Privacy and identity management for everyone. In: ACM 2005 WORKSHOP ON DIGITAL IDENTITY MANAGEMENT, USA. Proceedings… New York: ACM Press, 2005, p. 20-27.
CERT.BR. Cartilha de segurança para Internet. [s.l.: s.n.], 2005. Disponível em: <http://www.cartilha.cert.br/>. Acesso em: 01 abr. 2006.
CGI. The Common Gateway Interface. Disponível em: <http://hoohoo.ncsa.uiuc.edu/cgi/overview.html>. Acesso em: 01 nov. 2006.
DAMIANI, Ernesto; VIMERCATI, Sabrina De Capitani di; SAMARATI, Pierangela. Managing multiple and dependable identities. IEEE Internet Computing, USA, v. 7, n. 6, p. 29-37, Nov.-Dec. 2003.
DIAS, Cláudia. Segurança e auditoria da tecnologia da informação. Rio de Janeiro: Axcel Books do Brasil, 2000.
EDUCAUSE. eduPerson Object Class. Disponível em: <http://www.educause.edu/eduperson/>. Acesso em: 01 jul. 2006.
FINANCIAR. FINANCIAR – selecione sua instituição. Disponível em: <http://www.financiar.org.br/busca.asp>. Acesso em: 01 jun. 2006.
HANSEN, M.; KRASEMANN, H. Privacy and identity management for Europe – PRIME white paper. [s.l.: s.n.], 2005. Disponível em: <http://www.prime-project.eu.org/whitepaper/prime/public/press_room/whitepaper/PRIME-Whitepaper-V1.pdf>. Acesso em: 01 jun. 2006.
IAMSECT. IAMSECT Project. Disponível em: <http://iamsect.ncl.ac.uk/>. Acesso em: 01 jun. 2006.
110
ICPP/ULD; SNG. Identity management systems (IMS): identification and comparison study. [s.l.: s.n.], 2003. 305 p. Disponível em: <http://www.datenschutzzentrum.de/idmanage/study/ICPP_SNG_IMS-Study.pdf>. Acesso em: 31 mar. 2006.
INTERNET2. Internet2 middleware initiative. Disponível em: <http://middleware.internet2.edu/>. Acesso em: 10 abr. 2006.
KATHOLIEKE UNIVERSITEIT LEUVEN. Documentatie: Programmeertalen. [s.l.: s.n.], 2006. Disponível em: <https://ludit.kuleuven.be/aai/shibboleth/doc/talen#php>. Acesso em: 01 nov. 2006.
LAUREANO, Marcos Aurélio Pchek. Gestão de segurança da informação. [s.l.: s.n.], 2005. Disponível em: <http://www.laureano.eti.br/ensino/puc/gst/gestao_da_seguranca_da_informacao-v20.pdf>. Acesso em: 10 abr. 2006.
LCC – CENAPAD. Autenticação federativa. Disponível em: <http://www.lcc.ufmg.br/servicos-especiais/autenticacao-federativa.html>. Acesso em: 01 jun. 2006.
LINUX. Linux Documentation. Disponível em: <http://www.linux.org/docs/>. Acesso em: 15 maio 2006.
MAIA, Luiz Paulo. Criptografia e certificação digital. [s.l.: s.n.], 1999. Disponível em: <http://www.training.com.br/lpmaia/pub_seg_cripto.htm>. Acesso em: 20 abr. 2006.
MICROSOFT TECHNET. Microsoft identity and access management series: at a glance. [s.l.: s.n.], 2004. Disponível em <http://www.microsoft.com/technet/security/topics/identity/idmanage/default.mspx>. Acesso em: 25 mar. 2006.
MICROSOFT. Microsoft .NET passport. Disponível em: <http://www.passport.com>. Acesso em: 25 mar. 2006.
MYSQL. MySQL AB Documentation. Disponível em: <http://dev.mysql.com/doc/>. Acesso em: 15 maio 2006.
NETTO, Alvim Antônio de Oliveira. Metodologia da pesquisa científica: guia prático para a apresentação de trabalhos acadêmicos. Florianópolis: Visual Books, 2005.
NETWORKWORLD. Identity management, single sign on and SAML. Disponível em: <http://www.networkworld.com/topics/identity-management.html>. Acesso em: 30 mar. 2006.
OPENLDAP. Documentação OpenLDAP. Disponível em: <http://www.ldap.org.br/>. Acesso em: 15 maio 2006.
OPENSSL. OpenSSL Documents. Disponível em: <http://www.openssl.org/docs/>. Acesso em: 01 nov. 2006.
ORACLE. Oracle Berkeley DB Documentation. Disponível em: <http://www.oracle.com/technology/documentation/berkeley-db/db/index.html>. Acesso em: 02 nov. 2006.
111
PFITZMANN, Birgit; WAIDNER, Michael. Analysis of liberty single-sign-on with enabled clients. IEEE Internet Computing, USA, v. 7, n. 6, p. 38-44, Nov.-Dec. 2003.
PHP. PHP Documentation. Disponível em: <http://www.php.net/docs.php>. Acesso em: 15 maio 2006.
PHPLDAPADMIN. PHPLDAPADMIN Documentation. Disponível em: <http://wiki.phpldapadmin.info/tiki-index.php?page=Documentation&bl>. Acesso em: 02 nov. 2006.
PRIME. Project PRIME (privacy and identity management for Europe). Disponível em: <https://www.prime-project.eu/>. Acesso em: 01 jun. 2006.
PUBCOOKIE. Pubcookie Documentation. Disponível em: <http://www.pubcookie.org/docs/>. Acesso em: 20 maio 2006.
PURDUE. Identity management and protection. Disponível em: <http://homes.cerias.purdue.edu/~bhargav/IdM/index.html>. Acesso em: 01 jun. 2006.
REGISTRO.BR. FAQ - DNS. [s.l.: s.n.], 2006. Disponível em: <http://registro.br/faq/faq5.html>. Acesso em: 03 nov. 2006.
REINERT, Claiton Enilson. Estudo sobre gerenciamento de identidades e acesso à web. 2005. 115 f. (Trabalho de Conclusão de Curso)–Bacharelado em Ciência da Computação, Universidade do Vale do Itajaí, Itajaí, 2005.
SANDHU, Ravi; SAMARATI, Pierangela. Authentication, access control, and intrusion detection. [s.1.]: IEEE Communications, 1994.
SHARPE. Shibboleth attribute release policy editor (ShARPE). Disponível em: <http://federation.org.au/twiki/bin/view/Federation/ShARPE>. Acesso em: 20 maio 2006.
SHIBBOLETH. Shibboleth project. Disponível em: <http://shibboleth.internet2.edu/>. Acesso em: 20 maio 2006.
SILVA, Lino Sarlo da. Public key infrastructure: conheça a infra-estrutura de chaves públicas e a certificação digital. [s.l.]: Novatec, 2004.
STALLINGS, William. Cryptography and network security: principles and practice. 3. ed. [s.l.]: Prentice-Hall, 2002.
SWITCH. WAYF Service. Disponível em: <http://www.switch.ch/aai/wayf/>. [s.l.: s.n.], 2006. Acesso em: 02 nov. 2006.
TESTSHIB. TestShib. Disponível em: <http://www.testshib.org>. Acesso em: 01 jul. 2006.
TWIKI. Shibboleth Wiki. Disponível em: <https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/WebHome>. Acesso em: 20 maio 2006.
W3C. Extensible markup language (XML). Disponível em: <http://www.w3.org/XML/>. Acesso em: 10 maio 2006.
112
WHEELER, J. Final report – IAMSECT (inter-institutional authorization management to support e-learning with reference to clinical teaching). Project Report, April 2006. Disponível em: <http://iamsect.ncl.ac.uk/iamsect_finalv1.pdf>. Acesso em: 01 jun. 2006.
ZHANG, N. et al. Plugging a scalable authentication framework into Shibboleth. In: IEEE INTERNATIONAL WORKSHOP ON ENABLING TECHNOLOGIES: INFRASTRUCTURES FOR COLLABORATIVE ENTERPRISES, 14., 2005, Linköpings. Proceedings… Los Alamitos: IEEE Computer Society Press, 2005, p. 271-276.
APÊNDICES
A ARQUIVO DE METADATA
O arquivo inbrazil-metadata.xml ilustrado na Figura 112 contém parâmetros que garantem a
segurança e a comunicação entres os provedores da federação InBrazil, tais como, URL do
provedor de serviço e provedor de identidade, URL da página de autenticação do provedor de
identidade e chave pública do provedor de identidade e provedor de serviço.
<EntitiesDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata ../schemas/saml-
schema-metadata-2.0.xsd
urn:mace:shibboleth:metadata:1.0 ../schemas/shibboleth-metadata-1.0.xsd
http://www.w3.org/2000/09/xmldsig# ../schemas/xmldsig-core-schema.xsd"
Name="urn:mace:dalcoquio.com.br:inbrazil"
validUntil="2010-01-01T00:00:00Z">
<EntityDescriptor entityID="https://shib-
idp.dalcoquio.com.br/shibboleth/inbrazil/idp">
<IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol
urn:mace:shibboleth:1.0">
<Extensions>
<shibmd:Scope>dalcoquio.com.br</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDPTCCAqagAwIBAgIBAzANBgkqhkiG9w0BAQQFADCBqjELMAkGA1UEBhMCQlIx
FzAVBgNVBAgTDlNhbnRhIENhdGFyaW5hMQ8wDQYDVQQHEwZJdGFqYWkxETAPBgNV
BAoTCEluQnJhemlsMRQwEgYDVQQLEwtJbkJyYXppbCBDQTEiMCAGA1UEAxMZc2hp
Yi1pZHAuZGFsY29xdWlvLmNvbS5icjEkMCIGCSqGSIb3DQEJARYVY29yZG92YUBt
YXRyaXguY29tLmJyMB4XDTA2MTAxNTIzMzQzMloXDTA3MTAxNTIzMzQzMlowgacx
CzAJBgNVBAYTAkJSMRcwFQYDVQQIEw5TYW50YSBDYXRhcmluYTEPMA0GA1UEBxMG
SXRhamFpMREwDwYDVQQKEwhJbkJyYXppbDERMA8GA1UECxMISW5CcmF6aWwxIjAg
BgNVBAMTGXNoaWItaWRwLmRhbGNvcXVpby5jb20uYnIxJDAiBgkqhkiG9w0BCQEW
FWNvcmRvdmFAbWF0cml4LmNvbS5icjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAprE/lVv549SpEffhwGfGSJcfsCBzh//6FiSywfLLe56XspMzdBiZ1b8ScMkF
zsG0AL+OTaWPOmHaLqbCL2Y8kyyNaTGEHQ/COCH8GyzpMb6MHsoYh8XGv+PlI3vT
PQwh7Ekn8mGUd9OpV6EDqXWPnmo8QvtgTThHM8NhtgaJRjMCAwEAAaN0MHIwIAYD
VR0RBBkwF4EVY29yZG92YUBtYXRyaXguY29tLmJyMDsGCWCGSAGG+EIBDQQuFixT
aW1wbGVDQSBnZW5lcmF0ZWQgY3VzdG9tIHNlcnZlciBjZXJ0aWZpY2F0ZTARBglg
hkgBhvhCAQEEBAMCBkAwDQYJKoZIhvcNAQEEBQADgYEAG88APgugIOIv++Y2aMMZ
D4iyENtTz2YD6enDyI7aHBdbuo3pPGH7w9VA2sjKQ37djFp6TPI5a2ULbhIUA9ew
tl3jqE5H4spXi5kF1qMNyQBhkOnOYz7e8WI+vidhZsT6/Bn1S/xAODeH2cpwYhki
6ZKGywA0JJ58ndLd6aXCVow=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
115
</KeyDescriptor>
<ArtifactResolutionService index="1"
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://shib-idp.dalcoquio.com.br:8443/shibboleth-
idp/Artifact"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<SingleSignOnService
Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="https://shib-idp.dalcoquio.com.br/shibboleth-idp/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<Extensions>
<shibmd:Scope>dalcoquio.com.br</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDPTCCAqagAwIBAgIBAzANBgkqhkiG9w0BAQQFADCBqjELMAkGA1UEBhMCQlIx
FzAVBgNVBAgTDlNhbnRhIENhdGFyaW5hMQ8wDQYDVQQHEwZJdGFqYWkxETAPBgNV
BAoTCEluQnJhemlsMRQwEgYDVQQLEwtJbkJyYXppbCBDQTEiMCAGA1UEAxMZc2hp
Yi1pZHAuZGFsY29xdWlvLmNvbS5icjEkMCIGCSqGSIb3DQEJARYVY29yZG92YUBt
YXRyaXguY29tLmJyMB4XDTA2MTAxNTIzMzQzMloXDTA3MTAxNTIzMzQzMlowgacx
CzAJBgNVBAYTAkJSMRcwFQYDVQQIEw5TYW50YSBDYXRhcmluYTEPMA0GA1UEBxMG
SXRhamFpMREwDwYDVQQKEwhJbkJyYXppbDERMA8GA1UECxMISW5CcmF6aWwxIjAg
BgNVBAMTGXNoaWItaWRwLmRhbGNvcXVpby5jb20uYnIxJDAiBgkqhkiG9w0BCQEW
FWNvcmRvdmFAbWF0cml4LmNvbS5icjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAprE/lVv549SpEffhwGfGSJcfsCBzh//6FiSywfLLe56XspMzdBiZ1b8ScMkF
zsG0AL+OTaWPOmHaLqbCL2Y8kyyNaTGEHQ/COCH8GyzpMb6MHsoYh8XGv+PlI3vT
PQwh7Ekn8mGUd9OpV6EDqXWPnmo8QvtgTThHM8NhtgaJRjMCAwEAAaN0MHIwIAYD
VR0RBBkwF4EVY29yZG92YUBtYXRyaXguY29tLmJyMDsGCWCGSAGG+EIBDQQuFixT
aW1wbGVDQSBnZW5lcmF0ZWQgY3VzdG9tIHNlcnZlciBjZXJ0aWZpY2F0ZTARBglg
hkgBhvhCAQEEBAMCBkAwDQYJKoZIhvcNAQEEBQADgYEAG88APgugIOIv++Y2aMMZ
D4iyENtTz2YD6enDyI7aHBdbuo3pPGH7w9VA2sjKQ37djFp6TPI5a2ULbhIUA9ew
tl3jqE5H4spXi5kF1qMNyQBhkOnOYz7e8WI+vidhZsT6/Bn1S/xAODeH2cpwYhki
6ZKGywA0JJ58ndLd6aXCVow=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-
binding"
Location="https://shib-idp.dalcoquio.com.br:8443/shibboleth-
idp/AA"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
</AttributeAuthorityDescriptor>
<Organization>
<OrganizationName xml:lang="en">IdP InBrazil</OrganizationName>
<OrganizationDisplayName xml:lang="en">IdP
InBrazil</OrganizationDisplayName>
116
<OrganizationURL
xml:lang="en">http://www.dalcoquio.com.br/</OrganizationURL>
</Organization>
<ContactPerson contactType="technical">
<SurName>Andre Cordova</SurName>
<EmailAddress>[email protected]</EmailAddress>
</ContactPerson>
</EntityDescriptor>
<EntityDescriptor entityID="https://shib-
sp.dalcoquio.com.br/shibboleth/inbrazil/sp">
<SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIE7jCCA9agAwIBAgIJAKqRt5l/XPydMA0GCSqGSIb3DQEBBQUAMIGqMQswCQYD
VQQGEwJCUjEXMBUGA1UECBMOU2FudGEgQ2F0YXJpbmExDzANBgNVBAcTBkl0YWph
aTEbMBkGA1UEChMSSW5CcmF6aWwgRmVkZXJhY2FvMQswCQYDVQQLEwJUSTEhMB8G
A1UEAxMYc2hpYi1zcC5kYWxjb3F1aW8uY29tLmJyMSQwIgYJKoZIhvcNAQkBFhVj
b3Jkb3ZhQG1hdHJpeC5jb20uYnIwHhcNMDYxMDEyMTgzMzQxWhcNMTYxMDA5MTgz
MzQxWjCBqjELMAkGA1UEBhMCQlIxFzAVBgNVBAgTDlNhbnRhIENhdGFyaW5hMQ8w
DQYDVQQHEwZJdGFqYWkxGzAZBgNVBAoTEkluQnJhemlsIEZlZGVyYWNhbzELMAkG
A1UECxMCVEkxITAfBgNVBAMTGHNoaWItc3AuZGFsY29xdWlvLmNvbS5icjEkMCIG
CSqGSIb3DQEJARYVY29yZG92YUBtYXRyaXguY29tLmJyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7XHJ/O2hfik5X8c1Nk5aMuBrxNOqPrvf8lIfizBP
BvMQfQT5hV8bD4t9HL6UULMsowXEiM3ORAv9kfPbBp0JIAtqpewlXpftLOoSJbWZ
NWss9THwtVYv2ATLaBzpjkny0V58ZJY1i85wnj9ukWKU8oe9ts/wt7xbAi12n5Ec
9E9aLIpUVxGnesd/8F6RA0UaQuzdLd4KYpxUnLzMPfpdewJcpiZGdln64f9ds94J
q6qtq/hVT7pofyaNHx5zK2GAOt586PLD6pIMM+PlYeRzXVRsPSwHs0EzKe0Lgg1Z
E6D14C/dwHHCHFCj7r8hTwlTcAN/QnyJeUJY9gg/zKXNSQIDAQABo4IBEzCCAQ8w
HQYDVR0OBBYEFC0T90wOKH/oOn3VPzHIuyAb1/LbMIHfBgNVHSMEgdcwgdSAFC0T
90wOKH/oOn3VPzHIuyAb1/LboYGwpIGtMIGqMQswCQYDVQQGEwJCUjEXMBUGA1UE
CBMOU2FudGEgQ2F0YXJpbmExDzANBgNVBAcTBkl0YWphaTEbMBkGA1UEChMSSW5C
cmF6aWwgRmVkZXJhY2FvMQswCQYDVQQLEwJUSTEhMB8GA1UEAxMYc2hpYi1zcC5k
YWxjb3F1aW8uY29tLmJyMSQwIgYJKoZIhvcNAQkBFhVjb3Jkb3ZhQG1hdHJpeC5j
b20uYnKCCQCqkbeZf1z8nTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IB
AQBmvs3+bwLUbH8av8p7GFd4AEkyKpVh6soHq/O3qvwDMFYtZ7lBQc/EbxGL0zXd
OGxTi3PdpiGzbiPwtIqNJiYciq3Wzh3bEF8TBi8CA8I2LJTon5aV3vyReshc4LQF
Vrd5nQRjGeIgvY4MpfSDBVG0mqRJmO30cTx1gNsf40wh9khZRSOx3QOL6AsUEawV
DyE8GBXRCE/LG+kBdia+FeeQqbijAlpMo5Jn/omqslRcwxWJqs2PFlaRt4qRWtIp
d//ooVCzXTaN4w+wuZGJg/0HXSHjxHmO1L71/7Ak1i26S7PNsDmHIM76ycq2U2Co
nZSNs2HwIfDUfAuLT26TAv9M
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<AssertionConsumerService index="1" isDefault="true"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://shib-
sp.dalcoquio.com.br/Shibboleth.sso/SAML/POST"/>
<AssertionConsumerService index="2"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
117
Location="https://shib-
sp.dalcoquio.com.br/Shibboleth.sso/SAML/Artifact"/>
<AssertionConsumerService index="1" isDefault="true"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://shib-sp.dalcoquio.com.br/shibboleth-
sp/Shibboleth.sso/SAML/POST"/>
<AssertionConsumerService index="2"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://shib-sp.dalcoquio.com.br/shibboleth-
sp/Shibboleth.sso/SAML/Artifact"/>
</SPSSODescriptor>
<Organization>
<OrganizationName xml:lang="en">InBrazil SP</OrganizationName>
<OrganizationDisplayName xml:lang="en">InBrazil
SP</OrganizationDisplayName>
<OrganizationURL
xml:lang="en">http://www.dalcoquio.com.br/</OrganizationURL>
</Organization>
<ContactPerson contactType="technical">
<SurName>Andre Cordova</SurName>
<EmailAddress>[email protected]</EmailAddress>
</ContactPerson>
</EntityDescriptor>
</EntitiesDescriptor>
Figura 112. Arquivo inbrazil-metadata.xml
B LOGS DO SERVIDOR PROVEDOR DE IDENTIDADE
Os arquivos de log gerados pelos softwares Apache e Shibboleth IdP são identificados nos
apêndices B.1, B.2 e B.3.
B.1. LOG DO APACHE
A Figura 113 apresenta o arquivo apache_ssl.log gerado pelo software Apache que foi
instalado no provedor de identidade.
[09/Nov/2006:00:00:31 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET /shibboleth-
idp/SSO?shire=https%3A%2F%2Fshib-sp.dalcoquio.com.br%2FShibboleth.sso%2
FSAML%2FPOST&time=1163037600&target=cookie&providerId=https%3A%2F%2Fshib-
sp.dalcoquio.com.br%2Fshibboleth%2Finbrazil%2Fsp HTTP/1.1" 1495
[09/Nov/2006:00:00:32 -0200] 200.180.83.4 SSLv3 RC4-MD5 "POST /cgi-
bin/login/index.cgi HTTP/1.1" 3684
[09/Nov/2006:00:00:33 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET /cgi-
bin/login/media/pubcookie.css HTTP/1.1" 729
[09/Nov/2006:00:00:41 -0200] 200.180.83.4 SSLv3 RC4-MD5 "POST /cgi-
bin/login/index.cgi HTTP/1.1" 1230
[09/Nov/2006:00:00:42 -0200] 200.180.83.4 SSLv3 RC4-MD5 "POST /PubCookie.reply
HTTP/1.1" 372
[09/Nov/2006:00:00:43 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET /shibboleth-
idp/SSO?shire=https%3A%2F%2Fshib-sp.dalcoquio.com.br%2FShibboleth.sso%2
FSAML%2FPOST&time=1163037600&target=cookie&providerId=https%3A%2F%2Fshib-
sp.dalcoquio.com.br%2Fshibboleth%2Finbrazil%2Fsp HTTP/1.1" 6900
[09/Nov/2006:00:00:46 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET /shibboleth-
idp/main.css HTTP/1.1" -
[09/Nov/2006:00:00:52 -0200] 200.247.167.26 SSLv3 DHE-RSA-AES256-SHA "POST
/shibboleth-idp/AA HTTP/1.1" 1607
Figura 113. Arquivo apache_ssl.log
119
B.2. LOG DO SHIBBOLETH
A Figura 114 apresenta o arquivo shib-access.log gerado pelo software Shibboleth IdP.
2006-11-09 00:00:43,658 Authentication assertion issued to provider
(https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp) on
behalf of principal (andre.cordova). Name Identifier:
(_c074fa1029a95689ff1ebd5381f8a646). Name Identifier Format:
(urn:mace:shibboleth:1.0:nameIdentifier).
2006-11-09 00:00:53,225 Attribute assertion generated for provider
(https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp) on
behalf of principal (andre.cordova) with the following attributes:
(urn:mace:dir:attribute-def:eduPersonAffiliation)
2006-11-09 00:00:53,230 Attribute assertion issued to provider (https://shib-
sp.dalcoquio.com.br/shibboleth/inbrazil/sp) on
behalf of principal (andre.cordova).
Figura 114. Arquivo shib-access.log
B.3. LOG DO SHIBBOLETH
A Figura 115 apresenta o arquivo shib-error.log gerado pelo software Shibboleth IdP.
2006-11-09 00:00:43,600 DEBUG [IdP] 259314732 - Received a request via GET for location (https://shib-idp.dalcoquio.com.br/shibboleth-idp/SSO). 2006-11-09 00:00:43,602 DEBUG [IdP] 259314732 - Matched handler location: (https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO). 2006-11-09 00:00:43,603 INFO [IdP] 259314732 - Processing Shibboleth v1.x SSO request. 2006-11-09 00:00:43,604 DEBUG [IdP] 259314732 - Remote provider has identified itself as: (https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp). 2006-11-09 00:00:43,605 INFO [IdP] 259314732 - Found matching Relying Party for group (urn:mace:dalcoquio.com.br:inbrazil). 2006-11-09 00:00:43,605 INFO [IdP] 259314732 - Provider is a member of Relying Party (urn:mace:dalcoquio.com.br:inbrazil). 2006-11-09 00:00:43,606 INFO [IdP] 259314732 - Supplied consumer URL validated for this provider. 2006-11-09 00:00:43,607 DEBUG [IdP] 259314732 - Found a supported name identifier format that matches the metadata for the relying party: (urn:mace:shibboleth:1.0:nameIdentifier). 2006-11-09 00:00:43,608 DEBUG [IdP] 259314732 - Assigning handle (_c074fa1029a95689ff1ebd5381f8a646) to principal (andre.cordova). 2006-11-09 00:00:43,609 DEBUG [IdP] 259314732 - User was authenticated via the default method for this relying party (urn:oasis:names:tc:SAML:1.0:am:unspecified). 2006-11-09 00:00:43,610 DEBUG [IdP] 259314732 - Responding with POST profile. 2006-11-09 00:00:43,613 DEBUG [IdP] 259314732 - Dumping generated AuthN Assertion: 2006-11-09 00:00:43,645 DEBUG [IdP] 259314732 - Dumping generated SAML Response: 2006-11-09 00:00:52,022 DEBUG [IdP] -85853010 - Received a request via POST for location (https://shib-idp.dalcoquio.com.br:8443/shibboleth-idp/AA). 2006-11-09 00:00:52,029 DEBUG [IdP] -85853010 - Dumping generated SAML Request: 2006-11-09 00:00:52,030 DEBUG [IdP] -85853010 - Matched handler location: (.+:8443/shibboleth-idp/AA).
120
2006-11-09 00:00:52,031 INFO [IdP] -85853010 - Processing SAML v1.1 Attribute Query request. 2006-11-09 00:00:52,039 INFO [IdP] -85853010 - Request contains credentials: (1.2.840.113549.1.9.1=#1615636f72646f7661406d61747269782e636f6d2e6272,CN=shib-sp.dalcoquio.com.br,OU=TI,O=InBrazil Federacao,L=Itajai,ST=Santa Catarina,C=BR). 2006-11-09 00:00:52,040 INFO [IdP] -85853010 - Remote provider has identified itself as: (https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp). 2006-11-09 00:00:52,041 INFO [IdP] -85853010 - Metadata found for providerId: (https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp). 2006-11-09 00:00:52,041 DEBUG [IdP] -85853010 - Attempting to match X509 certificate. 2006-11-09 00:00:52,044 DEBUG [IdP] -85853010 - Match successful. 2006-11-09 00:00:52,045 INFO [IdP] -85853010 - Supplied credentials validated for this provider. 2006-11-09 00:00:52,046 DEBUG [IdP] -85853010 - Mapping authenticated provider (https://shib-sp.dalcoquio.com.br/shibboleth/inbrazil/sp) to Relying Party. 2006-11-09 00:00:52,047 INFO [IdP] -85853010 - Found matching Relying Party for group (urn:mace:dalcoquio.com.br:inbrazil). 2006-11-09 00:00:52,048 INFO [IdP] -85853010 - Provider is a member of Relying Party (urn:mace:dalcoquio.com.br:inbrazil). 2006-11-09 00:00:52,048 DEBUG [IdP] -85853010 - Name Identifier format: (urn:mace:shibboleth:1.0:nameIdentifier). 2006-11-09 00:00:52,049 DEBUG [IdP] -85853010 - Attribute Query Handle recognized. 2006-11-09 00:00:52,050 INFO [IdP] -85853010 - Request is for principal (andre.cordova). 2006-11-09 00:00:52,051 INFO [IdP] -85853010 - Request does not designate specific attributes, resolving all available. 2006-11-09 00:00:52,065 DEBUG [IdP] -85853010 - Loading XML from (null) with Schema validation 2006-11-09 00:00:52,070 DEBUG [IdP] -85853010 - Loading XML from (null) with Schema validation 2006-11-09 00:00:52,095 DEBUG [IdP] -85853010 - Creating effective ARP from (2) polic(y|ies). 2006-11-09 00:00:52,583 DEBUG [IdP] -85853010 - Dumping ARP: 2006-11-09 00:00:52,621 DEBUG [IdP] -85853010 - Dumping ARP: 2006-11-09 00:00:52,630 DEBUG [IdP] -85853010 - Computed possible attribute release set. 2006-11-09 00:00:52,631 DEBUG [IdP] -85853010 - Possible attribute: urn:mace:dir:attribute-def:eduPersonAffiliation 2006-11-09 00:00:52,632 DEBUG [IdP] -85853010 - Possible attribute: idp:urn:mace:dir:attribute-def:eduPersonAffiliation 2006-11-09 00:00:52,633 WARN [IdP] -85853010 - No PlugIn registered for attribute: (idp:urn:mace:dir:attribute-def:eduPersonAffiliation) 2006-11-09 00:00:52,634 INFO [IdP] -85853010 - Resolving attribute: (urn:mace:dir:attribute-def:eduPersonAffiliation) 2006-11-09 00:00:52,635 DEBUG [IdP] -85853010 - Attribute (urn:mace:dir:attribute-def:eduPersonAffiliation) depends on connector (directory). 2006-11-09 00:00:52,681 DEBUG [IdP] -85853010 - Resolving attribute: (urn:mace:dir:attribute-def:eduPersonAffiliation) 2006-11-09 00:00:52,683 DEBUG [IdP] -85853010 - Found value(s) for attribute (urn:mace:dir:attribute-def:eduPersonAffiliation). 2006-11-09 00:00:52,688 INFO [IdP] -85853010 - Applying Attribute Release Policies. 2006-11-09 00:00:52,690 DEBUG [IdP] -85853010 - Processing the following attributes: 2006-11-09 00:00:52,693 DEBUG [IdP] -85853010 - Attribute: (urn:mace:dir:attribute-def:eduPersonAffiliation) 2006-11-09 00:00:52,697 DEBUG [IdP] -85853010 - Loading XML from (null) with Schema validation 2006-11-09 00:00:52,705 DEBUG [IdP] -85853010 - Loading XML from (null) with Schema validation 2006-11-09 00:00:52,738 DEBUG [IdP] -85853010 - Creating effective ARP from (2) polic(y|ies). 2006-11-09 00:00:53,203 DEBUG [IdP] -85853010 - Dumping ARP: 2006-11-09 00:00:53,222 DEBUG [IdP] -85853010 - Dumping ARP: 2006-11-09 00:00:53,224 INFO [IdP] -85853010 - Found 1 attribute(s) for
121
andre.cordova 2006-11-09 00:00:53,229 DEBUG [IdP] -85853010 - Dumping generated SAML Response: 2006-11-09 00:00:53,230 INFO [IdP] -85853010 - Successfully created response for principal (andre.cordova).
Figura 115. Arquivo shib-error.log
C LOGS DO SERVIDOR PROVEDOR DE SERVIÇO
Os arquivos de log gerados pelos softwares instalados no servidor provedor de serviço são
identificados nos apêndices C.1, C.2 e C.3.
C.1. LOG DO APACHE
A Figura 116 apresenta o arquivo apache_ssl.log gerado pelo software Apache que foi
instalado no servidor provedor de serviço.
[09/Nov/2006:00:00:00 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/inbrazil/appl/protected_appl/upload.php HTTP/1.1" 509
[09/Nov/2006:00:00:48 -0200] 200.180.83.4 SSLv3 RC4-MD5 "POST
/Shibboleth.sso/SAML/POST HTTP/1.1" 346
[09/Nov/2006:00:00:50 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/inbrazil/appl/protected_appl/upload.php HTTP/1.1" 1641
Figura 116. Arquivo apache_ssl.log
C.2. LOG DO SHIBBOLETH
A Figura 117 apresenta o arquivo shibd.log gerado pelo software Shibboleth SP.
2006-11-09 00:00:48 INFO Shibboleth.Trust.Basic [192] sessionNew: signature
verified with KeyDescriptor
2006-11-09 00:00:48 INFO shibtarget.Listener [192] sessionNew: creating new
session
2006-11-09 00:00:48 INFO shibtarget.SessionCache [192] sessionNew: new session
created with session ID (_62d912ab7a24ab62a94358c2d386d0de)
2006-11-09 00:00:50 INFO shibtarget.SessionCache [193] sessionGet: trying to get
new attributes for session (ID=_62d912ab7a24ab62a94358c2d386d0de)
2006-11-09 00:00:50 INFO SAML.SAMLSOAPHTTPBinding [193] sessionGet: sending SOAP
message to https://shib-idp.dalcoquio.com.br:8443/shibboleth-idp/AA
2006-11-09 00:00:50 INFO Shibboleth.Trust.Basic [193] sessionGet: certificate
match found in KeyDescriptor
Figura 117. Arquivo shibd.log
123
C.3. LOG DO SHIBBOLETH
A Figura 118 apresenta o arquivo transaction.log gerado pelo software Shibboleth SP.
2006-11-09 00:00:48 INFO Shibboleth-TRANSACTION : New session (ID: _62d912ab7a24ab62a94358c2d386d0de) with (applicationId: default) for principal from (IdP: https://shib-idp.dalcoquio.com.br/shibboleth/inbrazil/idp) at (ClientAddress: 200.180.83.4) with (NameIdentifier: _c074fa1029a95689ff1ebd5381f8a646) 2006-11-09 00:00:50 INFO Shibboleth-TRANSACTION : Making attribute query for session (ID: _62d912ab7a24ab62a94358c2d386d0de) on (applicationId: default) for principal from (IdP: https://shib-idp.dalcoquio.com.br/shibboleth/inbrazil/idp) 2006-11-09 00:00:52 INFO Shibboleth-TRANSACTION : Caching the following attributes after AAP applied for session (ID: _62d912ab7a24ab62a94358c2d386d0de) on (applicationId: default) for principal from (IdP: https://shib-idp.dalcoquio.com.br/shibboleth/inbrazil/idp) { 2006-11-09 00:00:52 INFO Shibboleth-TRANSACTION : urn:mace:dir:attribute-def:eduPersonAffiliation (1 values) 2006-11-09 00:00:52 INFO Shibboleth-TRANSACTION : } 2006-11-09 00:00:52 INFO Shibboleth-TRANSACTION : Successful attribute query for session (ID: _62d912ab7a24ab62a94358c2d386d0de)
Figura 118. Arquivo transaction.log
D LOG DO SERVIDOR WAYF
O arquivo de log gerado pelo software instalado no servidor WAYF é identificado no
apêndice D.1.
D.1. LOG DO APACHE
A Figura 119 apresenta o arquivo apache_ssl.log gerado pelo software Apache que foi
instalado no servidor WAYF.
[09/Nov/2006:00:00:03 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/WAYF.php?shire=https%3A%2F%2Fshib-sp.dalcoquio.com.br%2FShibboleth.sso%2FSAML%2
FPOST&time=1163037600&target=cookie&providerId=https%3A%2F%2Fshib-
sp.dalcoquio.com.br%2Fshibboleth%2Finbrazil%2Fsp HTTP/1.1" 6040
[09/Nov/2006:00:00:05 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/topcenter.gif HTTP/1.1"
[09/Nov/2006:00:00:08 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/topleft.gif HTTP/1.1"
[09/Nov/2006:00:00:09 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/topright.gif HTTP/1.1"
[09/Nov/2006:00:00:10 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/middleleft.gif HTTP/1.1"
[09/Nov/2006:00:00:10 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/middleright.gif HTTP/1.1"
[09/Nov/2006:00:00:11 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/bottomcenter.gif HTTP/1.1"
[09/Nov/2006:00:00:12 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/bottomright.gif HTTP/1.1"
[09/Nov/2006:00:00:20 -0200] 200.180.83.4 SSLv3 RC4-MD5 "GET
/images/bottomleft.gif HTTP/1.1"
[09/Nov/2006:00:00:23 -0200] 200.180.83.4 SSLv3 RC4-MD5 "POST
/WAYF.php?shire=https%3A%2F%2Fshib-sp.dalcoquio.com.br%2FShibboleth.sso%2FSAML%2
FPOST&time=1163037600&target=cookie&providerId=https%3A%2F%2Fshib-
sp.dalcoquio.com.br%2Fshibboleth%2Finbrazil%2Fsp HTTP/1.1"
Figura 119. Arquivo apache_ssl.log
ANEXOS
I LISTA DE APLICAÇÕES E SERVIÇOS QUE UTILIZAM O SHIBBOLETH
Organization / URL Contact Comments
Blackboard www.blackboard.com
Chris Etesse [email protected]
Production Blackboard has the ability to consume Shibboleth credentials.
Bodington.org bodington.org
Bodington.org [email protected]
Production Open Source sourceforge.net/projects/bodington/ Bodington is open source software that the worldwide academic community can use for free and can contribute to its development. Bodington powers virtual learning environments in the UK and worldwide. Bodington is being used by educational institutions, including: University of the Highlands and Islands, University of Leeds, University of Oxford, University of Manchester, Eton College and Yorkshire Coast College. As of the 2.4 release series, Bodington has Shib IdP functionality out of the box. With users in the Bodington local database, you can easily manage a set of users for your IdP and can even point Bodington to authenticate those users via an external LDAP store through a simple xml configuration file. Bodington is also a very quick and easy way to test Shib IdP functions through a simple install process.
Darwin Streaming Server Gary Chapman [email protected] Jerome McDonough [email protected]
Production Open Source An Open Source version of Apple's Quicktime Streaming Server has been shib-enabled by Gary and Jerome at NYU.
Digitalbrain PLC www.digitalbrain.com
Customer Support Team [email protected]
Production Digitalbrain is a UK based provider of virtual learning envionments (VLE). Their VLE
127
can fully participate in a federation as both an IdP and/or an SP
EBSCO Publishing www.epnet.com/default.asp support.epnet.com
Alison Galati, Service Engineer [email protected]
Technical Support [email protected]
Production Shibboleth authentication is now available for EBSCOhost databases.
Elsevier ScienceDirect www.sciencedirect.com
Ale de Vries [email protected]
Production Shibboleth authentication is now in production and available on ScienceDirect.
ExLibris - SFX Oren Beit-Arie [email protected]
Development ExLibris - SFX plans to do testing this summer. They will be looking for campuses to work with.
Fedora www.fedora.info
Ronda A. Grizzle [email protected]
Development OpenSource Project Shibboleth will be incorporated in V.2 of Fedora due Q4 2004.
Horde www.protectnetwork.org/horde.html
Horde Shibboleth Team [email protected]
Development OpenSource Project Module has been delivered this to the Horde Project but not sure when they will include it as part of their standard release...
Hupnet hupnet.sourceforge.net
Viljo Viitanen [email protected]
Production OpenSource Project Hupnet (Helsinki University Public Network) is a free network access controller (NAC) software using WWW authentication, especially Shibboleth.
ILIAS www.ilias.de
Alex Killling Lead Developer [email protected]
Testing OpenSource Project ILIAS is an open source web-based learning management system. ILIAS 3.5 contains Shibboleth support and will be released soon. The Shibboleth attributes are used for authentication and for automatically creating user accounts. more...
JSTOR www.jstor.org
Stephen Martin, JSTOR User Services Technical Assistant
Testing JSTOR is testing access via Shib
128
Moodle www.moodle.org
Martin Dougiamas Moodle Lead Developer [email protected] Shibboleth module developers: Markus Hagman [email protected] Lukas Haemmerle [email protected]
Testing OpenSource Project Moodle is an open source web-based learning management system. Shibboleth is supported bye Moodle version 1.5 onward. The Shibboleth attributes are used for authentication and for automatically creating user accounts. more...
Napster www.napster.com
William Pence [email protected]
Production Napster is in production use.
NSDL David Milman [email protected]
Production
OCLC The Shibboleth Support Team [email protected]
Production Shibboleth authentication is now in production and available for OCLC FirstSearch.
OLAT - Online Learning and Training www.olat.org
Production In production at universities in Switzerland. Open Source Includes integrated, Java-based Shibboleth 1.3 Target implementation including WAYF server. Shibboleth attributes are propagated within the LMS for customization and access control.
ProQuest Information and Learning www.il.proquest.com
Rodger Miller [email protected]
Development ProQuest is working on a Shibbolether pilot with a few campus members.
Serials Solutions, Inc. www.serialssolutions.com
JR Jenkins [email protected]
Development Will begin testing in Q4 of 2005 for it's hosted application suite.
SYMPA www.sympa.org
Olivier Salaun [email protected]
Production Open source Shib user attributes are used by Sympa for both customization and access control
129
Thomson Gale www.gale.com
Gary Pollack [email protected]
Testing Thomson Gale has released Shibboleth authentication services for its databases and is testing in production.
TWiki Production Open Source
Useful Utilities - EZproxy www.usefulutilities.com
Chris Zagar [email protected]
Pilot A beta version of EZproxy that acts as a Service Provider is available for testing.
WebAssign www.webassign.net
Brian Marks [email protected]
Production WebAssign, a homework and grading service for higher ed math and sciences courses, is currently servicing several universities using Shibboleth both for student/faculty authentication and for roster creation. We encourage universities using WebAssign to contact us about Shibboleth integration
WebCT www.webct.com/standards
Mark Wilcox [email protected]
Production WebCT supports Shibboleth with both Campus Edition and Vista products. Please contact us to obtain a copy of the Shibboleth/WebCT integration guide.
II SAML SCHEMA DE CONFIRMAÇÃO DE AUTENTICAÇÃO DO USUÁRIO
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="a75adf55-01d7-40cc-929f-dbd8372ebdfc"
IssueInstant="2004-12-05T09:22:02Z"
Issuer="https://idp.example.org/shibboleth">
<saml:Conditions
NotBefore="2004-12-05T09:17:02Z"
NotOnOrAfter="2004-12-05T09:27:02Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>http://sp.example.org/shibboleth</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AuthenticationStatement
AuthenticationInstant="2004-12-05T09:22:00Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier
Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="https://idp.example.org/shibboleth">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#c7055387-af61-4fce-8b98-e2927324b306">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped409
signature"/>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces
PrefixList="#default saml samlp ds xsd xsi"
xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>TCDVSuG6grhyHbzhQFWFzGrxIPE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
131
<ds:SignatureValue>
x/GyPbzmFEe85pGD3c1aXG4Vspb9V9jGCjwcRCKrtwPS6vdVNCcY5rHaFPYWkf+5
EIYcPzx+pX1h43SmwviCqXRjRtMANWbHLhWAptaK1ywS7gFgsD01qjyen3CP+m3D
w6vKhaqledl0BYyrIzb4KkHO4ahNyBVXbJwqv5pUaE4=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0Eg
LS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsx
CzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFy
Ym9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVk
dTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJj
IHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+
c2MZVeXeTgV3Yz+USLg2Y1on+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE
pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkq
hkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2n
qgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX
8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>