Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’authentification est le processus d’identification de l’identité du client, généralement pour déterminer si le client est éligible à l’accès à une ressource. Le protocole HTTP prend en charge l’authentification comme moyen de négocier l’accès à une ressource sécurisée.
La requête initiale d’un client est généralement une requête anonyme, qui ne contient aucune information d’authentification. Les applications serveur HTTP peuvent refuser la demande anonyme tout en indiquant que l’authentification est requise. L'application serveur envoie des en-têtes WWW-Authentication pour indiquer les schémas d'authentification pris en charge. Cet article décrit plusieurs schémas d’authentification pour HTTP et décrit leur prise en charge dans Windows Communication Foundation (WCF).
Schémas d’authentification HTTP
Le serveur peut spécifier plusieurs schémas d’authentification pour le client à choisir. Le tableau suivant décrit certains des schémas d’authentification couramment trouvés dans les applications Windows :
| Schéma d’authentification | Descriptif |
|---|---|
| Anonyme | Une demande anonyme ne contient aucune information d’authentification. Anonyme équivaut à accorder à tout le monde l’accès à la ressource. |
| Élémentaire | L’authentification de base envoie une chaîne encodée en Base64 qui contient un nom d’utilisateur et un mot de passe pour le client. Base64 n’est pas une forme de chiffrement et doit être considéré comme identique à l’envoi du nom d’utilisateur et du mot de passe en texte clair. Si une ressource doit être protégée, envisagez fortement d’utiliser un schéma d’authentification autre que l’authentification de base. |
| Résumé | L’authentification Digest est un schéma de réponse aux défis destiné à remplacer l’authentification de base. Le serveur envoie une chaîne de données aléatoires appelée nonce au client en tant que défi. Le client répond avec un hachage qui inclut le nom d'utilisateur, le mot de passe et la valeur à usage unique entre autres informations. La complexité de cet échange introduit et le hachage de données rendent plus difficile le vol et la réutilisation des informations d’identification de l’utilisateur avec ce schéma d’authentification. L’authentification Digest nécessite l’utilisation de comptes de domaine Windows. Le domaine digest correspond au nom de domaine Windows. Par conséquent, vous ne pouvez pas utiliser un serveur s’exécutant sur un système d’exploitation qui ne prend pas en charge les domaines Windows, tels que Windows XP Home Edition, avec l’authentification Digest. À l’inverse, lorsque le client s’exécute sur un système d’exploitation qui ne prend pas en charge les domaines Windows, un compte de domaine doit être spécifié explicitement pendant l’authentification. |
| NTLM | L’authentification NT LAN Manager (NTLM) est un schéma de réponse aux défis qui est une variante plus sécurisée de l’authentification Digest. NTLM utilise les informations d’identification Windows pour transformer les données de défi au lieu du nom d’utilisateur et du mot de passe non codés. L’authentification NTLM nécessite plusieurs échanges entre le client et le serveur. Le serveur et tous les proxys intermédiaires doivent prendre en charge les connexions persistantes pour terminer l’authentification. |
| Négocier | L'authentification par négociation choisit automatiquement entre le protocole Kerberos et authentification NTLM, selon la disponibilité. Le protocole Kerberos est utilisé s’il est disponible ; sinon, NTLM est essayé. L’authentification Kerberos s’améliore considérablement sur NTLM. L’authentification Kerberos est à la fois plus rapide que NTLM et permet l’utilisation de l’authentification mutuelle et de la délégation d’informations d’identification sur des machines distantes. |
| Windows Live ID | Le service HTTP Windows sous-jacent inclut l’authentification à l’aide de protocoles fédérés. Toutefois, les transports HTTP standard dans WCF ne prennent pas en charge l’utilisation de schémas d’authentification fédérés, tels que Microsoft Windows Live ID. La prise en charge de cette fonctionnalité est actuellement disponible à l’aide de la sécurité des messages. Pour plus d’informations, consultez Fédération et Jetons émis. |
Choisir un schéma d’authentification
Lorsque vous sélectionnez les schémas d’authentification potentiels pour un serveur HTTP, quelques éléments à prendre en compte sont les suivants :
Déterminez si la ressource doit être protégée. L’utilisation de l’authentification HTTP nécessite la transmission de données supplémentaires et peut limiter l’interopérabilité avec les clients. Autorisez l’accès anonyme aux ressources qui n’ont pas besoin d’être protégées.
Si la ressource doit être protégée, tenez compte des schémas d’authentification qui fournissent le niveau de sécurité requis. Le schéma d’authentification standard le plus faible discuté ici est l’authentification de base. L’authentification de base ne protège pas les informations d’identification de l’utilisateur. Le schéma d’authentification standard le plus fort est l’authentification Negotiate, ce qui entraîne le protocole Kerberos.
Un serveur ne doit pas présenter, par exemple, dans les en-têtes WWW-Authentication), tout schéma qu’il n’est pas prêt à accepter ou qui ne sécurise pas correctement la ressource protégée. Les clients sont libres de choisir entre l’un des schémas d’authentification présentés par le serveur. Certains clients ont par défaut un schéma d’authentification faible ou le premier schéma d’authentification dans la liste du serveur.