wiki:CasPresentation

Présentation de CAS (Central Authentication Service)

TOC?

Introduction

CAS est une solution de Single Sign-On proposée par  JA-SIG. La liste suivante décrit ses principaux aspects :

  • Un point d’authentification unique pour toutes les applications Web ;
  • Ne gère que l’authentification ;
  • Le mot de passe ne transite que par connexion sécurisée SSL ;
  • Déployé dans de nombreuses universités, partout dans le monde ;
  • Développé avec Java et le framework  Spring ;
  • Open-Source (sous  licence JA-SIG) ;
  • De nombreux connecteurs vers des référentiels d’utilisateurs (bases de données relationnelles, annuaires LDAP, fichiers plats ou XML) ;
  • De nombreux clients disponibles (pour Apache, Java, PHP, Ruby on Rails, etc).

Le système de tickets

CAS a été conçu avec des impératifs de sécurité très élevés. CAS ne transmet jamais le mot de passe de l'utilisateur à des applications tierces. Il utilise à la place un système de tickets, inspiré par  Kerberos.

Nom simplifié Nom Description Rejouable ? Transmission sécurisée ?
TGC Ticket Granting Cookie Cookie de session transmis par le serveur CAS au navigateur. Il est utilisé pour identifier l'utilisateur sans avoir de mot de passe à retaper. oui oui
ST Service Ticket Ticket d'authentification sur CAS
PGT-IOU Proxy Granting Ticket IOU Ticket permettant l'obtention d'un vrai PGT oui
PGT Proxy Granting Ticket Ticket autorisant l'obtention d'un PT oui oui
PT Proxy Ticket Equivalent au ST dans un fonctionnement en mode proxy

Le fonctionnement de CAS (mode normal, non proxy)

Ce mode de fonctionnement a pour but d'identifier un utilisateur pour une application web, sans transmettre à cette dernière de mot de passe.

Un aperçu du fonctionnement

Quand quelqu'un accède à un site qui utilise CAS, le site redirige l'utilisateur vers le serveur CAS. Une fois que CAS a vérifié l'identité de l'utilisateur, il le redirige vers le site de départ. CAS attache un ticket unique à l'URL du site protégé. Ce dernier voit le ticket et le renvoie à CAS. Ensuite, CAS dit au site si le ticket est valide ou pas, et renseigne le nom d'utilisateur. Puis le service autorise l'accès selon la validité tu ticket.

Fonctionnement détaillé

Lorsque que vous vous identifiez sur CAS à https://auth.example.com, un cookie est enregistré sur le navigateur. Ce cookie contient un identifiant unique, le TGC, qui vous identifie sur le serveur CAS. A chaque accès à http://auth.example.com, ce cookie est transmis à CAS. C'est ce mécanisme qui maintient l'identification.

Les clients CAS se comportent de manière différente. Imaginons que vous souhaitez accéder à http://service.example.com. Cette page vous demande d'être identifié à CAS pour accéder au service. Comment ceci fonctionne-t-il ?

La page vous redirige sur https://auth.example.com/login?service=http://service.example.com grâce à une en-tête HTTP Location. Une fois que CAS a vérifié que vous êtes bien identifié, il vous renvoie à l'URL indiquée dans le paramètre service.

Mais l'URL du service reçoit un petit changement : CAS y ajoute un ticket à usage unique et limité dans un très court laps de temps, le ST, comme dans l'example suivant : http://service.example.com/?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc.

Le client CAS voit ce ticket et sait que l'utilisateur provient de https://auth.example.com. Il peut donc effectuer la requête suivante sur CAS https://auth.example.com/serviceValidate?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc&service=http://service.example.com.

Le serveur CAS répond avec un document XML qui décrit le ticket ; parmi les valeurs retournées, on retrouve une indication sur la validité du ticket ainsi que l'identifiant de l'utilisateur. C'est ensuite l'application qui décide d'autoriser l'accès au service ou pas.

Diagramme de séquence (utilisateur connecté)

Le système de tickets de CAS (UML)

Diagramme de séquence (utilisateur non connecté)

Le système d'authentification de CAS (UML)

Le mode proxy de CAS

L'évolution des architectures web a forcé les inventeurs de CAS à proposer un nouveau mode de fonctionnement : le mode proxy. En effet, de plus en plus d'applications communiquent avec des web services ; il est donc nécessaire de transmettre de manière sécurisée les informations d'authentification.

Mode proxy (fonctionnement global)

Ce type de configuration se retrouve par exemple dans le cas d'un portail (jouant le rôle de proxy CAS) qui souhaite accéder à l'emploi du temps de l'utilisateur.

Un aperçu rapide

Pour identifier l'utilisateur sur un web service, le proxy CAS doit demander au serveur CAS des tickets proxy (PT). Ces derniers se comportent de manière similaire aux tickets de service (ST).

Mais pour être autorisé à recevoir des ST, le proxy CAS doit tout d'abord posséder un PGT. Ce PGT est fourni au proxy lorsqu'il valide un ST sur le serveur CAS.

Diagramme de séquence (demande d'un PGT, utilisateur connecté)

Demande d'un ticket PGT (UML)

Diagramme de séquence (demande d'un PT, utilisateur connecté)

Demande d'un ticket PT (UML)

CAS à l'usage

Le serveur CAS centralise toutes les authentifications. C'est donc un point critique dans un système d'informations. Il est donc nécessaire de prendre quelques précautions avant la mise en service de CAS.

Balance de charge : bye, bye

Dans sa version courante (3.0.x), le serveur CAS ne partage pas les tickets et les informations de session des utilisateurs. Placer des serveurs CAS en redondance derrière un répartiteur de charge mènerait donc à des résultats incohérents. Pour assurer une disponibilité maximale, il importe donc que le CAS soit placé sur une machine suffisamment puissante, et résistante aux pannes (double alimentation, disques durs en RAID, etc).

Les prochaines versions de CAS devraient par contre proposer un moyen de partager les tickets et les sessions entre différentes instances.

Clients, utilisez un cache !

Nous avons vu précédemment qu'il faut un certain nombre de requêtes HTTP pour qu'une application identifie un utilisateur contre le serveur CAS. Voici le détail de ces requêtes, pour un utilisateur connecté :

Type de requête Cible Req. utilisateur ? Req. navigateur ? Req. service ?
1 L'utilisateur contacte le service de son choix. service oui
2 Le service redirige l'utilisateur sur CAS. CAS oui
3 CAS redirige l'utilisateur vers le service avec un ticket. service oui
4 Le service vérifie la validité du ticket sur CAS. CAS oui

Nous constatons que pour un accès d'un utilisateur connecté, il faut 3 requêtes HTTP supplémentaires pour l'identifier. Si ce processus était répété pour chaque requête, les performances du service seraient faibles, le serveur CAS régulièrement congestionné et l'expérience utilisateur très mauvaise.

Chaque service ne devrait donc identifier l'utilisateur qu'une seule fois et stocker le résultat de l'identification dans la session de l'utilisateur. C'est normalement le cas pour les librairies clientes de CAS.

Attachments