Flux des opérations

L’extension ISAPI utilise une clé symétrique
immuable pour crypter les données associées au cookie. Le
serveur frontal tente de décrypter le cookie avec la clé courante,
d’extraire les références et de les
rattacher à  l’en-tête d’authentification
du message. Tout échec dans le décryptage
du cookie (par exemple, si la
clé a changé, indiquant un timeout) ou
la non-existence du cookie, redirige la
demande entrante vers la page de logon.
A noter que tout le traitement associé
à  la génération des clés symétriques,
au traitement des cookies et au
cryptage/décryptage s’effectue sur le serveur que vous avez
validé pour l’authentification par formulaires. Par conséquent,
dans une mise en oeuvre classique, seul le serveur
frontal exécute ces tâches. Le serveur d’arrière plan n’a aucune
idée de ce qui se passe sur le frontal et ne voit que les
requêtes authentifiées habituelles que le serveur frontal
transmet par proxy.
Pour illustrer ce flux d’opérations et comment les divers
composants travaillent ensemble, examinons deux scénarios
de logon. Par souci de simplicité, supposons la présence
d’un serveur frontal appelé FE et d’un serveur d’arrière plan
appelé BE.
Scénario 1. Dans le premier scénario, l’utilisateur entre
https://fe/exchange dans le champ Address du navigateur
pour la première fois.
1. Le filtre ISAPI intercepte la requête et détermine si un
cookie est attaché ; dans le cas présent, il n’y a pas de cookie.
2. Le filtre laisse la requête passer non modifiée, et le serveur
frontal Exchange traite la requête.
3. Le filtre intercepte la réponse en provenance d’Exchange
et vérifie la présence d’un message 401 Access Denied.
Dans ce cas, la réponse contient ce message parce que la
requête initiale n’avait pas d’en-tête d’hôte d’authentification.
4. Le filtre change la réponse en un message 302 Moved
Temporarily qui spécifie http://fe/exchweb/ bin/auth/owalogon.
asp?url=https://fe/exchange comme nouvel emplacement.
5. Le client envoie une deuxième fois la requête à  cette URL.
A ce stade, aucune référence n’est nécessaire pour accéder
à  cette URL parce que le répertoire virtuel auth est validé
pour l’accès Anonymous. Owalogon.asp extrait l’entête
Accept-Language des requêtes entrantes et transfère
l’exécution à  logon.asp dans le dossier approprié, et le
navigateur affiche le formulaire de logon HTML. Sur le
formulaire, deux boutons radio permettent à  l’utilisateur
de choisir premium ou basic. Comme le filtre ISAPI peut
ajuster les en-têtes d’hôtes, il peut rétrograder l’en-tête
User-Agent au client basic.
6. L’utilisateur remplit le formulaire et le navigateur effectue un POST vers l’extension ISAPI DLL
sur le serveur frontal (c’est-à -dire,
\exchsrvr\exchweb\bin\auth\owaau
th.dll) mettant les données du formulaire
dans le corps du message.
Ces données incluent le nom de
l’utilisateur, le mot de passe et
l’URL originale que l’utilisateur a
demandée.
7. L’extension crée un cookie, génère
un coding base64 des références
utilisateur et utilise CryptoAPI pour
crypter les données avec la clé symétrique
courante. L’extension ordonne
ensuite au navigateur d’attacher
ce cookie (au moyen d’un
en-tête Set-Cookie) à  toutes les requêtes
HTTP dans la même session
et renvoie un message 302 Moved
Temporarily au navigateur, spécifiant
l’URL originale comme le nouvel
emplacement. Le navigateur accède
ensuite à  l’URL originale.
8. Nous voici revenus à  l’étape 1, à 
cela près que la requête HTTP a un
cookie contenant une version cryptée
des références codées en
base64. Mais la requête n’a pas encore
d’en-tête d’authentification
valide.
9. Le filtre ISAPI intercepte à  nouveau
la requête et trouve le cookie.
10. Le filtre décrypte le cookie avec la
clé symétrique et extrait les références
codées en base64, que le
filtre ajoute à  la requête comme un
en-tête d’authentification avant de
laisser la requête passer vers le serveur
frontal d’Exchange.
11. Exchange traite la requête qui, à  ce
stade, ressemble à  une requête
classique formatée pour une authentification
Basic valide. Mais la
différence est que l’utilisateur n’a
jamais vu la boîte de dialogue de logon
standard que le navigateur présente
quand un serveur défie un
navigateur d’utiliser l’authentification
Basic.

Le prochain scénario illustre ce
qu’il advient quand un utilisateur n’effectue
aucune opération dans un
certain laps de temps. L’opération suivante
que l’utilisateur essaie d’effectuer
présentera la page de logon. Avant
que j’explique comment cela se produit,
il est important de noter que le
serveur frontal garde la connaissance
de trois clés symétriques – la clé courante
et les deux clés précédentes. En
fait, il y a deux jeux de ces trois clés –
un jeu pour l’accès Public et un jeu
pour l’accès Trusted. Il y a deux jeux
pour pouvoir fournir différents timeouts
pour accéder à  l’OWA par l’intermédiaire
d’un ordinateur public (un
kiosque, par exemple) et à  partir d’un
lieu privé comme un bureau à  domicile.
On peut contrôler les valeurs de timeout
désirées en modifiant les valeurs
REG_DWord PublicClientTime-
Out et TrustedClientTimeOut dans le
sous-clé de registre HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Se
rvices\MsExchangeWeb\OWA sur le
serveur frontal. Ces valeurs sont exprimées
en minutes, avec un timeout par
défaut de 15 minutes pour un client
public et 1 440 minutes (24 heures)
pour un client privé.
Le serveur régénère une clé symétrique
à  une fréquence de la moitié de
la valeur de timeout désirée. Par conséquent,
le timeout réel se produira
entre 1 fois et 1,5 fois la valeur de timeout
désirée. Exemple : supposons
que vous établissiez une valeur de timeout
de 30 minutes. Toutes les 15 minutes,
le serveur génèrera une nouvelle
clé et, par conséquent, une clé
existera sur le serveur pour un maximum
de 45 minutes.
Quand le filtre ISAPI crée le cookie
(voir scénario 1, étape 7) et lui ajoute
les références base64 cryptées, le filtre
ajoute aussi le numéro de clé courante
et l’ID de session. Nous voyons cela
dans l’en-tête de cookie que montre la
figure 4. Cet en-tête revient d’une trace
de réseau pour l’étape 7.
La chaîne cadata commence par le
numéro d’index de la clé qui a été utilisée
pour le cryptage et sera une valeur
de 0, 1 ou 2. Une valeur de 2 indique la
clé courante. Dans l’exemple de la figure
4, la valeur 1 signifie que la clé
précédente a été utilisée. Etudions le
scénario suivant pour voir comment
les timeouts fonctionnent.
Scénario 2. Dans le second scénario,
un utilisateur reste inactif au-delà 
de la période de timeout puis essaie
d’ouvrir le dossier Calendar. Cette action
génère une requête HTTP vers le
serveur pour https://fe/exchange/user/
calendar?cmd=contents.
1. Le filtre ISAPI intercepte la requête
et détermine si un cookie est attaché.
Dans ce cas, la requête a un cookie.
2. Le filtre extrait du cookie le numéro
d’index de la clé symétrique utilisée
pour crypter les données. A noter
que ce n’est pas la vraie clé symétrique,
simplement le numéro d’index
de la clé.
3. Le filtre extrait la clé courante associée
à  ce numéro d’index et l’utilise
pour décrypter les données.
Rappelons que le serveur maintient
trois clés et en génère une nouvelle
après chaque intervalle de clé. Ainsi,
les clés associées à  chaque position
d’index changent aussi.
4. Dans ce cas, le décryptage échoue
parce que la clé qui est associée à  la
position d’index n’est plus la même
que celle qui se trouvait là  quand le
cryptage s’est produit pour la première
fois.
5. Le filtre ISAPI élimine le cookie et
passe la requête HTTP au serveur
Exchange.
6. Nous sommes maintenant dans la
même situation qu’au scénario 1,
étape 1.
Les deux scénarios que nous venons
de voir vous permettront de comprendre
le processus d’authentification
et comment la technologie par
formulaires peut aider à  formuler ce
processus. N’oubliez pas de lire l’encadré
« Forms-Based Authentication:
Problems and Points Worth Noting »
(http://www.itpro.fr Club abonnés)
pour déjouer quelques pièges lors du
déploiement de cette technologie
dans votre environnement.