Central Authentication Service

Un article de Wikipédia, l'encyclopédie libre.

CAS est un système d'authentification unique (SSO) développé par l'Université de Yale, partenaire majeur dans le développement de uPortal. C'est un mécanisme très solide, qui est implanté dans plusieurs universités et organismes dans le monde.

Sommaire 1 Intérêt 2 Principe de fonctionnement 2.1 Ticket-Granting Cookie (TGC) 2.2 Service Ticket (ST) 2.3 Proxy-Granting-Ticket (PGT) 2.4 Proxy-Ticket (PT) 3 Bibliothèques 4 Liens externes

[modifier] Intérêt

Il évite de s'authentifier à chaque fois qu'on accède à une application en mettant en place un système de ticket. CAS est un système de Single Sign-On (SSO) : on s'authentifie sur un site web, et on est alors authentifié sur tous les sites web qui utilisent le même serveur CAS.

[modifier] Principe de fonctionnement

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

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

[modifier] 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).

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

[modifier] Service Ticket (ST)

Ce ticket va servir à authentifier une personne pour une application web donnée. Il est envoyé par le serveur CAS après que l'utilisateur s'est authentifié et est transporté dans l'URL.

Ce ticket ne peut être utilisé qu'une seule fois. Il y a ensuite dialogue direct entre l'application 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 une personne, pour un service, et utilisable une seule fois.

[modifier] Proxy-Granting-Ticket (PGT)

Il est envoyé par le serveur CAS à une application 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.

[modifier] Proxy-Ticket (PT)

Il est généré par le serveur 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.

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 œuvre 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 bibliothèques 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.

[modifier] Bibliothèques

Différentes bibliothèques 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éressantes.

Aussi une intégration CAS-Shibooleth est planifiée.

[modifier] Liens externes

• uPortal
• Site officiel de CAS
• ESUP-phpCAS
• Article de présentation de CAS
• Fédération d'identités et propagation d'attributs avec Shibboleth