Partager via

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é Microsoft Digest (SSP). L’implémentation se compose d’un ensemble de fonctions de contexte de sécurité (SSPI) de l’interface du support microsoft auxquelles les applications clientes/serveurs appellent :

  • Établissez un contexte de sécurité pour l’échange de messages.
  • Obtenez des objets de données requis par le SSP Digest, tels que les informations d’identification et les handles de contexte.
  • Accéder au message des mécanismes d’intégrité et de confidentialité.

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

Lorsque le SSP Digest est utilisé pour l’authentification HTTP, aucune connexion n’est conservée entre la première et la deuxième paire de requêtes/réponses. En d’autres termes, le serveur n’attend pas la deuxième requête après l’envoi de 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 SSP Digest. Le mécanisme SASL utilise l’authentification mutuelle, de sorte que les données d’authentification sont renvoyées sur l’appel final du serveur ASC au client qui vérifie que le client communique avec le serveur approprié.

protocole d’accès digest

Le processus commence par le client demandant 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 le défi Digest en appelant la fonctionAcceptSecurityContext (Général).
  3. Le serveur envoie un en-tête WWW-Authenticate en tant que réponse à la requête du client (indiqué en tant que réponse HTTP 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 d’état 401 qui indique que la demande du client a généré une erreur d’accès non autorisée. Pour plus d’informations sur le défi Digest, consultez Contenu d’un défi Digest et Génération du défi digest.
  4. Le client reçoit http Response 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 fonctionInitializeSecurityContext (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 défi au serveur (indiqué comme requête HTTP 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 défi 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 au défi digest