|
|
||
| Date de création : | 24 mai 2003 | |
| Dernière modification : | 28 décembre 2003 | |
| Diffusion : | ESUP-Portail | |
Ce document résume les tâches a effectuer par le groupe 1B (SSO).
| état | priorité | |||
|---|---|---|---|---|
| Terminé | Action terminée | A | À faire en priorité | |
| Avancé | Étude en état avancé | B | À traiter rapidement | |
| EnCours | Action en cours | C | À traiter à moyen terme | |
| Active | Action importante, non traitée actuellement | D | À prendre en compte nécessairement, mais à échéance plus lointaine | |
| EnAttente | Action non traitée actuellement | E | A un intérêt certain, mais n'est pas vital pour le projet | |
| Abandon | Action abandonnée, au moins provisoirement | |||
| ? | On ne sait pas | Z | À faire avant la retraite ;-) | |
Les documents sont disponibles. L'installation a déja été effectuée par des stagiaires en suivant la documentation ... en moins d'une demi-journée.
Tous les sites partenaires sont concernés par cette action. L'avancement est le suivant :
La faiblesse essentielle en matière de tolérance aux fautes du serveur CAS réside dans la perte des tickets lors d'un redémarrage, car ceux-ci sont stockés en mémoire.
Un stockage en base de données doit permettre un redémarrage du serveur CAS sans aucune perte de tickets.
Cela doit également permettre la redondance du serveur par duplication de serveurs web (plusieurs tomcat derrière un frontal Apache), qui s'appuieront sur la même base de données. De ce fait, la validation d'un ticket pourra se faire sur un serveur différent de celui qui l'a émis. Raymond Bourges mets prochainement en ligne une documentation sur la configuration d'un frontal Apache devant plusieurs serveurs tomcat.
Note 1: cela ne fait que déplacer les problèmes de tolérance aux fautes et de redondance vers le serveur de données. Cette solution satisfait néanmoins les participants du groupe (certainement car les serveur de données sont beaucoup mieux maîtrisés).
Note 2 : ceci peut générer une charge importante au niveau du
serveur CAS et du SGBD. Une autre olution serait de ne cacher que les 'Granting
Ticket' (TGC et PGT).
Inconvénient : pas de partage de charge possible
Avantages : forte réduction de charge, et possibilité d'avoir
un serveur CAS de secours avec basculement quasi-transparent.
Rien :-(
Responsables : Pascal Aubry (back-end base de données).
CAS est utilisé dans des universités ayant un nombre d'étudiants similaires au nôtre (20 0000 - 30 000). Il faut quand même monter un protocole d'essais, et le mener à bien, dans notre environnement. En particulier, tester le module LDAP qui pourrait être un point de contention.
Le groupe SSO s'appuiera sur les travaux du groupe normes qui va regarder les outils et méthodes possibles.
La partie serveur CAS est avare en matière de logs (à des fins de débogage, par exemple) et d'accounting.
Il est indispensable d'enrichir ces aspects. Log4j est envisagé (voir avec le groupe normes).
CASGenericHandler est disponible, en production à Nancy 2.
Il reste à introduire l'authentification sur certificats x509, mais ce n'est pas une priorité.
Responsable : Pascal Aubry.
Toutes les librairies clientes ont été testées par le groupe, sauf la librairie ASP (inutile à ce jour).
Une librairie PHP (phpCAS) développée au sein de ESUP permettant de développer un client ou proxy CAS en php. La version courante est complètement opérationnelle, en phase de test. Suite à l'utilisation de phpCAS par Julien Marchal pour la CAS-ification de IMP, des ajustements s'avèrent nécessaires (pour fin novembre 2003).
Il faudrait éventuellement en plus intégrer la redirection des méthodes POST et le paramétrage standard.
Responsable : Pascal Aubry.
Les tests ont été mené, il faut encore tester les problèmes d'interaction avec d'autres mécanismes (mod_auth_xxx).
mod_cas a été complètement ré-écrit, en utilisant notamment la librairie cURL pour remplacer les appels bas-niveau de OpenSSL.
La redirection des méthodes POST et le paramétrage standard n'ont pas été intégrés.
Un mail a été envoyé à Drew Mazurek pour savoir si les modifs envoyées seront intégrées dans la prochaine version de cas-client, sans retour.
Responsable : Pascal Aubry.
La redirection des méthodes POST et le paramétrage standard n'ont pas été intégrés.
Responsable : Sébastien Gougeon. Fait le 15/09/03
Tests et documentation de la librairie cliente java.
Responsable : Jean-Guy Avelin. Dépot de doc le 8/12/2003.
Développement d'une nouvelle librairie cliente perl, celle distribuée étant trop limitée.
Librairie développée par Olivier Salaun, du CRU, le 15/11/2003, et à maintenir par le projet Esup-portail.
Responsable : Vincent Mathieu.
Le besoin de cette librairie ne s'est pas encore fait sentir dans le projet et personne n'est assignée à l'évolution de cette librairie.
Le code C ré-écrit pour mod_cas peut être réutilisé pour pam_cas. Il sera intéressant de développer une librairie libcas pour mutualiser le code de validation des tickets, et peut-être plus. Cette librairie pourra de plus être utilisée dans le cadre du développement d'une extension PHP (intéressante pour la visibilité de CAS).
L'écriture de la librairie a été mise en stand-by par l'absence de réponse de Drew Mazurek.
Responsable : Pascal Aubry.
Échance : fin août 2003.
Tous les sites partenaires sont concernés par cette action. Les sites suivants ont déjà intégré CAS dans uPortal :
Consiste à mettre à disposition dans uportal d'un 'module' permettant à un développeur d'un canal de récupérer un PT (Proxy Ticket) simplement.
CasUtil est disponible deepuis septembre 2003.
Responsable : Julien Marchal
C'est un des problèmes majeurs de l'utilisation de CAS avec uportal.
uportal gére, comme la plupart des applis web, des sessions utilisateur,
ayant un certain délai.
CAS gère également des sessions d'authentification, qui n'ont
pas nécessairement la même période que les sessions précédentes.
Il faut en outre qu'un "arrêt - relance" du serveur CAS ne
mette pas en péril le fonctionnement du portail.
Il est donc urgent de s'assurer qu'il est possible de traiter le cas d'une expiration d'un PGT (Proxy Granting Ticket) ou d'un arrêt du serveur CAS sans mettre l'utilisateur dans un état d'incompréhension.
Au pire, si la récupération d'un nouveau PGT d'une manière
transparente semble difficile, prévoir une procédure qui ne mette
pas uportal dans un état 'bizarre'.
Ceci est traité dans la librairie précédente, par remontée
d'une exception à uportal.
Responsable : Vincent Mathieu.
Il est probable qu'en exploitation, le serveur apache soit mis en frontal d'uportal. Il faudrait vérifier que l'authentification CAS fonctionne correctement dans cette hypothèse.
Tests fait par Raymond en juillet 2003, confirmés par Vincent en aout.
Des modifications ont été apportées au module et intégrées par les développeurs CAS (cf cas_pam.html).
Responsable : Vincent Mathieu
La CAS-ification de cyrus-imap a été réalisée par Vincent Mathieu (cf CyrusImapmap-cas.html), celle de IMP par Julien Marchal (Julien, as-tu une doc à ce propos ?).
La CAS-ification de IMP devra être revu en fonction des modifications de phpCAS.
Responsables : Vincent Mathieu, Julien Marchal.
Le problème est considéré comme résolu sur le plan théorique et il ne reste plus qu'à intégrer les décisions prises dans les librairies clientes.
Une page est consacrée à ce point.
Il s'agit ici de traîter la partie « autorisations », qui devra suivre les recommandations du groupe AAS.
Le format de documentation du groupe a été mis en place, puis porté à la documentation des autres groupes.
Responsable : Pascal Aubry.
Vincent Mathieu et Pascal Aubry sont les représentants du projet au sein du groupe AAS. Les documents relatifs au travail du groupe AAS sont disponibles.
Responsables : Vincent Mathieu, Pascal Aubry.
| Création : 24 mai 2003 - Vincent Mathieu (Université de Nancy 2) | |
|
Modifications : |