Partager via

Le protocole d’accès Digest

  • Article

Le protocole Digest Access spécifié par RFC 2617 est implémenté par le fournisseur de support de sécurité (SSP) Microsoft Digest. L’implémentation se compose d’un ensemble de fonctions de contexte de sécurité SSPI ( Security Support Provider Interface) microsoft auxquelles les applications clientes/serveurs appellent :

L’authentification Digest Access s’effectue dans des transactions de demande/réponse jumelées, avec des demandes provenant du client et des réponses provenant du serveur. Une authentification Digest Access réussie nécessite deux paires demande/réponse.

Lorsque le fournisseur de services partagés 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 requête après avoir envoyé la première réponse.

L’illustration suivante montre les étapes effectuées sur le chemin HTTP par un client et un serveur pour effectuer une authentification à l’aide du fournisseur de services partagés Digest. Le mécanisme SASL utilise l’authentification mutuelle, de sorte que les données d’authentification sont renvoyées lors de l’appel final du serveur ASC au client qui vérifie que le client communique avec le serveur approprié.

digest access protocol

Le processus commence par le client qui demande une ressource protégée par accès à partir du serveur en envoyant la requête HTTP 1.

Le serveur reçoit la requête HTTP 1 et détermine que la ressource nécessite des informations d’authentification qui n’ont pas été incluses dans la requête. Le serveur génère un défi pour le client comme suit :

  1. Le serveur obtient ses informations d’identification en appelant la fonction AcquireCredentialsHandle .
  2. Le serveur génère la requête Digest en appelant la fonction AcceptSecurityContext (Général).
  3. Le serveur envoie un en-tête WWW-Authenticate en tant que réponse à la requête du client (sous la forme Http Response 1). L’en-tête contient le défi 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 status 401 qui indique que la demande du client a généré une erreur d’accès non autorisé. Pour plus d’informations sur le défi Digest, consultez Contenu d’un défi de synthèse et Génération du défi de synthèse.
  4. Le client reçoit la réponse HTTP 1, extrait le défi Digest envoyé par le serveur et génère une réponse de défi Digest comme suit :
    1. 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.
    2. Les informations de défi et d’informations d’identification sont transmises à la fonction InitializeSecurityContext (Général), qui génère la réponse au défi Digest.
  5. Le client envoie un en-tête d’autorisation qui contient la réponse de la demande au serveur (sous la forme Http Request 2). Pour plus d’informations sur la réponse au défi Digest, consultez Contenu d’une réponse au défi digest et Génération de la réponse au défi digest.
  6. Le serveur reçoit la requête HTTP 2, extrait la réponse de demande envoyée par le client et authentifie les informations en appelant la fonction AcceptSecurityContext (Général). Pour plus d’informations sur le processus d’authentification, consultez Authentification initiale à l’aide de Microsoft Digest.
  7. Le serveur renvoie la réponse HTTP 2 au client en tant que deuxième et dernière réponse requise par le protocole Digest Access. Si l’authentification réussit, cette réponse contient la ressource demandée.

Contenu d’une réponse de défi digest