CAS

Un article de Wiki Paris Descartes.

Des clés pour comprendre l'Université numérique
Accès par catégories au glossaire : Accès thématique
HYPERGLOSSAIRE : A B C D E F G H I J K L M N O P Q R S T U V W X Y Z



CAS (Central Authentication Service) est un mécanisme d'authentification très solide implanté dans plusieurs universités et organismes dans le monde. C'est le système de SSO développé par l'Université de Yale.
CAS met en oeuvre un serveur d'authentification accessible par W3, composé de servlets java.
Ses point forts sont les suivants :

  • La sécurité est assurée par les dispositifs suivants :
    • le mot de passe de l'utilisateur ne circule qu'entre le navigateur client et le serveur d’authentification, nécessairement à travers un canal crypté.
    • Les ré-authentifications suivantes sont faites de manière transparente à l'utilisateur, sous réserve de l'acceptation d’un cookie privé et protégé. Seul le serveur d'authentification peut lire et écrire ce cookie, qui ne contient qu'un identifiant de session.
    • L'application reçoit du serveur d'authentification un « ticket opaque » qui n'est pas porteur d'information personnelle. Ce ticket circule en clair via le navigateur (en paramètre CGI) ; il n'est pas rejouable, a une durée de vie courte, est n'est utilisable que par l'application qui l'a demandé. L'application va ensuite contacter directement (en http) le serveur CAS afin de faire valider (et expirer) ce ticket ; le serveur CAS va retourner à l'application l'identifiant de la personne, validé. L'application n'a ainsi jamais accès au mot de passe (schéma pourtant classique de pratiquement tous les mécanismes de SSO).
  • Les mécanismes classiques imposent une communication entre le navigateur web et l’application, ce qui exclut les configurations n-tiers, où une application doit directement interroger un service nécessitant authentification (c'est le cas par exemple pour un portail accédant à un web service). CAS, dans sa version 2.0, résout ce problème en proposant un mécanisme de mandataires (proxies). Des tickets dédiés permettent à des applications tierces, n’ayant aucune communication avec le navigateur client, d’être assurées de l’authentification de l’utilisateur. Cette fonctionnalité est assurément le point fort de CAS.
  • Le package proposé implémente tout le protocole de mise en oeuvre du SSO, à l'exception du module d'authentification locale qui est à la charge de l'administrateur du serveur d’authentification. Cela laisse la liberté d’implémenter exactement l’authentification souhaitée (LDAP, Kerberos, certificats X509, NIS, un panachage, ...).
  • Des librairies clientes en Java, Perl, JSP, ASP, PL/SQL et PHP sont livrées. Cela permet une grande souplesse sur les serveurs d'applications. L’intégration dans des outils utilisés dans le monde universitaire est d’ores et déjà faite.
  • L'utilisation de cookies exclusivement privés dans CAS (passage de tickets entre serveur d’authentification et applications uniquement sous forme de paramètres de GET HTTP) permet à CAS d'être opérationnel sur des serveurs situés dans des domaines DNS différents.
  • Un module Apache (mod_cas) permet d'utiliser CAS pour protéger l'accès à des documents web statiques, les librairies clientes ne pouvant être utilisées dans ce cas.
  • Un module PAM (pam_cas) permet de « CAS-ifier » des services non web, tels que FTP, IMAP, ...
  • Enfin, CAS est en production dans plusieurs Universités américaines, avec des authentifications internes Kerberos ou LDAP, ce qui permet d’être confiant sur sa fiabilité.

Liens pour approfondir