SSO CAS

L'installation est facilement réalisable à l'aide du packet cas-toolbox téléchargeable ici et documenté ici. L'installation sera réalisé dans entièrement à l'aide d'un utilisateur POSIX cas dédié.

La configuration de cas-toolbox sera conservée dans un repos git (local) situé dans le dossier /home/cas/local.

/home/cas
  |- upstream : les sources logicielles téléchargées
  |- cas-toolbox-XXXXXX : les différentes versions de cas-toolbox présentes sur le serveur
  |- current : lien symbolique vers les sources de la version courante de cas-toolbox
   |- build.properties : fichier de configuration de la compilation
   |- config.properties : fichier de configuration de CAS
   |- custom : dossier de personnalisation de l'installation du CAS
   |- build : dossier de compilation du CAS
  |- local : repos GIT de personnalisation de l'application CAS
   |- static : données web statiques
  |- webapps : lien symbolique pointant sur le répertoire des webapps de Tomcat
    |- cas : Répertoire de déploiement de CAS

Cette application a pour dépendance les paquets Debian suivants :

• tomcat7
• ant
• maven
• openjdk-6-jre
• openjdk-6-jdk
• memcached

• Il est nécessaire de créer le lien symbolique suivant :

  ln -s /var/log/tomcat7/ /usr/share/tomcat7/logs

• Dans le fichier /etc/tomcat7/server.xml :
  • Commenter le <Connector port=“8080” …/>
  • Dé-commenter le <Connector port=“8009” …/>
• Redémarrer Tomcat :

  service tomcat7 restart

• Les modules Apache suivants doivent être activés :

  a2enmod proxy proxy_ajp proxy_http

<VirtualHost *:80>
    ServerAdmin webmaster@exemple.fr
    ServerName connexion.exemple.fr

    RedirectMatch / https://connexion.exemple.fr

    ErrorLog /var/log/apache2/connexion.exemple.fr.error.log
    CustomLog /var/log/apache2/connexion.exemple.fr.access.log combined
</VirtualHost>


<VirtualHost *:443>
    ServerAdmin webmaster@exemple.fr
    ServerName connexion.exemple.fr

    DocumentRoot /var/www/empty

    Alias /static /home/cas/local/static

    <Directory /home/cas/local/static>
        Options -Indexes
    </Directory>

    RedirectMatch ^/$ /cas/

    SSLEngine On

    ProxyRequests Off
    <Proxy *>
        Order Deny,Allow
        Allow From All
    </Proxy>

    ProxyPass /cas ajp://127.0.0.1:8009/cas retry=2

    ErrorLog /var/log/apache2/connexion.exemple.fr.error.log
    CustomLog /var/log/apache2/connexion.exemple.fr.access.log combined
</VirtualHost>

• Créer le fichier /etc/sudoers.d/cas :

  cas	ALL=NOPASSWD:/usr/bin/ant
  cas	ALL=NOPASSWD:/etc/init.d/tomcat7

• Corriger les droits du fichier :

  chmod 440 /etc/sudoers.d/cas

Il n'y a pas de modification à apporter à la configuration standard du service.

Vous pouvez utiliser comme base la configuration présente dans le repos cas-common-config. Votre configuration devra se trouver dans le dossier /home/cas/local.

Adapter le contenu du fichier config.properties et notamment les variables suivantes :

• log.dir : Le chemin du répertoire de log. Dans notre cas, mettre /var/log/tomcat7.
• cas.host : Le FQDN d'accès au serveur CAS
• cas.uri : Le contexte Web de déploiement du serveur CAS. Dans notre cas, mettre /cas.
• security.useradmin : Le login de l'utilisateur qui aura le droit de se connecte à l'interface de gestion des services utilisant l'annuaire LDAP
• Configuration LDAP :
  • ldap.host.1 et ldap.host.2 : les URI de vos serveurs LDAP. Si vous en avez qu'un seul, mettez simplement la même valeur dans les deux variables.
  • ldap.basedn : la base de recherche dans utilisateur dans l'annuaire LDAP
  • ldap.manager.dn : Le DN utilisateur par le serveur CAS pour se connecter à vos annuaires LDAP
  • ldap.manager.password : Le mot de passe associé

[...]
        <bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
                p:cookieSecure="false"
                p:cookieMaxAge="-1"
                p:cookieName="CASTGC"
[...]

• Créer le dossier /home/cas/upstream et y télécharger le package de cas-toolbox
• Décompresser le package dans le répertoire /home/cas/
• Créer le lien symbolique /home/cas/current pointant vers le répertoire de cas-toolbox
• Dans le répertoire /home/cas/current/, créer les liens symboliques suivant :

  cd /home/cas/current
  ln -s ../local/build.properties
  ln -s ../local/config.properties
  rmdir custom && ln -s ln -s ../local/custom

• Exécuter la tâche ant init :

  ant init

• Déployer l'installation du CAS :

  sudo ant deploy

• Redémarrer Tomcat7 :

  sudo /etc/init.d/tomcat7 restart

Un re-déploiment permet de prendre en compte les modifications faites sur la configuration du serveur Git.

Pour cela, il faut :

• Re-compiler CAS et le re-déployer :

  cd /home/cas/current
  ant
  sudo ant deploy

• Redémarrer Tomcat :

  sudo /etc/init.d/tomcat7 restart

CAS contrôles les services qui sont autorisés à utiliser son service de SSO. La liste des services autorisés au configurés dans le fichier custom/webpages/WEB-INF/deployerConfigContext.xml. Par défaut, le service autorise les services suivants :

http://**
https://**
imap://**
imaps://**

Il est possible d'ajouter des nouveaux services autorisés lorsque le service est démarré en utilisant l'interface https://login.example.fr/cas/services/manage.html. Il faudra pour cela se connecté avec un utilisateur reconnu comme ADMIN du service (cf. paramètre security.useradmin).

Pour bien comprendre le problème, mieux vaut l'expliquer complètement :

• lorsqu'un utilisateur s'authentifie auprès de serveur CAS, le serveur défini un cookie de session (stocké dans le navigateur du client) qui permet de faire en sorte qu'il soit reconnu à son prochain passage
• lorsqu'une application authentifie un utilisateur via le serveur CAS, elle initie également une session pour l'utilisateur et défini son propre cookie pour cette session
• lorsque l'authentification SSO est gérée par Apache, le module SSO d'Apache gère également sa propre session (et son propre cookie) en plus de celle géré par l'application.

Dans le cas d'un accès à une application (authentifié par Apache) via une application de type portail (gérant sa propre connexion SSO), l'utilisateur dispose donc normalement d'au moins quatre sessions :

• une au niveau du serveur CAS
• une au niveau de l'application portail
• une au niveau de l'Apache donnant accès à l'application tierce
• une au niveau de l'application tierce

Pour déconnecter l'utilisateur proprement, il faut :

• soit que l'utilisateur ferme son navigateur : tous les cookies de session seront alors invalidés/supprimés par le navigateur
• soit que chaque application clos sa propre session ce qui revient le plus souvent au final à supprimer son cookie de session

Dans le cas d'une authentification géré par Apache via le module mod_auth_cas, la déconnexion n'est pas gérée correctement. En outre, il est possible pour l'application authentifiée par Apache gère la suppression du cookie du module mod_auth_cas d'Apache en plus du sein au moment de la déconnexion.

Un autre critère est à prendre en compte par ailleurs : lors de la déconnexion d'un utilisateur au niveau d'une application, celle-ci clos sa session avant de rediriger l'utilisateur vers la déconnexion du niveau du portail SSO. Cependant, si l'utilisateur était connecté auprès d'une autre application, la déconnexion auprès de celle-ci n'est pas gérée si l'application ne supporte pas le mécanisme de Single-Sign-Out (ce qui est le cas de la plupart des applications utilisant le protocole CAS). Pour ce problème, il existe cependant une solution :

• les boutons de déconnexion des applications doivent renvoyer l'utilisateur vers une page web intermédiaire avant la déconnexion SSO.
• sur cette page intermédiaire, on fait appel à l'ensemble des pages de déconnexions des applications utilisant le SSO (via des balises iframes ou des pseudos balises images) avant de rediriger l'utilisateur vers la déconnexion au niveau du portail SSO en lui-même.