Reverse proxy et problème d'authentification
-
Donc de ton point de vue il n'est pas nécessaire de remettre une authentification au reverse proxy?
Car comme tu (Chris) l'as dis sur les serveurs en internes, il faut s'authentifier d'abord.
Donc si je comprends bien on pourra laissé la fonction reverse proxy et renforcer la sécurité sur les serveurs internes.
-
Ce n'est pas exactement mon point. Désolé si je n'ai pas été clair.
Ce que je veux dire, c'est que l'authentification au niveau du REVERSE proxy permet de contrôler qui a accès au LAN via ce reverse proxy. L'authentification côté application permet de géré authn et authz. Les deux sont probablement nécessaires en fonction de l'application.
Par contre, la tendance est très souvent, parce que on souhaite offrir à l'utilisateur un mode SSO like, de faire 'rejouer' au reverse proxy l'authentification de l'utilisateur, ce qui signifie stocker celle ci sur la machine qui a une patte sur Internet.
De mon point de vue, si on veut du SSO, il faut mettre en place l'infrastructure qui le supporte mais pas faire du faire. -
D'accord alors l'infrastructure que j'ai ne le supporte pas?
-
Je ne dis pas ça non plus ;)
Mais tu peux commencer avec une authentification à chaque étape et traiter ultérieurement les aspects SSO.
Comment ça fonctionne aujourd'hui pour les applications depuis le LAN ?
-
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.