Les techniques d’authentification

Les techniques d’authentification

CAS(Central Authentification Service) 

Définition 

Développé par l’Université de Yale, CAS (Central Authentication Service) met en œuvre un serveur d’authentification accessible, CAS est une architecture pour implémenter un système d’authentification unique (SSO) en s’appuyant sur des systèmes d’authentification tiers comme LDAP, Active Directory, une base SQL, etc. L’architecture est générique et ne dépend pas du système d’authentification choisi.

Le mécanisme d’Architecture CAS 

Le serveur CAS L’authentification est centralisée sur une machine unique, le serveur CAS. Ce serveur est le seul acteur du mécanisme CAS à avoir connaissance des mots de passe des utilisateurs. Son rôle est double : – authentifier les utilisateurs ; – transmettre et certifier l’identité de la personne authentifiée (aux clients CAS). Les navigateurs (web) Les navigateurs doivent satisfaire les contraintes suivantes pour bénéficier de tout le confort de CAS : – disposer d’un moteur de chiffrement leur permettant d’utiliser le protocole HTTPS. – savoir effectuer des redirections HTTP(accéder à une page donnée dans un entête Location lors d’une réponse 30x à une première requête HTTP) et interpréter le langage JavaScript. – savoir stocker des cookies. En particulier, les cookies privés ne devront être retransmis qu’au serveur les ayant émis pour garantir la sécurité du mécanisme CAS. Ces exigences sont satisfaites par tous les navigateurs classiquement utilisés, à savoir Microsoft Internet Explorer (depuis 5.0), Netscape Navigator (depuis 4.7) et Mozilla.

Les clients CAS 

Une application web muni d’une librairie cliente ou un serveur web utilisant le module mod_cas est alors appelé « client CAS ». Il ne délivre les ressources qu’après s’être assuré que le navigateur qui l’accède se soit authentifié auprès du serveur CAS. Parmi les clients CAS, on trouve : – des librairies correspondant aux langages communément employés en programmation web dynamique (Perl, Java, JSP,PHP, ASP) . – un module Apache, qui permet de protéger des documents statiques. – un module PAM, qui permet d’authentifier les utilisateurs au niveau système.

Authentification d’un utilisateur

 Un utilisateur non déjà précédemment authentifié, ou dont l’authentification a expiré, et qui accède au serveur CAS se voit proposer un formulaire d’authentification, dans lequel il est invité à entrer son nom de connexion et son mot de passe : Si les informations sont correctes, le serveur renvoie au navigateur un cookie appelé TGC (Ticket Granting Cookie) Le Ticket Granting Cookie (TGC) : est le passeport de l’utilisateur auprès du serveur CAS. Le TGC, à durée de vie limitée (typiquement quelques heures), est le moyen pour les navigateurs d’obtenir auprès du serveur CAS des tickets pour les clients CAS sans avoir à se ré-authentifier. C’est un cookie privé (n’est jamais transmis à d’autres serveurs que le serveur CAS) et protégé (toutes les requêtes des navigateurs vers le serveur CAS se font sous HTTPS). Comme tous les tickets utilisés dans le mécanisme CAS, il est opaque (ne contient aucune information sur l’utilisateur authentifié) : c’est un identifiant de session entre le navigateur et le serveur CAS

L’authentification unifiée 

Le concept d’authentification unifiée c’est le concept qu’on a utilisé dans notre mémoire se compose d’un annuaire LDAP qui est un référence fournissent un référentiel d’informations sur les autre plateformes. Le référentiel central utilisé pour les données LDAP qui est connecté et bien configurer avec le serveur de messagerie Zimbra et les plateformes Dokeos et Joomla , cette authentification va se concentrer beaucoup sur le travail du serveur LDAP qui regroupe tous les comptes des utilisateurs dans un seul annuaire , avec ce dernier l’utilisateur doit s’authentifier et accéder au plateformes , donc c’est une authentification unifiée qui unifier ces plateformes Zimbra , Joomla (CMS), Dokeos (LMS) .