Qu’est-ce que le protocole CAS (Central Authentication Service) ?
CAS, ou Central Authentication Service, est un protocole d’authentification unique (SSO) qui permet aux sites web d’authentifier les utilisateurs.
Les identifiants de connexion ne sont utilisés qu’une seule fois pour l’authentification auprès de multiples applications, sans jamais révéler le mot de passe sécurisé. L’application qui doit autoriser l’utilisateur redirige ce dernier vers un serveur centralisé approuvé, le serveur CAS.
Le protocole CAS permet d’authentifier des applications web non approuvées exigeant un ticket de service pour l’accès. CAS est un outil qui sert à authentifier un utilisateur, ce qui ne revient pas à autoriser ce dernier à accéder à une application. L’autorisation est propre à l’application concernée.
Après la configuration initiale, l’approche CAS peut être simple à gérer et à implémenter sur un vaste réseau d’ordinateurs. Elle offre aux utilisateurs commodité, cohérence ainsi qu’un niveau de sécurité élevé.
Fonctionnement de CAS
CAS peut fournir une solution d’authentification unique (SSO) pour plusieurs applications web afin d’offrir une expérience utilisateur plus fluide. Le serveur d’authentification centralisé, c.-à-d. le serveur CAS, représente une source fiable qui peut être utilisée à des fins d’authentification.
Le flux de protocole et d’authentification CAS s’organise comme suit :
- Un utilisateur tente d’accéder à une application web qui n’a pas encore été vérifiée. Il s’agit de la première tentative d’accès à une application CAS (une application qui utilise le service CAS).
- L’utilisateur est redirigé vers le serveur CAS.
- L’utilisateur saisit ensuite ses identifiants de connexion une seule fois sur le serveur CAS et ce dernier vérifie et confirme l’identité de l’utilisateur.
- Une fois l’utilisateur authentifié via le serveur CAS, un ticket de service est joint à l’URL.
- L’application envoie alors une demande au serveur CAS, validant le ticket de service. Si le ticket est valide, l’utilisateur est authentifié et renvoyé vers l’application.
Avec CAS, l’utilisateur ne doit pas répéter ce processus lorsqu’il bascule d’une application à une autre au cours d’une session d’authentification unique (SSO). Dès que l’utilisateur se connecte au système d’authentification centralisé, un cookie ou des données système sont générés pour indiquer un statut d’authentification sans devoir s’authentifier plusieurs fois au cours d’une même session.
Principaux composants de CAS
Le flux de protocole et d’authentification CAS comporte trois (ou quatre) parties.
- Navigateur web client : il s’agit du logiciel incorporé à l’application web qui utilise le service CAS.
- Application web : il s’agit de l’application requérant une authentification.
- Serveur CAS : ce composant autonome est utilisé pour authentifier les utilisateurs et octroyer l’accès aux applications web à l’aide du service CAS.
- Service backend : le protocole CAS peut également faire intervenir un serveur de base de données qui ne dispose pas de sa propre interface HTTP, mais peut néanmoins communiquer avec une application web.
CAS fait référence à un package logiciel qui utilise aussi le protocole CAS.
Utilisation de CAS sur votre site web
Pour intégrer des applications avec le protocole CAS, vous devez d’abord désigner votre serveur CAS. Tout utilisateur cherchant à s’authentifier auprès de ces applications doit disposer d’une connexion au serveur CAS. CAS peut être intégré à pratiquement toutes les applications web et prend en charge un large éventail de langages de programmation, dont Java, Python, PHP et PL/SQL.
Il existe aussi de nombreuses bibliothèques clients qui peuvent utiliser l’authentification CAS. Pour PHP, vous pouvez utiliser la bibliothèque phpCAS. Pour Python, qui inclut Flask et Django, la bibliothèque python-cas est optimale. Si vous utilisez un autre langage de programmation, vous pouvez lancer une recherche pour obtenir les bibliothèques existantes.
Open source, le protocole CAS est accessible au public. Pour plus de détails sur les modalités précises de fonctionnement et d’utilisation du protocole CAS, consultez cette page.
Authentification et autorisation informatiques
L’authentification et l’autorisation sont deux concepts différents.
Le protocole CAS se contente d’authentifier l’accès des utilisateurs aux applications web, mais ne sert pas aux autorisations. Lorsqu’un utilisateur se connecte au serveur CAS avec ses identifiants de connexion, le processus d’authentification CAS détermine l’identité de l’utilisateur, en consignant la personne qui se connecte, mais l’application ne « voit » pas directement le mot de passe et les informations de connexion.
Vous devez déterminer et configurer, dans le système, les utilisateurs qui disposent d’une autorisation d’accès et de privilèges au sein de l’application. Par exemple, vous pouvez définir des ID utilisateurs spécifiques qui disposent de privilèges « administrateur », ce qui leur accordera des droits en lecture et écriture sur des fichiers spécifiques. Il s’agit là d’une forme d’autorisation.
En résumé, le processus d’authentification vérifie l’identité d’un utilisateur, tandis que le processus d’autorisation vérifie le type d’accès aux données et les privilèges spécifiques dont l’utilisateur dispose. Votre système nécessite les deux mécanismes : l’authentification et l’autorisation. Le service CAS ne fournit que le composant d’authentification ; le processus d’autorisation doit être également implémenté sur une autre couche.
Avantages du protocole CAS
Le protocole CAS offre de nombreux avantages, dont les suivants :
- Commodité : les utilisateurs ne doivent se connecter qu’une seule fois au serveur CAS au cours d’une session pour accéder à plusieurs applications web sans devoir chaque fois se connecter ou se reconnecter.
- Cohérence : chaque utilisateur accède à la même page de connexion du serveur CAS.
- Procédure simplifiée pour les applications : les applications web ne doivent pas implémenter leurs propres processus et infrastructure d’authentification ni continuer à en inventer d’autres.
- Sécurité : les applications web n’ont pas accès aux identifiants de connexion, ni aux mots de passe.
Le protocole CAS peut être un peu plus long à configurer au départ, mais il offre une expérience utilisateur plus fluide. Il est également plus simple à gérer au fil du temps dès lors qu’il ne faut passer que par un seul serveur centralisé dans un système au lieu de devoir gérer des processus d’authentification dans chaque application web.
Vous ne devez pas intégrer des protocoles d’authentification dans chacune d’elles. Vous pouvez, au lieu de cela, gérer plusieurs applications web, dont les serveurs et les clients de messagerie web dans un seul emplacement centralisé et approuvé.
Points à retenir
Le protocole CAS est un service SSO open source qui permet aux utilisateurs de se connecter à un seul serveur approuvé une seule fois par session et d’avoir toujours la possibilité d’accéder à plusieurs applications sans constamment devoir se reconnecter. Les utilisateurs gagnent en rapidité, en productivité et bénéficient d’une expérience de meilleure qualité.
Le protocole nécessite la présence d’un serveur CAS centralisé et approuvé auquel tous les utilisateurs vont directement se connecter. Une fois ces derniers connectés, le système « se souvient » d’eux pour le reste de la session grâce à des cookies.
Lorsqu’un utilisateur tente d’accéder à une application web nécessitant une autorisation, il est initialement redirigé vers le serveur CAS pour autorisation. S’il est autorisé, un ticket de service est joint à l’URL. Lorsqu’il accède à une autre application web, l’autorisation est gérée au niveau du backend, sans que l’utilisateur doive intervenir.
Le protocole CAS renforce la sécurité dans la mesure où il dissimule les mots de passe aux applications web. Il est également pratique et convivial.
Références
Central Authentication Service. Microsoft Academic.
CAS Enterprise Single Sign-On. Apereo Foundation.
Python-cas/ Python-cas. 2021. GitHub, Inc.
Getting Started. Apereo Foundation.