|
|
||
| Date de création : | 12 mars 2003 | |
| Dernière modification : | 4 janvier 2004 | |
| Diffusion : | internet | |
C'est le système de SSO développé par l'Université de Yale.
Ce document décrit les principes de ce mécanisme de SSO.
page du projet CAS : http://www.yale.edu/tp/auth/
C'est un mécanisme qui gère l'aspect authentification,
au sens strict : il ne permet pas dans sa version actuelle de récupérer
des informations de droits d'accès ou des attributs liés à la
personne.
Néammoins, étant donné son architecture, on peut imaginer
qu'il soit possible de l'aménager dans ce sens.
Il permet du SSO local, c'est à dire lié à une
entité ou un établissement; l'aspect inter-établissement
n'est pas pris en compte. Il est implémenté sous forme de servlets.
C'est une solution mure, utilisée par plusieurs universités américaines.
L'intégration dans uPortal est assurée.
La version 2 offre un service d'authentification proxy.
Cette solution de proxy semble intéressante dans une solution multi
tier, comme un portail (voir ceci).
Elle permet également d'utiliser ce mécanisme pour des services
non directement accessibles au navigateur web qui seraient exécutés
via une application web (un web service, par exemple).
Cette version apporte également un dialogue plus riche entre les applications
et le serveur CAS, en XML. Elle reste compatible avec la version 1.
La distribution est composée de 3 parties : le serveur CAS, les différents clients CAS, et les librairies et documentations pour l'intégration dans uPortal.
Le serveur CAS est en attente de connexions http ou https sur plusieurs url :
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 :
Le fonctionnement en mode non proxy est le suivant :
1. Requête initiale : le client web accède à une appli web qui nécessite authentification. Cette appli redirige la requête vers l'url login du serveur CAS, en https.
En paramètre du GET est passé l'ID du service (c'est en fait l'URL de retour).2. Authentification : le serveur CAS authentifie la personne grâce au mécanisme local d'authentification (LDAP, kerberos, certificat, ...).
Il redirige la requête vers l'appli initiale. Si le client web accepte les cookies, le TGC est positionné.3. Retour à l'appli web avec le ST, passé en paramètre du GET.
4. Validation : L'appli web accède directement au serveur CAS en http(s) (url validate ou serviceValidate), et passe en paramètres l'ID de service (l'URL) et le ST.
Le serveur CAS s'assure de la validité du ticket; il retourne l'uid de la personne. Le ticket ne peut plus être rejoué.
A ce moment, la personne est authentifiée, et l'appli connait son identifiant.
Le fonctionnement en mode proxy est le suivant :
1, 2 et 3 : identique au déroulement précédent.
4. Validation : L'appli web accède directement au serveur CAS en http (url serviceValidate), et passe en paramètres l'ID de service (l'URL), le ST et une url de callback.
Si le ST est valide, le serveur retourne comme auparavant l'identifiant de l'utilisateur, et un PGT-id : ce n'est pas le PGT, mais un index permettant de valider le PGT.5. Envoi du PGT : en synchronisme, le serveur CAS génère une connexion https vers l'URL de callback de l'appli proxy CAS ; cette requête contient le PGT, et le PGT-id. Le PGT a une durée de vie limitée ; seuls, les tickets TGC et PGT sont rejouables.
Maintenant, l'appli web proxy CAS dispose d'un PGT propre à l'utilisateur. Grâce à celui-ci, le proxy CAS pourra demander au CAS de lui générer des PT, qui sont l'équivalent du ST, mais pour des services (URLs) tiers.
On suppose maintenant que le proxy CAS fait appel à un service tiers nécessitant authentification ; ça peut être tout type d'application, ce qui compte, c'est qu'elle sache parler http. Dans l'illustration, il s'agit d'un 'web service'.
L'utilisateur est alors authentifié par le web service.
Il est possible d'utiliser des proxies CAS en cascade.
Dans le fonctionnement de CAS, le service ayant besoin de l'authentification est en relation directe avec le serveur CAS lors de la validation du ticket. Ceci rend possible l'utilisation de ce mécanisme pour transporter des informations complémentaires (autorisations, attributs, ...).
Le package fourni propose le nécessaire pour mettre en oeuvre le 'protocole' CAS ; à charge de l'implémenteur de développer le module d'authentification interne. Un module d'authentification LDAP a été récupéré pour les essais ; il est à améliorer.
le portage de CAS vers uPortal se fait facilement (les librairies sont fournies). Dans ce cas, uPortal devient proxy CAS ; il obtient donc un PGT du serveur CAS. Il est donc possible à un canal qui utiliserait un service tiers sachant authentifier CAS de demander un PT pour ce service; des essais fructueux ont été fait dans ce sens.
Différentes librairies sont fournies, pour les langages JSP, java, ASP, perl, PL/SQL. Le portage vers php est simple.
Il y a même un module apache (mod_cas) et un module PAM (pam_cas), ce qui ouvre des perspectives intéressante.
| Création : 12 mars 2003 - Vincent Mathieu (Université de Nancy 2) | |
|
Modifications : |