Authentification des formulaires

les
utilisateurs se verraient demander sans
cesse leurs références au fil de la navigation
sur le Web: il n’en est bien sûr
pas question !
Les références sont mises en cache
pendant que la session de navigation
(iexplore.exe, netscape.exe, par exemple)
existe. Et la session existe jusqu’à 
ce que toutes les fenêtres ouvertes durant
la session soient fermées. C’est
précisément là  qu’est la difficulté.
Soit un utilisateur qui utilise l’OWA
à  partir d’un kiosque public puis
s’éloigne. S’il n’a pas fermé toutes les
fenêtres du navigateur – opération
physiquement impossible sur certains
kiosques – n’importe qui peut utiliser
le navigateur pour rebrousser chemin
vers la boîte à  lettres de l’utilisateur,
sans entrer aucune référence. Comme
toute personne peut facilement oublier
de se déconnecter correctement,
l’authentification des formulaires s’impose.
Avant la version IE 6.0 SP1, il n’y
avait aucun moyen garanti d’effacer
par programmation le cache sans installer
un contrôle ActiveX sur le client.
L’OWA d’Exchange 2003 tire parti de la
fonctionnalité d’effacement de cache
de IE 6.0 SP1, qui vide automatiquement
le cache dès qu’un utilisateur
clique sur le bouton de déconnexion.
Tout se passe bien dans le cas où un administrateur
a la maîtrise des navigateurs
utilisés, comme dans un environnement
d’entreprise. Mais que faire
lorsque les administrateurs n’ont aucun
contrôle sur le navigateur utilisé,
comme dans des kiosques publics ?
L’authentification des formulaires
vise cette situation de kiosque public.
Elle inclut trois zones fonctionnelles
principales correspondant aux
failles inhérentes aux navigateurs de
kiosques.

• Quand l’authentification de formulaires
  est en place, les utilisateurs ne
  voient pas la fenêtre d’authentification
  d’un navigateur standard, donc
  ils ne peuvent pas sélectionner l’option
  Remember my password. Au
  lieu de cela, l’OWA présente un formulaire
  de connexion personnalisé
  chaque fois qu’un contrôle d’authentification
  est nécessaire.

• A condition que l’utilisateur clique
  sur le bouton de déconnexion, toute
  tentative ultérieure d’accéder à 
  l’OWA à  partir de la même session de
  navigation affichera le formulaire de
  connexion personnalisé.

• Bien entendu, si aucune activité utilisateur
  n’est constatée pendant une
  période prédéfinie, un mécanisme
  de timeout intervient : la prochaine
  action affichera le formulaire de
  connexion. Cette précaution est utile
  dans le cas où un utilisateur oublie
  de fermer entièrement le navigateur.

L’authentification de formulaires
donne de meilleurs résultats dans un contexte serveur front-end/back-end.
Bien que l’on puisse utiliser la fonction
directement vis-à -vis d’un serveur
back-end, un utilisateur pourrait être
redirigé vers la page de connexion s’il
consulte des dossiers publics dont le
contenu se trouve sur un serveur différent
de celui qui héberge la boîte à 
lettres de l’utilisateur. Je suis en train
de travailler sur un article approfondi
sur l’authentification de formulaires. Je
n’entre pas ici dans les détails du mécanisme
sous-jacent.
Sur la page de connexion, les utilisateurs
peuvent choisir le type de
client (premium ou basic) qu’ils veulent
utiliser et s’ils utilisent un dispositif
public (café Internet, par exemple)
ou un privé (ordinateur personnel, par
exemple). Le choix entre public et
privé détermine la durée du timeout
d’inactivité. Logiquement, la période
d’inactivité est plus courte pour le
dispositif public que pour le privé.