L’authentification par proxy de confiance d’OpenClaw

L’authentification par proxy de confiance est le mode des passerelles qui vivent derrière un proxy conscient de l’identité : le proxy authentifie la personne, ajoute un en-tête avec son identité, et la passerelle fait confiance à cet en-tête, mais seulement venant du proxy. La documentation s’ouvre sur un avertissement qu’une mauvaise configuration expose la passerelle, et l’essentiel de la page est la liste des vérifications qui rendent cette confiance sûre. La voici, dans l’ordre où la passerelle l’évalue.

Quand et comment

• Utilisez-le derrière Pomerium, Caddy avec OAuth, nginx avec oauth2-proxy ou Traefik en authentification déléguée, dans des environnements de conteneurs où le proxy est le seul chemin, ou quand les navigateurs rencontrent des erreurs WebSocket non autorisées parce qu’ils ne peuvent pas passer de jetons dans la poignée de main ; ne l’utilisez pas quand le proxy ne fait que terminer TLS, quand un chemin contourne le proxy, quand vous n’êtes pas sûr que le proxy retire les en-têtes transmis, ou pour un accès personnel mono-utilisateur où un tailnet plus la boucle locale est plus simple.
• Le flux : le proxy authentifie l’utilisateur, ajoute un en-tête d’identité, la passerelle vérifie que la requête vient d’une adresse de proxy de confiance, lit les en-têtes requis et l’identité de l’utilisateur, et autorise quand la liste blanche d’utilisateurs, si elle est définie, inclut l’utilisateur ; la configuration se lie au réseau local, ne liste que les adresses ou plages du proxy, définit le mode d’authentification, l’en-tête utilisateur, des en-têtes requis optionnels, une liste blanche optionnelle, la boucle locale désactivée par défaut et l’approbation automatique désactivée par défaut.
• Règles d’exécution dans l’ordre : le trafic en forme de proxy est attribué avant l’authentification et doit venir d’un proxy de confiance avec des en-têtes d’adresse client résolvant vers un client hors boucle locale, sinon les routes authentifiées le rejettent pour attribution manquante ; le proxy doit réécrire la chaîne d’adresses transmises de façon sûre, l’en-tête d’adresse réelle n’étant accepté que si son repli est activé ; les sources en boucle locale sont rejetées sauf si l’option est activée et que la boucle locale est aussi listée ; les sources correspondant à l’une des adresses d’interface de l’hôte sont rejetées comme garde contre l’usurpation, et une découverte d’interfaces en échec rejette aussi ; ensuite les en-têtes requis et l’en-tête utilisateur doivent être présents et non vides, et la liste blanche doit inclure l’utilisateur.
• Une preuve d’en-tête transmis sur une requête en boucle locale la disqualifie du repli local direct par mot de passe et du filtrage par identité d’appareil tout en échouant quand même l’authentification par proxy ; les clients internes qui ne passent pas par le proxy utilisent le mot de passe de la passerelle, que la commande de statut sélectionne automatiquement sans surcharge d’URL ; la liste des proxys de confiance accepte les plages telles quelles ou en forme mappée, et un préfixe mappé couvrant tout exige encore l’option pour la boucle locale.

Un jeton de passerelle ne peut pas remplacer l’authentification par le proxy.

Attributions, approbation automatique et en-tête de scopes

Les scopes par identité donnent à des utilisateurs vérifiés choisis des scopes valables pour la session seulement, sans élargir leur attribution d’appareil : la clé est l’identité du proxy ou le login du tailnet, les emails correspondent sans tenir compte de la casse, l’attribution est unie aux scopes autorisés de l’appareil puis plafonnée par un en-tête de scopes explicite, et les connexions par jeton, mot de passe et sans authentification n’en reçoivent jamais. L’approbation automatique des appareils, désactivée par défaut, utilise l’identité du proxy comme frontière d’approbation pour les nouveaux appareils opérateur de navigateur et natifs et les montées de scopes à clé identique : seules les connexions par proxy avec une identité non vide ayant passé la liste blanche sont éligibles, les connexions de rôle nœud et les montées de rôle jamais, les scopes demandés sont intersectés avec la liste configurée (lecture, écriture, approbations et questions quand elle est absente, jamais élargie), l’en-tête de scopes du proxy plafonne aussi l’attribution persistante, et lister l’administration permet à chaque utilisateur du proxy de recevoir un appareil administrateur complet, ce que l’audit signale comme critique et que la passerelle avertit au démarrage. Les sessions d’interface de contrôle sans appareil ne peuvent pas déclarer leurs scopes : leur liste est vidée et une attribution par identité correspondante appliquée ; un échec de scope manquant après une connexion réussie signifie recharger pour que le navigateur appaire son identité d’appareil. L’en-tête de scopes déclare des scopes quand il est présent, n’en déclare aucun quand il est présent mais vide, et se rabat sur l’ensemble par défaut quand il est absent, tandis que les routes de plugin authentifiées par la passerelle se rabattent sur l’écriture seulement.

TLS, jetons mixtes et audit

• Terminez TLS une seule fois et posez l’en-tête de transport strict à cet endroit : au proxy pour les déploiements exposés à internet avec la passerelle en boucle locale derrière lui, ou sur la passerelle avec TLS activé et l’en-tête de sécurité correspondant quand elle sert HTTPS elle-même ; commencez par une durée courte, augmentez-la seulement une fois confiant, ajoutez l’option de sous-domaines seulement quand chacun est prêt, et laissez cela de côté pour le développement en boucle locale seule.
• Le démarrage rejette ce mode quand un jeton partagé est aussi configuré, parce qu’un jeton laisserait les appelants du même hôte s’authentifier par un chemin différent de l’identité vérifiée par le proxy ; retirez le jeton ou changez de mode, et rappelez-vous que les en-têtes d’identité en boucle locale échouent toujours fermés et que le repli par jeton n’est volontairement pas pris en charge.
• L’audit de sécurité signale le mode comme critique à dessein et vérifie une liste de proxys manquante, un en-tête utilisateur manquant, une liste blanche vide, l’option de boucle locale activée et l’approbation automatique activée ; la liste de contrôle ajoute que le proxy est le seul chemin, que la liste est minimale, que le proxy réécrit les en-têtes transmis et reconstruit la chaîne d’adresses, que les origines autorisées sont explicites pour une interface de contrôle hors boucle locale, et que tout repli par mot de passe local reste privé derrière le pare-feu.

Les scopes opérateur d’OpenClaw explique le modèle de scopes que ces attributions alimentent et OpenClaw sur Tailscale l’alternative plus simple pour un accès limité au tailnet.

Lire les codes de rejet

La section de dépannage associe chaque rejet : une source non fiable signifie que la requête ne venait pas d’une adresse de proxy listée, ce qui change quand les conteneurs redémarrent ; une source en boucle locale signifie un proxy sur le même hôte sans l’option délibérée ; une source d’interface locale signifie qu’un processus sur l’hôte envoie des en-têtes d’identité directement ou que le proxy partage l’espace de noms réseau de l’hôte ; un utilisateur manquant signifie que l’en-tête est absent ou mal nommé ; un utilisateur non autorisé signifie que le compte est authentifié mais pas dans la liste blanche, et la documentation dit de ne pas retirer la liste comme contournement ; une origine non autorisée signifie que l’origine du navigateur a échoué la vérification. Le message sur une authentification par proxy requise est une identité rejetée, pas une panne réseau, et le correctif est de se connecter au proxy plutôt que d’envoyer des en-têtes depuis le navigateur. La migration depuis l’authentification par jeton tient en six étapes : configurer le proxy, le tester indépendamment, mettre à jour la configuration, redémarrer, tester le WebSocket depuis l’interface de contrôle, et lancer l’audit. L’accès distant OpenClaw compare les autres schémas d’accès distant et L’appairage OpenClaw le flux d’appareils que l’approbation automatique remplace.

Sur Diali

Sur Diali chaque passerelle client est atteinte à travers l’entrée de la plateforme avec la configuration d’exécution générée depuis le tableau de bord et remplacée à chaque version, ce mode n’est donc pas quelque chose qu’un client doit assembler à la main. OpenClaw hébergé sur Diali décrit l’assistant hébergé et La sécurité Diali la frontière autour de chaque runtime.

• Ne faire confiance à l’en-tête que depuis les adresses de proxy listées.
• Les sources en boucle locale et sur ses propres interfaces échouent fermées.
• L’en-tête de scopes restreint ; les attributions par identité ajoutent, pour la session.