Shibboleth [35] ´e um sistema de SSO, baseado em formatos abertos, principalmente SAML. ´E um sistema federado, suportando um acesso seguro a recursos em v´arios dom´ınios. As chamadas federac¸˜oes podem servir para v´arios servidores de recursos confiarem entre si duma forma escal´avel. Entres estes servidores, numa federac¸˜ao, podem ser trocadas informac¸˜oes de identidade, direitos e atributos de utilizadores. O projecto Internet2 Shib- boleth comec¸ou em 2000, sendo que a vers˜ao 1.0 foi apenas lanc¸ada em 2003 e a vers˜ao 2.0 foi lanc¸ada em Marc¸o de 2008.
O Shibboleth tem dois componentes essenciais para o seu funcionamento: um Identity Provider (IdP) e um Service Provider (SP). O IdP tem como func¸˜ao principal responder a pedidos de informac¸˜ao sobre utilizadores. O SP utiliza esta informac¸˜ao para proteger os recursos. A componente IdP apenas necessita um servidor Web que seja capaz de correr servlets Java, como o Apache Tomcat ou JBoss e o Java JDK. Para o componente SP, existem m´odulos para os servidores aplicacionais Apache Web Server e IIS.
Como se pode ver na figura 3.2, um utilizador n˜ao autenticado ao tentar aceder a um recurso protegido ´e redireccionado para a p´agina de WAYF (“Where Are You From?”), cujo objectivo ´e canalizar os utilizadores n˜ao autenticados para as respectivas instituic¸˜oes de origem, ou seja, escolher o IdP onde as suas credenciais s˜ao mantidas (passos 1-3).
Ap´os a selecc¸˜ao, por parte do utilizador, da sua instituic¸˜ao, este servic¸o redirecciona o utilizador automaticamente para a p´agina de login do IdP da sua instituic¸˜ao (passos 4-6) . Se a autenticac¸˜ao for feita com sucesso, este IdP vai preparar a informac¸˜ao protegida para ser enviada para o recurso presente no SP, e ´e feito um redireccionamento para o SP juntamente com uma “handle” de autenticac¸˜ao (passos 7-9).
O SP vai receber esta handle e reenvia-a para o IdP, pedindo os atributos do utilizador (passo 10). A handle enviada pelo SP ´e assim verificada pelo IdP e, caso esteja tudo correcto, os atributos do utilizador s˜ao enviados ao recurso (passo 11). Ao receber os atributos, o SP pode tomar uma decis˜ao informada sobre o acesso do utilizador a recursos
protegido (passo 12) [36] [37].
O Shibboleth n˜ao oferece suporte para Single Sign-Out, recomendando que o browser Web seja fechado pelo utilizador quando este desejar terminar a sess˜ao.
Figura 3.2: Arquitectura de autenticac¸˜ao inicial e envio de atributos do Shibboleth
3.3
simpleSAMLphp
simpleSAMLphp [38] ´e uma aplicac¸˜ao escrita totalmente em PHP que agrega mecanismos de autenticac¸˜ao e protocolos de federac¸˜ao, podendo ser utilizado como Identity Provider e/ou Service Provider.
Esta aplicac¸˜ao suporta protocolos SAML 2.0 e Shibboleth 1.3 para ambos Identity Provider, IdP, e Service Provider, SP. A arquitectura de autenticac¸˜ao e autorizac¸˜ao desta aplicac¸˜ao, ´e, portanto, igual `a do Shibboleth. O simpleSAMLphp permite ainda a utilizac¸˜ao de mecanismos de autenticac¸˜ao SSO alternativos para o IdP, como ´e o caso do Jasig CAS, Twitter ou OpenId.
Cap´ıtulo 3. Soluc¸˜oes Single Sign-On 21
Server com o m´odulo PHP instalado e configurado com as extens˜oes zlib, OpenSSL, CURL e LDAP.
3.4
Pubcookie
Pubcookie [30] ´e um sistema de autenticac¸˜ao proveniente da Universidade de Washing- ton, que consiste apenas num servidor de login e filtros para servidores aplicacionais. O servidor de login requer apenas que haja um suporte para scripts CGI (Common Gateway Interface). CGI ´e um standard Web [4] que define como um software de um servidor Web delega a criac¸˜ao de p´aginas Web a uma aplicac¸˜ao. Estas aplicac¸˜oes tˆem o nome de scripts CGI, e podem ser escritas em qualquer linguagem de programac¸˜ao. Noutras palavras, ´e uma interface entre servidores Web e clientes. Por outro lado, os m´odulos do Pubcookie existem apenas para Apache Web Server ou Microsoft IIS, estando assim os servic¸os limitados ao uso destes servidores aplicacionais.
Figura 3.3: Arquitectura de autenticac¸˜ao inicial com Pubcookie
Como se pode observar na figura 3.3, o processo de autenticac¸˜ao comec¸a, habitual- mente, com um pedido de um utilizador a um recurso protegido pelo filtro Pubcookie (passo 1). Este filtro ao verificar que o utilizador ainda n˜ao efectuou a autenticac¸˜ao no servidor de login, ir´a criar dois cookies, um cookie de pr´e-sess˜ao associado ao recurso
pretendido e um Granting Request Cookie associado ao servidor de login e redirecciona o utilizador para a p´agina de login (passos 2-4).
Depois de se autenticar com sucesso, ´e gerado um Granting Cookie, contendo o nome de utilizador e um n´umero aleat´orio recebido do servidor aplicacional via Grant- ing Request Cookie, e um Login Cookie para ser utilizado em pedidos subsequentes de autenticac¸˜ao (passos 5-6). Este Granting Cookie est´a protegido contra modificac¸˜oes ao ser assinado pela chave privada do servidor de login, e protegido contra revelac¸˜ao ao ser cifrado com uma chave sim´etrica secreta partilhada entre o servidor aplicacional e o servidor de login. O utilizador ´e agora redireccionado para o recurso original, mas agora fazendo um pedido com o Granting Cookie e o Cookie de pr´e-sess˜ao (passo 7).
O filtro do servidor aplicacional intercepta novamente o pedido, verificando agora o Granting Cookiee o cookie de pr´e-sess˜ao. O filtro verifica a assinatura usando a chave p´ublica do servidor de login e compara o n´umero aleat´orio contido no Granting Cookie com n´umero aleat´orio contido no cookie de pr´e-sess˜ao. Se ambos os cookies s˜ao v´alidos, o filtro envia o nome de utilizador para a aplicac¸˜ao juntamente com o resto do pedido orig- inal. O filtro gera tamb´em uma cookie de sess˜ao para pedido subsequentes do utilizador `a aplicac¸˜ao. Tendo autenticado com sucesso o utilizador, a aplicac¸˜ao pode finalmente enviar o recurso originalmente pedido (passo 8).
Se o Granting Request Cookie for acompanhado por um j´a estabelecido, e v´alido, Login Cookie, o utilizador j´a n˜ao necessita de se autenticar novamente, comec¸ando assim a experiˆencia de SSO [31].
O Pubcookie n˜ao fornece qualquer tipo de mecanismo para autorizac¸˜ao ou Single Sign-Out.