UNIVERSIDADE DE LISBOA Faculdade de...

UNIVERSIDADE DE LISBOAFaculdade de Ciências

Departamento de Informática

SINGLE SIGN-ON NA FCUL

Francisco Wallenstein Teixeira Estanqueiro

MESTRADO EM ENGENHARIA INFORMÁTICAEspecialização em Sistemas de Informação

2010

UNIVERSIDADE DE LISBOAFaculdade de Ciências

Departamento de Informática

SINGLE SIGN-ON NA FCUL

Francisco Wallenstein Teixeira Estanqueiro

PROJECTO

Projecto orientado pelo Prof. Doutor Mário João Barata Calha e co-orientado pelo Lic.Pedro Miguel Gomes Silva Rosa

MESTRADO EM ENGENHARIA INFORMÁTICAEspecialização em Sistemas de Informação

2010

Resumo

Este projecto insere-se no âmbito da cadeira de Projecto em Engenharia Informática(PEI) do Mestrado de Engenharia Informática da Faculdade de Ciências da Universidadede Lisboa (FCUL).

Este trabalho teve como principal objectivo a criação de um sistema de Single Sign-On (SSO) para as aplicações web disponibilizadas pelo Centro de Informática (CI) daFCUL.

Single Sign-On (SSO) é um processo de autenticação em sessão, que permite a umutilizador introduzir as suas credenciais de acesso apenas uma vez para aceder a múltiplasaplicações protegidas. O processo autentica o utilizador para todas as aplicações a queeste tem direito de acesso e elimina a necessidade de se autenticar novamente ao mudarde aplicação durante a sessão. Deste modo, toda a autenticação passará a ser feita deum modo centralizado, ficando o serviço de SSO com a responsabilidade de fornecerinformação confiável de identidade dos utilizadores às aplicações.

De forma a atingir os objectivos propostos, foi necessário estudar com detalhe o estadoda arte, assim como as possı́veis soluções para a implementação de um sistema destegénero, tendo já em conta os requisitos das aplicações web na FCUL. Esta análise levouà escolha do software Central Authentication Service (CAS) que, após os devidos testes,entrou em produção no CI, tendo mais de mil acessos diários por funcionários e alunosda FCUL.

Adicionalmente, foi criado um novo modo de introdução de credenciais através doCartão de Cidadão Português, um sistema de autenticação para serviços federados e umaaplicação web para uma gestão eficaz de todo o sistema de SSO.

Palavras-chave: single sign-on, aplicações web, central authentication service, cartãode cidadão português, autenticação 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 ComputerEngineering 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 toenter their credentials only once to access multiple protected applications. The processauthenticates the user for all applications which he’s entitled to access to, eliminating theneed to authenticate again when changing applications during the same session. Withan SSO solution, all authentication is done in a centralized manner, thus making it theresponsibility of the SSO system to provide reliable information about the user’s identityto the web applications.

In order to achieve these objectives, it was necessary to examine in detail the state ofthe art and study the potential solutions to implementing this kind of service.

After detailed analysis, Central Authentication Service (CAS) was selected as the SSOsystem. Following an appropriate testing stage, the CAS was effectively made availableat 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 usersusing 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, portuguesecitizen card, federated authentication

Conteúdo

Lista de Figuras xi

Lista de Tabelas xiii

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Instituição de Acolhimento . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Estado da Arte e Conceitos 52.1 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Arquitecturas de Single Sign-On . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Pseudo SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 SSO Centralizado . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 SSO Federado . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Tecnologias Relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Certificados X.509 . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.5 Security Assertions Markup Language - SAML . . . . . . . . . . 132.3.6 Cookies HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.7 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.8 Secure Socket Layer - SSL . . . . . . . . . . . . . . . . . . . . . 15

3 Soluções Single Sign-On 173.1 Central Authentication Service - CAS . . . . . . . . . . . . . . . . . . . 173.2 Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

3.3 simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Pubcookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 CoSign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.6 WebAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7 Resumo das funcionalidades das soluções SSO . . . . . . . . . . . . . . 25

4 Single Sign-On na FCUL 274.1 Arquitectura de Autenticação na FCUL . . . . . . . . . . . . . . . . . . 274.2 Aplicações com necessidade de Single Sign-On . . . . . . . . . . . . . . 284.3 Escolha da solução Single Sign-On a implementar na FCUL . . . . . . . 294.4 Arquitectura da solução escolhida - CAS . . . . . . . . . . . . . . . . . . 31

4.4.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.2 Autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.3 Federação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.4 Alta Disponbilidade . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Implementação e testes 375.1 Implementação Servidor CAS . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.2 Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.3 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.4 Autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.5 Federação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.6 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Integração do CAS com as aplicações FCUL . . . . . . . . . . . . . . . 435.2.1 Aplicações escritas em PHP . . . . . . . . . . . . . . . . . . . . 435.2.2 Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.3 Outlook Web Access . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Página de Gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4.1 Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4.2 Teste de sobrecarga . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Conclusão e trabalho futuro 536.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A Protocolo CAS 55A.1 Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.2.1 Login (/login) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

viii

A.2.2 Logout (/logout) . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.2.3 Validação de Serviços (/serviceValidate) . . . . . . . . . . . . . . 58A.2.4 Validação de Proxys (/proxyValidate) . . . . . . . . . . . . . . . 59A.2.5 Proxy (/proxy) . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Abreviaturas 64

Bibliografia 70

ix

Lista de Figuras

2.1 Sistema sem SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Sistema com SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Single Sign-On Federado . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Exemplo de um directório LDAP . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Arquitectura CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Arquitectura Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Arquitectura Pubcookie . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Arquitectura CoSign . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Arquitectura WebAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Autenticação na FCUL sem Single Sign-On . . . . . . . . . . . . . . . . 284.2 Autenticação na FCUL com CAS . . . . . . . . . . . . . . . . . . . . . . 324.3 Arquitectura CAS na FCUL . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 Certificado de Autenticação do Cartão de Cidadão . . . . . . . . . . . . . 395.2 Caminho de certificação do certificado de Autenticação do Cartão de

Cidadão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Página de pesquisa dos registos de auditoria do CAS . . . . . . . . . . . 465.4 Página de estatı́sticas do CAS na aplicação de gestão de SSO . . . . . . . 475.5 Latência de respostas dos servidores CAS a pedidos de autenticação . . . 505.6 Latência de respostas dos servidores CAS a pedidos de STs . . . . . . . . 51

xi

Lista de Tabelas

3.1 Comparação entre as diferentes soluções de SSO . . . . . . . . . . . . . 26

4.1 Compatibilidade das diferentes soluções de SSO em relação aos serviçosda FCUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

xiii

Capı́tulo 1

Introdução

À medida que os serviços fornecidos pelo Centro de Informática da Faculdade de Ciênciasvão aumentando, utilizadores e administradores de sistema deparam-se com sistemas cadavez mais complexos. Os utilizadores, habitualmente, têm de fazer login em múltiplos sis-temas, necessitando assim de um número igual de diálogos de login, que podem envolverdiferentes nomes de utilizador e informação de autenticação. Administradores de sistemastêm de gerir essas mesmas contas, dentro dos vários sistemas, de uma maneira coorde-nada, de modo a manter a integridade das polı́ticas de segurança. Uma solução para estefardo administrativo é a implementação de um serviço de Single Sign-On.

Neste capı́tulo pretende-se fazer uma breve introdução ao projecto, o seu contexto eos objectivos a alcançar.

1.1 Motivação

Single Sign-On, SSO, é um processo de autenticação em sessão, que permite a um uti-lizador introduzir as suas credenciais de acesso apenas uma vez para aceder a múltiplasaplicações protegidas. O processo autentica o utilizador para todas as aplicações a queeste tem direito de acesso e elimina a necessidade de se autenticar novamente ao mudarde aplicação durante a sessão.

A maior vantagem no uso de um sistema de SSO é deixar de incomodar o utilizadorcom múltiplos pedidos de login, retirando também a necessidade de decorar múltiplosnomes 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 aautenticação e assumir que, se o pedido para aceder a uma aplicação vem com um nomede utilizador associado, então a autenticação já foi feita. Quando as aplicações participamnum protocolo de SSO, o fardo da administração de gerir contas é bastante simplificado.

Não havendo uma infra-estrutura de autenticação centralizada na FCUL, a maneirados utilizadores se autenticarem depende das polı́ticas definidas localmente em cada serviço.Um sistema SSO irá permitir aos serviços da FCUL fazer outsourcing a toda a autenticação,

1

Capı́tulo 1. Introdução 2

obrigando a que estes sigam as polı́ticas de autenticação deste sistema garantindo umamaior segurança e consistência.

1.2 Objectivos

O principal objectivo deste projecto é a concretização de um sistema de SSO para aautenticação centralizada de utilizadores por parte dos serviços web existentes na FCUL.Para que este projecto seja realizado com sucesso é necessário identificar todas as fasesque o envolvem.

A primeira fase será um estudo acerca do tema de SSO, incluindo o estado da arte, assuas possı́veis arquitecturas e as soluções que existem para a sua implementação. Dentrodeste estudo são identificadas também todas as vantagens e desvantagens no uso de umsistema central de autenticação.

Após este estudo, é preciso identificar todos os requisitos para a integração de umsistema de SSO com os serviços web disponibilizados pelo CI. Esta análise é feita deacordo com as aplicações e linguagens de programação utilizadas na FCUL e respectivosservidores aplicacionais onde estas estão a correr.

Identificados os requisitos, é feita a escolha do sistema de SSO a implementar naFCUL, focando os pontos fortes desta solução em relação às outras analisadas, tendo emconta todos os prós e contras.

Após a realização das fases anteriores, análise e especificação, é feita a representaçãoabstracta do sistema, descrevendo detalhadamente o seu funcionamento e a sua estrutura.Só após a conclusão do desenho/arquitectura deste novo sistema é possı́vel passar para afase final de implementação, testes e manutenção.

1.3 Instituição de Acolhimento

A Faculdade de Ciências da Universidade de Lisboa, FCUL, é uma das unidades orgânicasque integram a Universidade de Lisboa. Actualmente, a FCUL ocupa onze edifı́cios comuma área total de 77 492m2, no campus do Campo Grande, e em 2008/2009, tinha 5061alunos distribuı́dos pelos vários ciclos de ensino e 634 funcionários, entre os quais 419docentes.

O Centro de Informática, CI, é a Unidade Orgânica da FCUL responsável pela gestãoda rede Internet, bem como dos diversos serviços a ela associados, nomeadamente correioelectrónico e páginas Web. A manutenção de alguns sistemas de informação, tais comoas bases de dados relativas à gestão de utilizadores (docentes, funcionários e alunos), estátambém a cargo do CI.

O CI tem ainda a seu cargo o apoio técnico a todos os funcionários da FCUL, atravésde um serviço de Help Desk. Contudo, a prestação de apoio especializado é realizada no


âmbito de acordos de colaboração com as várias unidades orgânicas da FCUL [20].

1.4 Contribuições

A principal contribuição deste projecto é a concretização de um sistema de SSO num meioacadémico, para integração com várias aplicações Web utilizadas diariamente, com neces-sidade de estarem altamente disponı́veis para os seus utilizadores. O sistema apresentadoneste relatório inclui todas as fases da sua concretização, desde a análise de possı́veissoluções de software de SSO a utilizar até à gestão e manutenção do sistema escolhido.

Outras importantes contribuições relativas à autenticação de utilizadores na FCULsão também descritas neste relatório, incluindo a introdução de uma nova maneira deautenticar utilizadores nos serviços Web da FCUL, através do uso do Cartão de CidadãoPortuguês e um Identity Provider (IdP) para sistemas de SSO federados.

1.5 Estrutura do documento

Este documento está organizado da seguinte forma:Capı́tulo 2. Estado da Arte e Conceitos - Neste capı́tulo, é feita a análise do estado da

arte e os conceitos associados à mesma.Capı́tulo 3. Soluções Single Sign-On – Neste capı́tulo, são analisadas algumas das

soluções 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̧ão SSO e a respectiva arquitectura, encontram-se neste capı́tulo.Capı́tulo 5. Implementação e Testes - Todo o trabalho realizado na implementação,

testes e integração do sistema de SSO nos serviços da FCUL está descrito neste capı́tulo.Capı́tulo 6. Conclusões - Neste capı́tulo, apresentam-se as conclusões 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̧ão são bastante populares em sistemas de computadores degrande escala. Em ambientes deste género, não é muito eficiente, do ponto de vista deimplementação e administração, criar um sistema de autenticação separado para cadasistema de computadores, recursos e servidores aplicacionais. É bastante melhor delegaresta funcionalidade a uma infra-estrutura de autenticação centralizada. A criação de umainfra-estrutura deste género permite a utilização de um sistema SSO.

SSO é um conceito bastante utilizado em grandes organizações e Intranets, que per-mite aos utilizadores inserirem as suas credenciais apenas uma vez, e verem a sua auten-ticação propagada para todos os serviços a que estão autorizados a aceder. Um utilizador,normalmente, utiliza vários sites da mesma instituição e cada um deles utiliza mecanismospara autenticação independentes, obrigando, por vezes, o utilizador a decorar nomes deutilizador e/ou palavras-chave diferentes para cada serviço (figura 2.1) . Com um serviçode SSO, toda a autenticação passará a ser feita de um modo centralizado, ficando estecom a responsabilidade de fornecer informação confiável de identidade dos utilizadoresaos serviços (figura 2.2).

Figura 2.1: Sistema sem Single Sign-On

Autenticação e autorização são dois aspectos cruciais para efectuar controlo de aces-sos num sistema. Quando um utilizador tenta aceder a uma aplicação, o processo deautenticação é iniciado e, se este for efectuado com sucesso, é seguido do processo de

5

Capı́tulo 2. Estado da Arte e Conceitos 6

Figura 2.2: Sistema com Single Sign-On

autorização.

Autenticação é o processo através do qual as credenciais do utilizador são verificadaspara comprovar a sua identidade. Habitualmente, envolve um nome de utilizador e umapalavra-chave, mas pode ser utilizado outro método que comprove a identidade do uti-lizador como impressões digitais, reconhecimento de voz ou smart cards.

Para a realização das tarefas de autenticação são normalmente utilizados sistemas degestão de informação de utilizadores, como os serviços de directório LDAP (ver secção2.3.1), autoridades de certificação X.509 (ver secção 2.3.3) ou bases de dados simplescomo JBDC ou MySQL (entre outros). Estes sistemas mantêm informação confiável eactualizada dos utilizadores para que as aplicações consigam provar a autenticidade dascredenciais inseridas pelos utilizadores.

Autorização, por sua vez, é o processo que consiste na verificação das permissões deum 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ı́velde segurança. Mais formalmente, autorizar é definir uma polı́tica de controlo de acesso[15].

Para definir controlo de acesso dos utilizadores às aplicações são usados sistemas degestão de informação de autorização como Lista de controlo de acesso (ACLs) ou Listade Capacidades (C-List) [12].

Uma ACL é uma lista de permissões associadas a um objecto. Uma ACL especı́ficaque utilizadores ou processos têm acesso aos objectos, e que operações são permitidasem certos objectos. Cada entrada numa tı́pica ACL especı́fica contém o par . Por exemplo, se uma aplicação contém na sua ACL, istoirá dar permissão ao utilizador ”fwestanqueiro”para adicionar dados à aplicação. EstasACLs são, obviamente, protegidas contra modificações não autorizadas.

Numa C-List, ao contrário das ACL, cada sujeito tem uma lista de objectos a queeste pode aceder. Ou seja, cada entrada nesta lista contém o par .Por exemplo, se um utilizador contém na sua C-List o par , significaque este pode apenas visualizar uma dada aplicação. Tal como as ACLs, as C-Lists sãoprotegidas contra modificações não autorizadas.

Estas listas são feitas com base nos atributos dos utilizadores, populados no sistema


de gestão de utilizadores (p.e. LDAP), e enviados para as aplicações pelo sistema de SSO.Ao receber os atributos de um utilizador, a aplicação irá verificar se este tem permissãopara a aceder. Por exemplo, o sistema de SSO envia os atributos de um utilizador para aaplicação juntamente com o username após ter sido realizada a autenticação. Ao receberestes atributos, a aplicação pode verificar se o utilizador contém os atributos necessáriospara a aceder, definidos nas listas de controlo de acesso (p.e. se o utilizador está no grupo”Admin”).

Usando as funções oferecidas pelos mecanismos de um sistema de SSO, as tarefas deautenticação e autorização passam a ser geridas num ponto central, garantindo polı́ticasconsistentes e coordenadas para todas as aplicações web que o utilizem.

2.1.1 Vantagens

A implementação e uso de um sistema de SSO num sistema já existente, com diversosserviços já implementados que requerem autenticação dos utilizadores, trazem vantagenspara ambos utilizadores e administradores [2].

Do ponto de vista do utilizador irá haver notória redução do tempo despendido duranteas operações de autenticação, aumentando a sua produtividade. Havendo apenas um inter-face de login, irá também haver uma melhoria da usabilidade dos serviços. A segurançados utilizadores é também reforçada, já que o número de usernames e palavras-chave quecada um tem de gerir é mais reduzida.

Do ponto de vista do administrador toda a gestão das contas dos utilizadores fica maissegura e simplificada porque, com um ponto central de administração, existe uma reduçãodo tempo despendido a adicionar e eliminar utilizadores e modificar os seus privilégios eatributos. Passa também a haver um cumprimento consistente da polı́tica de autenticaçãodo sistema em todas as aplicações, fornecendo aos administradores uma maneira muitofácil 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 desegurança inerentes ao processo de autenticação centralizado. Por exemplo, o caso emque um computador é deixado sem vigia, com uma sessão aberta, poderá oferecer umacesso global indevido a todas as aplicações associadas ao utilizador do computador.

Ao centralizar a autenticação, é criado também um ponto de ataque único, tornando-oum alvo atractivo para hackers que queiram fazer ataques de negação de serviço - DenialOf Service (DoS). Um ataque DoS é uma tentativa de impedir utilizadores legı́timos deaceder a informação ou serviços. Geralmente um ataque DoS é feito através da inundaçãode informação numa rede. Ao encher a rede com pedidos, e visto que o servidor apenasconsegue processar um certo de número de pedidos, o pedido de um utilizador legı́timo


pode não ser processado. É um ataque de negação de serviço porque o serviço pretendidonão pode ser acedido. Um ataque deste tipo tem o custo elevado de nenhum utilizadorconseguir aceder aos recursos associados ao sistema de SSO [5].

A falha de um dos componentes cruciais para o funcionamento correcto do servidor deSSO, software ou hardware, pode ter sérios custos para o sistema onde está integrado. Porexemplo, se por acaso a máquina onde está a correr o servidor SSO falhar e esta for única adesempenhar este serviço, todas as próximas autenticações irão falhar, bloqueando todosos serviços a novos acessos. Como tal, é necessário preparar o servidor para funcionarcom alta disponibilidade tornando-o tolerante a faltas, sem pontos únicos de falha.

Também a adaptação do sistema de SSO às aplicações já existente pode ser dis-pendiosa e consumidora de tempo, sendo que deve ser adoptada a solução que melhorse integre com as mesmas.

Todos estes aspectos deverão ser analisados cuidadosamente para a implementação,com sucesso, de um sistema de SSO na FCUL.

2.2 Arquitecturas de Single Sign-On

2.2.1 Pseudo SSO

Uma aproximação óbvia para suporte do utilizador é fornecer-lhe a gestão das suas cre-denciais. O utilizador pode guardar todas as suas palavras-chave e informação de auten-ticação num ficheiro encriptado ou uma base de dados segura com uma palavra-chavemestre. Obviamente que esta palavra-chave necessita de um grau de complexidade maiselevado pois será a única palavra-chave que o utilizar necessita de utilizar. Mas múltiplose diferentes mecanismos de autenticação ainda são utilizados, mesmo que não tenhaintervenção de utilizadores, e estes sistemas não podem ser chamados verdadeiros sis-temas de SSO.

Esta arquitectura tem como maior problema a corrupção ou a perda da base de dadosdas credenciais, impedindo assim o acesso do utilizador ao sistema, se este não se lem-brar das palavras-chave (estas podem não ser utilizadas regularmente). Por outro lado outilizador tem de escrever várias vezes a palavra-chave mestre, o que irá fazer com queeste a decore.

Esta solução também afecta a mobilidade do utilizador porque a base de dados decredenciais tem de estar disponı́vel em todos os computadores que este usa. Para resolvereste problema as credenciais podem estar guardadas online, mas o utilizador tem de teracesso online contı́nuo.


2.2.2 SSO Centralizado

As caracterı́sticas chave de sistemas de SSO centralizados é, tal como o nome indica, acentralização da autenticação e da base de dados de utilizadores. Tal sistema, tem de teruma relação 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). Outilizador só 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 umtoken de software que é guardado na sua máquina utilizado para pedidos subsequentes aoTTP. Este token irá remover a necessidade do utilizador introduzir novamente as suas cre-denciais. Este token pode também ser reutilizado para identificar o utilizador para outrosdomı́nios de autenticação TTP. Os SP’s podem validar este token através de métodos crip-tográficos baseados em chaves secretas (criptografia simétrica). Estas chaves estabelecemuma relação de confiança entre o TTP e os SP’s. O software de SSO baseado em tokensvem já presente em alguns dos populares sistemas operativos como o Windows 2008 ouNetware. O melhor exemplo de um sistema de SSO baseado em tokens é o Kerberos (versecção 2.3.7 deste capı́tulo).

Baseados em PKI: Em sistemas baseados em PKI, o utilizador tem primeiro de seregistar numa TTP, neste caso chamado de Certification Authority (CA). Durante esteprocesso de registo são geradas um par de chaves assimétricas. A chave pública deste paré enviada para o CA e depois de o utilizador se autenticar com sucesso, o CA gera umcertificado de chave pública 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 pública do CA. Comoexemplos de uma estrutura PKI, temos o Cartão do Cidadão que possui um certificado deautenticação emitido para o cidadão assinado pelo estado português (CA). (ver secção2.3.4 deste capı́tulo).

2.2.3 SSO Federado

Sistemas de SSO, normalmente, estão limitados a uma organização ou um domı́nio. Paraestabelecer confiança entre diferentes domı́nios, são necessárias Federações. O objectivoé, portanto, um sistema em que as credenciais de um utilizador provindas do seu domı́nio,serão aceites num outro domı́nio sem que o utilizador tenha que reintroduzir as suas cre-denciais. Isto remove a necessidade de sincronização e cópia de credenciais entre difer-entes domı́nios. Para sistemas SSO baseados em PKI isto pode ser conseguido através de


hierarquias de CA’s ou certificação cruzada. Os sistemas federados têm a seguinte estru-tura:

Circulo de confiança – A base de um sistema federado é o cı́rculo de confiança, entreos fornecedores de serviços, Service Providers (SP). Este cı́rculo, para além de ter de serimplementado tecnicamente (p.e. hierarquias CA), tem de ser feito através de contratosde negócio entre as companhias participantes. Estes contratos incluem também acordosde operação que cada SP tem de cumprir.

Identity Provider (IdP) – Dentro de um domı́nio é possı́vel centralizar a administraçãoe a gestão da identidade de um utilizador usando um IdP ou formando um domı́nio desegurança contendo vários IdP, cada um confiando nos restantes. Este último tem umaestrutura similar ao cı́rculo de confiança mas apenas dentro da organização.

Identity Federation – À parte do cı́rculo de confiança, os SPs têm também de nego-ciar acordos de operação com outros SP’s de outros domı́nios de segurança. Um possı́vel,e importante, acordo deverá ser sobre a privacidade dos utilizadores. A identidade de umutilizador (gerida pelo IdP) consiste num conjunto de atributos e deve-se portanto mar-car os atributos com dados mais sensı́veis ou informação confidencial. Atributos comesta marca não são transferidos aos outros SPs. Normalmente tal informação nem énecessária para a autorização. Os atributos que são 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, ondeas suas credenciais são mantidas, tem acesso aos recursos académicos da Universidade Batravés do acordo de federação que ambas fizeram. Um bom exemplo da utilização desta


arquitectura de SSO é o projecto Internet2 Shibboleth, explicado em detalhe na secção3.2.

2.3 Tecnologias Relacionadas

2.3.1 LDAP

LDAP, Lightweight Directory Access Protocol, é um protocolo de aplicações com o ob-jectivo de guardar, modificar e pesquisar dados, usando serviços de directório a correrTCP/IP.

Um directório é um conjunto de objectos com atributos organizados de uma maneiralógica e hierárquica. Um exemplo simples é um directório de telefones, que consistenuma lista de nomes (de pessoas ou organizações) organizados alfabeticamente, cada umtendo um endereço e um número de telefone associado.

Um directório LDAP, organizado em árvore, reflecte normalmente barreiras, polı́ticasou situações geográficas, dependendo do modelo escolhido. Cada entrada neste directóriocontém um conjunto de atributos. Cada atributo destes, possui um ou mais valores, sendoque todos os elementos estão definidos num schema. Cada entrada tem um DistinguishedName (DN) único, construı́do a partir dos seus atributos, seguido do DN do directório pai,como se pode ver na figura 2.4. Os atributos mais comuns num DN são OU, Organiza-tional Unit, CN, Common Name, e DC, Domain Controller.

Figura 2.4: Exemplo de um directório em árvore LDAP

O LDAP tende a ser usado com o Domain Name System, DNS, para estruturar nı́veis


hierárquicos, usualmente indicados no atributo DC [3]. Neste momento o LDAP vai nasua versão 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 directório usada em computadores e servi-dores baseados no sistema operativo Microsoft Windows, utilizada para guardar informaçãoe dados sobre redes e domı́nios. Tal como o LDAP, é definido por uma estrutura hierárquicaem árvore com conjuntos de objectos. Um AD ainda fornece os seguintes serviços:

• Compatibilidade com aplicações que suportam LDAP;

• Autenticação baseada em Kerberos;

• Nomes baseados em DNS e outra informação de rede;

• Localização centralizada para administração de rede e delegação de autoridade;

• Informações de segurança e SSO para o utilizador aceder a recursos de rede;

• Escalabilidade;

• Armazenamento central para dados de aplicação e sincronização de actualizaçõesde directório entre vários servidores;

Um Active Directory permite também aos administradores definir polı́ticas, instalarsoftware e aplicar updates crı́ticos à organização em ambientes Windows. Redes de Ac-tive Directory podem variar desde uma pequena instalação com poucos computadores,utilizadores e impressoras, até milhares de utilizadores, diferentes domı́nios e vários servi-dores em diferentes zonas geográficas [9].

2.3.3 Certificados X.509

Os algoritmos de codificação assimétrica baseiam-se na partilha, entre os diferentes uti-lizadores, de uma chave pública. Um certificado X.509 permite associar uma chavepública a uma entidade (uma pessoa, uma máquina, . . . ) a fim de assegurar a sua valida-de. Ou seja, este certificado é o como um bilhete de identidade para um chave pública,emitido por uma autoridade de certificação (Certification Authority, CA).

O CA está encarregue de emitir certificados e atribuir-lhes uma data de validade. Nocaso de comprometimento da chave (ou do proprietário desta) ou data de validade expi-rada, o CA têm a obrigação de revogar este certificado.

Uma autenticação baseada em certificados X.509 faz tecnicamente parte do métodode autenticação por chaves públicas. Ou seja, a assinatura criada com uma chave privada


e a verificação dessa mesma assinatura usando uma chave pública (contida no certificadoX.509). A diferença está em determinar se um dado utilizador está autorizado a fazerlogin com uma chave pública ou certificado. Com chaves públicas convencionais, cadaservidor tem de ter todas as chaves públicas dos utilizadores. Com certificados, as chavespúblicas dos utilizadores não têm de ser distribuı́das pelos servidores. Distribuir a chavepública da Autoridade de Certificadora é o suficiente para verificar a assinatura.

2.3.4 Cartão de Cidadão

O Cartão de Cidadão, CC, é o novo documento único de identificação de cidadania Por-tuguesa. Este novo documento de identificação não é mais que um smart card ondese encontra um par de chaves, pública/privada, e certificados associados ao seu deten-tor, sendo o estado português o CA. Esta chave privada encontra-se protegida por umapalavra-chave numérica. Este smart card possui dois certificados com finalidades distin-tas. Um destina-se à de assinatura de documentos, o outro permite efectuar autenticações.Visto que ambos os certificados foram emitidos pelo CA do Estado Português, 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̧ões electrónicas efectuadas com omesmo.

A autenticação forte utilizando o Cartão de Cidadão tem uma vantagem crucial emrelação a outros mecanismos normalmente utilizados, pois é baseada em 2 factores (algoque se tem e algo que se sabe). Isto é, garante que o utilizador de um serviço electrónicopossui o Cartão de Cidadão e também conhece o seu PIN. Em comparação, a autenticaçãobaseada em nome de utilizador/palavra-chave (utilizada na maioria dos sistemas actu-ais), esta última é muito mais vulnerável ao ”roubo”e ”empréstimo”da senha pessoal docidadão [16].

2.3.5 Security Assertions Markup Language - SAML

Security Assertions Markup Language, SAML, é uma framework baseada em XML paracomunicação de informação de identidade, direitos e atributos dos utilizadores, e foi de-senvolvido pelo OASIS (Security Services Technical Committee of the Organization forthe Advancement of Structured Information Standards).

Como o seu nome sugere, o SAML permite às entidades organizacionais fazer asserçõessobre a identidade, atributos e direitos de um sujeito para outras entidades, que podem seruma organização parceira, uma aplicação de outra empresa, etc. O SAML é um pro-tocolo extensı́vel desenhado para ser usado por outros protocolos com outros standards.Por exemplo, a “Liberty Alliance”, o projecto “Internet2 Shibboleth”, e o “OASIS WebServices Security (WS-Security)” adoptaram o SAML, utilizando-o tecnologicamente avários nı́veis.


Ao nı́vel do SSO, o uso da tecnologia SAML traz o benefı́cio de tornar os serviçosWeb seguros, visto as suas asserções poderem ser utilizadas como tokens de segurançadentro de headers SOAP de maneira a transportar seguramente e com privacidade informaçõesde identidade. O uso destas asserções pode também ser utilizado para ser criada umaautorização baseada em atributos do utilizador [8].

2.3.6 Cookies HTTP

Um HTTP cookie, também conhecido apenas por cookie, é uma cadeia de caracteresguardada num browser Web de um utilizador. Um cookie consiste num ou mais pares denome-valor contendo pedaços de informação, que podem estar encriptados para privaci-dade de informação ou segurança de dados. Um cookie é enviado do servidor Web para obrowser no cabeçalho de um pacote HTTP, e posteriormente enviado pelo browser Webcada vez que aquele servidor Web é acedido.

No caso de ser usado num sistema de SSO, o agente que autentica utilizadores deixaum cookie no browser do cliente. Quando o utilizador tenta aceder a um recurso, o sistemapede o cookie e se este está presente e é verificado como estando válido então o utilizadortem o acesso autorizado. Se não está presente ou está algo incorrecto com o cookie, porexemplo, se já passou o perı́odo de validade em que o sistema de SSO opera, então épedido ao utilizador para se reautenticar. Os cookies vêm em texto visı́vel, o que não éseguro. Toda a informação que está no cookie pode sofrer ataques de sniffing e como tal,a informação sensı́vel não deve ser passada desta maneira. Uma boa maneira de garantirque os cookies não são retornados sem qualquer tipo de segurança é utilizar o parâmetro“secure”, que garante que o browser não retorna o cookie a não ser que seja usado umURL seguro, com o protocolo https [23].

2.3.7 Kerberos

Kerberos é um famoso sistema de SSO centralizado baseado em tokens, desenvolvido nosanos 80 no MIT. Para usar Kerberos, tem de haver um servidor com serviços, um clientee o Key Distribution Center, KDC. O KDC está dividido em duas partes (o Servidor deAutenticação, 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. Só depois da autenticação serefectuada com sucesso, é gerado um Ticket Granting Ticket, TGT. Se o cliente quer usaroutro serviço, já não é necessário 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 donovo serviço deve verificar se o ticket do cliente é valido ou não. Resumindo, o cliente sónecessita de se autenticar uma vez, e daı́ em diante contacta o TGS enquanto o seu ticketfor válido [6]. Um exemplo do uso do Kerberos é o Microsoft Windows 2000.


2.3.8 Secure Socket Layer - SSL

O protocolo SSL, Secure Socket Layer, foi criado originalmente pela Netscape para as-segurar transacções seguras entre servidores Web e browsers. Este protocolo usa umaterceira parte, uma Autoridade de Certificação (CA), para identificar um dos lados, ouambos da transacção. Funciona da seguinte maneira:

1. Um browser pede uma página segura (usualmente https://);2. O servidor Web envia a sua chave pública com o seu certificado;3. O browser verifica que o certificado foi atribuı́do por uma entidade confiável (nor-

malmente uma CA root confiável), que ainda está válido e que o certificado está rela-cionado com o site visitado;

4. O browser usa então a chave pública para cifrar uma chave de encriptação simétricaaleatória e envia-a para o servidor juntamente com o URL encriptado, requerido, assimcomo outros dados http cifrados;

5. O servidor Web decifra a chave de encriptação simétrica usando a sua chave privadae usa a chave simétrica para decifrar o URL e os dados http;

6. O servidor envia então o documento HTML pedido e dados HTTP encriptados coma chave simétrica;

7. O browser decifra os dados HTTP e o documento HTML, usando a chave simétrica,e mostra a informação. [40]

Capı́tulo 3

Soluções Single Sign-On

Existem várias soluções, open source, de sistemas SSO para aplicações Web. Nestecapı́tulo serão analisadas as várias opções disponı́veis para implementação de um sis-tema SSO na FCUL. Estas soluções foram escolhidas já tendo em conta o suporte deautenticação num directório Microsoft Active Directory ou LDAPv3, sendo que esta seráa maneira de autenticação primária dos utilizadores na FCUL (ver Capı́tulo 4).

3.1 Central Authentication Service - CAS

O projecto CAS [19], Central Authentication Service, foi inicialmente desenvolvido em2001 pela Universidade de Yale para autenticação de utilizadores de uma maneira confiávele centralizada. Em Dezembro de 2004, passou a ser um projecto da empresa Jasig.

O CAS fornece um serviço de SSO com o seu próprio protocolo, aberto, e com oservidor de autenticação totalmente escrito na linguagem Java. A integração do CAS comas aplicações pode ser ao nı́vel de módulos/filtros no servidor aplicacional ou do ladoda aplicação através de bibliotecas/clientes para várias linguagens de programação, comoPHP ou ASP.NET. O servidor CAS apenas requer um servidor Web que seja capaz decorrer servlets Java, como o Apache Tomcat ou JBoss e o Java JDK.

O CAS foi desenhado para ser um produto sem autorização, focando-se apenas naautenticação do utilizador. No entanto, o CAS permite a gestão de autorização de serviçosassociados ao SSO e escolher que atributos do utilizador a aplicação tem direito a receber.Assim, a aplicação pode criar o seu mecanismo de controlo de acesso próprio com basenestes atributos.

Como se pode observar na figura 3.1, o processo de autenticação, geralmente, começacom um pedido de um utilizador a um recurso protegido, que o redirecciona para a páginade login. Este redireccionamento é feito juntamente com o URL para o qual o CAS vaienviar o utilizador após a autenticação ser efectuada (passo 1-3). Esta autenticação irágerar um Ticket Granting Cookie (TGC) - uma longa cadeia de caracteres aleatórios quemapeia este cookie ao utilizador. É através deste cookie que o utilizador é indexado na

17

Capı́tulo 3. Soluções Single Sign-On 18

Figura 3.1: Arquitectura de autenticação inicial com CAS

memória cache de credenciais no servidor CAS. Se o browser suportar cookies, entãoo TGC é enviado para o browser como um cookie não persistente identificando um lo-gin bem sucedido, evitando assim a necessidade de autenticação no servidor CAS parapedidos subsequentes (passos 4-5).

Depois de concluı́do o processo de autenticação, o CAS redirecciona o browser parao serviço pedido, juntamente com um Service Ticket (ST) - outra cadeia de caracteresaleatórios que mapeia o utilizador e o serviço pedido (passo 6). A aplicação pode agoraextrair o ticket e valida-lo usando o URL de validação do CAS, passando o ticket e oserviço como parâmetros deste URL (passos 7). Uma validação feita com sucesso resultana destruição no ticket de serviço e é retornado o nome de utilizador ao serviço (passos8). Finalmente, o utilizador tem acesso ao recurso pretendido inicialmente (passo 9).Futuros pedidos a servidores/aplicações protegidas pelo CAS não irão necessitar que outilizador se autentique novamente, visto este já possuir todos os tokens necessários parauma experiência SSO [18].

O CAS também tem suporte para Proxy. Proxy é basicamente um serviço que desejacomunicar com outro serviço em nome de um utilizador. Isto é conseguido através de um


Proxy-Granting Ticket (PGT) do CAS que permite produzir um Proxy Ticket (PT) que dáacesso ao serviço simulando um utilizador. Esta habilidade de proxy é particularmenteimportante para serviços, como portais, que desejam comunicar com outros serviços emnome do utilizador sem perguntar novamente pelas credenciais [17].

O CAS oferece um protocolo de Single Sign-Out, efectuado quando um utilizadoracede à página de logout. Para isto, o CAS envia uma mensagem POST HTTP a todasas aplicações que estejam associadas à sessão do utilizador. Este Single Sign-Out apenasfunciona para clientes / linguagens cuja gestão de sessão é mantida do lado do servi-dor. Isto significa que em aplicações cuja sessão é mantida em cookies no browser doutilizador, a que o CAS não tem acesso, não participam no protocolo de Single Sign-Out.

3.2 Shibboleth

Shibboleth [35] é um sistema de SSO, baseado em formatos abertos, principalmenteSAML. É um sistema federado, suportando um acesso seguro a recursos em vários domı́nios.As chamadas federações podem servir para vários servidores de recursos confiarem entresi duma forma escalável. Entres estes servidores, numa federação, podem ser trocadasinformações de identidade, direitos e atributos de utilizadores. O projecto Internet2 Shib-boleth começou em 2000, sendo que a versão 1.0 foi apenas lançada em 2003 e a versão2.0 foi lançada em Março de 2008.

O Shibboleth tem dois componentes essenciais para o seu funcionamento: um IdentityProvider (IdP) e um Service Provider (SP). O IdP tem como função principal responder apedidos de informação sobre utilizadores. O SP utiliza esta informação para proteger osrecursos. A componente IdP apenas necessita um servidor Web que seja capaz de correrservlets Java, como o Apache Tomcat ou JBoss e o Java JDK. Para o componente SP,existem módulos para os servidores aplicacionais Apache Web Server e IIS.

Como se pode ver na figura 3.2, um utilizador não autenticado ao tentar aceder a umrecurso protegido é redireccionado para a página de WAYF (“Where Are You From?”),cujo objectivo é canalizar os utilizadores não autenticados para as respectivas instituiçõesde origem, ou seja, escolher o IdP onde as suas credenciais são mantidas (passos 1-3).

Após a selecção, por parte do utilizador, da sua instituição, este serviço redirecciona outilizador automaticamente para a página de login do IdP da sua instituição (passos 4-6). Se a autenticação for feita com sucesso, este IdP vai preparar a informação protegidapara ser enviada para o recurso presente no SP, e é feito um redireccionamento para o SPjuntamente com uma “handle” de autenticação (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 tudocorrecto, os atributos do utilizador são enviados ao recurso (passo 11). Ao receber osatributos, o SP pode tomar uma decisão informada sobre o acesso do utilizador a recursos


protegido (passo 12) [36] [37].O Shibboleth não oferece suporte para Single Sign-Out, recomendando que o browser

Web seja fechado pelo utilizador quando este desejar terminar a sessão.

Figura 3.2: Arquitectura de autenticação inicial e envio de atributos do Shibboleth

3.3 simpleSAMLphp

simpleSAMLphp [38] é uma aplicação escrita totalmente em PHP que agrega mecanismosde autenticação e protocolos de federação, podendo ser utilizado como Identity Providere/ou Service Provider.

Esta aplicação suporta protocolos SAML 2.0 e Shibboleth 1.3 para ambos IdentityProvider, IdP, e Service Provider, SP. A arquitectura de autenticação e autorização destaaplicação, é, portanto, igual à do Shibboleth. O simpleSAMLphp permite ainda a utilizaçãode mecanismos de autenticação SSO alternativos para o IdP, como é o caso do Jasig CAS,Twitter ou OpenId.

Apenas necessita de um servidor capaz de interpretar PHP, como o Apache Web


Server com o módulo PHP instalado e configurado com as extensões zlib, OpenSSL,CURL e LDAP.

3.4 Pubcookie

Pubcookie [30] é um sistema de autenticação proveniente da Universidade de Washing-ton, que consiste apenas num servidor de login e filtros para servidores aplicacionais. Oservidor de login requer apenas que haja um suporte para scripts CGI (Common GatewayInterface). CGI é um standard Web [4] que define como um software de um servidorWeb delega a criação de páginas Web a uma aplicação. Estas aplicações têm o nomede scripts CGI, e podem ser escritas em qualquer linguagem de programação. Noutraspalavras, é uma interface entre servidores Web e clientes. Por outro lado, os módulos doPubcookie existem apenas para Apache Web Server ou Microsoft IIS, estando assim osserviços limitados ao uso destes servidores aplicacionais.

Figura 3.3: Arquitectura de autenticação inicial com Pubcookie

Como se pode observar na figura 3.3, o processo de autenticação 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 não efectuou a autenticação noservidor de login, irá criar dois cookies, um cookie de pré-sessão associado ao recurso


pretendido e um Granting Request Cookie associado ao servidor de login e redireccionao utilizador para a página de login (passos 2-4).

Depois de se autenticar com sucesso, é gerado um Granting Cookie, contendo onome de utilizador e um número aleatório recebido do servidor aplicacional via Grant-ing Request Cookie, e um Login Cookie para ser utilizado em pedidos subsequentes deautenticação (passos 5-6). Este Granting Cookie está protegido contra modificações aoser assinado pela chave privada do servidor de login, e protegido contra revelação aoser cifrado com uma chave simétrica secreta partilhada entre o servidor aplicacional e oservidor de login. O utilizador é agora redireccionado para o recurso original, mas agorafazendo um pedido com o Granting Cookie e o Cookie de pré-sessão (passo 7).

O filtro do servidor aplicacional intercepta novamente o pedido, verificando agora oGranting Cookie e o cookie de pré-sessão. O filtro verifica a assinatura usando a chavepública do servidor de login e compara o número aleatório contido no Granting Cookiecom número aleatório contido no cookie de pré-sessão. Se ambos os cookies são válidos,o filtro envia o nome de utilizador para a aplicação juntamente com o resto do pedido orig-inal. O filtro gera também uma cookie de sessão para pedido subsequentes do utilizadorà aplicação. Tendo autenticado com sucesso o utilizador, a aplicação pode finalmenteenviar o recurso originalmente pedido (passo 8).

Se o Granting Request Cookie for acompanhado por um já estabelecido, e válido,Login Cookie, o utilizador já não necessita de se autenticar novamente, começando assima experiência de SSO [31].

O Pubcookie não fornece qualquer tipo de mecanismo para autorização ou SingleSign-Out.

3.5 CoSign

CoSign [24] foi lançado em versão beta em 2002 para providenciar à Universidade deMichigan um sistema de SSO na Web, constituı́do por três componentes.

O CGI central é responsável por autenticar utilizadores no servidor central CoSign. Étambém responsável para registar cada serviço que o utilizador acede – esta acção associao cookie de login do utilizador à sua sessão nas aplicações. Este CGI foi construı́do parautilizar Kerberos V e GSSAPI para autenticar os utilizadores.

O segundo componente, é o daemon central responsável por manter o estado de todasas sessões do CoSign, incluindo utilizadores que fizeram login, logout ou idle time out.Isto significa que o daemon mantém o estado de todos os cookies de serviço que represen-tam as aplicações Web que o utilizador acedeu. O daemon tem a habilidade de replicar asua base de dados de cookies para múltiplos servidores, para que a falha de um servidornão constitua a falha de um sistema. O daemon responde a interrogações de identidade deutilizadores do CGI e do filtro e comunica com os outros daemons através do protocolo


de replicação. O daemon foi escrito inteiramente em C e tem conhecimento dos ticketsKerberus V.

Por último existe o filtro que é instalado nos servidores aplicacionais, responsável pordeterminar que áreas do Web site estão protegidas pelo CoSign e as que não estão. Se umutilizador tenta aceder a uma área protegida, o filtro assegura que o utilizador está autenti-cado, e obtém o seu username, o realm de autenticação, endereço ip e opcionalmente umticket Kerberos. Esta informação pode ser utilizada por mecanismos externos para pos-teriores decisões de autorização. CoSign permite a integração deste filtro nos servidoresaplicacionais Apache Web Server, IIS 6 e 7 e também para servidores que suportam Java,como o Tomcat ou o JBoss.

Figura 3.4: Arquitectura de autenticação inicial com CoSign

Como se pode observar pela figura 3.4, o processo de autenticação é bastante semel-hante ao processo de autenticação do CAS. Este processo inicia-se, tipicamente, peloacesso de um utilizador a um recurso protegido sendo redireccionado para a página delogin caso não apresente um Service Token válido (passos 1-3). A autenticação do uti-lizador nesta página irá gerar um Login Cookie, para indexar o utilizador é indexado namemória cache de credenciais do CoSign, e o Service Token para acesso ao serviço (pas-


sos 4-6) . Após a recepção do Service Token, a aplicação irá verificar se este é válidocomunicando com o servidor de login (passo 7). Se o servidor de login responder com oID de utilizador, significa que o token está válido e a aplicação envia o utilizador para orecurso pretendido (passos 8-9).

O CoSign suporta o Single Sign-Out de todos os serviços associados ao CoSignatravés de um URL [25].

3.6 WebAuth

WebAuth [41] é sistema de SSO construı́do a pensar em servidores aplicacionais com oApache Web Server como front end de pedidos HTTP. Entrou em produção em Stanford,em Julho de 1997 e teve a sua maior reformulação em Fevereiro de 2003. O WebAuthconsiste no WAS (servidor aplicacional com WebAuth activado) e o WebKDC (WebAuthKey Distribution Centre), ambos escritos em C. Tanto para o WAS como para o WebKDCé necessário instalado Apache, OpenSSL, MIT Kerberus ou Heimdal Kerberus e cURL.

Como se pode verificar na figura 3.5, o WAS é responsável por verificar se um uti-lizador já está identificado no WebKDC, ou seja, se este já possui um ID Token (passo 3).Se o utilizador não tiver este token, o pedido é redireccionado para o WebKDC com umRequest Token (passo 4) . A componente WebLogin do WebKDC apresenta uma páginade login no browser do utilizador e se a autenticação for feita com sucesso, o WebKDCvai 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 ovai verificar após a sua recepção (passo 8). Se este estiver correcto, é criado um cookie desessão, e o utilizador ficará então com acesso ao recurso inicialmente pretendido (passo9).

A maior desvantagem neste sistema é não ter suporte para mais nenhum servidor apli-cacional, como o IIS. Não possui um sistema de Single Sign-Out e para integração comautenticação em directórios LDAP/Microsoft Active Directory é necessário a instalaçãode um segundo módulo Apache e as aplicações Cyrus SASL e OpenLDAP. Para o enviodos atributos de um utilizador, populado num directório deste tipo, é ainda necessário ummódulo adicional instalado no WebKDC [44].


Figura 3.5: Arquitectura da autenticação inicial com WebAuth

3.7 Resumo das funcionalidades das soluções SSO

Para uma melhor comparação entre as diversas soluções SSO previamente analisadas,foram definidas as seguintes funcionalidades chave:

• Autenticação - A solução permite autenticação tendo como base de credenciais umdirectório LDAP;

• Autorização - A solução possui a capacidade de serem disponibilizados à aplicaçãoos atributos populados num directório LDAP;

• Federação - A solução permite, de raiz, a possibilidade de federar a identidade deutilizadores de um directório LDAP;

• Filtros - A solução fornece filtros e/ou módulos para os servidores aplicacionaisreferidos;

• Single Sign-Out - A solução permite Single Sign-Out, ou seja, logout simultâneoem todas as aplicações.


Software Autenticação Autorização Federação Filtros SingleSign-Out

CAS√ √

χ IIS, Apache√

Shibboleth√ √ √

IIS, Apache χsimpleSAMLphp

√ √ √IIS, Apache

√

PubCookie√

χ χ IIS, Apache χCoSign

√χ χ IIS, Apache

√

WebAuth√ √

χ Apache χ

Tabela 3.1: Comparação entre as diferentes soluções de SSO

Ao analisar a tabela 3.1 é possı́vel fazer uma rápida comparação entres as funcional-idades das diversas soluções encontradas. No capı́tulo seguinte irá ser feita a análisedestas mesmas soluções para integração das aplicações Web especificas da FCUL comnecessidade de SSO.

Capı́tulo 4

Single Sign-On na FCUL

4.1 Arquitectura de Autenticação na FCUL

O Centro de Informática (CI) disponibiliza cada vez mais sistemas de informação naInternet aos utilizadores da FCUL. Estes utilizadores estão representados através de ob-jectos num directório, Microsoft Active Directory, em dois domı́nios diferentes, fc.ul.pte alunos.fc.ul.pt. O domı́nio fc.ul.pt, contém as contas dos funcionários, docentes e nãodocentes, enquanto o domı́nio alunos.fc.ul.pt contém todas contas de alunos da Faculdade.

Este directório permite aos serviços do CI ligarem-se todos à mesma central de cre-denciais de utilizadores para realizar operações de autenticação, sem redundância deinformação. Ou seja, para um serviço autenticar um utilizador basta criar uma ligaçãoao directório e verificar se as credenciais inseridas estão correctas. Mas não havendouma infra-estrutura de autenticação, esta tarefa têm de ser codificada individualmentepara cada serviço, não havendo polı́ticas de autenticação obrigatoriamente consistentes.O facto de não existir um sistema de SSO na FCUL tem as seguintes desvantagens:

• Para efectuarem a ligação ao directório, os serviços precisam de fornecer as creden-ciais de um utilizador com as devidas permissões para este efeito. Isto originou acriação excessiva de contas com esta permissão à medida que foram criados novosserviços disponibilizados pelo CI.

• Apesar de ser usada a mesma base de dados de credenciais, a maneira como osserviços autenticam os utilizadores não é necessariamente a mesma. Não havendouma centralização de polı́ticas de autenticação, certos serviços da FCUL exigiamapenas o username, outros o endereço de correio electrónico completo para realizara autenticação ([email protected] ou [email protected]). Como se podeobservar na figura 4.1, esta falta de coordenação pode dar origem a confusão porparte dos utilizadores na maneira de como se devem autenticar em certos serviços.

• O aspecto da página de login varia entre os diferentes serviços. O facto de osutilizadores não reconhecerem a página na qual estão a introduzir as credenciais

27

Capı́tulo 4. Single Sign-On na FCUL 28

Figura 4.1: Autenticação na FCUL sem Single Sign-On

traz sérios riscos de segurança. É bastante mais seguro os utilizadores inseriremsempre as suas credencias numa página que conhecem e confiam.

• Os registos de acesso nas aplicações não estão centralizados, aumentado os custosde auditoria de processos de autenticação.

Com um sistema de SSO, os serviços deixarão de ter poder de decisão na autenticaçãode utilizadores, cumprindo as polı́ticas definidas externamente. Ou seja, quando os serviçosrecebem um nome de utilizador, podem assumir que todo o processo de autenticação jáfoi efectuado.

4.2 Aplicações com necessidade de Single Sign-On

Existem várias aplicações com necessidade de integração com o sistema de SSO, cadauma com um mecanismo de autenticação e autorização próprio:

• Correio Electrónico (webmail.fc.ul.pt) – Aplicação onde os utilizadores da FCULpodem verificar a sua conta de correio electrónico num browser Web. Todos os uti-lizadores de ambos domı́nios, fc.ul.pt e alunos.fc.ul.pt, têm acesso a esta aplicação.Para autenticação nesta aplicação, os utilizadores do domı́nio alunos.fc.ul.pt, têmde inserir o endereço de correio electrónico completo, enquanto que para contasdo domı́nio fc.ul.pt pode apenas ser inserido o username. Esta aplicação utiliza osistema Microsoft Outlook Web Access do Microsoft Exchange.

• Gestão de Utilizadores / Tomadas (gestao.fc.ul.pt) – Aplicação responsável peloregisto de novos utilizadores e pedidos de activação/desactivação de tomadas porparte dos utilizadores da rede da Faculdade e usado para a gestão de utilizadores etomadas pelos administradores de rede. A aplicação foi escrita totalmente em PHP,a correr em Apache Web Server, e só utilizadores do domı́nio fc.ul.pt têm acesso aesta aplicação. A autenticação é efectuada inserindo o username.

• Gestão de Contas de Alunos (gestao.alunos.fc.ul.pt) – Aplicação onde os alunosda Faculdade podem verificar e gerir a sua conta de utilizador. Inclui também a


informação do sistema de impressões e controlo de acesso da Faculdade. Estaaplicação foi escrita totalmente em PHP, a correr em Apache Web Server, e ape-nas têm acesso alunos com uma conta do domı́nio alunos.fc.ul.pt. A autenticação éefectuada inserindo o username.

• Moodle (moodle.fc.ul.pt) – Plataforma de e-learning, onde professores e alunosacedem para dar um suporte mais interactivo às aulas, ou até mesmo realizar provasde avaliação. O moodle tem suporte de base para alguns sistemas de SSO e estáescrito em PHP, a correr em Apache Web Server. Esta plataforma está acessı́vel,para além de todos os utilizadores dos dominios fc.ul.pt e alunos.fc.ul.pt, tambéma utilizadores com o domı́nio campus.ul.pt. Utilizadores com este domı́nio sãoalunos externos ao directório de utilizadores da FCUL, mas que fazem parte daUniversidade de Lisboa e necessitam do acesso a esta plataforma para algumasdisciplinas do seu curso leccionadas no campus da FCUL. A autenticação é feitaatravés da inserção do endereço de correio electrónico completo.

• Site de downloads do CI (ci.fc.ul.pt/software) – Aplicação onde todos os uti-lizadores da FCUL, fc.ul.pt ou alunos.fc.ul.pt, têm acesso a software disponı́velpara download. Aplicação escrita totalmente em PHP, a correr em Apache WebServer. A autenticação é feita através do endereço de correio electrónico completo.

• Candidaturas FCUL (candidaturas.fc.ul.pt) – Aplicação pública para candidatu-ras a Mestrados de 2oCiclo de Bolonha na FCUL. Esta aplicação apenas necessita deautenticação caso o candidato ao mestrado seja já aluno da FCUL, com uma contado domı́nio alunos.fc.ul.pt. Neste caso, o aluno autentica-se com o seu usernamee alguns dos campos do formulário de candidatura já se encontram preenchidos.Aplicação escrita totalmente em PHP, a correr em Apache Web Server.

4.3 Escolha da solução Single Sign-On a implementar naFCUL

Para a escolha da melhor solução SSO a implementar na FCUL é preciso verificar acompatibilidade das soluções encontradas com os serviços Web com necessidade de SSO.


Software Aplicações em PHP Moodle OWACAS CasOwaShibboleth Módulo para Apache

ou biblioteca PHP adi-cional

Integração de origem

simpleSAMLphp

PubCookie Requer instalação deNãodisponı́vel

CoSign Módulo para Apache um módulo adicionalno Moodle

WebAuth Não disponı́vel

Tabela 4.1: Compatibilidade das diferentes soluções de SSO em relação aos serviços daFCUL

Observando a tabela 4.1 verifica-se que a solução CAS é a única que apresenta a total-idade de requisitos necessários à integração de um sistema de SSO com todos os serviçosda FCUL. A razão mais forte para ser escolhido o CAS em vez dos outros sistemas éa possibilidade de ser utilizado como sistema de autenticação do OWA. É o único sis-tema, de todos os analisados, que oferece uma versão funcional para a integração comeste software proprietário. A integração out-of-the-box do Moodle com um sistema CAS,ou seja, sem qualquer alteração de código ou instalação de módulos adicionais, é tambémum grande ponto a favor.

Apesar de não oferecer um sistema federado de raiz, ou seja, oferecer todas as ca-pacidades de um IdP federado, a possibilidade de ser utilizado como mecanismo deautenticação com outro sistema que o faça, como o simpleSAMLphp ou Shibboleth, pos-sibilita uma possı́vel integração numa federação.

De todos os sistemas analisados foi a solução que apresentou melhor documentaçãotendo em conta a instalação de um servidor de autenticação CAS, a alta disponibilidade,a expansibilidade para novos tipos de autenticação e a integração com diversos servidoresaplicacionais, linguagens de programação e aplicações.

Por fim, foi considerado este sistema a pensar no futuro dos sistemas Web ofereci-dos pelo CI, e na possı́vel integração com serviços do Departamento de Informática, DI,da FCUL. O DI é uma excepção aos outros departamentos da FCUL, onde os alunos,bolseiros, investigadores, docentes e não docentes, para além de terem uma conta no CI,também possuem uma segunda conta para os serviços do seu departamento. Isto significaque existem duas contas electrónicas, em directórios diferentes, para representar a mesmapessoa informaticamente na FCUL. Esta integração seria feita com o fim de unificaros directórios, fc.ul.pt e di.fc.ul.pt (incluindo ambos os subdirectórios alunos.fc.ul.pt ealunos.di.fc.ul.pt). Esta unificação permitiria eliminar a redundância de dados entre asduas contas electrónicas para o mesmo aluno e permitiria as aplicações do DI partici-


parem no protocolo de SSO do CI. Tendo esta possibilidade em mente, o CAS seria amelhor solução de SSO a implementar visto o DI já utilizar este sistema de autenticaçãopara o serviço de Administração de Sistemas Informáticos do DI (admin.di.fc.ul.pt) e oserviço de arquivo de conteúdo académico na plataforma moodle (coruja.di.fc.ul.pt), epossivelmente o vir a adaptar a outras aplicações e serviços.

4.4 Arquitectura da solução escolhida - CAS

Para que seja possı́vel desenhar uma arquitectura para utilização do CAS como sistema deSSO na FCUL, é necessaário compreender todos os componentes envolvidos na autenticaçãode utilizadores. Apesar dos seus aspectos principais já estarem descritos na secção 3.1,pode ser encontrado no Apêndice A toda informação sobre os tokens e URIs do CAS.

4.4.1 Autenticação

Como já foi anteriormente referido, todos os serviços com necessidade de SSO autenticamos utilizadores no mesmo directório. Ao centralizar a autenticação, os serviços da FCULdeixarão de efectuar ligações directamente ao directório para autenticar utilizadores. Ouseja, a autenticação de utilizadores nos serviços da FCUL irá passar a ser feita através dainstalação/configuração de filtros:

• phpCAS - Biblioteca para integrar aplicações escritas em PHP com o protocoloCAS. A integração das aplicações escritas em PHP da FCUL com esta biblioteca éexplicada em pormenor na sub-secção 5.2.1;

• auth cas - Filtro presente no Moodle para uso do CAS como modo de autenticaçãode utilizadores. A activação deste filtro no Moodle da FCUL é explicado em por-menor na sub-secção 5.2.2;

• casOwa - Filtro para alteração do modo de autenticação de utilizadores do Out-look Web Access para CAS. A integração do webmail da FCUL com este filtro éexplicado em pormenor na sub-secção 5.2.3;

Tal como se pode observar na figura 4.2, os serviços passam a comunicar, atravésdestes filtros, directamente com o servidor CAS para autenticar utilizadores. Por outraspalavras, o sistema de autenticação das aplicações, feito pela ligação directa ao directório,é substituı́do pelos filtros CAS. O servidor CAS apenas garante que o utilizador estáautenticado sendo que é da obrigação dos serviços criar o mecanismo de controlo deacesso aos mesmos. Por exemplo, o serviço ”gestao.fc.ul.pt”tem de permitir o acesso autilizadores autenticados apenas do domı́nio fc.ul.pt. Ou seja, utilizadores autenticados,mas do domı́nio alunos.fc.ul.pt, não estão autorizados a aceder a este serviço.


Figura 4.2: Autenticação na FCUL com CAS

No novo sistema de SSO, os utilizadores irão ter duas maneiras de se autenticarem. Aprimeira, e mais comum, irá ser através do seu endereço de correio electrónico e respectivapalavra-chave.

A segunda será através da autenticação através do Cartão de Cidadão (CC). Os cer-tificados de autenticação do CC, como referido na subsecção 2.3.4, contêm informaçõesconfiáveis do seu detentor, incluindo o número do Cartão de Cidadão. Visto que no di-rectório da FCUL existe um atributo para cada utilizador com o seu número do CC, épossı́vel fazer autenticação de utilizadores desta forma:

1) Ao escolher o método de autenticação por CC (na página de login), o uti-lizador envia o seu certificado de autenticação do CC e outros dados aleatórios, atravésdo 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 ocertificado do utilizador é válido;

3) O CAS verifica que o utilizador têm uma chave privada válida ao analisar aassinatura do pacote inicial;

4) Após esta verificação, o gestor de autenticação do CAS extrai o número doBI do certificado e procura um utilizador no directório com este número;

5) Se encontrar um utilizador com este número de BI no directório, autentica outilizador no CAS e envia o email deste utilizador para a aplicação;

Deste modo, é indiferente para as aplicações o modo como o utilizador foi autenticado.Qualquer que seja o método escolhido pelo utilizador, o resultado final do processo deautenticação é igual, sendo enviado o email do utilizador à aplicação.


4.4.2 Autorização

O CAS foi desenhado para ser um produto de Single Sign-On sem suporte explı́cito paraautorização, pensado para sistemas distribuı́dos e ambientes descentralizados. No en-tanto, é possı́vel controlar que serviços estão autorizados a autenticar-se via CAS e, emparticular, o que é que esses serviços podem fazer com o CAS [45].

Esta autorização/gestão de serviços é feita através de uma base de dados, alojada noservidor MySQL da FCUL, mysql.fc.ul.pt. Nesta base de dados, cada serviço, para alémdo nome e descrição, tem associados os seguintes atributos:

• URL - URL do serviço que será comparado com o URL do serviço que está a tentaraceder ao CAS. Podem ser utilizadas expressões regulares neste atributo como, porexemplo, http*://servico.fc.ul.pt/**.

• Tema - Nome do tema utilizado pelo serviço. Estes temas são configurados noservidor, através de ficheiros com a extensão ”.properties”, permitindo mudar oaspecto visual da página de login para cada serviço.

• Single Sign-On – Caso o utilizador já esteja autenticado, este atributo indica se outilizador ao chegar a este serviço tem de inserir as credenciais novamente. Ou seja,se existe uma experiência de SSO associada a este serviço.

• Proxy – Indica se o serviço pode fazer proxy às credenciais do utilizador a outroserviço através de Proxy Tickets.

• Acesso Anónimo – Indica se é necessária autenticação para aceder ao serviço.

• Activo – Indica se a autenticação pelo CAS é permitida, caso contrário, é equiva-lente a um serviço não autorizado a comunicar com o servidor.

Para gestão desta base de dados, o CAS fornece uma aplicação Web, “Services Man-agement”, onde é possı́vel adicionar, remover e modificar serviços. A modificação dosserviços consiste apenas na alteração dos atributos acima mencionados.

4.4.3 Federação

Como já foi referido na secção anterior, o CAS oferece a possibilidade de ser utilizadocomo mecanismo de autenticação de um software de SSO Federado. Pensando numapossı́vel federação de serviços com outras Universidades, foi criado um IdP para a FCULusando o software simpleSAMLphp. Assim, os utilizadores da FCUL poderão conseguiraceder a recursos externos (SPs) que confiem neste IdP. Por exemplo, um aluno da FCULao tentar aceder a recursos federados é redireccionados para o IdP da FCUL. Se este já seencontrar autenticado no CAS, é automaticamente redireccionado para o recurso. Casocontrário, é apresentada a página de login do CAS para que o possa fazer.


4.4.4 Alta Disponbilidade

Como já foi referido, na subsecção 2.1.2, um sistema de SSO tem de ser analisado paranão conter pontos únicos de falha, sendo este um serviço com necessidade de estar alta-mente disponı́vel. Um ponto único de falha é a parte do sistema que, em caso de falha,irá fazer com que o sistema inteiro pare de funcionar. Sendo impossı́vel evitar todas asfalhas, é necessário tolera-las de maneira a atingir computação fiável [1]. Para evitar estasfalhas são usados clusters - um grupo de servidores a fornecer o mesmo serviço. A altadisponibilidade pode ser conseguida através da detecção automática da falha de um nó docluster, e a respectiva reconfiguração apropriada, para que a carga de trabalho seja feitapelos restantes nós. Implementações de clusters de alta disponibilidade tentam através daredundância dos componentes de um cluster, eliminar os pontos únicos de falha.

Para que o servidor a correr o CAS não seja um ponto único de falha é necessário criarum segundo servidor, réplica do primeiro. Este servidor irá assegurar a continuidade doserviço de SSO, caso o outro servidor falhe. A falha do servidor central de autenticaçãosignifica que todas as aplicações associadas ao SSO irão ficar bloqueadas aquando danecessidade de autenticação, e na maioria dos casos, totalmente bloqueadas.

Ao ser criado um segundo servidor CAS, este não tem necessariamente de estar idle,ou seja, sem qualquer tipo de carga. Pode ser feito um balanceamento de carga entre osdois servidores CAS para que ambos respondam a pedidos de SSO. Este balanceamentoé conseguido através uma máquina responsável por dividir os pedidos feitos ao endereçoid.fc.ul.pt pelos dois servidores id1.fc.ul.pt e id2.fc.ul.pt, tal como é apresentado na figura4.3).

Figura 4.3: Arquitectura CAS na FCUL

Este balanceador de carga, contém um processo daemon de monitorização de serviçospara verificar a saúde dos servidores periodicamente. Se não existe resposta para o pedidode acesso ao serviço ou um ICMP echo request vindo do servidor num tempo especifico,


o monitor de serviços irá considerar este servidor morto e remove-o da lista de servidoresdisponı́veis no servidor de balanceamento de carga, e como tal, novos pedidos não serãoenviados para o servidor morto.

Quando o monitor de serviços detecta que o servidor morto está recuperado para tra-balhar, volta a adicioná-lo à lista de servidores disponı́veis. Assim, o servidor de bal-anceamento de carga pode automaticamente mascarar a falha de serviços ou servidores.Ainda mais, os administradores podem adicionar novos servidores para aumentar o de-sempenho do sistema ou para remover servidores para manutenção de serviço, sem que oserviço para de correr.

Agora, o servidor de balanceamento de carga pode se tornar um ponto único de falhapara todo o sistema. De maneira a prevenir que todo o sistema fique sem funcionar porcausa do servidor de balanceamento de carga, é necessário criar um, ou mais, servidoresde reserva, backup. Dois daemons do heartbeat correm no servidor primário e no dereserva que enviam entre si uma mensagem do tipo ”estou vivo”, através de interfacesde rede periodicamente. Quando um dos daemons do heartbeat do servidor de reservanão consegue “ouvir” a mensagem do heartbeat do servidor primário dentro dum tempoespecifico, este irá tomar conta do IP virtual deste, de maneira a providenciar o serviço debalanceamento de carga.

Quando o servidor de balanceamento fica activo de novo, existem duas soluções, umaé este ficar o servidor de reserva automaticamente, a outra é que o servidor de balancea-mento de carga activo disponibiliza o seu IP virtual ao servidor que agora recuperou epassa a ser o servidor primário.

Ao ser utilizado um balanceador de carga é preciso ter em atenção que o CAS é umaaplicação dependente do estado. Ou seja, é necessário que todas as instâncias do CASconheçam o que cada instância CAS fez. O CAS para além de manter o estado de cadasessão de utilizador, ainda mantém o estado dos serviços que o utilizador visitou e ostickets usados na visita a esses serviços. Embora os tickets de serviço e de proxy sejamapenas guardados em memória por um curto intervalo de tempo, se estiverem atrás deum servidor de balanceamento de carga e inseridos num cluster, é essencial que todasas instâncias do CAS tenham conhecimento destes tickets. Se não, o CAS simplesmentenão irá funcionar. Apesar da existência sticky sessions do servidor de balanceamento decarga, estas não irão ser suficientes. As sticky sessions servem para enviar o utilizador(via browser Web) de volta à mesma instância do CAS, mas não resolve o problemadas aplicações que também usem CAS e que o servidor de balanceamento de carga játenha decidido que uma aplicação deveria usar outra instância do CAS (através das stickysessions).

Posto isto, existem três passos que necessitam de ser feitos para que o cluster deinstâncias CAS funcione:

• Replicar a informação de login do utilizador - Visto o CAS guardar a informação


de login na sessão da aplicação, é necessário haver replicação de sessão entre asinstâncias do Tomcat a correr o CAS.

• Replicar cache de tickets - A partilha da cache de tickets é feita através de um reg-isto de tickets partilhado, onde todas as alterações de cache são partilhadas pelosnós do cluster. Esta partilha não é feita de um modo persistente, ficando apenas emmemória. Isto irá evitar, no caso de falha de um servidor, que todos os tickets cria-dos neste servidor não sejam perdidos, obrigando os utilizadores a autenticarem-senovamente.

• Visibilidade do Ticket-Granting-Ticket Cookie - É necessário garantir que TGTcookie posto nos browsers Web dos utilizadores é visı́vel para todos os nós docluster.

Finalmente, existem dois componentes essenciais no sistema da FCUL essenciais parao funcionamento do CAS. O directório de utilizadores da FCUL, Active Directory, e abase de dados dos serviços CAS. Estes dois componentes já se encontram em modo dealta disponibilidade sendo que são utilizados por outras aplicações sem ser o CAS. Écrucial que estes se encontrem disponı́veis já que sem estes o CAS não irá funcionarcorrectamente.

Se o directório de utilizadores falha (fc.ul.pt e alunos.fc.ul.pt), todas as autenticaçõesirão falhar (excepto as sessões SSO já iniciadas). Se o servidor de base de dados (mysql.fc.ul.pt)falha, o CAS não irá conseguir aceder à lista de serviços autorizados a realizar SSO. Istosignifica que todos os serviços, autorizados a utilizar o CAS, irão ver os seus pedidosrejeitados (ver secção 4.4.2).

Após identificados todos os pontos únicos de falha e componentes do CAS, ficoudesenhada uma arquitectura final para a implementação de um serviço de SSO tolerantea faltas.

Capı́tulo 5

Implementação e testes

5.1 Implementação Servidor CAS

5.1.1 Instalação

Para a implementação do servidor CAS, foram utilizadas duas máquinas virtuais (id1.fc.ul.pte id2.fc.ul.pt) com o sistema operativo Red Hat Enterprise Linux Server Release 5.4(Tikanga).

Neste sistema operativo foi necessário instalar a ultima versão do Java JDK junta-mente com o servidor de páginas Web, Apache Tomcat 6, sendo o servlet container ondeo CAS vai ser instalado. Como front end para receber pedidos dos utilizadores, foi insta-lado e configurado o Apache Web Server. Este servidor Web está a correr no porto 443,com o protocolo https, SSL, associado a um certificado qualificado com o nome do servi-dor. Deste modo é feita a protecção da integridade e privacidade dos dados do utilizadorentre o browser do utilizador e o servidor. Através do uso do módulo mod jk do ApacheWeb Server, os pedidos feitos ao endereço do CAS são redireccionados directamente parao Tomcat.

5.1.2 Configuração

Depois do servidor Apache Web Server e Tomcat correctamente instalados, poderá dar-seinicio à instalação do CAS. O método escolhido para realizar esta instalação, e também orecomendado pelos seus criadores, foi através da utilização do software Apache Maven.

O Apache Maven, como descrito no site oficial, é ”uma tentativa de aplicar padrões auma infra-estrutura de construção de um projecto de maneira a promover a compreensãoe produtividade ao fornecer um caminho claro na maneira de usar os bons costumes”.É essencialmente um gestor de projectos focado na manutenção de software (builds,documentação, dependências, versões e distribuição). Em relação ao CAS, esta aplicaçãopermite:

• Compilação de ficheiros .java (customização de classes);

37

Capı́tulo 5. Implementação e testes 38

• Adição de dependênciais e extensões;

• Actualizações indicando que ficheiros são persistentes (temas, ficheiros de configuração,customizações, etc..);

• Compilação de todo os ficheiros do CAS num ficheiro .war;

Todos estes atributos são essenciais para uma personalização facilitada do servidor CASe minimização dos custos de upgrade para uma nova versão.

5.1.3 Autenticação

Active Directory (AD)

Date post:	01-Feb-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

UNIVERSIDADE DE LISBOA Faculdade de...

Documents