Appendix E. Guidance for Clients Desiring to Authenticate (Conseils pour les clients souhaitant s'authentifier)

Annexe E. Guidance for Clients Desiring to Authenticate (Conseils pour les clients souhaitant s'authentifier)

De nombreux clients WebDAV qui ont déjà été implémentés ont des paramètres de compte (similaires à la façon dont les clients de messagerie stockent les paramètres de compte IMAP). Ainsi, le client WebDAV serait capable de s'authentifier avec ses premières requêtes au serveur, à condition qu'il ait un moyen d'obtenir le défi d'authentification du serveur avec le nom de royaume, le nonce et d'autres informations de défi. Notez que les résultats de certaines requêtes peuvent varier selon que le client est authentifié ou non -- un PROPFIND pourrait renvoyer plus de ressources visibles si le client est authentifié, mais ne pas échouer si le client est anonyme.

Il existe plusieurs façons pour le client de déclencher le serveur pour fournir un défi d'authentification. Cette annexe décrit quelques approches qui semblent particulièrement susceptibles de fonctionner.

La première approche consiste à effectuer une requête qui devrait nécessiter une authentification. Cependant, il est possible qu'un serveur puisse traiter n'importe quelle requête même sans authentification, donc pour être entièrement sûr, le client pourrait ajouter un en-tête conditionnel pour s'assurer que même si la requête passe les vérifications de permissions, elle n'est pas réellement traitée par le serveur. Un exemple de suivi de cette approche serait d'utiliser une requête PUT avec un en-tête "If-Match" avec une valeur ETag inventée. Cette approche pourrait ne pas aboutir à un défi d'authentification si le serveur ne teste pas l'autorisation avant de tester les conditionnels comme requis (voir Section 8.5), ou si le serveur n'a pas besoin de tester l'autorisation.

Exemple - forcer le défi d'authentification avec une requête d'écriture

>>Request

  PUT /forceauth.txt HTTP/1.1
  Host: www.example.com
  If-Match: "xxx"
  Content-Type: text/plain
  Content-Length: 0

La deuxième approche consiste à utiliser un en-tête Authorization (défini dans [RFC2617]), qui est susceptible d'être rejeté par le serveur mais qui déclenchera ensuite un défi d'authentification approprié. Par exemple, le client pourrait commencer par une requête PROPFIND contenant un en-tête Authorization contenant une chaîne userid:password Basic inventée ou avec des informations d'identification réelles plausibles. Cette approche repose sur le serveur répondant avec un "401 Unauthorized" accompagné d'un défi s'il reçoit un en-tête Authorization avec un nom d'utilisateur non reconnu, un mot de passe invalide, ou s'il ne gère même pas l'authentification Basic. Cela semble susceptible de fonctionner en raison des exigences de RFC 2617:

"Si le serveur d'origine ne souhaite pas accepter les informations d'identification envoyées avec une requête, il DEVRAIT renvoyer une réponse 401 (Unauthorized). La réponse DOIT inclure un champ d'en-tête WWW-Authenticate contenant au moins un défi (éventuellement nouveau) applicable à la ressource demandée."

Il y a un léger problème avec l'implémentation de cette recommandation dans certains cas, car certains serveurs n'ont même pas d'informations de défi pour certaines ressources. Ainsi, lorsqu'il n'y a aucun moyen de s'authentifier auprès d'une ressource ou que la ressource est entièrement disponible publiquement sur toutes les méthodes acceptées, le serveur PEUT ignorer l'en-tête Authorization, et le client réessaiera probablement plus tard.

Exemple - forcer le défi d'authentification avec l'en-tête Authorization

>>Request

  PROPFIND /docs/ HTTP/1.1
  Host: www.example.com
  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  Content-type: application/xml; charset="utf-8"
  Content-Length: xxxx

  [body omitted]