RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS
HTTP propose un mécanisme simple de "modèle-accréditif" pour permettre à un serveur de fournir un modèle d'identification et d'authentification à un client, et à un client de s'authentifier pour une requête particulière. Ce mécanisme utilise un système de noms extensible et indépendant de la casse, dans le but d'identifier le schéma d'authentification, suivie d'une liste de paires "attribut/valeur" séparées par des virgules, destinées à transmettre les paramètres nécessaires pour achever l'authentification.
Scheme-auth = nom_de_scheme
param-auth = nom_param "=" chaîne entre guillemets
Le message de réponse 401 (non autorisé) est utilisé par un serveur origine pour soumettre le "modèle" d'authentification à un client. Cette réponse doit comporter un champ d'en-tête WWW-Authenticate proposant au moins un modèle valide pour la ressource à atteindre.
Modèle = scheme-auth 1*SP domaine_valide *( "," param_auth )
domaine_valide = "realm" "=" espace_domaine
espace-domaine = chaîne entre guillemets
L'attribut de domaine (indépendant de la casse) est requis dans tous les schèmes d'authentification qui soumettent un modèle. L'espace de domaine (indépendant de la casse), combiné à l'URL canonique du serveur origine, définit l'espace protégé. Cette technique permet de partitionner un serveur protégé en plusieurs sous ensembles, protégés individuellement, chacun avec leur propre modèle et leurs propres paramètres d'autorisation liées ou non à une base de donnée d'authentification. Le domaine accessible est exprimé sous forme de chaîne de caractères, en général donnée par le serveur origine, avec éventuellement une sémantique supplémentaire dépendant du modèle d'authentification.
Un utilisateur désireux de s'authentifier auprès d'un serveur - en général, mais pas nécessairement, après avoir reçu une réponse 401-peut le faire en spécifiant un champ Authorization dans l'en-tête de sa requête. La valeur dans le champ Authorization consiste contient l'accréditif nécessaire à l'accès au domaine autorisé pour la ressource visée.
accréditif = accréditif_de_base | ( modèle_authentification#paramètres )
Le domaine accessible par un utilisateur utilisant cet accréditif est déterminé par les données de protection du serveur. Si une requête précédente à abouti à une autorisation d'accès, le même accréditif donnera accès au même domaine accessible durant un temps déterminé par le le modèle d'authentification, ses paramètres, et/ou les préférences utilisateur. Sauf mention explicite dans le modèle, un espace protégé ne peut sortir du cadre du serveur qui le gère.
Si le serveur refuse l'accès à une requête, il délivrera en retour une réponse 403 (accès interdit).
Le protocole HTTP n'exclut pas l'utilisation de schémas de protection additionnels, venant compléter ou remplacer le paradigme "modèle-accréditif". D'autres mécanismes, tels que le cryptage au niveau "transport" ou l'encapsulation de messages, peuvent être utilisés avec des champs d'en-tête additionnels véhiculant les informations d'authentification. Ces mécanismes ne sont toutefois pas décrits dans cette spécification.
Les proxies doivent être complètement transparents vis à vis du mécanisme d'authentification. C'est à dire qu'ils doivent retransmettre les champs WWW-Authenticate et Authorization tels que, et ne doivent pas enregistrer une réponse à un message contenant le champ Authorization dans leur cache. HTTP/1.0 ne fournit aucun moyen à un client de s'identifier vis à vis d'un proxy.
Le modèle dit "de base" demande à un utilisateur de s'authentifier par un user-ID et un mot de passe pour chaque "domaine d'accès". La donnée d'authentification doit représenter comme une chaîne non visible, pouvant seulement être comparée à d'autres accréditifs de référence par le serveur concerné. Le serveur n'autorisera l'accès que si et l'user-ID, et le mot de passe correspondent à un schème d'authentification défini pour le domaine auquel appartient l'URI-visée. Il n'y a pas de paramètres optionnels pour ce modèle.
Sur toute réception d'une requête non autorisée visant une URI dans l'espace protégé, le serveur doit renvoyer une demande d'identification de forme:
dans laquelle "WallyWorld" est le nom symbolique de l'espace contenant l'URI-visée, attribué par le serveur.
Pour obtenir l'autorisation d'accès, le client enverra l'user-ID et le mot de passe, séparatés par un "deux-points" (":"), le tout encodé en base64 [5].
Accréditif_de_base = "Basic" SP cookie-basique
cookie-basique = ["userID-mot_de_passe" encodé base64 [5],
limité à 76 char/line]
userID-mot_de_passe = [ nom_ID ] ":" *TEXT
Si le client voulait utiliser l'user-ID "Aladdin" et le mot de passe "open sesame", il spécifierait le champ ainsi:
Le modèle de base ci-défini est une méthode non sécurisée de filtrage d'accès à des ressources données sur un serveur HTTP. Il suppose en effet que la connexion entre l'utilisateur et le serveur est un lien digne de confiance. Ceci n'est pas le cas sur des réseaux ouverts, et ce modèle doit être utilisé en connaissance de cause. Malgré cette faiblesse, les clients devront implémenter ce modèle afin de pouvoir communiquer avec les serveurs qui l'utilisent.