Protocole d’accès Digest
Le protocole d’accès Digest spécifié par RFC 2617 est implémenté par le fournisseur SSP (Security support Provider ) Microsoft Digest. L’implémentation se compose d’un ensemble de fonctions de contexte de sécurité SSPI ( Microsoft Security Support Provider Interface ) que les applications client/serveur appellent pour :
- Établissez un contexte de sécurité pour l’échange de messages.
- Obtenir les objets de données requis par le SSP Digest, tels que les informations d’identification et les handles de contexte.
- Accédez aux mécanismes d' intégrité et de confidentialité des messages.
L’authentification d’accès Digest a lieu dans les transactions de demande/réponse jumelées, avec les demandes provenant du client et les réponses provenant du serveur. Une authentification Digest Access réussie requiert deux paires demande/réponse.
Lorsque le SSP Digest est utilisé pour l’authentification HTTP, aucune connexion n’est maintenue entre la première et la deuxième paire demande/réponse. En d’autres termes, le serveur n’attend pas la deuxième demande après l’envoi de la première réponse.
L’illustration suivante montre les étapes effectuées sur le chemin d’accès HTTP par un client et un serveur pour effectuer une authentification à l’aide du SSP Digest. Le mécanisme SASL utilise l’authentification mutuelle, de sorte que les données d’authentification sont renvoyées au dernier appel du serveur ASC au client, qui vérifie que le client communique avec le serveur approprié.

Le processus commence par le client qui demande une ressource protégée par l’accès au serveur en envoyant la requête HTTP 1.
Le serveur reçoit la requête HTTP 1 et détermine que la ressource requiert des informations d’authentification qui n’étaient pas incluses dans la demande. Le serveur génère une demande de test pour le client comme suit :
- Le serveur obtient ses informations d’identification en appelant la fonction AcquireCredentialsHandle .
- Le serveur génère la stimulation Digest en appelant la fonction AcceptSecurityContext (General) .
- Le serveur envoie un en-tête de WWW-Authenticate en tant que réponse à la demande du client (indiqué en tant que réponse HTTP 1). L’en-tête contient la stimulation Digest et une directive opaque qui contient une référence à un contexte de sécurité partiel établi pour le client. L’en-tête est envoyé avec un code d’état 401 qui indique que la demande du client a généré une erreur d’accès non autorisé. Pour plus d’informations sur la demande de résumé, consultez le contenu d’une demande de résumé et la génération de la demande de résumé.
- Le client reçoit une réponse HTTP 1, extrait la stimulation de synthèse envoyée par le serveur et génère une réponse de demande de résumé comme suit :
- Les informations d’identification de l’utilisateur sont obtenues en appelant la fonction AcquireCredentialsHandle ou en invitant l’utilisateur à entrer des informations d’identification de manière interactive.
- Les informations sur les informations d’identification et les informations d’identification sont transmises à la fonction InitializeSecurityContext (General) , qui génère la réponse de la stimulation de synthèse.
- Le client envoie un en-tête d’autorisation qui contient la réponse de stimulation au serveur (indiqué sous la forme HTTP request 2). Pour plus d’informations sur la réponse à la demande de synthèse, consultez le contenu d’une réponse de stimulation Digest et la génération de la réponse à la stimulation de synthèse.
- Le serveur reçoit la requête HTTP 2, extrait la réponse de stimulation envoyée par le client et authentifie les informations en appelant la fonction AcceptSecurityContext (General) . Pour plus d’informations sur le processus d’authentification, consultez authentification initiale à l’aide de Microsoft Digest.
- Le serveur envoie la réponse HTTP 2 au client en tant que deuxième et dernière réponse requise par le protocole d’accès Digest. Si l’authentification réussit, cette réponse contient la ressource demandée.