web-dev-qa-db-fra.com

Un serveur d'authentification proxy inverse serait-il une configuration sécurisée?

Je travaille dans un petit cabinet de conseil et nous réalisons souvent des applications web pour nos clients. Le système d'authentification est une partie de l'application Web qui est souvent répétitive à écrire. Dans beaucoup de nos applications Web, nous aimerions prendre en charge la connexion OAuth des différents fournisseurs ainsi que l'enregistrement par courrier électronique.

Cependant, sa programmation dans chaque application Web prend du temps. Idéalement, ce que nous aimerions, c'est un serveur proxy d'authentification générique qui se trouve devant le serveur d'applications et gère tout ce qui concerne l'authentification (y compris la connexion, l'enregistrement et la déconnexion). Je me demande si quelque chose comme ça serait sécurisé? Ou s'il y a une raison liée à la sécurité pour laquelle cela ne devrait pas être fait comme ça?

J'imagine que cela ressemblerait à ceci:

reverse proxy auth server

Serveur d'authentification

  • Il s'agit essentiellement d'un serveur proxy inverse. Il possède sa propre base de données avec des informations relatives à l'authentification (par exemple, adresse e-mail, mot de passe, etc.).
  • Il vérifie chaque requête pour un cookie spécifique avec des informations de session (par exemple, un JWT dans un cookie appelé SESSION). Ces informations de session seraient la preuve que l'utilisateur s'est connecté correctement à un moment donné dans le passé. Si les informations de session sont correctes, il ajoute un X-UserId en-tête de la demande et la transmet au serveur d'applications. S'il n'y a pas de cookie avec des informations d'authentification ou si les informations de session sont incorrectes, il transmet la demande au serveur d'applications sans le X-UserId entête.
  • Il aura des itinéraires spécifiques pour la connexion, la déconnexion et l'enregistrement (par exemple, /login, /logout, et /register). Il gérera ces demandes de lui-même. Le serveur d'applications ne sera même pas au courant de ces demandes.

Serveur d'applications

  • Il s'agit d'un serveur d'applications Web normal.
  • Il n'effectue aucune authentification, reposant entièrement sur le X-UserId en-tête du serveur Auth.
  • Il n'est pas accessible depuis le monde extérieur. La seule façon d'y accéder est de passer par le serveur Auth.
  • Il possède également sa propre base de données. Il est rempli de toutes les informations relatives à l'application (à l'exception des informations d'authentification).

Voici un exemple de fonctionnement de la connexion, ainsi que l'interaction entre le serveur Auth et le serveur d'applications:

Voici les étapes pour obtenir le login.html page.

  1. Le client envoie une demande de /login.html.
  2. Le serveur d'authentification reçoit la demande. Le serveur d'authentification essaie de rechercher un cookie appelé SESSION. Il n'existe pas, il transmet donc la demande au serveur d'applications sans ajouter de X-UserId entête.
  3. Le serveur d'applications reçoit la demande. Il existe une route définie pour /login.html et il ne nécessite pas le X-UserId l'en-tête existe, il renvoie donc le code HTML pour login.html.
  4. Le serveur d'authentification reçoit la réponse et la renvoie à l'utilisateur.

Le login.html la page pourrait contenir le code JS pour se connecter réellement. Voici une façon possible de le faire.

  1. Le client envoie une demande AJAX à /login/email pour vous connecter à l'aide d'une adresse e-mail et d'un mot de passe.
  2. Le serveur d'authentification reçoit la demande. Puisqu'il s'agit d'une demande pour le serveur d'authentification, il ne transmet pas la demande au serveur d'applications.
  3. Le serveur d'authentification examine le corps de la demande pour une adresse e-mail et un mot de passe. Il vérifie l'adresse e-mail et le mot de passe dans sa base de données d'authentification.
  4. Si l'adresse e-mail et le mot de passe sont corrects, il renvoie un cookie HttpOnly appelé SESSION qui contient un JWT.

Après cela, l'utilisateur pourrait être dirigé vers /home.html. Les étapes à suivre sont similaires à /login.html, sauf que l'utilisateur doit être authentifié:

  1. L'utilisateur envoie une demande à /home.html.
  2. Le serveur d'authentification reçoit la demande. Le serveur Auth vérifie le cookie SESSION et décode le JWT. Le serveur Auth obtient l'ID utilisateur de la base de données en fonction des informations contenues dans le JWT. Disons que l'ID utilisateur est 5.
  3. Le serveur Auth ajoute un X-UserId=5 en-tête de la demande et la transmet au serveur d'applications. (Dans le cas où le cookie SESSION n'existe pas ou si le JWT ne peut pas être décodé avec succès, le serveur Auth transmet la demande au serveur d'applications sans ajouter de X-UserId entête. Les étapes suivantes sont écrites en supposant que l'authentification réussit et que le serveur d'authentification ajoute l'en-tête `X-UserId.)
  4. Le serveur d'applications reçoit la demande. Étant donné que la demande concerne /home.html, le serveur d'applications sait qu'un ID utilisateur valide est requis, il vérifie donc le X-UserId entête.
  5. Le serveur d'applications obtient avec succès l'ID utilisateur à partir du X-UserId en-tête et l'utilise pour extraire des données de la base de données d'application et créer le home.html page.
  6. Le serveur d'applications envoie la réponse avec le home.html page vers le serveur Auth.
  7. Le serveur d'authentification reçoit la réponse et la renvoie à l'utilisateur.

Voici quelques informations supplémentaires qui ne cadraient pas vraiment ci-dessus:

  • Le serveur Auth supprimerait le X-UserId en-tête s'il est envoyé par un utilisateur avant de transmettre la demande au serveur d'applications.
  • Le serveur d'authentification peut être relativement général et utilisé sur plusieurs projets différents. Le serveur d'applications n'aurait pas à se soucier du tout de l'authentification.
  • Le serveur d'applications devrait être en charge de l'autorisation (par exemple, s'assurer que chaque utilisateur ne pouvait modifier que ses propres informations).
  • Le serveur d'authentification gérerait complètement l'enregistrement d'un nouvel utilisateur. Cela peut inclure un flux OAuth (pour utiliser OAuth tel que fourni par Google, Twitter, Facebook, etc.)), ainsi qu'une simple inscription par courrier électronique. un nouvel utilisateur s'inscrit, le serveur d'authentification crée un ID utilisateur et le lie à l'adresse e-mail de l'utilisateur, au nom d'utilisateur Google, au nom d'utilisateur Twitter, etc. Le serveur d'applications ne voit que cet ID utilisateur (jamais l'adresse e-mail de l'utilisateur, le nom d'utilisateur Google, Nom d'utilisateur Twitter, etc.).

Une configuration comme celle-ci est-elle sécurisée?

authenticationweb-applicationproxyhttp-proxyapi-gateway
9
illabout

Les procurations inversées sont assez courantes pour ce que vous demandez. Un certain nombre d'entreprises fabriquent des serveurs conçus pour répondre à vos demandes afin que vous puissiez les utiliser comme référence.

Par exemple, j'ai beaucoup utilisé WebSeal (IBM ISAM) dans l'entreprise (semble populaire pour une raison quelconque autour de moi). Ils ont déjà des modules pour OAuth et la plupart des autres types d'authentification.

Vous pouvez utiliser ces serveurs pour:

  • fournir une seule "identité" sur plusieurs systèmes avec des magasins d'utilisateurs différents.
  • Fournissez une méthode d'authentification plus sécurisée pour les utilisateurs, sur les systèmes hérités qui peuvent ne pas avoir les fonctionnalités souhaitées (par exemple, fournir des autorisations OAuth pour les utilisateurs, tandis que le proxy utilise l'authentification de base pour un appel principal). )
  • Isolez les systèmes en forçant les connexions via un seul point
  • Combinaisons pour tous ces éléments.

Notes de conception:

  • OAuth est un protocole d'AUTORISATION PAS un protocole d'AUTHENTIFICATION.
  • Lorsque vous essayez d'établir une identité, recherchez OpenID ou JWT ou SAML ou exécutez en tant que fournisseur d'identité appartenant à vous.

  • Lorsque vous essayez d'autoriser une demande, regardez OAuth 2.0 ou JWT.

  • Utilisez un jeton d'identification pour l'identité (par exemple, spécification OpenID, ou si vous jetez votre propre regard sur les JWT)

  • Demandez aux applications Web d'utiliser un jeton d'autorisation pour obtenir un jeton d'accès.

  • Utilisez des jetons d'accès pour fournir des ressources protégées.

2
Shane Andrie

Ceci est une excellente configuration.

Consultez la documentation de Google au-delà de Corp pour en savoir plus sur la façon dont ils pensent les réseaux et ce type d'accès.

https://cloud.google.com/beyondcorp/

Si vous voulez rouler le vôtre, vous pouvez utiliser quelque chose comme une passerelle réseau duo. Mais le problème avec les proxy inverses est que vous devez pointer tous les DNS vers la même IP du proxy inverse et configurer manuellement chaque ressource.

Une autre approche est une combinaison de fichiers PAC et d'un proxy direct qui nécessite une authentification. Vous pouvez ensuite spécifier que N'IMPORTE QUELLE URL doit être envoyée via le proxy direct, le proxy direct effectue l'authentification et transmet le trafic à la ressource où qu'elle se trouve. La ressource peut être configurée pour autoriser uniquement l'adresse IP source.

1
Jonathan