Teste de sobrecarga

Para testar como o CAS se comportaria com uma sobrecarga de pedidos foi utilizado o programa JMeter. Este programa, escrito em java, foi desenhado para testar o compor- tamento funcional das aplicac¸˜oes e respectivas medidas de performance. Para este teste, foram criados dez utilizadores no direct´orio da FCUL com a intenc¸˜ao de sobrecarregar o CAS com pedido. Este teste foi realizado com um script para JMeter criado com este prop´osito [13]. Para cada utilizador, o teste ´e realizado da seguinte maneira:

1) ´E chamada a p´agina de login para que seja poss´ıvel extrair o LT;

2) ´E feito um POST `a p´agina de login com o nome de utilizador, palavra-chave e o LT;

3) ´E verificado se a resposta ao pedido de login cont´em um TGC;

4) ´E feito um pedido a uma p´agina protegida, https://cas-protected.fc.ul.pt, para verificar se autenticac¸˜ao foi realizada com sucesso.

5) ´E feito um pedido ao URI /login com o parˆametro service com o URL do servic¸o vinte vezes consecutivas. Ap´os cada pedido a este URI ´e verificado se o servic¸o cont´em no header o ”Location: https://cas-protected.fc.ul.pt/..?ticket=ST-”;

6) S˜ao limpos os cookies e volta a repetir o passo 1;

Esta sequˆencia ´e realizada cinco vezes seguidas para cada utilizador, o que significa que s˜ao emitidos no total mil STs. Com este teste foi poss´ıvel verificar como o CAS se comportaria para uma carga de utilizac¸˜ao (excessivamente) alta.

Ap´os a realizac¸˜ao sucessiva destes testes, obteve-se respostas para pedidos de autenticac¸˜ao (passos 1 e 2) com latˆencia m´edia de 64.82ms. As respostas para pedidos de emiss˜ao de

STs tiveram uma latˆencia m´edia de 51.16ms. Estes resultados s˜ao bastante positivos visto que, apesar de haver picos de latˆencia elevada, nenhum pedido foi descartado ou resultou em erro. Por exemplo, na figura 5.5 ´e apresentado a latˆencia de respostas dos servidores CAS a pedidos de autenticac¸˜ao num dos testes realizados, onde os valores variam entre 28ms e os 257ms. Na figura 5.6, ´e apresentada a latˆencia das respostas dos servidores CAS a pedidos de STs num dos testes realizados, onde os valores variam entre os 29ms e os 356ms.

Cap´ıtulo 5. Implementac¸˜ao e testes 51

Cap´ıtulo 6

Conclus˜ao e trabalho futuro

Este trabalho, enquadrado num projecto de final de curso, contribuiu para o desenvolvi- mento de um novo sistema de autenticac¸˜ao para os utilizadores da rede da Faculdade de Ciˆencias da Universidade de Lisboa. Ap´os a conclus˜ao deste projecto de 9 meses, ´e poss´ıvel afirmar que foram conclu´ıdas com sucesso todas as tarefas planeadas para o desenvolvimento do sistema previsto. Estas tarefas incluiram :

• An´alise do estado da arte relativo ao SSO em aplicac¸˜oes web e de algumas aplicac¸˜oes open-source para este prop´osito;

• Desenho de uma nova arquitectura de autenticac¸˜ao para a FCUL, tolerante a faltas e altamente expans´ıvel;

• Implementac¸˜ao de todo o sistema de autenticac¸˜ao, incluindo a sua integrac¸˜ao com as aplicac¸˜oes web do CI, uma p´agina de gest˜ao de todo o sistema e ainda uma aplicac¸˜ao para federac¸˜ao da identidade dos utilizadores da FCUL;

• Implementac¸˜ao de um sistema de autenticac¸˜ao com certificados X.509, atrav´es do Cart˜ao de Cidad˜ao Portuguˆes;

• Testes funcionais e de sobrecarga a todo o sistema de SSO;

Dos testes realizados obtiveram-se resultados extremamente positivos, sendo que ´e poss´ıvel afirmar que o sistema desenvolvido ficou preparado para eventuais sobrecargas de pedidos por parte de servic¸os e utilizadores, n˜ao afectando o seu funcionamento.

Todas as tarefas planeadas foram conclu´ıdas dentro do tempo previsto e o sistema entrou em produc¸˜ao no dia 1 de Junho de 2010, integrado j´a com os servic¸os de Gest˜ao de Utilizadores [26], Moodle [28] e Site de Downloads do CI [21].

A formac¸˜ao adquirida previamente serviu de ponto de partida para o desenvolvimento de todas funcionalidades previstas para o sistema e ainda algumas que n˜ao estavam pre- viamente planeadas como a autenticac¸˜ao com Cart˜ao de Cidad˜ao e a aplicac¸˜ao web de Gest˜ao de SSO.

As maiores dificuldades encontradas surgiram durante a integrac¸˜ao do Outlook Web Access com o CAS atrav´es do casOwa, visto n˜ao haver documentac¸˜ao dispon´ıvel para o tipo de servidor aplicacional usado pelo CI a fornecer este servic¸o (IIS6). Depois de en- contrada a soluc¸˜ao, foi realizada pelo autor deste projecto uma contribuic¸˜ao no ”wiki”do CAS com os passos necess´arios para a sua instalac¸˜ao [47].

6.1

Trabalho Futuro

Apesar de terem sido conclu´ıdos todos os objectivos com este projecto, s˜ao sugeridos, como trabalho futuro, os seguintes t´opicos:

• Tipo de Autenticac¸˜ao Obrigat´orio - Ao ser introduzido o Cart˜ao de Cidad˜ao como modo de autenticar utilizadores, pode ser pensada uma forma de proteger obri- gat´oriamente certos servic¸os com este tipo de autenticac¸˜ao de modo ao aumentar a seguranc¸a.

• STORK - O objectivo do projecto STORK ´e estabelecer um plataforma de autenticac¸˜ao electr´onica a n´ıvel europeu que permite aos cidad˜aos estabelecer relac¸˜oes electr´onicas ao apresentar o seu Cart˜ao de Cidad˜ao [42]. Basicamente, permitir aos alunos es- trangeiros na FCUL utilizarem o Cart˜ao de Cidad˜ao do seu pa´ıs para se autenti- carem no servic¸o de SSO da FCUL;

• An´alise Estat´ıstica - Ao centralizar a autenticac¸˜ao, ´e f´acil realizar uma an´alise es- tat´ıstica de acesso a servic¸os e autenticac¸˜oes no direct´orio. Esta an´alise estat´ıstica permitir´a tirar interessantes conclus˜oes sobre a carga e hor´ario de utilizac¸˜ao dos servic¸os do CI.

Apˆendice A

Protocolo CAS

A.1

Tickets

Como j´a foi referido na secc¸˜ao 3.1 deste documento, o CAS ´e um sistema de Single Sign-On que, tal como o Kerberos, funciona `a base de tickets:

• Login Ticket (LT) - A p´agina de login do CAS ao ser carregada ir´a gerar um login ticket, uma cadeia de caracteres aleat´orios, embutido no c´odigo HTML da p´agina, criado unicamente para impedir ataques replay. Um ataque de replay ´e uma forma de ataque a sistemas web, em que o atacante utiliza m´etodos de repetic¸˜ao ou de atraso para enviar dados maliciosos ou fraudulentos.

• Ticket-Granting Cookie (TGC) - Ap´os o utilizador submeter as suas credenciais correctamente ´e enviado para o browser deste utilizador um Ticket-Granting Ticket, TGT, encapsulado num cookie, Ticket-Granting Cookie, TGC. Este ticket estab- elece a identidade de um utilizador com o CAS e permite ao CAS agir com um sistema de SSO na Web.

• Service Ticket (ST) - Ticket enviado pelo CAS, atrav´es do browser web do uti- lizador, para um servic¸o. Cada ST apenas pode ser utilizado uma vez, e tem de ser combinado com o identificador ´unico e espec´ıfico para cada servic¸o, normal- mente o URL deste, de maneira a ser ´util. De outra maneira, um servic¸o que sabe o seu identificador ´unico vai recusar aceitar STs pretendidos para outro servic¸o. Isto previne um servic¸o de montar um ataque “man-in-the-middle” contra outro servic¸o. • Proxy-Granting ticket (PGT) - Ticket enviado pelo CAS a um servic¸o que tem um ST v´alido. Este ticket, associado a um servic¸o e um utilizador espec´ıficos, confere a habilidade de produzir proxy tickets.

• Proxy-granting ticket IOU (PGTIOU) - Um ticket enviado pelo apenas pelo CAS numa resposta de validac¸˜ao a um servic¸o com um PGT. ´E da responsabilidade da aplicac¸˜ao Web manter a tabela que correlaciona os PGTIOUs e PGT’s.

• Proxy ticket (PT) - Um ticket utiliz´avel por uma proxy para aceder um servic¸o em nome de um utilizador espec´ıfico. O PT cont´em informac¸˜ao sobre a proxy ou proxies em fila para obter acesso. Para servic¸os que tamb´em s˜ao proxies (segundo- n´ıvel ou maior), um PT tamb´em pode ser usado para obter um PGT, mas este PGT vai perservar a informac¸˜ao sobre a s´erie linear de proxies que est˜ao entre o utilizador e o destino final.