Un utilisateur ouvre une session dans le domaine Active Directory. Une fois connecté, il accède aux différents partages réseaux auxquels il a droit sur des serveurs différents sans se réauthentifier. Il peut même accéder à des sites web IIS ou des applications web asp.net qui utilisent l'authentification intégrée windows. C'est que l'on appelle le Single Sign On (SSO) ou authentification unique en français. L'utilisateur s'est authentifié une seule fois et son identité est transmise automatiquement aux différents serveurs et aux différentes applications sans que celui-ci ne s'en rende compte.

C'est extrêmement simple pour l'utilisateur, peut être magique pour un administrateur système. Dans le monde Microsoft le magicien s'appelle Active Directory (AD), pour les autres Kerberos. D'ailleurs AD peut être considéré comme la réunion de Kerberos et d'un annuaire accessible via le protocole LDAP.
En règle générale, une solution de SSO va un peu plus loin, il permet aussi le transfert de l'authentification à diverses, voire toutes, applications. Pour les applications qui ont leurs propres couples compte, mot de passe, il simule l'authentification en utilisant ce couple spécifique, comme peut le faire un navigateur web lorsqu'il enregistre le mot de passe. Ceci implique la notion de gestion et de sécurisation d'un portefeuille de comptes avec les mots de passe associés. Je ne connais que des solutions commerciales (evidian, illex, CA, etc.) qui permettent cela. En outre elles proposent aussi les briques nécessaires à une gestion des identités ou même mieux une gestion des identités et des accès (IAM : Identity and Access Management).

Si maintenant j'ai plusieurs application web, et tant qu'à faire, sur des machines différentes, et encore une couche, avec des systèmes d'exploitations différents. L'utilisateur devra s'authentifier pour chaque application. Et dans bien des cas chaque application aura sa propre base d'utilisateurs et de mots de passe. Je vous laisse imaginer la gymnastique pour synchroniser les mots de passe et/ou le nombre de « post-it » sur les écrans.

C'est l'objectif du webSSO, que je traduis par authentification unique pour le web. Le principe est d'avoir un système qui permet au voyageur cybernétique de s'authentifier une seule fois et qui transmet ensuite son identité aux différentes applications qu'il utilise uniquement dans un contexte web en utilisant uniquement les protocoles du web : http et https.
Bien entendu cette problématique adresse le monde de l'entreprise qui dispose d'applications web dans un intranet pour limiter la prolifération de comptes et de mots de passe. Pour que cela soit fonctionnel, il faut que les applications utilisent toutes le même identifiant et délèguent l'authentification au serveur d'authentification.

Il existe plusieurs solutions open source comme lemonldap, webauth qui font du webSSO. Mais nous utilisons JA-SIG CAS comme serveur d'authentification web.

Comme son nom l'indique JA-SIG CAS est une application web écrite en java qui permet de faire du webSSO suivant un principe qui est proche de Kerberos en utilisant un cookie de session. Le principe principal du protocole d'authentification est le suivant :

1. Un internaute accède à une ressource web.
2. Le navigateur est redirigé vers le serveur cas
3. Le serveur envoie le formulaire d'authentification
4. Réponse de l'internaute.
5. Le serveur vérifie le couple compte / mot de passe.
6. Le serveur CAS crée un cookie de session (TGC) et redirige le navigateur vers la ressource web avec un Service Ticket (ST) à utilisation unique
7. L'application valide le ST en contactant directement le serveur cas qui retourne l'identifiant de la personne.
8. L'internaute accède à la ressource demandée

Pour une information plus détaillée sur le protocole le mieux est de consulter le site du JA-SIG qui est en anglais. Le site du consortium Esup recèle aussi quelques pages sur le sujet en français. CAS est même cité dans la version française de wikipédia.

Maintenant il suffit de s'authentifier à la première connexion sur l'application web à l'aide du formulaire qui ressemble à l'image suivante : Lors du passage à une autre application, l'utilisateur est automatiquement authentifié par les redirections du navigateur. Bien entendu la session CAS est perdue quand le navigateur se ferme.