2.4. Processing Rules (Règles de traitement)

2.4. Processing Rules (Règles de traitement)

Cette section décrit les règles de traitement applicables pour un TTRP qui a négocié une connexion TLS mutuellement authentifiée pour transmettre le certificat client de cette connexion aux serveurs d'origine backend. Cette technique doit être utilisée comme option de configuration ou de déploiement, et les règles de traitement décrites ici concernent les serveurs fonctionnant avec cette option activée.

Un TTRP négocie l'utilisation d'une connexion TLS mutuellement authentifiée avec le client, comme décrit dans [TLS] ou [TLS1.2], et valide le certificat client selon sa politique et ses autorités de certification de confiance. Chaque requête HTTP sur la connexion TLS sous-jacente est distribuée au serveur d'origine avec les modifications suivantes:

1. Le certificat client est placé dans le champ d'en-tête Client-Cert de la requête distribuée, comme décrit dans la Section 2.2.

2. Si configuré ainsi, la chaîne de validation du certificat client est placée dans le champ d'en-tête Client-Cert-Chain de la requête, comme décrit dans la Section 2.3.

3. Toute occurrence des champs d'en-tête Client-Cert ou Client-Cert-Chain dans la requête entrante d'origine DOIT être supprimée ou écrasée avant de transmettre la requête. Une requête entrante qui possède un champ d'en-tête Client-Cert ou Client-Cert-Chain PEUT être rejetée avec une réponse HTTP 400.

Les requêtes au TTRP effectuées sur une connexion TLS où l'utilisation de l'authentification par certificat client n'a pas été négociée DOIVENT être nettoyées en supprimant toutes les occurrences des champs d'en-tête Client-Cert et Client-Cert-Chain avant de distribuer la requête au serveur backend.

Les serveurs d'origine backend peuvent ensuite utiliser le champ d'en-tête Client-Cert de la requête pour déterminer si la connexion du client au TTRP a été mutuellement authentifiée et, si c'est le cas, le certificat ainsi présenté par le client. Les décisions de contrôle d'accès basées sur le certificat client (ou son absence) peuvent être transmises en sélectionnant le contenu de la réponse de manière appropriée ou avec une réponse HTTP 403, si le certificat est jugé inacceptable pour le contexte donné. Notez que les clients TLS qui s'appuient sur des indications d'erreur au niveau de la couche TLS pour un certificat inacceptable ne recevront pas ces signaux.

Lorsque la valeur du champ d'en-tête de requête Client-Cert est utilisée pour sélectionner une réponse (par exemple, le contenu de la réponse est contrôlé par accès), la réponse DOIT soit être non cacheable (par exemple, en envoyant Cache-Control: no-store) soit être désignée pour une réutilisation sélective uniquement pour les requêtes ultérieures avec la même valeur de champ d'en-tête Client-Cert en envoyant un en-tête de réponse Vary: Client-Cert. Si un TTRP rencontre une réponse avec Client-Cert ou Client-Cert-Chain dans le champ d'en-tête Vary (Section 12.5.5 de [HTTP]), il DEVRAIT empêcher l'agent utilisateur de mettre en cache la réponse en transformant la valeur du champ d'en-tête de réponse Vary en *.

Les proxies directs et autres intermédiaires NE DOIVENT PAS ajouter les champs d'en-tête Client-Cert ou Client-Cert-Chain aux requêtes ou modifier un champ d'en-tête Client-Cert ou Client-Cert-Chain existant. De même, les clients NE DOIVENT PAS utiliser le champ d'en-tête Client-Cert ou Client-Cert-Chain dans les requêtes.