Comment configurer l'authentification HTTP de base dans NGINX
L'authentification de base des noms d'utilisateur et des mots de passe est un moyen simple et sûr de sécuriser les panneaux d'administration et les services backend. Nginx peut être configuré pour protéger certaines zones de votre site Web, ou même utilisé comme proxy inverse pour sécuriser d'autres services.
Sommaire
Comment fonctionne l'authentification HTTP?
Dans l'authentification HTTP de base, certains itinéraires sur le serveur sont verrouillés et nécessitent un nom d'utilisateur et un mot de passe pour y accéder. Par exemple, les panneaux d'administration de la plupart des routeurs domestiques sont sécurisés de cette façon; lorsque vous essayez d'y accéder, le navigateur ouvre une boîte de dialogue demandant des informations d'identification.
Lorsqu'un utilisateur tente d'accéder à une ressource protégée, le serveur envoie à l'utilisateur un WWW-Authenticate en-tête avec un 401 Unauthorized réponse. Le client renvoie le nom d'utilisateur et le mot de passe appropriés, stockés dans le Authorization et s'il correspond à un fichier clé, ils sont autorisés à se connecter.
Parce que l'authentification HTTP de base nécessite l'envoi de mots de passe le long du câble, vous devez configurer HTTPS / TLS sur votre serveur, sinon toute personne au milieu pourrait flairer le mot de passe en clair. HTTPS cryptera la connexion, ce qui rendra la transmission sûre. Vous pouvez configurer un certificat gratuit avec LetsEncrypt, ou si vous cherchez à sécuriser un serveur privé, créez-en un et signez-le vous-même.
L'authentification de base du nom d'utilisateur / mot de passe n'est qu'un des nombreux schémas d'authentification; un autre schéma commun est les jetons supports, utilisés pour les flux OAuth 2.0. Vous pouvez utiliser ce schéma avec Nginx à l'aide du module JSON Web Tokens, mais la configuration complète est beaucoup plus complexe que l'authentification par nom d'utilisateur / mot de passe.
Générer un fichier de mot de passe
Vous pouvez utiliser le htpasswd pour générer des fichiers de mots de passe. C'est probablement déjà installé sur votre système, mais si ce n'est pas le cas, vous pouvez l'installer à partir du apache2-utils paquet. (Nginx utilise le même format de mot de passe qu'Apache):
sudo apt-get install apache2-utils
Générez un nouveau fichier de mots de passe en exécutant htpasswd avec le -c drapeau, dans ce cas, pour l'utilisateur "admin":
sudo htpasswd -c /etc/nginx/.htpasswd admin
Vous serez invité à saisir un mot de passe, qui sera haché et stocké dans /etc/nginx/.htpasswd. Si vous souhaitez ajouter plusieurs utilisateurs, omettez le -c pour ajouter de nouvelles entrées.
Activer l'authentification HTTP de base
Vous pouvez protéger n'importe quel itinéraire dans nginx en utilisant le auth_basic directive à l'intérieur d'un emplacement. Par exemple, pour protéger par mot de passe /admin, vous placeriez ce bloc d'emplacement à l'intérieur du bloc serveur dans votre fichier de configuration nginx principal (généralement situé à /etc/nginx/nginx.conf):
location /admin {
try_files $uri $uri/ =404;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
}
le auth_basic_user_file La directive doit pointer vers le fichier de mots de passe que vous avez créé à la première étape. Il n’a pas besoin d’être nommé spécial, vous pouvez donc créer différents fichiers de mots de passe pour différents itinéraires.
Nginx devrait s'occuper du reste pour vous. Redémarrez pour appliquer les modifications:
sudo service nginx restart
Et vérifiez l'itinéraire protégé dans votre navigateur. Vous devriez être invité à saisir un mot de passe et à vous refuser l'accès si vous ne pouvez pas le fournir.
Utilisation de l'authentification proxy
Un cas d'utilisation courant de l'authentification de base est la sécurisation d'une ressource externe avec un proxy inverse nginx. Cela fonctionne parfaitement avec auth_basicet est aussi simple que d'utiliser les deux ensemble:
location / {
#//turn on auth for this location
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
#//normal proxy configuration
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Accept-Encoding "";
proxy_pass https://;
proxy_redirect default;
}
Cela fonctionne en refusant toute entrée au proxy avant qu'un utilisateur ne s'authentifie. Une fois authentifiés, nginx fonctionne normalement.
Cependant, si vous souhaitez effectuer l'authentification sur le serveur derrière le proxy inverse, la configuration est plus compliquée. Vous souhaiterez plutôt que nginx procède à un proxy de vos entrées sur le serveur Web, ce qui pourrait, par exemple, interroger une base de données ou effectuer une vérification plus complexe qu’un simple fichier de mots de passe.
Vous devrez utiliser le module headers-more pour pouvoir modifier les en-têtes plus directement:
location / {
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Accept-Encoding "";
proxy_pass https://;
proxy_redirect default;
more_set_input_headers 'Authorization: $http_authorization';
more_set_headers -s 401 'WWW-Authenticate: Basic realm="your_server.com"';
}
La configuration du proxy est la même, sauf qu'elle est manquante auth_basic parce que nous ne voulons pas faire l'authentification avec nginx. le more_set_input_headers La directive fait la magie ici et définit l'en-tête lorsqu'elle communique avec le serveur Web pour inclure le $http_authorization variable obtenue du client. De cette façon, le nom d'utilisateur et le mot de passe sont transmis via nginx au backend.
La ligne suivante est plus compliquée; la manière régulière de définir les en-têtes remplacera le realm variable quand il est mandaté via nginx, ce qui n'est pas idéal. En utilisant more_set_headers conservera cela et montrera au client les informations correctes.
