|
Ce document décrit l'installation et le paramétrage du module mod_cas esup-portail pour apache V2. |
| Dates de modification | ||
|---|---|---|
|
|
|
|
C'est le module initial. Le principal inconvénient est que le paramétrage se fait 'en dur', avant compilation.
Il est disponible ici.
C'est la distribution précédente, modifiée par esup-portail. Ce document en décrit les différences.
Elle est disponible ici.
C'est une distribution binaire RPM du package esup-portail, proposée par Jehan Procacci, de l'int d'Evry.
mod_cas est un module apache V2 qui permet de filtrer des accès http à l'aide de directives 'require user' ou 'require valid-user' en utilisant le mécanisme de SSO CAS.
Il est distributé par l'Université de Yales avec les clients cas. Voir la documentation Yale associée.
esup-portail a apporté des modifications importantes à ce module.
Le fonctionnement global du module est le suivant :
Lors d'un accès http vers une url protégée par mod_cas,
Si le navigateur n'a pas encore de 'session' http valide établie avec le serveur :
mod_cas redirige le navigateur vers l'url de login CAS pour authentification
Le navigateur revient du serveur CAS porteur du Service Ticket (ST), en paramètre de GET
mod_cas valide directement le ST auprès du serveur CAS en https ; il connait donc le 'login' de l'utilisateur.
mod_cas crée alors une session :
création d'un identifiant local de session
écriture dans un fichier 'cache' de cet id de session, du timestamp et du login correspondant
écriture de cet identifiant de session dans un cookie auprès du navigateur
Sinon, le navigateur a déja établi une session, et celle-ci est valide (le délai de fin de session n'est pas expiré) :
lecture du cookie de session
Validation de celui-ci (donc, récupération locale du login). Il n'y a alors pas de trafic spécifique lié à l'authentification CAS.
L'utilisation de la session est facultative. Elle est en fait pratiquement indispensable pour des raisons de performances.
L'utilisation de ce module amène certaines restrictions.
La plupart des problèmes liés à ces restrictions n'apparaissent que lors d'un accès http en n'étant pas en session 'mod_cas'.
Pour authentifier CAS, il est nécessaire de rediriger le navigateur vers le serveur CAS ; si la requête initiale est un POST ou d'autre requêtes porteurs d'informations dans le corps de la requête, ces informations sont perdues.
Un exemple :
un POST vers le serveur apache, alors qu'il n'y a pas encore de session mod_cas.
mod_cas redirige le navigateur vers le serveur CAS, via un GET HTTP. Après authentification, le navigateur va revenir à l'URL initiale, porteur du Service Ticket (ST), mais par un GET HTTP et non par le POST d'origine.
Les informations du POST sont donc perdues.
CAS ne gère pas les autorisations. Aussi, il est possible de poser des directives "require user toto", ou "require valid-user", mais pas "require group machin".
Il faudrait pour celà chainer mod_cas avec un autre module traitant des autorisations ... à faire.
Des anomalies dans le traitement de l'option "Indexes" ont déja été rencontrées lorsque les directives mod_cas sont incluses dans un container "Location" plutot que dans un container "Directory".
Le problème rencontré est le suivant :
Si on n'est pas encore en session mod_cas et qu'on tente d'accéder directement à un répertoire, apache ne traite pas les éventuels fichiers d'index (index.html, ....).
Si vous rencontrez ce problème et que les directives CAS sont dans un container "Location", essayez de les mettre dans un container "Directory" (ou dans un .htaccess).
Une autre anomaile relevée ; mise en évidence avec le module php.
Voici l'exemple de config :
<Directory /> DirectoryIndex index.html index.htm index.php ... </Directory> <Files *.php> SetOutputFilter PHP SetInputFilter PHP </Files>
Dans cet exemple, index.php ne sera pas 'exécuté' lorqu'on n'est pas encore en 'session mod_cas'.
Il faut remplacer le <Files *.php> par :
AddType application/x-httpd-php .php
De la même facon, il faut retirer tout <Files *.php> qui seraient dans la config apache. Par exemple, mod_ssl donne de base :
<Files ~ "\.(cgi|shtml|phtml|php|php3?)$"> SSLOptions +StdEnvVars </Files>
il faut le retirer (au moins pour php)
Les modifications apportées par rapport à la distribution de yale sont les suivantes :
La plupart des paramètres de configuration de la distribution yale sont 'en dur' dans un fichier include (cas.h). Ils sont donc figés lors de la compilation.
Les modifs esup-portail permettent de gérer ces paramètres au niveau de la config apache.
La partie de code consacrée à la connexion http ou https a été entièrement ré-écrite. Elle s'appuie toujours sur l'API openssl, mais en utilisant des fonctions de plus haut niveau qu'auparavant (objet BIO).
En fait, le code est repris du package pam_cas d'esup-portail.
Le code devient donc plus simple.
La gestion des certificats devient également plus souple :
Si le certificat du serveur CAS a été délivré par une Autorité de Certification, il était nécessaire avec le mod_cas initial de passer en paramètre tous les certificats de la chaine de certification ; avec mod_cas esup-portail, seul le certificat de l'autorité de certification racine est nécessaire.
Il est possible de forcer le domaine et le 'path' du cookie de mod_cas.
Cette fonctionnalité peut être nécessaire, par exemple dans le cas d'un apache gérant de multiples serveurs virtuels ; par exemple, www1.univ.fr, www2.univ.fr, ...
Le domaine peut être forcé à ".univ.fr", qui est valide pour tous les domaines enfants de univ.fr.
Il faut compiler le module mod_cas ; il est aussi nécessaire de 'patcher' le module mod_dir , sinon l'indexation des directories (Option Indexes) ne fonctionne pas lorqu'on accède à un répertoire et que l'on n'est pas en session mod_cas.
Deux types de compilation sont possibles, selon qu'apache a été installé en 'package binaire', ou qu'il soit compilé localement.
en pré-requis, openssl doit être installé.
Il suffit de recopier les répertoires sources/cas et sources/mappers vers le répertoire modules de la distribution source d'apache. (sources/cas contient mod_cas, sources/mappers contient mod_dir).
Ensuite, lancer ./buildconf dans le répertoire des sources apache.
Puis, ajouter --enable-cas=shared lors du 'configure'.
Cette procédure fonctionne sour redhat ou fedora, elle est à adapter pour d'autres configurations.
cd sources/cas
apxs -I/usr/kerberos/include/ -i -c mod_cas.c ssl_client.c
Puis, pour mod_dir :
cd sources/mappers
apxs -c -i mod_dir.c
Lire le fichier README.yale du répertoire sources/cas.
C'est un fichier distribué avec le package cas-client de Yale.
Il faut indiquer à Apache de charger le module mod_cas. Ceci se fait par la directive :
LoadModule cas_module modules/mod_cas.so
La configuration se fait dans un 'container' Directory, ou dans un fichier .htaccess.
Les différents paramètres possibles sont les suivants :
Voir README.yale
Indique que l'on veut authentifier à l'aide du mécanisme CAS.
Voir README.yale. Facultatif.
C'est le nom (chemin complet) d'un fichier qui va servir au cache local pour le mécanisme de session.
S'il n'est pas spécifié, mod_cas ne gère pas de mécanisme de session (déconseillé).
Par exemple :
CASLocalCacheFile /tmp/CAScache
Facultatif.
C'est la taille en nombre d'entrées du cach local de session.
Par défaut : 1000
Voir README.yale. Facultatif.
C'est la durée de validité du cache de session, en minutes.
Par défaut, 3600 (une heure)
Voir README.yale. Facultatif.
Force un cookie 'secure' si Off. Mette à On si on ne désire pas ce type de cookie.
Par défaut, Off
Voir README.yale. Facultatif.
Pas documenté. Sert à forcer un logout CAS
Ajout esup-portail. Obligatoire.
C'est le nom de host du serveur CAS
Par exemple :
CASHost auth.univ.fr
Ajout esup-portail. Facultatif
C'est le port d'accès au serveur CAS.
Par défaut, 443.
Ajout esup-portail. Obligatoire
C'est l'url complète de login CAS.
Par exemple :
CASLoginURL https://auth.univ-nancy2.fr
Ajout esup-portail. Obligatoire
C'est un nom de fichier complet qui contient le certificat (format PEM) permettant de valider (coté SSL) la requête https de validation de ticket CAS.
Si le certificat du serveur CAS est autosigné, c'est celui-ci qui est présenté.
Si le certificat du serveur CAS a été délivré par une Autorité de Certification, c'est le certificat de l'Autorité racine qui doir être présenté.
Par exemple :
CASTrustedCACert /Cert/ac-racine.pem
Ajout esup-portail. Facultatif
C'est l'uri du serveur CAS utilisée pour faire valider un ticket CAS (en protocole CAS V1)
Par défaut, /cas/validate
Ajout esup-portail. Facultatif
C'est le nom du cookie de session mod_cas.
Par défaut, MODCASID
Ajout esup-portail. Facultatif
C'est le domaine du cookie de session CAS.
Par défaut, aucun domaine n'est indiqué lors de la création du cookie ; le domaine est donc celui d'accès au serveur virtuel apache. Si le serveur est accédé en "http://www.unserv.univ.fr", le domaine par défaut sera : "www.univ-nancy2.fr".
Exemple d'utilisation :
CASCookieDomain .unserv.univ-nancy2.fr
(ceci crée un cookie accessible à tout site dans la hiérarchie de unserv.univ.fr, comme www1.unserv.univ.fr).
Ajout esup-portail. Facultatif
C'est le "path" du cookie de session CAS.
Par défaut, /
On veut limiter l'accès à http://exemple.univ-fr/essai à toute personne authentifiée CAS, et à http://exemple.univ-fr/essai/toto à l'utilisateur toto
LoadModule cas_module modules/mod_cas.so
...
<IfModule mod_cas.c>
CASLocalCacheInsecure On
CASLocalCacheFile /tmp/CAScache
CASTrustedCACert /Cert/ac-racine.pem
CASLoginURL https://auth.univ.fr
CASHost auth.univ.fr
CASPort 443
CASValidate /validate
</IfModule>
...
Directory /home/essai>
<IfModule mod_cas.c>
AuthType CAS
AuthName "bases en ligne"
Require valid-user
</IfModule>
</Directory>
Directory /home/essai/toto>
Require user toto
</Directory>