Skip to end of metadata
Go to start of metadata
Adaptation d'un serveur CAS existant

Cette page décrit l'installation de A à Z d'un nouveau serveur CAS qui permet :

  • l'authentification transparente des utilisateurs par la transmission de tickets Kerberos
  • l'alimentation automatique d'un royaume Kerberos à partir des utilisateurs LDAP lors de leur connexion

Il est facile pour un administrateur CAs d'extraire de cette documentation les éléments nécessaires à l'adaptation d'un serveur CAS existant pour lui donner les fonctionnalités voulues.

Nom du serveur

cas-kerb.univ-rennes1.fr

Système

RedHat Entreprise 5

Ouverture de ports

ssh (22 tcp)
https (443)

Installation système

Installer les packages Tomcat (yum install tomcat5), Apache (yum install httpd), puis Maven :

Installation de CAS

Télécharger la dernière version de CAS depuis http://www.jasig.org/cas/download et décompresser :

Pour diminuer les temps de compilation, on ajoute la propriété skipTests au plugin maven-sunfire dans le fichier pom.xml à la racine du projet :

Créer un répertoire cas-server-rennes1 dans lequel seront stockées toutes les personnalisations et y ajouter le fichier pom.xml suivant :

Plutôt que modifier les fichiers de la distribution CAS, il est préférable de maintenir toutes modifications effectuées dans ce répertoire, ce qui facilite les mises à jour. Tous les fichiers trouvés dans ce répertoire écraseront les fichiers de la distribution, on adoptera donc exactement la même hiérarchie de fichiers que celle de la distribution.

Installation basique

Copier le fichier src/main/webapp/WEB-INF/classes/log4j.properties de cas-server-webapp dans src/main/webapp/WEB-INF/classes et indiquer le chemin des logs :

Générer le WAR, le copier dans Tomcat et redémarrer :

Debug

Ajouter dans le fichier src/main/webapp/WEB-INF/classes/log4j.properties la ligne suivante :

Les logs se trouvent dans le répertoire /var/log/tomcat5.

La mise au point la plus difficile est celle de Kerberos (les logs en debug de Krb5LoginModule se trouvent dans catalina.out).

Test

Tester http://cas-kerb.univ-rennes1.fr:8080 (user = test, password = test).

Script de déploiement de CAS

Pour faciliter le déploiement du serveur CAS et le redémarrage de Tomcat, on pourra ajouter le script /usr/local/cas-server-3.3.5/deploy-restart.sh suivant :

Ajout d'un frontal Apache

On va dans cette partie configurer un frontal Apache sur le port 80, qui va accéder au Tomcat du serveur CAS en AJP sur le port 8009.

Il n'est pas obligatoire de mettre un frontal Apache devant Tomcat, mais cela délègue le chiffrement à Apache au lieu de Tomcat et simplifie l'administration système (cette architecture est employée de manière générale sur les plateformes d'exploitation).

Configuration de Apache

Insérer dans /etc/httpd/conf.d/proxy_ajp.conf les lignes suivantes :

Configuration de Tomcat

S'assurer que le connecteur AJP sur le port 8009 n'est pas commenté et a bien le paramètres tomcatAuthentication positionné à false :

Test

Après redémarrage de Apache et Tomcat, le serveur CAS doit désormais répondre sur l'URL https://cas-kerb.univ-rennes1.fr (sur le port 80 par défaut en HTTP).

Passage en HTTPS

Installer si nécessaire le package mod_ssl (yum install mod_ssl).

Installerle certificat x509 et la cléprivée du serveur dans les répertoires appropriés (/etc/pki/tls/

Configuration de Apache

Installer le certificat du serveur en éditant /etc/httpd/conf.d/ssl.conf et modifier les lignes suivantes dans le virtual host _default_:443 :

Test

Après redémarrage de Apache, le serveur CAS doit désormais répondre sur l'URL https://cas.ifsic.univ-rennes1.fr  (sur le port 443 par défaut en HTTPS).

Suppression de l'accès en HTTP

Ne pas oublier de supprimer la ligne suivante de /etc/httpd/conf/httpd.conf :

Ajout de l'authentification LDAP

Configuration de CAS pour LDAP

Ajouter la dépendance vers le module cas-server-support-ldap dans le fichier pom.xml :

Copier le fichier src/main/webapp/WEB-INF/deployerConfigContext.xml de cas-server-webapp dans src/main/webapp/WEB-INF, ajouter le bean suivant pour déclarer le contexte LDAP :

puis changer le handler SimpleTestUsernamePasswordAuthenticationHandler par celui-ci :

Test

Redéployer le serveur CAS, et tester l'authentification d'un utilisateur LDAP.

Ajout de l'authentification Kerberos

La documentation de référence est http://www.ja-sig.org/wiki/display/CASUM/SPNEGO .

Configuration de Kerberos

Editer le fichier /etc/krb5.conf pour intégrer le serveur au domaine Kerberos :

Ajouter le principal HTTP/cas-kerb.univ-rennes1.fr (casse importante) au royaume et l'exporter dans le fichier /etc/http.keytab :

Le fichier /etc/http.keytab sera utilisé par la librairie JCIFS, il doit être lisible par l'utilisateur tomcat :

Debug

Ajouter dans le fichier /etc/tomcat5/tomcat5.conf les lignes suivantes :

Les logs se trouvent dans /var/log/tomcat5/catalina.out.

Configuration de CAS

Ajouter le support du handler spnego

Editer le fichier pom.xml et ajouter la dépendance suivante (par exemple juste après la dépendance vers le module cas-server-support-ldap) :

Modifier le login webflow

Editer le fichier src/main/webapp/WEB-INF/login-webflow.xml et ajouter l'état suivant juste avant l'état viewLoginForm :

Dans ce même fichier, remplacer les références à viewLoginForm par startAuthenticate pour les deux decision-state gatewayRequestCheck et renewRequestCheck :

Déclarer le bean implémentant le nouvel état du webflow en ajoutant les lignes suivantes dans le fichier src/main/webapp/WEB-INF/cas-servlet.xml (par exemple juste avant le bean authenticationViaFormAction) :

Modifier le schéma d'authentification

Pour modifier le schéma d'authentification, éditer le fichier src/main/webapp/WEB-INF/deployerConfigContext.xml et modifier le bean authenticationManager en ajoutant :

  • PrincipalBearingCredentialsToPrincipalResolver après les resolvers existants de credentialsToPrincipalResolvers
  • PrincipalBearingCredentialsAuthenticationHandler avant les handlers existants de authenticationHandlers

Le bean authenticationManager doit ainsi ressembler à :

Ajouter enfin le bean jcifsConfig, qui done les options de configuration de JCIFS :

Configuration de JCIFS

La configuration de JCIFS se fait également dans le fichier login.conf pointé par le bean jcifsConfig. Créer ce fichier avec le contenu suivant :

Configuration de Tomcat

Il faut passer à la JVM qui exécute Tomcat l'option -Djavax.security.auth.useSubjectCredsOnly=false, par exemple en éditant le fichier /etc/tomcat5/tomcat5.conf et en ajoutant la ligne suivante :

Test

Un navigateur bien configuré et possédant des credentials Kerberos valides doit maintenant se connecter au serveur CAS sans aucune interaction....

Ajout de l'alimentation Kerberos

L'alimentation Kerberos désigne le processus qui permet d'alimenter un royaume Kerberos avec comptes utilisateurs lors de la connexion au serveur CAS. Elle peut être utilisée pour amorcer le remplissage du royaume à partir d'un annuaire LDAP, ce que nous montrons dans cet exemple.

Configuration de Kerberos

En premier lieu, déclarer le principal qui servira à la mise à jour du royaume Kerberos (ici cas/admin) et l'exporter dans le fichier /etc/cas-admin.keytab :

Le fichier cas-admin.keytab doit être lisible par l'utilisateur tomcat :

Il est également nécessaire de modifier les permissions du fichier de log de kadmin sans quoi l'appel de kadmin par l'utilisateur tomcat provoquerait une erreur.

Intégration du module cas-server-integration-kerberosfeed

L'alimentation du royaume Kerberos se fait en utilisant le module cas-server-integration-kerberosfeed (téléchargeable ici ), qui doit être installé au même niveau que les autres modules du projet puis compilé (lancer la commande mvn package install depuis le répertoire du module).

Il faut ensuite ajouter la dépendance de cas-server-rennes1 vers cas-server-integration-kerberosfeed en ajoutant dans le fichier pom.xml du module cas-server-rennes1 les lignes suivantes :

Configuration de CAS

On utilise la classe KerberosFeedAuthenticationHandlerWrapper pour enrober l'appel des authenticationHandlers pour lesquels on souhaite mettre en place une alimentation du royaume Kerberos. Les lignes suivantes de src/main/webapp/WEB-INF/deployerConfigContext.xml

Seront ainsi remplacées par :

Lorsqu'un authenticationHandler est enrobé de la sorte et que l'authentification du bean enrobé (ici FastBindLdapAuthenticationHandler) s'effectue avec succès, alors elle est suivie de l'ajout dans le royaume de l'utilisateur à l'aide d'une commande kadmin, en utilisant la configuration donnée par le bean kerberosFeedConfig :

La propriété password n'est utilisée que lorsque useKeytab est positionnée à false, dans le cas ci-dessous on utilise la keytab générée précédemment.

L'ajout d'un utilisateur déjà présent dans le royaume Kerberos provoque une erreur de kadmin, qui n'est pas prise en compte (rien n'est fait dans ce cas, l'erreur n'est pas dommageable). Néanmoins, afin de ne pas rejouer l'ajout d'un utilisateur déjà présent dans le royaume, le bean KerberosFeedAuthenticationHandlerWrapper s'appuie sur un registre (propriété registry), dans lequel il mémorise les utilisateurs déjà ajoutés dans le royaume. Par défaut (lorsque la propriété registry n'est pas positionnée), la mémorisation est faite en mémoire (implémentation InMemoryRegistryImpl) et les informations sont perdues à chaque redémarrage du serveur CAS. On peut aussi utiliser un registre basé sur BerkeleyDb, dont les informations seront permanentes :

Les informations seront ici stockées dans le répertoire /tmp.

Test

Se connecter sur le serveur CAS avec un utilisateur de l'annuaire LDAP (par exemple dupont) et vérifier qu'il est bien ajouté dans la base Kerberos (getprinc dupont sous kadmin sur le KDC).

Labels
  • None