Authentification par formulaires dans l’OWA 2003

L’OWA est une application de type Web qui utilise HTTP pour permettre aux navigateurs
clients de communiquer avec Exchange. L’OWA encapsule les requêtes
et les réponses dans des messages HTTP, lesquels, dans leur forme la plus simple,
comportent trois parties : le type de requête ou de réponse, les lecteurs hôtes qui
qualifient la requête ou la réponse, et le corps du message. D’après la réponse
qu’il reçoit du serveur, le navigateur agit en conséquence : en affichant le corps
du message, en le redirigeant vers une URL différente, ou en demandant des références
à  l’utilisateur.
HTTP est un protocole sans état
qui demande que chaque requête
contienne les références utilisateur
sous la forme d’un en-tête d’hôte d’authentification.
Le format de cet en-tête
dépendra des genres d’authentification
(Anonymous, Basic, Digest, Windows
Integrated Authentication,
Microsoft .NET Passport, par exemple)
que l’application de type Web accepte.
Les étapes suivantes représentent un
dialogue d’authentification Basic simple entre un navigateur client et une application
Web (comme l’OWA) tournant sur Microsoft IIS.
1. Quand un utilisateur entre une URL dans le navigateur, celui-ci envoie un message
HTTP demandant une page Web au serveur. A ce stade, le message HTTP
n’a pas d’en-tête d’hôte d’authentification.
2. Le serveur renvoie un message d’erreur 401 Access Denied
et envoie un message de réponse HTTP informant le navigateur
des méthodes d’authentification que l’application
supporte (dans ce cas, authentification Basic).
3. Le navigateur réagit au défi d’authentification Basic en présentant
à  l’utilisateur une boîte de dialogue Logon demandant
le nom de l’utilisateur, le mot de passe et le domaine.
4. Le navigateur utilise base64 pour coder ces détails, les
ajoute comme un en-tête d’hôte d’authentification à  la requête
HTTP originale puis renvoie la requête.
5. Le serveur vérifie la validité des références. Si elles sont
bonnes, il renvoie la page Web demandée ; dans le cas
contraire, il renvoie un autre message 401 Access Denied.
6. Le navigateur met les références en cache et les ajoute aux
requêtes HTTP suivantes selon le cas, pour éviter de demander
des références à  l’utilisateur à  chaque requête.
L’étape 6 est nécessaire pour la viabilité des applications
Web. En effet, aucun utilisateur n’est prêt à  fournir continuellement
des références pour chaque requête HTTP.
Cependant, la mise en cache des références affaiblit un peu
la sécurité, parce que le navigateur met les
références en cache pendant tout le temps
où la session navigateur reste ouverte. Cet
état de chose signifie qu’un utilisateur doit
fermer chaque fenêtre qu’il a ouverte à  partir
de la session navigateur originale avant
que les références mises en cache ne
soient effacées.
Egalement, à  l’étape 3, les utilisateurs
peuvent cocher une case pour se souvenir
de leur mot de passe afin que quand la
page de logon suivante apparaît, le champ mot de passe soit
déjà  renseigné. Certes commode pour l’utilisateur final,
cette possibilité n’est pas sans danger.
Finis les jours où l’on accédait à  l’information à  partir
d’un PC desktop verrouillé. Aujourd’hui, les travailleurs nomades
utilisent une multitude d’appareils dans une foule
d’endroits. Ainsi, les utilisateurs qui laissent le navigateur actif
avec des références en cache sont à  la merci d’utilisateurs
indiscrets. C’est pourquoi, certains emplacements, comme
les kiosques publics, ne permettent pas aux utilisateurs de
fermer la session navigateur.