U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
SINGLE SIGN-ON NA FCUL
Francisco Wallenstein Teixeira Estanqueiro
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Sistemas de Informac¸˜ao
U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
SINGLE SIGN-ON NA FCUL
Francisco Wallenstein Teixeira Estanqueiro
PROJECTO
Projecto orientado pelo Prof. Doutor M´ario Jo˜ao Barata Calha e co-orientado pelo Lic. Pedro Miguel Gomes Silva Rosa
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Sistemas de Informac¸˜ao
Resumo
Este projecto insere-se no ˆambito da cadeira de Projecto em Engenharia Inform´atica (PEI) do Mestrado de Engenharia Inform´atica da Faculdade de Ciˆencias da Universidade de Lisboa (FCUL).
Este trabalho teve como principal objectivo a criac¸˜ao de um sistema de Single Sign-On (SSO) para as aplicac¸˜oes web disponibilizadas pelo Centro de Inform´atica (CI) da FCUL.
Single Sign-On (SSO) ´e um processo de autenticac¸˜ao em sess˜ao, que permite a um utilizador introduzir as suas credenciais de acesso apenas uma vez para aceder a m´ultiplas aplicac¸˜oes protegidas. O processo autentica o utilizador para todas as aplicac¸˜oes a que este tem direito de acesso e elimina a necessidade de se autenticar novamente ao mudar de aplicac¸˜ao durante a sess˜ao. Deste modo, toda a autenticac¸˜ao passar´a a ser feita de um modo centralizado, ficando o servic¸o de SSO com a responsabilidade de fornecer informac¸˜ao confi´avel de identidade dos utilizadores `as aplicac¸˜oes.
De forma a atingir os objectivos propostos, foi necess´ario estudar com detalhe o estado da arte, assim como as poss´ıveis soluc¸˜oes para a implementac¸˜ao de um sistema deste g´enero, tendo j´a em conta os requisitos das aplicac¸˜oes web na FCUL. Esta an´alise levou `a escolha do software Central Authentication Service (CAS) que, ap´os os devidos testes, entrou em produc¸˜ao no CI, tendo mais de mil acessos di´arios por funcion´arios e alunos da FCUL.
Adicionalmente, foi criado um novo modo de introduc¸˜ao de credenciais atrav´es do Cart˜ao de Cidad˜ao Portuguˆes, um sistema de autenticac¸˜ao para servic¸os federados e uma aplicac¸˜ao web para uma gest˜ao eficaz de todo o sistema de SSO.
Palavras-chave: single sign-on, aplicac¸˜oes web, central authentication service, cart˜ao de cidad˜ao portuguˆes, autenticac¸˜ao federada
Abstract
This document describes in detail the project set up for the module of Computer En-gineering Project (PEI) integrating the postgraduate programme for Master of Computer Engineering in the Faculty of Science of the Lisbon University (FCUL).
This project was primarily aimed at the analysis and development of a Single Sign-On (SSO) system for web applications made available by the IT Centre (CI) at FCUL.
Single Sign-On (SSO) is a session authentication process, which allows a user to enter their credentials only once to access multiple protected applications. The process authenticates the user for all applications which he’s entitled to access to, eliminating the need to authenticate again when changing applications during the same session. With an SSO solution, all authentication is done in a centralized manner, thus making it the responsibility of the SSO system to provide reliable information about the user’s identity to the web applications.
In order to achieve these objectives, it was necessary to examine in detail the state of the art and study the potential solutions to implementing this kind of service.
After detailed analysis, Central Authentication Service (CAS) was selected as the SSO system. Following an appropriate testing stage, the CAS was effectively made available at FCUL campus, counting over a thousand daily logins among FCUL staff and students. To expand the SSO system it was also created an alternative way to authenticate users using the Portuguese Citizen Card, a federated authentication system and a web applica-tion to manage the entire system.
Keywords: single sign-on, web applications, central authentication service, portuguese citizen card, federated authentication
Conte ´udo
Lista de Figuras xi
Lista de Tabelas xiii
1 Introduc¸˜ao 1 1.1 Motivac¸˜ao . . . 1 1.2 Objectivos . . . 2 1.3 Instituic¸˜ao de Acolhimento . . . 2 1.4 Contribuic¸˜oes . . . 3 1.5 Estrutura do documento . . . 3
2 Estado da Arte e Conceitos 5 2.1 Single Sign-On . . . 5
2.1.1 Vantagens . . . 7
2.1.2 Desvantagens . . . 7
2.2 Arquitecturas de Single Sign-On . . . 8
2.2.1 Pseudo SSO . . . 8 2.2.2 SSO Centralizado . . . 9 2.2.3 SSO Federado . . . 9 2.3 Tecnologias Relacionadas . . . 11 2.3.1 LDAP . . . 11 2.3.2 Active Directory . . . 12 2.3.3 Certificados X.509 . . . 12 2.3.4 Cart˜ao de Cidad˜ao . . . 13
2.3.5 Security Assertions Markup Language - SAML . . . 13
2.3.6 Cookies HTTP . . . 14
2.3.7 Kerberos . . . 14
2.3.8 Secure Socket Layer - SSL . . . 15
3 Soluc¸˜oes Single Sign-On 17 3.1 Central Authentication Service - CAS . . . 17
3.2 Shibboleth . . . 19
3.5 CoSign . . . 22
3.6 WebAuth . . . 24
3.7 Resumo das funcionalidades das soluc¸˜oes SSO . . . 25
4 Single Sign-On na FCUL 27 4.1 Arquitectura de Autenticac¸˜ao na FCUL . . . 27
4.2 Aplicac¸˜oes com necessidade de Single Sign-On . . . 28
4.3 Escolha da soluc¸˜ao Single Sign-On a implementar na FCUL . . . 29
4.4 Arquitectura da soluc¸˜ao escolhida - CAS . . . 31
4.4.1 Autenticac¸˜ao . . . 31
4.4.2 Autorizac¸˜ao . . . 33
4.4.3 Federac¸˜ao . . . 33
4.4.4 Alta Disponbilidade . . . 34
5 Implementac¸˜ao e testes 37 5.1 Implementac¸˜ao Servidor CAS . . . 37
5.1.1 Instalac¸˜ao . . . 37 5.1.2 Configurac¸˜ao . . . 37 5.1.3 Autenticac¸˜ao . . . 38 5.1.4 Autorizac¸˜ao . . . 41 5.1.5 Federac¸˜ao . . . 41 5.1.6 Alta Disponibilidade . . . 41
5.2 Integrac¸˜ao do CAS com as aplicac¸˜oes FCUL . . . 43
5.2.1 Aplicac¸˜oes escritas em PHP . . . 43
5.2.2 Moodle . . . 44
5.2.3 Outlook Web Access . . . 44
5.3 P´agina de Gest˜ao . . . 45
5.4 Testes . . . 47
5.4.1 Funcionais . . . 47
5.4.2 Teste de sobrecarga . . . 49
6 Conclus˜ao e trabalho futuro 53 6.1 Trabalho Futuro . . . 54
A Protocolo CAS 55 A.1 Tickets . . . 55
A.2 URIs . . . 56
A.2.1 Login (/login) . . . 56
A.2.2 Logout (/logout) . . . 58
A.2.3 Validac¸˜ao de Servic¸os (/serviceValidate) . . . 58
A.2.4 Validac¸˜ao de Proxys (/proxyValidate) . . . 59
A.2.5 Proxy (/proxy) . . . 60
Abreviaturas 64
Bibliografia 70
Lista de Figuras
2.1 Sistema sem SSO . . . 5
2.2 Sistema com SSO . . . 6
2.3 Single Sign-On Federado . . . 10
2.4 Exemplo de um direct´orio LDAP . . . 11
3.1 Arquitectura CAS . . . 18
3.2 Arquitectura Shibboleth . . . 20
3.3 Arquitectura Pubcookie . . . 21
3.4 Arquitectura CoSign . . . 23
3.5 Arquitectura WebAuth . . . 25
4.1 Autenticac¸˜ao na FCUL sem Single Sign-On . . . 28
4.2 Autenticac¸˜ao na FCUL com CAS . . . 32
4.3 Arquitectura CAS na FCUL . . . 34
5.1 Certificado de Autenticac¸˜ao do Cart˜ao de Cidad˜ao . . . 39
5.2 Caminho de certificac¸˜ao do certificado de Autenticac¸˜ao do Cart˜ao de Cidad˜ao . . . 39
5.3 P´agina de pesquisa dos registos de auditoria do CAS . . . 46
5.4 P´agina de estat´ısticas do CAS na aplicac¸˜ao de gest˜ao de SSO . . . 47
5.5 Latˆencia de respostas dos servidores CAS a pedidos de autenticac¸˜ao . . . 50
5.6 Latˆencia de respostas dos servidores CAS a pedidos de STs . . . 51
Lista de Tabelas
3.1 Comparac¸˜ao entre as diferentes soluc¸˜oes de SSO . . . 26
4.1 Compatibilidade das diferentes soluc¸˜oes de SSO em relac¸˜ao aos servic¸os da FCUL . . . 30
Cap´ıtulo 1
Introduc¸˜ao
`
A medida que os servic¸os fornecidos pelo Centro de Inform´atica da Faculdade de Ciˆencias v˜ao aumentando, utilizadores e administradores de sistema deparam-se com sistemas cada vez mais complexos. Os utilizadores, habitualmente, tˆem de fazer login em m´ultiplos sis-temas, necessitando assim de um n´umero igual de di´alogos de login, que podem envolver diferentes nomes de utilizador e informac¸˜ao de autenticac¸˜ao. Administradores de sistemas tˆem de gerir essas mesmas contas, dentro dos v´arios sistemas, de uma maneira coorde-nada, de modo a manter a integridade das pol´ıticas de seguranc¸a. Uma soluc¸˜ao para este fardo administrativo ´e a implementac¸˜ao de um servic¸o de Single Sign-On.
Neste cap´ıtulo pretende-se fazer uma breve introduc¸˜ao ao projecto, o seu contexto e os objectivos a alcanc¸ar.
1.1
Motivac¸˜ao
Single Sign-On, SSO, ´e um processo de autenticac¸˜ao em sess˜ao, que permite a um uti-lizador introduzir as suas credenciais de acesso apenas uma vez para aceder a m´ultiplas aplicac¸˜oes protegidas. O processo autentica o utilizador para todas as aplicac¸˜oes a que este tem direito de acesso e elimina a necessidade de se autenticar novamente ao mudar de aplicac¸˜ao durante a sess˜ao.
A maior vantagem no uso de um sistema de SSO ´e deixar de incomodar o utilizador com m´ultiplos pedidos de login, retirando tamb´em a necessidade de decorar m´ultiplos nomes de utilizador e palavras-chave. Do ponto de vista do programador, visto o sis-tema de SSO ser independente, a maior vantagem ´e deixar de se preocupar com toda a autenticac¸˜ao e assumir que, se o pedido para aceder a uma aplicac¸˜ao vem com um nome de utilizador associado, ent˜ao a autenticac¸˜ao j´a foi feita. Quando as aplicac¸˜oes participam num protocolo de SSO, o fardo da administrac¸˜ao de gerir contas ´e bastante simplificado.
N˜ao havendo uma infra-estrutura de autenticac¸˜ao centralizada na FCUL, a maneira dos utilizadores se autenticarem depende das pol´ıticas definidas localmente em cada servic¸o. Um sistema SSO ir´a permitir aos servic¸os da FCUL fazer outsourcing a toda a autenticac¸˜ao,
obrigando a que estes sigam as pol´ıticas de autenticac¸˜ao deste sistema garantindo uma maior seguranc¸a e consistˆencia.
1.2
Objectivos
O principal objectivo deste projecto ´e a concretizac¸˜ao de um sistema de SSO para a autenticac¸˜ao centralizada de utilizadores por parte dos servic¸os web existentes na FCUL. Para que este projecto seja realizado com sucesso ´e necess´ario identificar todas as fases que o envolvem.
A primeira fase ser´a um estudo acerca do tema de SSO, incluindo o estado da arte, as suas poss´ıveis arquitecturas e as soluc¸˜oes que existem para a sua implementac¸˜ao. Dentro deste estudo s˜ao identificadas tamb´em todas as vantagens e desvantagens no uso de um sistema central de autenticac¸˜ao.
Ap´os este estudo, ´e preciso identificar todos os requisitos para a integrac¸˜ao de um sistema de SSO com os servic¸os web disponibilizados pelo CI. Esta an´alise ´e feita de acordo com as aplicac¸˜oes e linguagens de programac¸˜ao utilizadas na FCUL e respectivos servidores aplicacionais onde estas est˜ao a correr.
Identificados os requisitos, ´e feita a escolha do sistema de SSO a implementar na FCUL, focando os pontos fortes desta soluc¸˜ao em relac¸˜ao `as outras analisadas, tendo em conta todos os pr´os e contras.
Ap´os a realizac¸˜ao das fases anteriores, an´alise e especificac¸˜ao, ´e feita a representac¸˜ao abstracta do sistema, descrevendo detalhadamente o seu funcionamento e a sua estrutura. S´o ap´os a conclus˜ao do desenho/arquitectura deste novo sistema ´e poss´ıvel passar para a fase final de implementac¸˜ao, testes e manutenc¸˜ao.
1.3
Instituic¸˜ao de Acolhimento
A Faculdade de Ciˆencias da Universidade de Lisboa, FCUL, ´e uma das unidades orgˆanicas que integram a Universidade de Lisboa. Actualmente, a FCUL ocupa onze edif´ıcios com uma ´area total de 77 492m2, no campus do Campo Grande, e em 2008/2009, tinha 5061 alunos distribu´ıdos pelos v´arios ciclos de ensino e 634 funcion´arios, entre os quais 419 docentes.
O Centro de Inform´atica, CI, ´e a Unidade Orgˆanica da FCUL respons´avel pela gest˜ao da rede Internet, bem como dos diversos servic¸os a ela associados, nomeadamente correio electr´onico e p´aginas Web. A manutenc¸˜ao de alguns sistemas de informac¸˜ao, tais como as bases de dados relativas `a gest˜ao de utilizadores (docentes, funcion´arios e alunos), est´a tamb´em a cargo do CI.
O CI tem ainda a seu cargo o apoio t´ecnico a todos os funcion´arios da FCUL, atrav´es de um servic¸o de Help Desk. Contudo, a prestac¸˜ao de apoio especializado ´e realizada no
Cap´ıtulo 1. Introduc¸˜ao 3
ˆambito de acordos de colaborac¸˜ao com as v´arias unidades orgˆanicas da FCUL [20].
1.4
Contribuic¸˜oes
A principal contribuic¸˜ao deste projecto ´e a concretizac¸˜ao de um sistema de SSO num meio acad´emico, para integrac¸˜ao com v´arias aplicac¸˜oes Web utilizadas diariamente, com neces-sidade de estarem altamente dispon´ıveis para os seus utilizadores. O sistema apresentado neste relat´orio inclui todas as fases da sua concretizac¸˜ao, desde a an´alise de poss´ıveis soluc¸˜oes de software de SSO a utilizar at´e `a gest˜ao e manutenc¸˜ao do sistema escolhido.
Outras importantes contribuic¸˜oes relativas `a autenticac¸˜ao de utilizadores na FCUL s˜ao tamb´em descritas neste relat´orio, incluindo a introduc¸˜ao de uma nova maneira de autenticar utilizadores nos servic¸os Web da FCUL, atrav´es do uso do Cart˜ao de Cidad˜ao Portuguˆes e um Identity Provider (IdP) para sistemas de SSO federados.
1.5
Estrutura do documento
Este documento est´a organizado da seguinte forma:
Cap´ıtulo 2. Estado da Arte e Conceitos - Neste cap´ıtulo, ´e feita a an´alise do estado da arte e os conceitos associados `a mesma.
Cap´ıtulo 3. Soluc¸˜oes Single Sign-On – Neste cap´ıtulo, s˜ao analisadas algumas das soluc¸˜oes open source de SSO para a FCUL.
Cap´ıtulo 4. Single Sign-On na FCUL - Todos os sistemas com necessidade de SSO na FCUL, a escolha da soluc¸˜ao SSO e a respectiva arquitectura, encontram-se neste cap´ıtulo. Cap´ıtulo 5. Implementac¸˜ao e Testes - Todo o trabalho realizado na implementac¸˜ao, testes e integrac¸˜ao do sistema de SSO nos servic¸os da FCUL est´a descrito neste cap´ıtulo. Cap´ıtulo 6. Conclus˜oes - Neste cap´ıtulo, apresentam-se as conclus˜oes finais do pro-jecto, as dificuldades encontradas e o trabalho futuro.
Cap´ıtulo 2
Estado da Arte e Conceitos
2.1
Single Sign-On
Infra-estruturas de autenticac¸˜ao s˜ao bastante populares em sistemas de computadores de grande escala. Em ambientes deste g´enero, n˜ao ´e muito eficiente, do ponto de vista de implementac¸˜ao e administrac¸˜ao, criar um sistema de autenticac¸˜ao separado para cada sistema de computadores, recursos e servidores aplicacionais. ´E bastante melhor delegar esta funcionalidade a uma infra-estrutura de autenticac¸˜ao centralizada. A criac¸˜ao de uma infra-estrutura deste g´enero permite a utilizac¸˜ao de um sistema SSO.
SSO ´e um conceito bastante utilizado em grandes organizac¸˜oes e Intranets, que per-mite aos utilizadores inserirem as suas credenciais apenas uma vez, e verem a sua auten-ticac¸˜ao propagada para todos os servic¸os a que est˜ao autorizados a aceder. Um utilizador, normalmente, utiliza v´arios sites da mesma instituic¸˜ao e cada um deles utiliza mecanismos para autenticac¸˜ao independentes, obrigando, por vezes, o utilizador a decorar nomes de utilizador e/ou palavras-chave diferentes para cada servic¸o (figura 2.1) . Com um servic¸o de SSO, toda a autenticac¸˜ao passar´a a ser feita de um modo centralizado, ficando este com a responsabilidade de fornecer informac¸˜ao confi´avel de identidade dos utilizadores aos servic¸os (figura 2.2).
Figura 2.1: Sistema sem Single Sign-On
Autenticac¸˜ao e autorizac¸˜ao s˜ao dois aspectos cruciais para efectuar controlo de aces-sos num sistema. Quando um utilizador tenta aceder a uma aplicac¸˜ao, o processo de autenticac¸˜ao ´e iniciado e, se este for efectuado com sucesso, ´e seguido do processo de
Figura 2.2: Sistema com Single Sign-On
autorizac¸˜ao.
Autenticac¸˜ao ´e o processo atrav´es do qual as credenciais do utilizador s˜ao verificadas para comprovar a sua identidade. Habitualmente, envolve um nome de utilizador e uma palavra-chave, mas pode ser utilizado outro m´etodo que comprove a identidade do uti-lizador como impress˜oes digitais, reconhecimento de voz ou smart cards.
Para a realizac¸˜ao das tarefas de autenticac¸˜ao s˜ao normalmente utilizados sistemas de gest˜ao de informac¸˜ao de utilizadores, como os servic¸os de direct´orio LDAP (ver secc¸˜ao 2.3.1), autoridades de certificac¸˜ao X.509 (ver secc¸˜ao 2.3.3) ou bases de dados simples como JBDC ou MySQL (entre outros). Estes sistemas mantˆem informac¸˜ao confi´avel e actualizada dos utilizadores para que as aplicac¸˜oes consigam provar a autenticidade das credenciais inseridas pelos utilizadores.
Autorizac¸˜ao, por sua vez, ´e o processo que consiste na verificac¸˜ao das permiss˜oes de um utilizador autenticado para aceder a um recurso espec´ıfico. Normalmente, ´e determi-nada verificando se um utilizador faz parte de um grupo ou se possui determinado n´ıvel de seguranc¸a. Mais formalmente, autorizar ´e definir uma pol´ıtica de controlo de acesso [15].
Para definir controlo de acesso dos utilizadores `as aplicac¸˜oes s˜ao usados sistemas de gest˜ao de informac¸˜ao de autorizac¸˜ao como Lista de controlo de acesso (ACLs) ou Lista de Capacidades (C-List) [12].
Uma ACL ´e uma lista de permiss˜oes associadas a um objecto. Uma ACL espec´ıfica que utilizadores ou processos tˆem acesso aos objectos, e que operac¸˜oes s˜ao permitidas em certos objectos. Cada entrada numa t´ıpica ACL espec´ıfica cont´em o par <sujeito, direitos>. Por exemplo, se uma aplicac¸˜ao cont´em <fwestanqueiro, add> na sua ACL, isto ir´a dar permiss˜ao ao utilizador ”fwestanqueiro”para adicionar dados `a aplicac¸˜ao. Estas ACLs s˜ao, obviamente, protegidas contra modificac¸˜oes n˜ao autorizadas.
Numa C-List, ao contr´ario das ACL, cada sujeito tem uma lista de objectos a que este pode aceder. Ou seja, cada entrada nesta lista cont´em o par <objecto, direitos>. Por exemplo, se um utilizador cont´em na sua C-List o par <aplicac¸˜ao, view>, significa que este pode apenas visualizar uma dada aplicac¸˜ao. Tal como as ACLs, as C-Lists s˜ao protegidas contra modificac¸˜oes n˜ao autorizadas.
Cap´ıtulo 2. Estado da Arte e Conceitos 7
de gest˜ao de utilizadores (p.e. LDAP), e enviados para as aplicac¸˜oes pelo sistema de SSO. Ao receber os atributos de um utilizador, a aplicac¸˜ao ir´a verificar se este tem permiss˜ao para a aceder. Por exemplo, o sistema de SSO envia os atributos de um utilizador para a aplicac¸˜ao juntamente com o username ap´os ter sido realizada a autenticac¸˜ao. Ao receber estes atributos, a aplicac¸˜ao pode verificar se o utilizador cont´em os atributos necess´arios para a aceder, definidos nas listas de controlo de acesso (p.e. se o utilizador est´a no grupo ”Admin”).
Usando as func¸˜oes oferecidas pelos mecanismos de um sistema de SSO, as tarefas de autenticac¸˜ao e autorizac¸˜ao passam a ser geridas num ponto central, garantindo pol´ıticas consistentes e coordenadas para todas as aplicac¸˜oes web que o utilizem.
2.1.1
Vantagens
A implementac¸˜ao e uso de um sistema de SSO num sistema j´a existente, com diversos servic¸os j´a implementados que requerem autenticac¸˜ao dos utilizadores, trazem vantagens para ambos utilizadores e administradores [2].
Do ponto de vista do utilizador ir´a haver not´oria reduc¸˜ao do tempo despendido durante as operac¸˜oes de autenticac¸˜ao, aumentando a sua produtividade. Havendo apenas um inter-face de login, ir´a tamb´em haver uma melhoria da usabilidade dos servic¸os. A seguranc¸a dos utilizadores ´e tamb´em reforc¸ada, j´a que o n´umero de usernames e palavras-chave que cada um tem de gerir ´e mais reduzida.
Do ponto de vista do administrador toda a gest˜ao das contas dos utilizadores fica mais segura e simplificada porque, com um ponto central de administrac¸˜ao, existe uma reduc¸˜ao do tempo despendido a adicionar e eliminar utilizadores e modificar os seus privil´egios e atributos. Passa tamb´em a haver um cumprimento consistente da pol´ıtica de autenticac¸˜ao do sistema em todas as aplicac¸˜oes, fornecendo aos administradores uma maneira muito f´acil de garantir a seguranc¸a aos utilizadores.
2.1.2
Desvantagens
O maior problema proveniente do uso de um sistema de SSO ´e o aumento de riscos de seguranc¸a inerentes ao processo de autenticac¸˜ao centralizado. Por exemplo, o caso em que um computador ´e deixado sem vigia, com uma sess˜ao aberta, poder´a oferecer um acesso global indevido a todas as aplicac¸˜oes associadas ao utilizador do computador.
Ao centralizar a autenticac¸˜ao, ´e criado tamb´em um ponto de ataque ´unico, tornando-o um alvo atractivo para hackers que queiram fazer ataques de negac¸˜ao de servic¸o - Denial Of Service (DoS). Um ataque DoS ´e uma tentativa de impedir utilizadores leg´ıtimos de aceder a informac¸˜ao ou servic¸os. Geralmente um ataque DoS ´e feito atrav´es da inundac¸˜ao de informac¸˜ao numa rede. Ao encher a rede com pedidos, e visto que o servidor apenas consegue processar um certo de n´umero de pedidos, o pedido de um utilizador leg´ıtimo
pode n˜ao ser processado. ´E um ataque de negac¸˜ao de servic¸o porque o servic¸o pretendido n˜ao pode ser acedido. Um ataque deste tipo tem o custo elevado de nenhum utilizador conseguir aceder aos recursos associados ao sistema de SSO [5].
A falha de um dos componentes cruciais para o funcionamento correcto do servidor de SSO, software ou hardware, pode ter s´erios custos para o sistema onde est´a integrado. Por exemplo, se por acaso a m´aquina onde est´a a correr o servidor SSO falhar e esta for ´unica a desempenhar este servic¸o, todas as pr´oximas autenticac¸˜oes ir˜ao falhar, bloqueando todos os servic¸os a novos acessos. Como tal, ´e necess´ario preparar o servidor para funcionar com alta disponibilidade tornando-o tolerante a faltas, sem pontos ´unicos de falha.
Tamb´em a adaptac¸˜ao do sistema de SSO `as aplicac¸˜oes j´a existente pode ser dis-pendiosa e consumidora de tempo, sendo que deve ser adoptada a soluc¸˜ao que melhor se integre com as mesmas.
Todos estes aspectos dever˜ao ser analisados cuidadosamente para a implementac¸˜ao, com sucesso, de um sistema de SSO na FCUL.
2.2
Arquitecturas de Single Sign-On
2.2.1
Pseudo SSO
Uma aproximac¸˜ao ´obvia para suporte do utilizador ´e fornecer-lhe a gest˜ao das suas cre-denciais. O utilizador pode guardar todas as suas palavras-chave e informac¸˜ao de auten-ticac¸˜ao num ficheiro encriptado ou uma base de dados segura com uma palavra-chave mestre. Obviamente que esta palavra-chave necessita de um grau de complexidade mais elevado pois ser´a a ´unica palavra-chave que o utilizar necessita de utilizar. Mas m´ultiplos e diferentes mecanismos de autenticac¸˜ao ainda s˜ao utilizados, mesmo que n˜ao tenha intervenc¸˜ao de utilizadores, e estes sistemas n˜ao podem ser chamados verdadeiros sis-temas de SSO.
Esta arquitectura tem como maior problema a corrupc¸˜ao ou a perda da base de dados das credenciais, impedindo assim o acesso do utilizador ao sistema, se este n˜ao se lem-brar das palavras-chave (estas podem n˜ao ser utilizadas regularmente). Por outro lado o utilizador tem de escrever v´arias vezes a palavra-chave mestre, o que ir´a fazer com que este a decore.
Esta soluc¸˜ao tamb´em afecta a mobilidade do utilizador porque a base de dados de credenciais tem de estar dispon´ıvel em todos os computadores que este usa. Para resolver este problema as credenciais podem estar guardadas online, mas o utilizador tem de ter acesso online cont´ınuo.
Cap´ıtulo 2. Estado da Arte e Conceitos 9
2.2.2
SSO Centralizado
As caracter´ısticas chave de sistemas de SSO centralizados ´e, tal como o nome indica, a centralizac¸˜ao da autenticac¸˜ao e da base de dados de utilizadores. Tal sistema, tem de ter uma relac¸˜ao de confianc¸a com cada um dos servidores aplicacionais, Service Providers (SP), num certo dom´ınio e ´e normalmente chamado de Trusted Third Party (TTP). O utilizador s´o necessita de fornecer as suas credenciais a este TTP, no qual confia.
Estes sistemas diferem na maneira como o utilizador ´e autenticado e podem ser cate-gorizados da seguinte maneira [2] [10]:
Baseados em Tokens: depois de um utilizador se autenticar no TTP, este recebe um tokende software que ´e guardado na sua m´aquina utilizado para pedidos subsequentes ao TTP. Este token ir´a remover a necessidade do utilizador introduzir novamente as suas cre-denciais. Este token pode tamb´em ser reutilizado para identificar o utilizador para outros dom´ınios de autenticac¸˜ao TTP. Os SP’s podem validar este token atrav´es de m´etodos crip-togr´aficos baseados em chaves secretas (criptografia sim´etrica). Estas chaves estabelecem uma relac¸˜ao de confianc¸a entre o TTP e os SP’s. O software de SSO baseado em tokens vem j´a presente em alguns dos populares sistemas operativos como o Windows 2008 ou Netware. O melhor exemplo de um sistema de SSO baseado em tokens ´e o Kerberos (ver secc¸˜ao 2.3.7 deste cap´ıtulo).
Baseados em PKI: Em sistemas baseados em PKI, o utilizador tem primeiro de se registar numa TTP, neste caso chamado de Certification Authority (CA). Durante este processo de registo s˜ao geradas um par de chaves assim´etricas. A chave p´ublica deste par ´e enviada para o CA e depois de o utilizador se autenticar com sucesso, o CA gera um certificado de chave p´ublica para este utilizador e envia-o de volta ao utilizador. O SP ´e capaz agora de verificar os certificados de utilizador ao usar a chave p´ublica do CA. Como exemplos de uma estrutura PKI, temos o Cart˜ao do Cidad˜ao que possui um certificado de autenticac¸˜ao emitido para o cidad˜ao assinado pelo estado portuguˆes (CA). (ver secc¸˜ao 2.3.4 deste cap´ıtulo).
2.2.3
SSO Federado
Sistemas de SSO, normalmente, est˜ao limitados a uma organizac¸˜ao ou um dom´ınio. Para estabelecer confianc¸a entre diferentes dom´ınios, s˜ao necess´arias Federac¸˜oes. O objectivo ´e, portanto, um sistema em que as credenciais de um utilizador provindas do seu dom´ınio, ser˜ao aceites num outro dom´ınio sem que o utilizador tenha que reintroduzir as suas cre-denciais. Isto remove a necessidade de sincronizac¸˜ao e c´opia de credenciais entre difer-entes dom´ınios. Para sistemas SSO baseados em PKI isto pode ser conseguido atrav´es de
hierarquias de CA’s ou certificac¸˜ao cruzada. Os sistemas federados tˆem a seguinte estru-tura:
Circulo de confianc¸a – A base de um sistema federado ´e o c´ırculo de confianc¸a, entre os fornecedores de servic¸os, Service Providers (SP). Este c´ırculo, para al´em de ter de ser implementado tecnicamente (p.e. hierarquias CA), tem de ser feito atrav´es de contratos de neg´ocio entre as companhias participantes. Estes contratos incluem tamb´em acordos de operac¸˜ao que cada SP tem de cumprir.
Identity Provider (IdP) – Dentro de um dom´ınio ´e poss´ıvel centralizar a administrac¸˜ao e a gest˜ao da identidade de um utilizador usando um IdP ou formando um dom´ınio de seguranc¸a contendo v´arios IdP, cada um confiando nos restantes. Este ´ultimo tem uma estrutura similar ao c´ırculo de confianc¸a mas apenas dentro da organizac¸˜ao.
Identity Federation – `A parte do c´ırculo de confianc¸a, os SPs tˆem tamb´em de nego-ciar acordos de operac¸˜ao com outros SP’s de outros dom´ınios de seguranc¸a. Um poss´ıvel, e importante, acordo dever´a ser sobre a privacidade dos utilizadores. A identidade de um utilizador (gerida pelo IdP) consiste num conjunto de atributos e deve-se portanto mar-car os atributos com dados mais sens´ıveis ou informac¸˜ao confidencial. Atributos com esta marca n˜ao s˜ao transferidos aos outros SPs. Normalmente tal informac¸˜ao nem ´e necess´aria para a autorizac¸˜ao. Os atributos que s˜ao permitidos serem transferidos con-stroem a chamada identidade federada de um utilizador.
Figura 2.3: Single Sign-On Federado
Por exemplo, na figura 2.3, um utilizador autenticado no IdP da Universidade A, onde as suas credenciais s˜ao mantidas, tem acesso aos recursos acad´emicos da Universidade B atrav´es do acordo de federac¸˜ao que ambas fizeram. Um bom exemplo da utilizac¸˜ao desta
Cap´ıtulo 2. Estado da Arte e Conceitos 11
arquitectura de SSO ´e o projecto Internet2 Shibboleth, explicado em detalhe na secc¸˜ao 3.2.
2.3
Tecnologias Relacionadas
2.3.1
LDAP
LDAP, Lightweight Directory Access Protocol, ´e um protocolo de aplicac¸˜oes com o ob-jectivo de guardar, modificar e pesquisar dados, usando servic¸os de direct´orio a correr TCP/IP.
Um direct´orio ´e um conjunto de objectos com atributos organizados de uma maneira l´ogica e hier´arquica. Um exemplo simples ´e um direct´orio de telefones, que consiste numa lista de nomes (de pessoas ou organizac¸˜oes) organizados alfabeticamente, cada um tendo um enderec¸o e um n´umero de telefone associado.
Um direct´orio LDAP, organizado em ´arvore, reflecte normalmente barreiras, pol´ıticas ou situac¸˜oes geogr´aficas, dependendo do modelo escolhido. Cada entrada neste direct´orio cont´em um conjunto de atributos. Cada atributo destes, possui um ou mais valores, sendo que todos os elementos est˜ao definidos num schema. Cada entrada tem um Distinguished Name (DN) ´unico, constru´ıdo a partir dos seus atributos, seguido do DN do direct´orio pai, como se pode ver na figura 2.4. Os atributos mais comuns num DN s˜ao OU, Organiza-tional Unit, CN, Common Name, e DC, Domain Controller.
Figura 2.4: Exemplo de um direct´orio em ´arvore LDAP
hier´arquicos, usualmente indicados no atributo DC [3]. Neste momento o LDAP vai na sua vers˜ao 3, especificado pelo IETF, Internet Engineering Task Force no RFC 4510 [7].
2.3.2
Active Directory
Um Active Directory, AD, ´e uma estrutura de direct´orio usada em computadores e servi-dores baseados no sistema operativo Microsoft Windows, utilizada para guardar informac¸˜ao e dados sobre redes e dom´ınios. Tal como o LDAP, ´e definido por uma estrutura hier´arquica em ´arvore com conjuntos de objectos. Um AD ainda fornece os seguintes servic¸os:
• Compatibilidade com aplicac¸˜oes que suportam LDAP;
• Autenticac¸˜ao baseada em Kerberos;
• Nomes baseados em DNS e outra informac¸˜ao de rede;
• Localizac¸˜ao centralizada para administrac¸˜ao de rede e delegac¸˜ao de autoridade;
• Informac¸˜oes de seguranc¸a e SSO para o utilizador aceder a recursos de rede;
• Escalabilidade;
• Armazenamento central para dados de aplicac¸˜ao e sincronizac¸˜ao de actualizac¸˜oes de direct´orio entre v´arios servidores;
Um Active Directory permite tamb´em aos administradores definir pol´ıticas, instalar softwaree aplicar updates cr´ıticos `a organizac¸˜ao em ambientes Windows. Redes de Ac-tive Directory podem variar desde uma pequena instalac¸˜ao com poucos computadores, utilizadores e impressoras, at´e milhares de utilizadores, diferentes dom´ınios e v´arios servi-dores em diferentes zonas geogr´aficas [9].
2.3.3
Certificados X.509
Os algoritmos de codificac¸˜ao assim´etrica baseiam-se na partilha, entre os diferentes uti-lizadores, de uma chave p´ublica. Um certificado X.509 permite associar uma chave p´ublica a uma entidade (uma pessoa, uma m´aquina, . . . ) a fim de assegurar a sua valida-de. Ou seja, este certificado ´e o como um bilhete de identidade para um chave p´ublica, emitido por uma autoridade de certificac¸˜ao (Certification Authority, CA).
O CA est´a encarregue de emitir certificados e atribuir-lhes uma data de validade. No caso de comprometimento da chave (ou do propriet´ario desta) ou data de validade expi-rada, o CA tˆem a obrigac¸˜ao de revogar este certificado.
Uma autenticac¸˜ao baseada em certificados X.509 faz tecnicamente parte do m´etodo de autenticac¸˜ao por chaves p´ublicas. Ou seja, a assinatura criada com uma chave privada
Cap´ıtulo 2. Estado da Arte e Conceitos 13
e a verificac¸˜ao dessa mesma assinatura usando uma chave p´ublica (contida no certificado X.509). A diferenc¸a est´a em determinar se um dado utilizador est´a autorizado a fazer logincom uma chave p´ublica ou certificado. Com chaves p´ublicas convencionais, cada servidor tem de ter todas as chaves p´ublicas dos utilizadores. Com certificados, as chaves p´ublicas dos utilizadores n˜ao tˆem de ser distribu´ıdas pelos servidores. Distribuir a chave p´ublica da Autoridade de Certificadora ´e o suficiente para verificar a assinatura.
2.3.4
Cart˜ao de Cidad˜ao
O Cart˜ao de Cidad˜ao, CC, ´e o novo documento ´unico de identificac¸˜ao de cidadania Por-tuguesa. Este novo documento de identificac¸˜ao n˜ao ´e mais que um smart card onde se encontra um par de chaves, p´ublica/privada, e certificados associados ao seu deten-tor, sendo o estado portuguˆes o CA. Esta chave privada encontra-se protegida por uma palavra-chave num´erica. Este smart card possui dois certificados com finalidades distin-tas. Um destina-se `a de assinatura de documentos, o outro permite efectuar autenticac¸˜oes. Visto que ambos os certificados foram emitidos pelo CA do Estado Portuguˆes, este doc-umento possui a mesma validade legal que um Bilhete de Identidade ou um Passaporte, e ´e da responsabilidade do seu detentor todas as operac¸˜oes electr´onicas efectuadas com o mesmo.
A autenticac¸˜ao forte utilizando o Cart˜ao de Cidad˜ao tem uma vantagem crucial em relac¸˜ao a outros mecanismos normalmente utilizados, pois ´e baseada em 2 factores (algo que se tem e algo que se sabe). Isto ´e, garante que o utilizador de um servic¸o electr´onico possui o Cart˜ao de Cidad˜ao e tamb´em conhece o seu PIN. Em comparac¸˜ao, a autenticac¸˜ao baseada em nome de utilizador/palavra-chave (utilizada na maioria dos sistemas actu-ais), esta ´ultima ´e muito mais vulner´avel ao ”roubo”e ”empr´estimo”da senha pessoal do cidad˜ao [16].
2.3.5
Security Assertions Markup Language - SAML
Security Assertions Markup Language, SAML, ´e uma framework baseada em XML para comunicac¸˜ao de informac¸˜ao de identidade, direitos e atributos dos utilizadores, e foi de-senvolvido pelo OASIS (Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards).
Como o seu nome sugere, o SAML permite `as entidades organizacionais fazer asserc¸˜oes sobre a identidade, atributos e direitos de um sujeito para outras entidades, que podem ser uma organizac¸˜ao parceira, uma aplicac¸˜ao de outra empresa, etc. O SAML ´e um pro-tocolo extens´ıvel desenhado para ser usado por outros propro-tocolos com outros standards. Por exemplo, a “Liberty Alliance”, o projecto “Internet2 Shibboleth”, e o “OASIS Web Services Security (WS-Security)” adoptaram o SAML, utilizando-o tecnologicamente a v´arios n´ıveis.
Ao n´ıvel do SSO, o uso da tecnologia SAML traz o benef´ıcio de tornar os servic¸os Web seguros, visto as suas asserc¸˜oes poderem ser utilizadas como tokens de seguranc¸a dentro de headers SOAP de maneira a transportar seguramente e com privacidade informac¸˜oes de identidade. O uso destas asserc¸˜oes pode tamb´em ser utilizado para ser criada uma autorizac¸˜ao baseada em atributos do utilizador [8].
2.3.6
Cookies HTTP
Um HTTP cookie, tamb´em conhecido apenas por cookie, ´e uma cadeia de caracteres guardada num browser Web de um utilizador. Um cookie consiste num ou mais pares de nome-valor contendo pedac¸os de informac¸˜ao, que podem estar encriptados para privaci-dade de informac¸˜ao ou seguranc¸a de dados. Um cookie ´e enviado do servidor Web para o browserno cabec¸alho de um pacote HTTP, e posteriormente enviado pelo browser Web cada vez que aquele servidor Web ´e acedido.
No caso de ser usado num sistema de SSO, o agente que autentica utilizadores deixa um cookie no browser do cliente. Quando o utilizador tenta aceder a um recurso, o sistema pede o cookie e se este est´a presente e ´e verificado como estando v´alido ent˜ao o utilizador tem o acesso autorizado. Se n˜ao est´a presente ou est´a algo incorrecto com o cookie, por exemplo, se j´a passou o per´ıodo de validade em que o sistema de SSO opera, ent˜ao ´e pedido ao utilizador para se reautenticar. Os cookies vˆem em texto vis´ıvel, o que n˜ao ´e seguro. Toda a informac¸˜ao que est´a no cookie pode sofrer ataques de sniffing e como tal, a informac¸˜ao sens´ıvel n˜ao deve ser passada desta maneira. Uma boa maneira de garantir que os cookies n˜ao s˜ao retornados sem qualquer tipo de seguranc¸a ´e utilizar o parˆametro “secure”, que garante que o browser n˜ao retorna o cookie a n˜ao ser que seja usado um URL seguro, com o protocolo https [23].
2.3.7
Kerberos
Kerberos ´e um famoso sistema de SSO centralizado baseado em tokens, desenvolvido nos anos 80 no MIT. Para usar Kerberos, tem de haver um servidor com servic¸os, um cliente e o Key Distribution Center, KDC. O KDC est´a dividido em duas partes (o Servidor de Autenticac¸˜ao, AS, e o Ticket Granting Server, TGS). O cliente tem primeiro de se au-tenticar no KDC antes de usar um servic¸o no servidor. S´o depois da autenticac¸˜ao ser efectuada com sucesso, ´e gerado um Ticket Granting Ticket, TGT. Se o cliente quer usar outro servic¸o, j´a n˜ao ´e necess´ario autenticar-se no AS novamente. Pode contactar direc-tamente o TGS com o seu TGT para obter um ticket para outro servic¸o. O servidor do novo servic¸o deve verificar se o ticket do cliente ´e valido ou n˜ao. Resumindo, o cliente s´o necessita de se autenticar uma vez, e da´ı em diante contacta o TGS enquanto o seu ticket for v´alido [6]. Um exemplo do uso do Kerberos ´e o Microsoft Windows 2000.
Cap´ıtulo 2. Estado da Arte e Conceitos 15
2.3.8
Secure Socket Layer - SSL
O protocolo SSL, Secure Socket Layer, foi criado originalmente pela Netscape para as-segurar transacc¸˜oes seguras entre servidores Web e browsers. Este protocolo usa uma terceira parte, uma Autoridade de Certificac¸˜ao (CA), para identificar um dos lados, ou ambos da transacc¸˜ao. Funciona da seguinte maneira:
1. Um browser pede uma p´agina segura (usualmente https://); 2. O servidor Web envia a sua chave p´ublica com o seu certificado;
3. O browser verifica que o certificado foi atribu´ıdo por uma entidade confi´avel (nor-malmente uma CA root confi´avel), que ainda est´a v´alido e que o certificado est´a rela-cionado com o site visitado;
4. O browser usa ent˜ao a chave p´ublica para cifrar uma chave de encriptac¸˜ao sim´etrica aleat´oria e envia-a para o servidor juntamente com o URL encriptado, requerido, assim como outros dados http cifrados;
5. O servidor Web decifra a chave de encriptac¸˜ao sim´etrica usando a sua chave privada e usa a chave sim´etrica para decifrar o URL e os dados http;
6. O servidor envia ent˜ao o documento HTML pedido e dados HTTP encriptados com a chave sim´etrica;
7. O browser decifra os dados HTTP e o documento HTML, usando a chave sim´etrica, e mostra a informac¸˜ao. [40]
Cap´ıtulo 3
Soluc¸˜oes Single Sign-On
Existem v´arias soluc¸˜oes, open source, de sistemas SSO para aplicac¸˜oes Web. Neste cap´ıtulo ser˜ao analisadas as v´arias opc¸˜oes dispon´ıveis para implementac¸˜ao de um sis-tema SSO na FCUL. Estas soluc¸˜oes foram escolhidas j´a tendo em conta o suporte de autenticac¸˜ao num direct´orio Microsoft Active Directory ou LDAPv3, sendo que esta ser´a a maneira de autenticac¸˜ao prim´aria dos utilizadores na FCUL (ver Cap´ıtulo 4).
3.1
Central Authentication Service - CAS
O projecto CAS [19], Central Authentication Service, foi inicialmente desenvolvido em 2001 pela Universidade de Yale para autenticac¸˜ao de utilizadores de uma maneira confi´avel e centralizada. Em Dezembro de 2004, passou a ser um projecto da empresa Jasig.
O CAS fornece um servic¸o de SSO com o seu pr´oprio protocolo, aberto, e com o servidor de autenticac¸˜ao totalmente escrito na linguagem Java. A integrac¸˜ao do CAS com as aplicac¸˜oes pode ser ao n´ıvel de m´odulos/filtros no servidor aplicacional ou do lado da aplicac¸˜ao atrav´es de bibliotecas/clientes para v´arias linguagens de programac¸˜ao, como PHP ou ASP.NET. O servidor CAS apenas requer um servidor Web que seja capaz de correr servlets Java, como o Apache Tomcat ou JBoss e o Java JDK.
O CAS foi desenhado para ser um produto sem autorizac¸˜ao, focando-se apenas na autenticac¸˜ao do utilizador. No entanto, o CAS permite a gest˜ao de autorizac¸˜ao de servic¸os associados ao SSO e escolher que atributos do utilizador a aplicac¸˜ao tem direito a receber. Assim, a aplicac¸˜ao pode criar o seu mecanismo de controlo de acesso pr´oprio com base nestes atributos.
Como se pode observar na figura 3.1, o processo de autenticac¸˜ao, geralmente, comec¸a com um pedido de um utilizador a um recurso protegido, que o redirecciona para a p´agina de login. Este redireccionamento ´e feito juntamente com o URL para o qual o CAS vai enviar o utilizador ap´os a autenticac¸˜ao ser efectuada (passo 1-3). Esta autenticac¸˜ao ir´a gerar um Ticket Granting Cookie (TGC) - uma longa cadeia de caracteres aleat´orios que mapeia este cookie ao utilizador. ´E atrav´es deste cookie que o utilizador ´e indexado na
Figura 3.1: Arquitectura de autenticac¸˜ao inicial com CAS
mem´oria cache de credenciais no servidor CAS. Se o browser suportar cookies, ent˜ao o TGC ´e enviado para o browser como um cookie n˜ao persistente identificando um lo-ginbem sucedido, evitando assim a necessidade de autenticac¸˜ao no servidor CAS para pedidos subsequentes (passos 4-5).
Depois de conclu´ıdo o processo de autenticac¸˜ao, o CAS redirecciona o browser para o servic¸o pedido, juntamente com um Service Ticket (ST) - outra cadeia de caracteres aleat´orios que mapeia o utilizador e o servic¸o pedido (passo 6). A aplicac¸˜ao pode agora extrair o ticket e valida-lo usando o URL de validac¸˜ao do CAS, passando o ticket e o servic¸o como parˆametros deste URL (passos 7). Uma validac¸˜ao feita com sucesso resulta na destruic¸˜ao no ticket de servic¸o e ´e retornado o nome de utilizador ao servic¸o (passos 8). Finalmente, o utilizador tem acesso ao recurso pretendido inicialmente (passo 9). Futuros pedidos a servidores/aplicac¸˜oes protegidas pelo CAS n˜ao ir˜ao necessitar que o utilizador se autentique novamente, visto este j´a possuir todos os tokens necess´arios para uma experiˆencia SSO [18].
O CAS tamb´em tem suporte para Proxy. Proxy ´e basicamente um servic¸o que deseja comunicar com outro servic¸o em nome de um utilizador. Isto ´e conseguido atrav´es de um
Cap´ıtulo 3. Soluc¸˜oes Single Sign-On 19
Proxy-Granting Ticket (PGT) do CAS que permite produzir um Proxy Ticket (PT) que d´a acesso ao servic¸o simulando um utilizador. Esta habilidade de proxy ´e particularmente importante para servic¸os, como portais, que desejam comunicar com outros servic¸os em nome do utilizador sem perguntar novamente pelas credenciais [17].
O CAS oferece um protocolo de Single Sign-Out, efectuado quando um utilizador acede `a p´agina de logout. Para isto, o CAS envia uma mensagem POST HTTP a todas as aplicac¸˜oes que estejam associadas `a sess˜ao do utilizador. Este Single Sign-Out apenas funciona para clientes / linguagens cuja gest˜ao de sess˜ao ´e mantida do lado do servi-dor. Isto significa que em aplicac¸˜oes cuja sess˜ao ´e mantida em cookies no browser do utilizador, a que o CAS n˜ao tem acesso, n˜ao participam no protocolo de Single Sign-Out.
3.2
Shibboleth
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.
3.5
CoSign
CoSign [24] foi lanc¸ado em vers˜ao beta em 2002 para providenciar `a Universidade de Michigan um sistema de SSO na Web, constitu´ıdo por trˆes componentes.
O CGI central ´e respons´avel por autenticar utilizadores no servidor central CoSign. ´E tamb´em respons´avel para registar cada servic¸o que o utilizador acede – esta acc¸˜ao associa o cookie de login do utilizador `a sua sess˜ao nas aplicac¸˜oes. Este CGI foi constru´ıdo para utilizar Kerberos V e GSSAPI para autenticar os utilizadores.
O segundo componente, ´e o daemon central respons´avel por manter o estado de todas as sess˜oes do CoSign, incluindo utilizadores que fizeram login, logout ou idle time out. Isto significa que o daemon mant´em o estado de todos os cookies de servic¸o que represen-tam as aplicac¸˜oes Web que o utilizador acedeu. O daemon tem a habilidade de replicar a sua base de dados de cookies para m´ultiplos servidores, para que a falha de um servidor n˜ao constitua a falha de um sistema. O daemon responde a interrogac¸˜oes de identidade de utilizadores do CGI e do filtro e comunica com os outros daemons atrav´es do protocolo
Cap´ıtulo 3. Soluc¸˜oes Single Sign-On 23
de replicac¸˜ao. O daemon foi escrito inteiramente em C e tem conhecimento dos tickets Kerberus V.
Por ´ultimo existe o filtro que ´e instalado nos servidores aplicacionais, respons´avel por determinar que ´areas do Web site est˜ao protegidas pelo CoSign e as que n˜ao est˜ao. Se um utilizador tenta aceder a uma ´area protegida, o filtro assegura que o utilizador est´a autenti-cado, e obt´em o seu username, o realm de autenticac¸˜ao, enderec¸o ip e opcionalmente um ticket Kerberos. Esta informac¸˜ao pode ser utilizada por mecanismos externos para pos-teriores decis˜oes de autorizac¸˜ao. CoSign permite a integrac¸˜ao deste filtro nos servidores aplicacionais Apache Web Server, IIS 6 e 7 e tamb´em para servidores que suportam Java, como o Tomcat ou o JBoss.
Figura 3.4: Arquitectura de autenticac¸˜ao inicial com CoSign
Como se pode observar pela figura 3.4, o processo de autenticac¸˜ao ´e bastante semel-hante ao processo de autenticac¸˜ao do CAS. Este processo inicia-se, tipicamente, pelo acesso de um utilizador a um recurso protegido sendo redireccionado para a p´agina de logincaso n˜ao apresente um Service Token v´alido (passos 1-3). A autenticac¸˜ao do uti-lizador nesta p´agina ir´a gerar um Login Cookie, para indexar o utiuti-lizador ´e indexado na mem´oria cache de credenciais do CoSign, e o Service Token para acesso ao servic¸o
(pas-sos 4-6) . Ap´os a recepc¸˜ao do Service Token, a aplicac¸˜ao ir´a verificar se este ´e v´alido comunicando com o servidor de login (passo 7). Se o servidor de login responder com o ID de utilizador, significa que o token est´a v´alido e a aplicac¸˜ao envia o utilizador para o recurso pretendido (passos 8-9).
O CoSign suporta o Single Sign-Out de todos os servic¸os associados ao CoSign atrav´es de um URL [25].
3.6
WebAuth
WebAuth [41] ´e sistema de SSO constru´ıdo a pensar em servidores aplicacionais com o Apache Web Server como front end de pedidos HTTP. Entrou em produc¸˜ao em Stanford, em Julho de 1997 e teve a sua maior reformulac¸˜ao em Fevereiro de 2003. O WebAuth consiste no WAS (servidor aplicacional com WebAuth activado) e o WebKDC (WebAuth Key Distribution Centre), ambos escritos em C. Tanto para o WAS como para o WebKDC ´e necess´ario instalado Apache, OpenSSL, MIT Kerberus ou Heimdal Kerberus e cURL.
Como se pode verificar na figura 3.5, o WAS ´e respons´avel por verificar se um uti-lizador j´a est´a identificado no WebKDC, ou seja, se este j´a possui um ID Token (passo 3). Se o utilizador n˜ao tiver este token, o pedido ´e redireccionado para o WebKDC com um Request Token (passo 4) . A componente WebLogin do WebKDC apresenta uma p´agina de login no browser do utilizador e se a autenticac¸˜ao for feita com sucesso, o WebKDC vai gerar dois tokens (passos 5-7). O primeiro token, WebKDC cookie, ´e usado para prov-idenciar futuros pedidos de SSO, e o segundo, ID Token, ´e enviado para o WAS, que o vai verificar ap´os a sua recepc¸˜ao (passo 8). Se este estiver correcto, ´e criado um cookie de sess˜ao, e o utilizador ficar´a ent˜ao com acesso ao recurso inicialmente pretendido (passo 9).
A maior desvantagem neste sistema ´e n˜ao ter suporte para mais nenhum servidor apli-cacional, como o IIS. N˜ao possui um sistema de Single Sign-Out e para integrac¸˜ao com autenticac¸˜ao em direct´orios LDAP/Microsoft Active Directory ´e necess´ario a instalac¸˜ao de um segundo m´odulo Apache e as aplicac¸˜oes Cyrus SASL e OpenLDAP. Para o envio dos atributos de um utilizador, populado num direct´orio deste tipo, ´e ainda necess´ario um m´odulo adicional instalado no WebKDC [44].
Cap´ıtulo 3. Soluc¸˜oes Single Sign-On 25
Figura 3.5: Arquitectura da autenticac¸˜ao inicial com WebAuth
3.7
Resumo das funcionalidades das soluc¸˜oes SSO
Para uma melhor comparac¸˜ao entre as diversas soluc¸˜oes SSO previamente analisadas, foram definidas as seguintes funcionalidades chave:
• Autenticac¸˜ao - A soluc¸˜ao permite autenticac¸˜ao tendo como base de credenciais um direct´orio LDAP;
• Autorizac¸˜ao - A soluc¸˜ao possui a capacidade de serem disponibilizados `a aplicac¸˜ao os atributos populados num direct´orio LDAP;
• Federac¸˜ao - A soluc¸˜ao permite, de raiz, a possibilidade de federar a identidade de utilizadores de um direct´orio LDAP;
• Filtros - A soluc¸˜ao fornece filtros e/ou m´odulos para os servidores aplicacionais referidos;
• Single Sign-Out - A soluc¸˜ao permite Single Sign-Out, ou seja, logout simultˆaneo em todas as aplicac¸˜oes.
Software Autenticac¸˜ao Autorizac¸˜ao Federac¸˜ao Filtros Single Sign-Out CAS √ √ χ IIS, Apache √
Shibboleth √ √ √ IIS, Apache χ simpleSAMLphp √ √ √ IIS, Apache √ PubCookie √ χ χ IIS, Apache χ CoSign √ χ χ IIS, Apache √ WebAuth √ √ χ Apache χ
Tabela 3.1: Comparac¸˜ao entre as diferentes soluc¸˜oes de SSO
Ao analisar a tabela 3.1 ´e poss´ıvel fazer uma r´apida comparac¸˜ao entres as funcional-idades das diversas soluc¸˜oes encontradas. No cap´ıtulo seguinte ir´a ser feita a an´alise destas mesmas soluc¸˜oes para integrac¸˜ao das aplicac¸˜oes Web especificas da FCUL com necessidade de SSO.
Cap´ıtulo 4
Single Sign-On na FCUL
4.1
Arquitectura de Autenticac¸˜ao na FCUL
O Centro de Inform´atica (CI) disponibiliza cada vez mais sistemas de informac¸˜ao na Internet aos utilizadores da FCUL. Estes utilizadores est˜ao representados atrav´es de ob-jectos num direct´orio, Microsoft Active Directory, em dois dom´ınios diferentes, fc.ul.pt e alunos.fc.ul.pt. O dom´ınio fc.ul.pt, cont´em as contas dos funcion´arios, docentes e n˜ao docentes, enquanto o dom´ınio alunos.fc.ul.pt cont´em todas contas de alunos da Faculdade. Este direct´orio permite aos servic¸os do CI ligarem-se todos `a mesma central de cre-denciais de utilizadores para realizar operac¸˜oes de autenticac¸˜ao, sem redundˆancia de informac¸˜ao. Ou seja, para um servic¸o autenticar um utilizador basta criar uma ligac¸˜ao ao direct´orio e verificar se as credenciais inseridas est˜ao correctas. Mas n˜ao havendo uma infra-estrutura de autenticac¸˜ao, esta tarefa tˆem de ser codificada individualmente para cada servic¸o, n˜ao havendo pol´ıticas de autenticac¸˜ao obrigatoriamente consistentes. O facto de n˜ao existir um sistema de SSO na FCUL tem as seguintes desvantagens:
• Para efectuarem a ligac¸˜ao ao direct´orio, os servic¸os precisam de fornecer as creden-ciais de um utilizador com as devidas permiss˜oes para este efeito. Isto originou a criac¸˜ao excessiva de contas com esta permiss˜ao `a medida que foram criados novos servic¸os disponibilizados pelo CI.
• Apesar de ser usada a mesma base de dados de credenciais, a maneira como os servic¸os autenticam os utilizadores n˜ao ´e necessariamente a mesma. N˜ao havendo uma centralizac¸˜ao de pol´ıticas de autenticac¸˜ao, certos servic¸os da FCUL exigiam apenas o username, outros o enderec¸o de correio electr´onico completo para realizar a autenticac¸˜ao ([email protected] ou [email protected]). Como se pode observar na figura 4.1, esta falta de coordenac¸˜ao pode dar origem a confus˜ao por parte dos utilizadores na maneira de como se devem autenticar em certos servic¸os.
• O aspecto da p´agina de login varia entre os diferentes servic¸os. O facto de os utilizadores n˜ao reconhecerem a p´agina na qual est˜ao a introduzir as credenciais
Figura 4.1: Autenticac¸˜ao na FCUL sem Single Sign-On
traz s´erios riscos de seguranc¸a. ´E bastante mais seguro os utilizadores inserirem sempre as suas credencias numa p´agina que conhecem e confiam.
• Os registos de acesso nas aplicac¸˜oes n˜ao est˜ao centralizados, aumentado os custos de auditoria de processos de autenticac¸˜ao.
Com um sistema de SSO, os servic¸os deixar˜ao de ter poder de decis˜ao na autenticac¸˜ao de utilizadores, cumprindo as pol´ıticas definidas externamente. Ou seja, quando os servic¸os recebem um nome de utilizador, podem assumir que todo o processo de autenticac¸˜ao j´a foi efectuado.
4.2
Aplicac¸˜oes com necessidade de Single Sign-On
Existem v´arias aplicac¸˜oes com necessidade de integrac¸˜ao com o sistema de SSO, cada uma com um mecanismo de autenticac¸˜ao e autorizac¸˜ao pr´oprio:
• Correio Electr´onico (webmail.fc.ul.pt) – Aplicac¸˜ao onde os utilizadores da FCUL podem verificar a sua conta de correio electr´onico num browser Web. Todos os uti-lizadores de ambos dom´ınios, fc.ul.pt e alunos.fc.ul.pt, tˆem acesso a esta aplicac¸˜ao. Para autenticac¸˜ao nesta aplicac¸˜ao, os utilizadores do dom´ınio alunos.fc.ul.pt, tˆem de inserir o enderec¸o de correio electr´onico completo, enquanto que para contas do dom´ınio fc.ul.pt pode apenas ser inserido o username. Esta aplicac¸˜ao utiliza o sistema Microsoft Outlook Web Access do Microsoft Exchange.
• Gest˜ao de Utilizadores / Tomadas (gestao.fc.ul.pt) – Aplicac¸˜ao respons´avel pelo registo de novos utilizadores e pedidos de activac¸˜ao/desactivac¸˜ao de tomadas por parte dos utilizadores da rede da Faculdade e usado para a gest˜ao de utilizadores e tomadas pelos administradores de rede. A aplicac¸˜ao foi escrita totalmente em PHP, a correr em Apache Web Server, e s´o utilizadores do dom´ınio fc.ul.pt tˆem acesso a esta aplicac¸˜ao. A autenticac¸˜ao ´e efectuada inserindo o username.
• Gest˜ao de Contas de Alunos (gestao.alunos.fc.ul.pt) – Aplicac¸˜ao onde os alunos da Faculdade podem verificar e gerir a sua conta de utilizador. Inclui tamb´em a
Cap´ıtulo 4. Single Sign-On na FCUL 29
informac¸˜ao do sistema de impress˜oes e controlo de acesso da Faculdade. Esta aplicac¸˜ao foi escrita totalmente em PHP, a correr em Apache Web Server, e ape-nas tˆem acesso alunos com uma conta do dom´ınio alunos.fc.ul.pt. A autenticac¸˜ao ´e efectuada inserindo o username.
• Moodle (moodle.fc.ul.pt) – Plataforma de e-learning, onde professores e alunos acedem para dar um suporte mais interactivo `as aulas, ou at´e mesmo realizar provas de avaliac¸˜ao. O moodle tem suporte de base para alguns sistemas de SSO e est´a escrito em PHP, a correr em Apache Web Server. Esta plataforma est´a acess´ıvel, para al´em de todos os utilizadores dos dominios fc.ul.pt e alunos.fc.ul.pt, tamb´em a utilizadores com o dom´ınio campus.ul.pt. Utilizadores com este dom´ınio s˜ao alunos externos ao direct´orio de utilizadores da FCUL, mas que fazem parte da Universidade de Lisboa e necessitam do acesso a esta plataforma para algumas disciplinas do seu curso leccionadas no campus da FCUL. A autenticac¸˜ao ´e feita atrav´es da inserc¸˜ao do enderec¸o de correio electr´onico completo.
• Site de downloads do CI (ci.fc.ul.pt/software) – Aplicac¸˜ao onde todos os uti-lizadores da FCUL, fc.ul.pt ou alunos.fc.ul.pt, tˆem acesso a software dispon´ıvel para download. Aplicac¸˜ao escrita totalmente em PHP, a correr em Apache Web Server. A autenticac¸˜ao ´e feita atrav´es do enderec¸o de correio electr´onico completo.
• Candidaturas FCUL (candidaturas.fc.ul.pt) – Aplicac¸˜ao p´ublica para candidatu-ras a Mestrados de 2oCiclo de Bolonha na FCUL. Esta aplicac¸˜ao apenas necessita de autenticac¸˜ao caso o candidato ao mestrado seja j´a aluno da FCUL, com uma conta do dom´ınio alunos.fc.ul.pt. Neste caso, o aluno autentica-se com o seu username e alguns dos campos do formul´ario de candidatura j´a se encontram preenchidos. Aplicac¸˜ao escrita totalmente em PHP, a correr em Apache Web Server.
4.3
Escolha da soluc¸˜ao Single Sign-On a implementar na
FCUL
Para a escolha da melhor soluc¸˜ao SSO a implementar na FCUL ´e preciso verificar a compatibilidade das soluc¸˜oes encontradas com os servic¸os Web com necessidade de SSO.
Software Aplicac¸˜oes em PHP Moodle OWA
CAS CasOwa
Shibboleth M´odulo para Apache ou biblioteca PHP adi-cional
Integrac¸˜ao de origem
simpleSAMLphp
PubCookie Requer instalac¸˜ao de N˜ao dispon´ıvel CoSign M´odulo para Apache um m´odulo adicional
no Moodle WebAuth N˜ao dispon´ıvel
Tabela 4.1: Compatibilidade das diferentes soluc¸˜oes de SSO em relac¸˜ao aos servic¸os da FCUL
Observando a tabela 4.1 verifica-se que a soluc¸˜ao CAS ´e a ´unica que apresenta a total-idade de requisitos necess´arios `a integrac¸˜ao de um sistema de SSO com todos os servic¸os da FCUL. A raz˜ao mais forte para ser escolhido o CAS em vez dos outros sistemas ´e a possibilidade de ser utilizado como sistema de autenticac¸˜ao do OWA. ´E o ´unico sis-tema, de todos os analisados, que oferece uma vers˜ao funcional para a integrac¸˜ao com este software propriet´ario. A integrac¸˜ao out-of-the-box do Moodle com um sistema CAS, ou seja, sem qualquer alterac¸˜ao de c´odigo ou instalac¸˜ao de m´odulos adicionais, ´e tamb´em um grande ponto a favor.
Apesar de n˜ao oferecer um sistema federado de raiz, ou seja, oferecer todas as ca-pacidades de um IdP federado, a possibilidade de ser utilizado como mecanismo de autenticac¸˜ao com outro sistema que o fac¸a, como o simpleSAMLphp ou Shibboleth, pos-sibilita uma poss´ıvel integrac¸˜ao numa federac¸˜ao.
De todos os sistemas analisados foi a soluc¸˜ao que apresentou melhor documentac¸˜ao tendo em conta a instalac¸˜ao de um servidor de autenticac¸˜ao CAS, a alta disponibilidade, a expansibilidade para novos tipos de autenticac¸˜ao e a integrac¸˜ao com diversos servidores aplicacionais, linguagens de programac¸˜ao e aplicac¸˜oes.
Por fim, foi considerado este sistema a pensar no futuro dos sistemas Web ofereci-dos pelo CI, e na poss´ıvel integrac¸˜ao com servic¸os do Departamento de Inform´atica, DI, da FCUL. O DI ´e uma excepc¸˜ao aos outros departamentos da FCUL, onde os alunos, bolseiros, investigadores, docentes e n˜ao docentes, para al´em de terem uma conta no CI, tamb´em possuem uma segunda conta para os servic¸os do seu departamento. Isto significa que existem duas contas electr´onicas, em direct´orios diferentes, para representar a mesma pessoa informaticamente na FCUL. Esta integrac¸˜ao seria feita com o fim de unificar os direct´orios, fc.ul.pt e di.fc.ul.pt (incluindo ambos os subdirect´orios alunos.fc.ul.pt e alunos.di.fc.ul.pt). Esta unificac¸˜ao permitiria eliminar a redundˆancia de dados entre as duas contas electr´onicas para o mesmo aluno e permitiria as aplicac¸˜oes do DI
partici-Cap´ıtulo 4. Single Sign-On na FCUL 31
parem no protocolo de SSO do CI. Tendo esta possibilidade em mente, o CAS seria a melhor soluc¸˜ao de SSO a implementar visto o DI j´a utilizar este sistema de autenticac¸˜ao para o servic¸o de Administrac¸˜ao de Sistemas Inform´aticos do DI (admin.di.fc.ul.pt) e o servic¸o de arquivo de conte´udo acad´emico na plataforma moodle (coruja.di.fc.ul.pt), e possivelmente o vir a adaptar a outras aplicac¸˜oes e servic¸os.
4.4
Arquitectura da soluc¸˜ao escolhida - CAS
Para que seja poss´ıvel desenhar uma arquitectura para utilizac¸˜ao do CAS como sistema de SSO na FCUL, ´e necessa´ario compreender todos os componentes envolvidos na autenticac¸˜ao de utilizadores. Apesar dos seus aspectos principais j´a estarem descritos na secc¸˜ao 3.1, pode ser encontrado no Apˆendice A toda informac¸˜ao sobre os tokens e URIs do CAS.
4.4.1
Autenticac¸˜ao
Como j´a foi anteriormente referido, todos os servic¸os com necessidade de SSO autenticam os utilizadores no mesmo direct´orio. Ao centralizar a autenticac¸˜ao, os servic¸os da FCUL deixar˜ao de efectuar ligac¸˜oes directamente ao direct´orio para autenticar utilizadores. Ou seja, a autenticac¸˜ao de utilizadores nos servic¸os da FCUL ir´a passar a ser feita atrav´es da instalac¸˜ao/configurac¸˜ao de filtros:
• phpCAS - Biblioteca para integrar aplicac¸˜oes escritas em PHP com o protocolo CAS. A integrac¸˜ao das aplicac¸˜oes escritas em PHP da FCUL com esta biblioteca ´e explicada em pormenor na sub-secc¸˜ao 5.2.1;
• auth cas - Filtro presente no Moodle para uso do CAS como modo de autenticac¸˜ao de utilizadores. A activac¸˜ao deste filtro no Moodle da FCUL ´e explicado em por-menor na sub-secc¸˜ao 5.2.2;
• casOwa - Filtro para alterac¸˜ao do modo de autenticac¸˜ao de utilizadores do Out-look Web Access para CAS. A integrac¸˜ao do webmail da FCUL com este filtro ´e explicado em pormenor na sub-secc¸˜ao 5.2.3;
Tal como se pode observar na figura 4.2, os servic¸os passam a comunicar, atrav´es destes filtros, directamente com o servidor CAS para autenticar utilizadores. Por outras palavras, o sistema de autenticac¸˜ao das aplicac¸˜oes, feito pela ligac¸˜ao directa ao direct´orio, ´e substitu´ıdo pelos filtros CAS. O servidor CAS apenas garante que o utilizador est´a autenticado sendo que ´e da obrigac¸˜ao dos servic¸os criar o mecanismo de controlo de acesso aos mesmos. Por exemplo, o servic¸o ”gestao.fc.ul.pt”tem de permitir o acesso a utilizadores autenticados apenas do dom´ınio fc.ul.pt. Ou seja, utilizadores autenticados, mas do dom´ınio alunos.fc.ul.pt, n˜ao est˜ao autorizados a aceder a este servic¸o.
Figura 4.2: Autenticac¸˜ao na FCUL com CAS
No novo sistema de SSO, os utilizadores ir˜ao ter duas maneiras de se autenticarem. A primeira, e mais comum, ir´a ser atrav´es do seu enderec¸o de correio electr´onico e respectiva palavra-chave.
A segunda ser´a atrav´es da autenticac¸˜ao atrav´es do Cart˜ao de Cidad˜ao (CC). Os cer-tificados de autenticac¸˜ao do CC, como referido na subsecc¸˜ao 2.3.4, contˆem informac¸˜oes confi´aveis do seu detentor, incluindo o n´umero do Cart˜ao de Cidad˜ao. Visto que no di-rect´orio da FCUL existe um atributo para cada utilizador com o seu n´umero do CC, ´e poss´ıvel fazer autenticac¸˜ao de utilizadores desta forma:
1) Ao escolher o m´etodo de autenticac¸˜ao por CC (na p´agina de login), o uti-lizador envia o seu certificado de autenticac¸˜ao do CC e outros dados aleat´orios, atrav´es do browser, assinados com a chave privada, pin, para o servidor CAS;
2) O CAS utiliza o certificado do CA (e recursos externos) para verificar se o certificado do utilizador ´e v´alido;
3) O CAS verifica que o utilizador tˆem uma chave privada v´alida ao analisar a assinatura do pacote inicial;
4) Ap´os esta verificac¸˜ao, o gestor de autenticac¸˜ao do CAS extrai o n´umero do BI do certificado e procura um utilizador no direct´orio com este n´umero;
5) Se encontrar um utilizador com este n´umero de BI no direct´orio, autentica o utilizador no CAS e envia o email deste utilizador para a aplicac¸˜ao;
Deste modo, ´e indiferente para as aplicac¸˜oes o modo como o utilizador foi autenticado. Qualquer que seja o m´etodo escolhido pelo utilizador, o resultado final do processo de autenticac¸˜ao ´e igual, sendo enviado o email do utilizador `a aplicac¸˜ao.
