Reverse proxy et problème d'authentification
-
Les applications sont accessibles depuis internet et il faut tout simplement mettre un login et mot de passe pour y accéder.
-
Oui certes… Mais comment sont gérés les comptes des utilisateurs autorisés à accéder à ces applications ?
Localement sur chaque serveur ? -
OUI! pardon sur chaque serveur il y'a une base données des utilisateurs qui sont autorisés.
-
Dans ma liste des solutions possibles j'ai oublié Vulture : https://www.vultureproject.org/doc/
L'authentification (et tout ce qui tourne autour, SSO, propagation, …. ) est une partie importante et il y de nombreuse façon de la mettre en œuvre.
Voir aussi : https://kemptechnologies.com/news/kemp-technologies-adds-pre-authorization-single-sign-sso-and-persistent-logging-load-balancers/ -
Merci des solutions je suis entrain de regarder Vulture.
-
Vulture pour faire du reverse proxy, pourquoi pas. C'est basé sur HAproxy.
donc pour la partie "proxy", oui sans réserver.
Pour la partie authentification ou velléité de SSO, tu es, à mon avis parti dans la mauvaise direction. Mais ce n'est que mon avis personnel bien sûr ;)
Déjà avec une base de compte locale pour chaque application, le SSO c'est mal parti. que comptes tu faire ? appuyer l’authentification du reverse proxy sur une de ces bases ou bien comptes-tu en créer une de plus ?De mon point de vue, en ce qui concerne la gestion des comptes, le strict minimum ici c'est LDAP.
Je ne dis pas qu'il n'y a QUE LDAP mais en ce qui concerne les comptes, c'est quand même mieux. Après pour la gestion de l'authentification, il y a des solutions comme CAS (Jasig) qui permettent, à la mode Kerberos, du "web-SSO"
Et, encore une fois c'est un avis qui n'engage que moi, la fonctionnalité qui permet de faire du "store & forward" de l'authentification tel que proposé par Vulture (qui par ailleurs est un assemblage élégant de solutions open source) n'est pas une très bonne idée.
-
permet de faire du "store & forward" de l'authentification tel que proposé par Vulture
Dans la dernière version c'est quand même un peu plus que cela.
Sinon, pour le reste en effet, la question de la gestion de l'authentification, le stockage sur chaque serveur n'est pas une solution très satisfaisante. Un ldap serait un minimum.
-
Ce que je compte faire (Chris) c'est de centraliser l'authentification au niveau de mon reverse proxy de ce fait après on pourra même supprimer les authentifications se trouvant au niveau des serveurs en internes.
-
@ccnet: j'avoue ne pas avoir regardé récemment les évolutions de Vulture tellement je suis fermé au concept même du relais d'authentification.
@saliou: pourquoi pas… Mais l'idée me semble plutôt étrange. Ça signifie que, en interne, les applications ne demandent plus d'authentification ? Et où est la base de comptes utilisée par le reverse proxy ?
-
Chris. En fait le fait que je supprimerai l'authentification au niveau des serveurs internes c'est juste une supposition je pourrai le laisser comme ça pour plus de sécurité.
Mais en fait mon problème c'est qu'en ce moment je n'ai pas encore de solutions pour mettre l'authentification sur mon reverse proxy (le plus important pour moi). -
Il faut :
- choisir ta solution
- implémenter le backend supporté par cette solution en terme d'authentification
… Et c'est tout.
Quel est ton point de blocage ?
-
Oui je vois je bloque par rapport au choix de la solution.
-
Il est évident qu'il faut débuter par la définition des critères qui sont pour toi importants mais au final, il n'y a pas beaucoup de choix techniques :
- squid
- nginx
- HAproxy, en mode standalone ou dans un bundle type Vulture.
Ça ne t'engage pas beaucoup d'en choisir un et d'aller au bout de l'implémentation. De toute manière tu vas te rendre compte que la problématique n'est pas le reverse proxy lui même mais la gestion des comptes utilisateurs
-
SQUID c'est ce que j'ai pour le reverse proxy mais à ce que j'ai vu l'authentification ne serai pas prise en compte.
T'en pense quoi? -
Je ne sais pas d'où tu sors que Squid en mode reverse proxy ne supporte pas d'authentification ???
-
Ban, parce sa mise en oeuvre je ne vois pas où çà se fait sur mon pfsense.
-
La mise en oeuvre de l'authentification sur reverse proxy squid avec pfSense, je ne voit pas où ça se fait.
-
D'où l'intérêt de formuler dès le début le contexte et la bonne question (et si tu l'as fait, je ne l'ai pas mémorisé)…
Je ne sais pas si le package Squid délivré avec pfsense permet un fonctionnement en mode reverse proxy. Même si le produit et le même, la configuration est différente.
Et donc si l'interface ne le permet pas, ce n'est pas la solution à retenir.
Ce qui ne t'empêche pas d'utiliser Squid mais pas en tant que package et donc pas "sur" pfsense -
D'accord Merci, mais est ce qu'alors HAproxy fait une authentification avec l'interface.
En plus est ce que sa(HAproxy) documentation est "abondante". :) -
Il est évident qu'il faut débuter par la définition des critères qui sont pour toi importants mais au final, il n'y a pas beaucoup de choix techniques :
- squid
- nginx
- HAproxy, en mode standalone ou dans un bundle type Vulture.
Ça ne t'engage pas beaucoup d'en choisir un et d'aller au bout de l'implémentation. De toute manière tu vas te rendre compte que la problématique n'est pas le reverse proxy lui même mais la gestion des comptes utilisateurs
Entièrement d'accord. Un problème bien posé est à moité résolu.