CAS est un système d'authentification initialement créé par l'Université de Yale pour fournir un moyen fiable d'authentifier un utilisateur pour une application. CAS est devenu un projet JASIG en Décembre 2004.

Le projet nous permet également de bénéficier du SSO: l'authentification unique pour les webservices authentifiés par ces soins.

• CAS : Central Authentication Service
• SSO : Single Sign On
• JASIG : Consortium sans but lucratif d'universités et filiales commerciales commanditaires de projets open source pour l'enseignement supérieur.
• Doc officielle: Wiki Jasig

Le CAS est un composant (ensemble de servlets Java) à déployer sur un serveur d'application Java.

Le serveur CAS est en attente de connexions http ou https sur plusieurs url :

• 3 urls nécessaires au fonctionnement de base : login, validation, logout.

En fait, l'url de validation est bien validate pour la compatibilité CAS V1 (servlet LegacyValidate), et serviceValidate en CAS V2.

• 2 urls pour le fonctionnement en proxy : proxy et proxyValidate.

Pour plus de détails: ESUP Portail

Il y a une notion de tickets, un peu à la manière kerberos.
Ces tickets sont des 'opaque handles' : ils ne transportent aucun information.

Il y a 2 tickets nécessaires au fonctionnement de base, plus 2 autres tickets dans le cas d'utilisation de proxy CAS :

• ticket-granting cookie (TGC) : C'est un cookie de session qui est transmis par le serveur CAS au navigateur du client lors de la phase de login. Ce cookie ne peut être lu / écrit que par le serveur CAS, sur canal sécurisé (https).

Il est facultatif. Si le navigateur web n'accepte pas les cookies, l'utilisateur devra se ré-authentifier à chaque appel au serveur CAS.

• service ticket (ST) : Ce ticket va servir à authentifier une personne pour une appli web donnée. Il est transporté en paramètre d'un GET, en retour du serveur CAS lors de la phase de login.

Ce ticket ne peut être utilisé qu'une seule fois. Il y a ensuite dialogue direct entre l'appli web et le CAS via un GET http, avec le ST en paramètre. En réponse, le serveur CAS retourne l'identifiant de la personne, et donc l'authentifie. Il invalide également le ticket (libération des ressources associées). En fait, ce ticket concerne un personne, pour un service, et utilisable une seule fois.

• proxy-granting-ticket (PGT) : envoyé par le CAS à une appli web 'proxy CAS' disposant d'un ST valide. Ce ticket confère au proxy CAS la possiblité de demander au serveur CAS de générer un Proxy Ticket (PT) pour une application tierce et une personne donnée.
• proxy-ticket (PT) : généré par le CAS à la demande d'un proxy CAS. Il permet d'authentifier l'utilisateur pour un service distant, avec lequel le client web n'a pas d'accès direct. Le service distant l'utilisera comme le ST.

Ce tutoriel a été réalisé sur une base Debian Squeeze et la dernière version disponible CAS 4.3.11.
Le but étant d'authentifier des users d'un Active Directory 2008 par le biais du CAS SSO.

• Récupérer les sources du projet :

wget http://downloads.jasig.org/cas/cas-server-3.4.11-release.tar.gz
tar xvzf cas-server-3.4.11-release.tar.gz
more cas-server-3.4.11/INSTALL.txt

On peut noter que la page de login peut-être designé.

• Sous la tutelle du wiki CAS , configuration du fichier pom.xml pour le Handler de l'authentification LDAP:

cd cas-server-3.4.11/cas-server-webapp
vi pom.xml

• Ajouter à la fin des dépendances :

<!-- Dependance support LDAP -->
        <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>cas-server-support-ldap</artifactId>
        <version>${project.version}</version>
        </dependency>

• Configuration de la connexion LDAP :

cd ./src/main/webapp/WEB-INF
vi deployerConfigContext.xml

• Ajouter sous la balise <property name=“authenticationHandlers”>, déclarer votre adaptateur pour l'authentification LDAP:

 <property name="authenticationHandlers">
                        <list>
<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"
  p:filter="sAMAccountName=%u"
  p:searchBase="cn=Users,dc=mathieu,dc=local"
  p:contextSource-ref="contextSource"
  p:ignorePartialResultException="true" />
                        </list>
                </property>
        </bean>

• Créer en parallèle dans votre AD, l'utilisateur définit pour la connexion à la base de comptes LDAP:

• Retour au fichier deployerConfigContext.xml, sous la balise <bean id=“auditTrailManager” ….>, renseigner votre utilisateur pour vérifier les utilisateurs dans l'annuaire LDAP:

<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
  <property name="pooled" value="false"/>
  <property name="url" value="ldap://ad.mathieu.local:389" />
  <property name="userDn" value="cn=ldapuser,cn=Users,dc=mathieu,dc=local"/>
  <property name="password" value="P@ssw0rd"/>
  <property name="baseEnvironmentProperties">
    <map>
      <entry key="com.sun.jndi.ldap.connect.timeout" value="3000" />
      <entry key="com.sun.jndi.ldap.read.timeout" value="3000" />
      <entry key="java.naming.security.authentication" value="simple" />
    </map>
  </property>
</bean>

Le filtre peut-être plus complexe: GID ou attributs spécifiques …

• Une astuce pour vérifier que vous pourrez requêter sur l'annuaire LDAP :

ldapsearch -b "DC=test,DC=local" -H ldap://dc1.test.local:389 -D 'administrateur' -w 'Pa$$w0rd'

Les paramétrages sont terminés, il faut maintenant compiler l'application avec la dépendance du support d'authentification LDAP ainsi que les paramétres de connexion à l'annuaire.

• Pour se faire, on utilise MAVEN : outil de management de projets Java

aptitude install maven2 sun-java6-jdk sun-java6-fonts

• Retourner à la racine du projet, soit cas-server-webapp :

cd /root/sources/cas-server-3.4.11/cas-server-webapp

• Fixer la variable d'environnement JAVA_HOME :

export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.26/

Pour installer le paquet sun-java6-jdk, il vous ajouter les repos non-free dans le /etc/apt/source.list.

• Lancer la compilation du projet JAVA:

mvn -Dmaven.test.skip=true package install -e

La compilation doit se terminait ainsi :

Et comme indiqué, l'application compilé avec succès est diposnible dans le dossier target sous la forme d'une archive cas.war.

Je pars du principe que vous avez le Tomcat installé sinon vous disposez des infos nécessaires sur ce tuto:

• Administration du serveur d'application Java Tomcat

• Copier le cas.war dans le Directory des applis Java gérées par Tomcat:

cp target/cas.war /var/lib/tomcat6/webapps/

Une fois le war déployé, arretez le tomcat et déplacez le cas.war dans un emplacement de sauvegarde.

• J'ai rencontré quelques problèmes que j'ai solutionné en debuggant à l'aide du catalina.out:

vi ./cas/WEB-INF/classes/log4j.xml

• Correction des chemins de logs :

<param name="File" value="/var/log/tomcat6/cas.log" />
<param name="File" value="/var/log/tomcat6/perfStats.log"/>

• Créer les fichiers :

touch /var/log/tomcat/cas.log
chown tomcat6:tomcat6 /var/log/tomcat/cas.log
touch /var/log/tomcat/perfStats.log
chown tomcat6:tomcat6 /var/log/tomcat/cas.log

• Un reload du service tomcat avec succès, et une connexion réussie :

• Voici les logs qui valide le user en arrière plan:

Afin de sécuriser les échanges entre le servlet CAS SSO de Jasig et notre annuaire LDAP ActiveDirectory,
il est judicieux de configurer la connexion sous LDAPS.

• Pour se faire, il faut installer une Autorité de certification sur le contrôleur de domaine (PKI):

• Il faut ensuite publier le certificat Authentification du contrôleur de domaine si celà n'est pas fait:

• Depuis une console certificats ordinateur, demander le certificat “Authentification du contrôleur de domaine”:

Le certificat doit-être installer dans le magasin personnel de l'ordinateur local.

• Redémarrez le serveur et tester la connexion LDAPS avec l'utilitaire ldp.exe :

Si le contrôleur de domaine est catalogue global, le protocole LDAPS bind au port 3269.
Si ne l'est pas, le protocole LDAPS bind au port 636.

Pour pouvoir attaquer le serveur en LDAPS, il faut disposer du certificat de la CA racine dans le magasin des autorités de certification approuvées.

• Exporter le certificat de la CA Racine au format X509 en base64 (sans la clé privé bien sur…):

• Transférer le certificat sur le serveur Linux, nous allons le convertir au format PEM:

openssl -x509 -in /root/CA_root.cer -out /root/CA_root.pem

• Déplacer le certificat dans le magasin des autorités approuvées:

cp /root/CA_root.prm /etc/ssl/certs
rm -f /root/CA_root.*

• Renseigner le certificat de la CA Racine dans le fichier ldap.conf:

vi /etc/ldap/ldap.conf

TLS_CACERT /etc/ssl/certs/CA_root.pem

• En principe vous pouvez donc attaquer l'annuaire AD en LDAP comme ceci:

ldapsearch -x -H 'ldap://2K8R2.mathieu.local:389' -b 'DC=mathieu,DC=local' -D 'administrateur' -w 'P@$$w0rd' "sAMAccountName=Administrateur"

• Et maintenant en LDAPS:

ldapsearch -x -H 'ldaps://2K8R2.mathieu.local:3269' -b 'DC=mathieu,DC=local' -D 'administrateur' -w 'P@$$w0rd' "sAMAccountName=Administrateur"

• Pour le servlet cas, le support TLS sur LDAP nécessite de stocker sur le certificat “Contrôleur de domaine” du serveur LDAP. Si vous ne le faites pas, le CAS vous enverra ce message d'erreur : unable to find valid certification path to requested target

Exporter le certificat du serveur LDAP au format x509 en base64 et transférer le sur le tomcat.

• Conversion du certificat au format DER:

openssl x509 -in LDAP.cer -out LDAP.der -outform DER

• Importer le certificat dans le magasin des autorités de certifications approuvées:

keytool -import -trustcacerts -alias LDAPS -keystore /usr/lib/jvm/java-1.6.0-openjdk/jre/lib/security/cacerts -file LDAP.der

• Reste à modifier la configuration du CAS SSO pour utiliser LDAPS plutôt que LDAP:

vi /var/lib/tomcat6/webapps/cas/WEB-INF/deployerConfigContext.xml

<property name="url" value="ldaps://192.168.1.32:3269" />

• Renseigner le magasin des autorités de certification reconnues dans le connector HTTPS du Tomcat:

vi /etc/tomcat6/server.xml

<file xml>

 <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
             maxThreads="150" scheme="https" secure="true"
             clientAuth="false" sslProtocol="TLS"
              keystoreFile="/etc/tomcat6/mykeystore"
              keystorePass="P@$$w0rd"
              truststoreFile="/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/security/cacerts" />

</code>

• Un paquet intercepté lors de la requête en LDAP:

• Un paquet intercepté lors de la requête en LDAPS: