Apache2 – autorise les utilisateurs contre un emplacement utilisant BasicAuth mais UNIQUEMENT pour les utilisateurs extérieurs au sous-réseau local

Dans ma configuration Apache 2, j’ai un VirtualHost qui ressemble à ceci:

  ServerName sub.domain.com # username:password sent on to endpoint RequestHeader set Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ==" ProxyPass /xyz http://192.168.1.253:8080/endpoint ProxyPassReverse /xyz http://192.168.1.253:8080/endpoint  # This needs to let users through under the following circumstances # * They are in 192.168.1.0/24 # * They have a valid user in a htpasswd file # So what goes here?   

J’utilise l’hôte virtuel comme proxy inverse sur un autre serveur (que j’appellerai le sharepoint terminaison) sur le réseau.

J’essaie de trouver une configuration qui permettrait aux utilisateurs de la navigation réseau de sub.domain.com de sub.domain.com automatiquement le noeud final. Toutefois, les utilisateurs externes au réseau doivent être invités à entrer leurs informations d’identification.

Le noeud final nécessite un mot de passe que j’ai masqué en utilisant RequestHeader (ce que je veux). Le mot de passe que les utilisateurs externes doivent recevoir est DIFFERENT et devra être BasicAuth, en obtenant la liste d’utilisateurs depuis un fichier htpasswd .

  # This needs to let users through under the following circumstances # * They are in 192.168.1.0/24 # * They have a valid user in a htpasswd file 

À droite de http://httpd.apache.org/docs/2.2/mod/core.html#satisfy :

  Require valid-user Order allow,deny Allow from 192.168.1 Satisfy any 

Bien entendu, vous devez également inclure vos directives AuthUserFile ou autres

  AuthType basic AuthName "yadayadayada" AuthUserFile /foo/bar/blah/.htpasswd  

Vous pouvez créer deux hôtes virtuels, l’un qui écoute l’interface externe et l’autre local. Les parameters d’authentification seraient dans l’ancien.

Je pense que David a assez bien couvert la configuration d’Apache2, mais il est également courant d’utiliser le DNS partagé pour fournir différents services à vos utilisateurs internes et externes. Il n’y a vraiment aucune raison pour que vos utilisateurs internes fassent une demande à partir de votre proxy, car ils ont (apparemment) un access direct au “noeud final”.

Il y a des cas où vous pouvez réellement subir des retards de routage et des encombrements si vos utilisateurs internes se connectent à l’une de vos adresses IP publiques. À l’origine, j’étais fan d’avoir du matériel distinct pour les deux serveurs DNS, mais j’ai récemment opté pour l’utilisation de “vues” de liaison pour fournir différentes zones à mes deux classes d’utilisateurs.