Dans l’univers de l’authentification, certains protocoles dominent largement le marché, comme SAML, OAuth 2 et OpenID Connect. Pourtant, un protocole plus ancien mais toujours en usage mérite que l’on s’y attarde : le protocole d’authentification CAS (Central Authentication Service). S’il a perdu du terrain face à des solutions plus modernes, il reste bien implanté, notamment dans le secteur public. Cet article propose de revenir sur CAS, son fonctionnement et ses différences avec d’autres protocoles comme OpenID Connect.

 

Qu’est-ce que CAS (Central Authentication Service) ?

Le protocole d’authentification CAS est un protocole centralisée conçu à l’origine par l’Université de Yale. Son objectif est simple : permettre à un utilisateur de s’authentifier une seule fois auprès d’un serveur CAS, puis d’accéder à plusieurs applications sans devoir s’identifier de nouveau.

Contrairement à SAML ou OpenID Connect, qui reposent sur des assertions et des jetons, CAS utilise un mécanisme de tickets pour valider l’identité des utilisateurs. Cette approche présente des avantages en termes de simplicité, mais aussi certaines limitations.

Bien qu’il soit moins populaire aujourd’hui, CAS est encore rencontré dans des infrastructures existantes, et certaines solutions modernes comme Keycloak proposent même une compatibilité CAS via une extension dédiée..

 

Comment fonctionne le protocole d’authentification CAS ?

CAS repose sur un schéma relativement simple en trois étapes principales :

1. Requête d’authentification : L’utilisateur tente d’accéder à une application protégée. Celle-ci redirige l’utilisateur vers le serveur CAS pour s’authentifier.
2. Validation de l’identité : Le serveur CAS authentifie l’utilisateur (via un identifiant/mot de passe ou un autre moyen) et génère un ticket de service.
3. Vérification par l’application : L’application récupère ce ticket et le valide auprès du serveur CAS, qui renvoie alors l’identité de l’utilisateur.

À la différence d’OpenID Connect, où l’identité est contenue dans un jeton JWT, ou de SAML qui fournit une assertion, CAS ne fournit qu’un ticket opaque (comme Kerberos) qui doit être échangé contre les informations d’identité.

 

CAS vs OpenID Connect : quelles différences ?

CAS et OpenID Connect partagent des principes similaires, mais se distinguent par plusieurs aspects fondamentaux :

• Nature de la preuve d’identité :
  • CAS utilise un ticket de service opaque qui doit être validé par le serveur, il n’y a donc pas de matérialisation de la preuve d’identité
  • OpenID Connect fournit un jeton JWT contenant directement les informations d’identité.
• Transmission des informations :
  • Le ticket CAS s’apparente à un code, il transite par le navigateur (dans la query string) et donne accès à l’identité au travers d’une requête auprès du serveur
  • OpenID Connect utilise des requêtes plus structurées avec un state pour protéger contre le CSRF.
• Rejouabilité et sécurité :
  • Le ticket CAS est opaque et n’est pas rejouable, il devient inutilisable après validation.
  • OpenID Connect génère des jetons avec une durée de validité, qui nécessitent une gestion des rafraîchissements.

Si CAS offre une approche plus simple, l’absence de state dans la requête d’authentification implique que l’application prenne en charge certains aspects de sécurité, notamment contre les attaques CSRF.

 

Décryptage du protocole d’authentification CAS

Les spécifications CAS sont accessibles en ligne ici : ici. Elles définissent plusieurs URL standardisées pour interagir avec le serveur d’authentification :

• /login : Redirection de l’utilisateur vers le serveur CAS pour l’authentification.
• /serviceValidate (CAS 2.0) ou /p3/serviceValidate (CAS 3.0) : Validation du ticket et récupération de l’identité.
• /logout : Déconnexion de l’utilisateur.

Il suffit donc d’avoir le nom du serveur pour en déduire toutes les URL. CAS offre des fonctionnalités de type OAuth 2, avec des URL supplémentaires, qui ne seront pas abordées dans cet article.

 

L’authentification avec le protocole CAS

La requête d’authentification ne comporte qu’un élément essentiel service qui est l’URL de retour à l’application, qui identifie par là même l’application auprès du serveur. Tout comme en OpenID Connect, le serveur CAS doit vérifier que cette URL est bien connue. Une requête ressemblera donc par exemple à :

https://casserver.com/login?service=https%3A%2F%2Flocalhost%2Fclient%2Fcas%2Flogin%2Fcallback

 

Après authentification, le serveur CAS redirige l’utilisateur vers l’URL de service (celle de la requête d’authentification). Il n’y associe que le ticket de service, dans le paramètre ticket :

• par défaut dans la query string
• si le serveur est compatible dans le corps (en POST)
• si le serveur est compatible dans un entête HTTP

Le ticket est opaque : il ne porte aucune information en propre (au contraire du jeton d’identité). On ne peut donc pas l’exploiter en tant que tel (il ne contient en particulier pas l’identifiant de l’utilisateur).

https://localhost/client/cas/login/callback?ticket=ST-1234567890

L’application doit alors valider ce ticket en appelant le serveur CAS.

 

Les options d’authentification avancée

CAS propose plusieurs options d’authentification avancées et de gestion des connexions permettant de moduler son comportement :

• renew (paramètre fonctionnel): Force une ré-authentification de l’utilisateur, équivalent à prompt=login en OpenID Connect.
• gateway (paramètre fonctionnel): Permet une authentification silencieuse sans interaction utilisateur, équivalent à prompt=none en OpenID Connect
• method (paramètre technique): Définit la façon dont le ticket est retourné par le serveur (dans la query string (GET), dans le corps (POST) ou dans un en-tête http (HEADER)).

La méthode GET doit être implémentée par tous les serveurs CAS, qui peuvent choisir d’accepter POST ou HEADER. Keycloak (en version 26) ignore le paramètre et ne retourne le ticket qu’en query string.

 

La validation du ticket de service avec CAS

L’application récupère le ticket et le valide auprès du serveur tout en récupérant l’identité de l’utilisateur. Pour cela, l’application fait une requête directe auprès du serveur (sans passer donc par le navigateur).

Cette requête se fait en GET, avec comme paramètres 

• service, qui reprend l’URL du paramètre éponyme de la requête d’authentification
• ticket, avec le ticket de service

En fonction du protocole, des paramètres additionnels sont possibles.

Lorsque l’application valide le ticket auprès du serveur CAS, elle reçoit donc en retour une réponse structurée contenant l’identité de l’utilisateur. Par exemple :

{
  « serviceResponse »: {
    « authenticationSuccess »: {
      « user »: « monet »,
      « attributes »: {
        « mail »: « claude.monet@aduneo.com »,
        « givenName »: « Claude »,
        « sn »: « Monet »,
        « cn »: « Claude Monet »
      }
    }
  }
}

La réponse de validation du ticket de service dépend de l’URL du serveur requêtée, et des versions du protocole, 3 niveaux sont possibles :

• /validate (CAS 1.0) ne donne que l’identifiant unique de l’utilisateur
• /serviceValidate (CAS 2.0) retourne optionnellement un ticket qui permettra à l’application d’obtenir des tickets pour s’authentifier auprès d’API (pour les cas d’usage de type OAuth 2)
• /p3/serviceValidate (CAS 3.0) reprendre CAS 2.0 et ajoute la récupération d’attributs d’identité sur l’utilisateur

Si CAS 1.0 retourne l’information dans un format propriétaire ressemblant à de l’HTML, l’application a le choix entre XML et JSON pour la réponse du serveur (en positionnant le paramètre format de la requête de validation).

 

CAS et la gestion de la déconnexion

CAS permet une déconnexion simplifiée via une simple requête /logout auprès du serveur, sans nécessairement de paramètre :

https://casserver.com/logout?service=https%3A%2F%2Fapplication.com

Le seul paramètre admis est une URL de retour :

• service pour rediriger l’utilisateur vers l’application après déconnexion

Cela permet de rediriger l’utilisateur après déconnexion, bien que certaines implémentations, comme Keycloak, ne gèrent pas toujours correctement ce paramètre.

 

CAS aujourd’hui : quelle utilité ?

Malgré son ancienneté, CAS reste utilisé dans certaines infrastructures qui n’ont pas encore migré vers OpenID Connect. Son intégration à Keycloak via une extension permet de maintenir la compatibilité avec des applications historiques tout en évoluant vers des solutions modernes.

Pour tester CAS, plusieurs options existent :

• Installer un serveur CAS Apereo (téléchargement ici : https://github.com/apereo/cas/releases)
• Utiliser l’extension CAS de Keycloak, compatible avec les versions récentes.

Si OpenID Connect est aujourd’hui le standard pour l’authentification fédérée, CAS reste une alternative viable dans certains contextes, notamment pour des applications nécessitant une transition progressive vers des solutions plus modernes.

 

Conclusion

CAS est un protocole d’authentification encore présent dans certaines infrastructures, notamment dans le secteur public. Bien qu’il soit plus limité que OpenID Connect, il répond toujours à certains besoins spécifiques, notamment en matière de simplicité et de compatibilité avec des applications existantes. Son intégration avec Keycloak permet d’assurer une transition progressive vers des solutions plus modernes, sans rupture brutale avec l’existant.

Pour les organisations disposant encore d’applications utilisant CAS, il est intéressant de considérer des scénarios de migration vers OpenID Connect tout en assurant la compatibilité avec les systèmes historiques.

 

Pour en savoir plus sur notre offre de service dédiée à la gestion des accès et aux solutions d’authentification, explorez notre page expertise.