A framework de autenticação Central Authentication Service

A framework de autenticação Central Authentication Service (CAS) foi criada pela universidade de Yale, ganhando visibilidade como um projeto do consórcio JASIG (JASIG, 2014a) em 2004. O principal objetivo da framework e do sistema que a implementa é o de centralizar, o processo de autenticação de utilizadores, numa única aplicação web, facilitando:

 A gestão de palavras-passe por parte dos utilizadores, que passam a ter um conjunto único de credenciais;

 A gestão da lógica de autenticação por parte da administração de sistemas, que passa a ter um ponto único de gestão.

O sistema implementa o conceito de Single Sign-On (SSO), facilitando os procedimentos de autenticação de utilizadores e permitindo que, nos sistemas aderentes, os utilizadores sejam autenticados sem que o sistema tenha conhecimento das suas credenciais de autenticação, o que é uma mais-valia em cenários de sistemas sob tutelas distintas (De Clercq, 2002).

Figura 6 - Fluxo de execução do protocolo CAS

A implementação CAS da JASIG tem uma base imensa de utilizadores nos setores da educação e investigação em todo o mundo (Aubry, Mathieu, & Marchal, 2004; Shen & Zhu,

Capítulo 3 – Sistemas de Informação em IES

61

2007). Um exemplo é o consórcio Francês ESUP (ESUP-Portail, 2014), fornecedor de soluções de gestão de conteúdos e serviços online, e que utiliza CAS como forma autenticação nos seus produtos. Em França, e através deste consórcio, há cerca de 800 mil utilizadores que são autenticados em sistemas CAS (ESUP-Portail, 2013).

Na Figura 6, descreve-se o fluxo de execução do protocolo CAS, pressupondo um ambiente web e uma autenticação bem-sucedida com cookies e SSO (Aubry et al., 2004) (Mazurek, Bramhall, Gilbert, Newman, & Petro, 2005).

A aplicação web

A aplicação web é uma aplicação instalada num servidor web com HTTP a que o utilizador acede através de um browser. Tem um endereço web comum (e.g.: http://endereco.com/app). O Servidor CAS

O servidor CAS é uma aplicação web, que implementa o protocolo CAS e tem um endereço web (e.g. https://secure.its.yale.edu/cas/servlet/login) que atua como solicitador de credenciais (credential requester), apresentando uma página de autenticação para inserção de credenciais, ou aceitador de credenciais (credential acceptor), validando as credenciais apresentadas.

O servidor de autenticação

O Servidor de autenticação implementa um mecanismo específico de autenticação (e.g. Kerberos, LDAP, Active Directory, etc.), sendo utilizado pelo servidor CAS para validar as credenciais que lhe são submetidas. O Servidor CAS pode dispor de vários servidores de autenticação específicos, suportando assim vários mecanismos de autenticação.

Fluxo de execução do protocolo

1. O utilizador acede a uma aplicação web, que reencaminha o browser para o servidor CAS; a aplicação passa como parâmetro um identificador de serviço (normalmente um URL da aplicação) para onde o servidor de autenticação a seguir reencaminhará o browser.

Exemplo:

https://secure.its.yale.edu/cas/login?service=http://www.yale.e du/tp/auth.jsp

Em que https://secure.its.yale.edu/cas/login é o URL solicitador de credenciais do servidor CAS; e o parâmetrohttp://www.yale.edu/tp/auth.jsp é o identificador de serviço.

2. No servidor de CAS:

2.1. O utilizador insere as credenciais

2.2. O servidor CAS (URL de autenticação) valida as credenciais junto de um servidor de autenticação local, normalmente, através de um plugin para um ou vários protocolos de validação.

Após autenticação bem-sucedida, o servidor CAS cria um ticket (número longo aleatório), que regista internamente, associando com o utilizador e com o serviço (aplicação web) que pediu a sua autenticação.

O servidor CAS cria um cookie em memória (ticket-granting cookie) que identifica o utilizador como tendo autenticação bem-sucedida. Assim, se outro serviço (outra aplicação web) reencaminhar o browser para o Servidor CAS para autenticação deste utilizador, o servidor não necessitará de voltar a pedir as credenciais ao utilizador, criando assim a funcionalidade de SSO. Este cookie é destruído quando se fecha o browser ou através de um URL específico do servidor de autenticação, normalmente, o URL de “Sair” ou “Fechar”

Exemplo:

https://secure.its.yale.edu/cas/servlet/logout.

2.3. O servidor CAS redireciona o browser de volta para o endereço identificador de serviço da aplicação web, adicionando o ticket como parâmetro.

Exemplo:

http://www.yale.edu/tp/authenticate.jsp?ticket=ticket-string- com-numero-longo

Em que http://www.yale.edu/tp/authenticate.jsp é o URL de retorno da aplicação web; e ticket-string-com-numero-longo é o ticket enviado como parâmetro.

3. Na aplicação web, o browser é novamente reencaminhado para o servidor CAS, com o ticket como parâmetro a fim de o validar e obter o nome-de-utilizador.

4. O servidor CAS compara o ticket recebido com o registo que guarda com informação do ticket, do utilizador e da aplicação web, respondendo com duas linhas de texto, contendo, “yes” (se o ticket for válido) e o nome do utilizador associado ao ticket.

Capítulo 3 – Sistemas de Informação em IES

63 Exemplo:

yes peon

Em que “yes” significa que o ticket é válido e “peon” é o nome do utilizador validado. Sendo o ticket válido, o servidor CAS remove imediatamente este ticket, e a informação associada, do seu registo interno.

No fim deste fluxo de execução, executada através de um browser com suporte para cookies, e em que a autenticação foi bem-sucedida, o utilizador foi autenticado sem que a aplicação tivesse conhecimento da sua palavra-passe. Foi também criado um cookie (token-granting cookie) que, se na sessão deste browser houver uma tentativa de autenticação a partir de outra aplicação web participante no sistema, então o servidor CAS reconhecerá o cookie e concederá a autorização, sem que sejam pedidas, novamente, as credenciais ao utilizador. O protocolo CAS e a respetiva implementação são frequentemente objeto de atualizações e extensões no sentido de os adaptar a diferentes cenários de implementação, de onde se destaca o trabalho de Naito para a inclusão de mecanismos de gestão de autorização para controle de acesso a informação em níveis distintos das camadas aplicacionais (Naito, Kajita, Hirano, & Mase, 2007).

Atualmente o sistema CAS é reconhecido como sendo um sistema aberto e bem documentado; baseado em componentes de servidor Java; com uma extensa livraria de clientes (e.g., Java, .Net, PHP, Perl, Apache, uPortal, etc); com uma extensa comunidade de utilizadores; e com módulos de integração para muitos dos sistemas de software que se utilizam em instituições de ensino e investigação (e.g., uPortal, Sakai, Moodle, TikiWiki, Mule, Liferay, etc.).

A framework CAS segue um modelo simples de SSO, com uma implementação também simples, flexível e fácil de incorporar num conjunto de aplicações web. Os principais aspetos podem-se resumir em:

 Não possui uma base de dados central para autenticação, podendo usar qualquer base de dados externa;

 Pode ser utilizado por aplicações que dependam da autenticação de utilizadores em web services, preservando a confidencialidade da informação do utilizador;

 A conversão de uma aplicação web para CAS é feita introduzindo um módulo cliente na aplicação web, sendo um processo simples;

 Tem uma base de utilizadores grande nos setores da educação e da investigação.