Synthèse sur la modélisation de la coupure et la modélisation électroma-

Para a implementac¸˜ao do servidor CAS, foram utilizadas duas m´aquinas virtuais (id1.fc.ul.pt e id2.fc.ul.pt) com o sistema operativo Red Hat Enterprise Linux Server Release 5.4 (Tikanga).

Neste sistema operativo foi necess´ario instalar a ultima vers˜ao do Java JDK junta- mente com o servidor de p´aginas Web, Apache Tomcat 6, sendo o servlet container onde o CAS vai ser instalado. Como front end para receber pedidos dos utilizadores, foi insta- lado e configurado o Apache Web Server. Este servidor Web est´a 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¸˜ao da integridade e privacidade dos dados do utilizador entre o browser do utilizador e o servidor. Atrav´es do uso do m´odulo mod jk do Apache Web Server, os pedidos feitos ao enderec¸o do CAS s˜ao redireccionados directamente para o Tomcat.

5.1.2

Configurac¸˜ao

Depois do servidor Apache Web Server e Tomcat correctamente instalados, poder´a dar-se inicio `a instalac¸˜ao do CAS. O m´etodo escolhido para realizar esta instalac¸˜ao, e tamb´em o recomendado pelos seus criadores, foi atrav´es da utilizac¸˜ao do software Apache Maven.

O Apache Maven, como descrito no site oficial, ´e ”uma tentativa de aplicar padr˜oes a uma infra-estrutura de construc¸˜ao de um projecto de maneira a promover a compreens˜ao e produtividade ao fornecer um caminho claro na maneira de usar os bons costumes”.

´

E essencialmente um gestor de projectos focado na manutenc¸˜ao de software (builds, documentac¸˜ao, dependˆencias, vers˜oes e distribuic¸˜ao). Em relac¸˜ao ao CAS, esta aplicac¸˜ao permite:

• Compilac¸˜ao de ficheiros .java (customizac¸˜ao de classes);

• Adic¸˜ao de dependˆenciais e extens˜oes;

• Actualizac¸˜oes indicando que ficheiros s˜ao persistentes (temas, ficheiros de configurac¸˜ao, customizac¸˜oes, etc..);

• Compilac¸˜ao de todo os ficheiros do CAS num ficheiro .war;

Todos estes atributos s˜ao essenciais para uma personalizac¸˜ao facilitada do servidor CAS e minimizac¸˜ao dos custos de upgrade para uma nova vers˜ao.

5.1.3

Autenticac¸˜ao

Active Directory (AD) - Este tipo de autenticac¸˜ao ´e implementada atrav´es da modificac¸˜ao do ficheiro ”deployersConfigContext.xml”. ´E neste ficheiro que ´e feita toda gest˜ao da autenticac¸˜ao e respectiva ligac¸˜ao `a base de dados de credenciais.

Esta configurac¸˜ao ´e feita atrav´es do uso da inserc¸˜ao dois blocos de xml, beans, neste ficheiro. Estes beans s˜ao utilizados para a criac¸˜ao de objectos Java do servidor CAS .

O primeiro bean, da classe ”org.springframework.ldap.core.support.LdapContextSource”, ´e utilizado para fornecer as informac¸˜oes da ligac¸˜ao ao direct´orio da FCUL. Estas informac¸˜oes incluem o enderec¸o LDAP da ligac¸˜ao `a AD e respectivo utilizador/palavra-chave com as devidas permiss˜oes de acesso.

O segundo bean, da classe ”org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler”, serve para indicar como ´e feita a autenticac¸˜ao no dom´ınio definido no primeiro bean. Isto permite definir que atributo do direct´orio ser´a o nome de utilizador. No caso do sistema de SSO da FCUL passar´a a ser utilizado o enderec¸o de correio electr´onico como nome de utilizador (atributo ”mail”), mas poderia ser utilizado qualquer atributo do direct´orio, como o n´umero de telefone ou n´umero do BI, desde que este identifique a conta. Neste bean ´e tamb´em definido qual ser´a a base de procura no direct´orio para utilizadores no dom´ınio.

Este segundo bean ser´a inserido no bean ”authenticationManager”, dentro da pro- priedade ”credentialsToPrincipalResolvers”, de maneira a indicar ao servidor CAS esta maneira de autenticar utilizadores [11].

Cart˜ao de Cidad˜ao (CC) - O outro tipo de autenticac¸˜ao ser´a atrav´es do Cart˜ao de Cidad˜ao (ver secc¸˜ao 2.3.4). Este smart card cont´em um certificado de autenticac¸˜ao com dados confi´aveis sobre o cidad˜ao. Entre estes dados, no atributo ”SERIALNUMBER”, est´a presente o n´umero ´unico do CC, antigo n´umero do Bilhete de Identidade (como se pode observar na figura 5.1). Este n´umero est´a tamb´em presente no atributo ”employ- eeId”de cada utilizador no direct´orio da FCUL mas n˜ao cont´em os primeiros dois carac- teres, ”BI”, nem o ´ultimo car´acter, o n´umero suplementar do BI. Comparando o atributo

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

”SERIALNUMBER”, sem estes caracteres, do CC com o atributo ”employeeId”do di- rect´orio, ´e poss´ıvel associar um CC a uma conta do direct´orio, identificando um utilizador inequivocamente.

Figura 5.1: Certificado de Autenticac¸˜ao do Cart˜ao de Cidad˜ao

A autenticac¸˜ao por CC ´e feita atrav´es do modelo de autenticac¸˜ao por certificados X.509. Para implementar este modelo ´e necess´ario que o servidor CAS confie no certifi- cado de autenticac¸˜ao presente no CC para poder identificar o utilizador. Esta confianc¸a ´e conseguida atrav´es da instalac¸˜ao, no servidor, do certificado da entidade emissora destes certificados de utilizador. Como se pode observar na figura 5.2, o caminho de certificac¸˜ao tem como root o CA ”GTE CyberTrust Global Root”, sendo a instalac¸˜ao do certificado deste CA o suficiente.

Para o CAS suportar autenticac¸˜ao com certificados X.509 ´e preciso primeiro adicionar a depˆendencia ”cas-server-support-x509”ao ficheiro de configurac¸˜ao de build do Maven. Esta depˆendencia ir´a adicionar as bibliotecas java com as classes necess´arios para o su- porte desta autenticac¸˜ao.

O CAS utiliza como base de dados de certificados confi´aveis uma keystore Java. Nesta keystore, ´e poss´ıvel adicionar certificados dos CA’s que o CAS deve confiar. Para a autenticac¸˜ao atrav´es do CC, ´e apenas necess´ario adicionar o certificado do CA ”GTE Cyber Trust Global Root”`a keystore.

´

E agora necess´ario um conector HTTPS no Tomcat, num novo porto (p.e. 8443), in- dicando ao browser que deve apresentar certificados de um utilizador (se houver algum dispon´ıvel). Isto ´e feito atrav´es do parˆametro ”clientAuth=want”no conector HTTPS. Ap´os o utilizador apresentar o seu certificado, este ´e enviado para o gestor de autenticac¸˜ao do CAS. Este gestor, definido no ficheiro ”deployersConfigContext.xml”, ir´a fazer ligac¸˜ao entre o certificado de autenticac¸˜ao do utilizador do CC e a conta deste utilizador no di- rect´orio da FCUL. Esta ligac¸˜ao est´a feita da seguinte forma:

• O CAS comec¸a por verificar se o certificado ´e v´alido, comparando-o com um padr˜ao previamente definido. Este padr˜ao tem o valor ”CN=GTE CyberTrust Global Root”, filtrando assim certificados inv´alidos.

• Estando o certificado v´alido, ´e retirada a informac¸˜ao presente no atributo ”SERI- ALNUMBER”;

• Este atributo ´e passado a uma classe java auxiliar que retira os dois primeiros car- acteres e o o ´ultimo caracter. Por exemplo, se atributo ”SERIALNUMBER”tem o valor ”BI129650986”, este dever´a ficar ”12965098”. Esta modificac¸˜ao permite a comparac¸˜ao do o n´umero do BI guardado no direct´orio com este atributo do certifi- cado;

• Se for encontrado um utilizador com este n´umero de BI no direct´orio, ´e extraido o atributo ”mail”desta conta. Este atributo passar´a agora a ser o nome de utilizador na sess˜ao de SSO;

Finalmente, ´e feita a alterac¸˜ao do Web flow. O Web flow consiste num sequˆencia de operac¸˜oes, onde os resultados variam de verdadeiro, falso, sucesso ou erro. Cada resultado destes faz com que o flow mude para outra operac¸˜ao. Por exemplo, a operac¸˜ao que mostra a p´agina de login ´e o ”viewLoginForm”. Esta operac¸˜ao ´e realizada ap´os a verificac¸˜ao dos testes preliminares (se o utilizador tem o login cookie, etc.), ou chamada novamente se o utilizador inseriu o username e/ou palavra-chave incorrectamente.

A configurac¸˜ao de um novo flow permite adicionar a verificac¸˜ao de certificados X.509 `a sequˆencia destes testes preliminares desta operac¸˜ao. Isto signfica que se for enviado um

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

certificado para o CAS, este ir´a verificar a validade para autenticar um utilizador antes de apresentar a p´agina de login.

Esta alterac¸˜ao ´e feita no ficheiro ”login-webflow.xml”, adicionando uma nova operac¸˜ao com o nome ”x509check”. Esta operac¸˜ao ´e inserida neste ficheiro, alterando a operac¸˜ao inicial de ”viewLoginForm”para ”x509check”. Esta modificac¸˜ao indica ao CAS que tem de verificar se o cliente apresentou um certificado X509 para se autenticar. Se este for v´alido, de acordo com os aspectos referidos anteriormente, ´e emitido um TGT e o uti- lizador ´e reenviado para o servic¸o pretendido (se houver algum especificado no URL). Caso contr´ario, ir´a para a operac¸˜ao ”viewLoginForm”[46].

5.1.4

Autorizac¸˜ao

Para a implementac¸˜ao da autorizac¸˜ao da utilizac¸˜ao do CAS, como referido na secc¸˜ao 4.4.2, ´e utilizada uma base de dados que mant´em a informac¸˜ao sobre os servic¸os. Esta gest˜ao de servic¸os ´e feita adicionado as depˆendicas de MySQL ao Maven e configurac¸˜ao no ficheiro no ”deployerConfigContext.xml”indicando as propriedades da ligac¸˜ao `a base de dados [34] [33].

5.1.5

Federac¸˜ao

Para a implementac¸˜ao do IdP da FCUL, foi utilizado o software simpleSAMLphp in- stalado em ambos os servidores id1 e id2. Estes servidores apenas necessitaram da instalac¸˜ao e configurac¸˜ao do m´odulo de PHP para Apache Web Server com as extens˜oes zlib, openssl, curl e ldap. Depois de instalado, foi activado e configurado o m´odulo de autenticac¸˜ao CAS e a ligac¸˜ao ao direct´orio da FCUL, para que o simpleSAMLphp possa enviar atributos aos recursos federados [43]. Apesar da f´acil configurac¸˜ao, foi necess´ario modificar uma parte do c´odigo da ligac¸˜ao LDAP do simpleSAMLphp para que funcionasse com Microsoft Active Directory.

5.1.6

Alta Disponibilidade

Como j´a foi referido, na subsecc¸˜ao 4.4.4, existem trˆes pontos cruciais para que a replicac¸˜ao do CAS seja feita [22]. Esta secc¸˜ao ir´a descrever os passos necess´arios para a sua implementac¸˜ao.

• Replicar a informac¸˜ao de login do utilizador

Visto que o CAS guarda a informac¸˜ao de login na sess˜ao de aplicac¸˜ao, ´e necess´ario haver replicac¸˜ao de sess˜ao entre as instˆancias do Tomcat a correr o CAS. Esta replicac¸˜ao ´e feita em mem´oria, atrav´es da classe dispon´ıvel com a distribuic¸˜ao Tom- cat 6, SimpleTcpCluster.

O Tomcat atrav´es desta classe, faz uma replicac¸˜ao de sess˜ao, all-to-all usando o gestor DeltaManager. Replicac¸˜ao all-to-all, tal como nome indica, toda a informac¸˜ao ´e replicada para todos os membros do cluster. Este algoritmo ´e eficiente para clus- tersde pequena dimens˜ao, como ´e o caso.

Para um novo membro fazer parte do cluster apenas s˜ao usados pings multicast. Cada instˆancia do Tomcat vai periodicamente enviar um ping multicast, e nessa mensagem a instˆancia vai fazer broadcast do seu IP e o porto TCP em escuta para replicac¸˜ao.

Depois de receber esse ping multicast, o membro ´e adicionado ao cluster. No pr´oximo pedido de replicac¸˜ao, a instˆancia que enviou o pedido vai utilizar a informac¸˜ao do IP e porto para estabelecer uma socket TCP para enviar a dados serializados. O uso desta socket TCP garante um controlo de flow e entrega garantida, ao contr´ario do protocolo UDP que n˜ao garante que os dados s˜ao entregues.

Se uma instˆancia de um n˜ao recebeu um ping, de um dado membro, dentro de um determinado intervalo de tempo, esse membro ´e considerado morto.

• Replicar cache de tickets

Para configurar a replicac¸˜ao da cache de tickets ´e usada uma classe j´a implementada pelos criadores do CAS, JBossCacheTicketRegistry, que permite utilizar o sistema JBoss Cache.

JBoss Cache ´e uma sistema de cache transaccional estruturado em ´arvore. ´E a base para muitos servic¸os de cluster no JBoss Application Service, inclu´ıdos em certas vers˜oes, sess˜oes JNDI, http e EJB.

O JBoss Cache pode tamb´em ser usado como biblioteca de caching clustered e transaccional ou at´e um armazenamento de dados orientado a objectos. Pode tamb´em ser embebido em outras frameworks Java Enterprise ou servidores aplicacionais como ´e o caso do Tomcat, Spring, Hibernate, BEA WebLogic ou IBM Websphere, entre outros. Geralmente ´e utilizado directamente em aplicac¸˜oes Java (standalone) que n˜ao correm atrav´es do servidor aplicacional, de maneira a manter o estado do cluster.

A cache ´e organizada como uma ´arvore, com apenas um “root”. Cada n´o nesta ´arvore essencialmente cont´em um mapa, que age com armazenamento para pares chave/valor. O ´unico requisito dos objectos que s˜ao inseridos na cache, ´e imple- mentarem a classe java.io.Serializable.

A cache JBoss pode ser local ou replicada. As ´arvores locais apenas existem den- tro da JVM onde foram criadas, j´a que as ´arvores replicadas propagam quaisquer mudanc¸as a algumas ou todas as ´arvores no mesmo cluster. Um cluster pode propa-

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

gar para diferentes m´aquinas numa rede ou s´o diferentes JVM’s numa m´aquina apenas.

Para que esta integrac¸˜ao seja feita no servidores CAS ´e necess´ario editar o ficheiro ticketRegistry.xml alterando a responsabilidade de registo de tickets da classe De- faultTicketRegistry para JBossCacheTicketRegistry. Para a configurac¸˜ao desta replicac¸˜ao ´e definido em ambos os servidores um IP e um porto para a comunicac¸˜ao multicast e um porto para comunicac¸˜ao TCP entre os n´os do cluster.

• Garantir a Visibilidade do Ticket-Granting-Ticket Cookie

O ´ultimo passo para fazer cluster ao CAS correctamente ´e garantir que o TGT cookie posto nos browsers dos utilizadores ´e vis´ıvel para todos os n´os do cluster. Para este efeito ´e necess´ario editar os ficheiros ticketGrantingCookieGenerator.xml e warnCookieGenerator.xml indicando que o cookie est´a vis´ıvel para entre os servi- dores no cluster do CAS.