[TECH] Suggestion de serveur IdP ? Keycloak, Gluu, LemonLDAP::NG, ...
Pré-scriptum : Premier message sur cette liste, je suis FRnOG depuis quelques temps mais je n'ai découvert FRsAG que récemment. Donc j'en profite pour adresser un *bonjour à tous* et me présenter en quelques mots clés : homme, admin réseau, admin serveur, debian, open-source, lyon, ~120 utilisateurs. Chez mon employeur, pour gérer les informations sur les utilisateurs (nom, prénom, e-mail, uid, nom d'utilisateur, mot de passe, etc.) on dispose d'un serveur LDAP ce qui permet à chacun de n'avoir qu'un seul mot de passe pour accéder à toutes les applications Web qu'on utilise (via connecteur LDAP dans l'application ou via module Apache/Nginx style "mod_authnz_ldap"). Mais pour (enfin) pouvoir : * Proposer du SSO aux utilisateurs ("sign-on" et "sign-out") * Contrôler/gérer/contrôler tout ça (d'un endroit unique) * S'ouvrir aux autres applications via les standard tels que OAuth, OpenID, etc. J'envisage de monter un serveur "IdP", j'ai donc regardé les solutions qu'on pouvait installer sur nos propres serveur et j'ai retenu : * Keycloak * Gluu * LemonLDAP::NG J'ai trouvé la documentation de *Keycloak* est assez bien faite et ça m'a permit d'appréhender l'étendue des possibilités : ça semble bien correspondre à mes besoins. Seul petit hic, c'est en Java. Pour *Gluu*, je trouve la documentation un peu moins précise et il reste quelques points d'ombre sur les possibilités offertes. Point noir : il utilise, en interne, un serveur LDAP et rajouter des métadonnées aux utilisateurs semble compliqué. Bon point : il est distribué sous forme de package .deb. J'avais déjà découvert *LemonLDAP::NG* il y a des années (sans m'en servir) et ça me branchait bien. Je dirais qu'il semble moins joli que Keycloak mais tout aussi performant. A l'époque, l'intégration du SSO sur les applications web maison m'avait paru aisée (Apache seulement). Je vais donc tester Keycloak et LemonLDAP::NG, mais avez-vous d'autres produits à conseiller (tant que je suis lancé) ? J'ajoute que, dans un futur proche, j'aimerais disposer d'un serveur RADIUS. Ça me permettra de faire de la restriction d'accès sur des équipements réseau (eg. bornes WiFi) : mais j'ignore encore quelle passerelle il pourrait y avoir entre RADIUS et un des IdP testé plus haut. Je sais juste que si je n'avais pas ce projet d'IdP, je connecterais tout simplement le serveur RADIUS sur le serveur LDAP. Merci pour votre attention :) -- DUVERGIER Claude
Bonjour,
* Proposer du SSO aux utilisateurs ("sign-on" et "sign-out") * Contrôler/gérer/contrôler tout ça (d'un endroit unique)
pour atteindre cet objectif, il me semble inutile de passer a un full IdM. ajouter un moteur de SSO qui se plug a votre LDAP suffirait. De toute facon, les applis devront etre modifiees, donc tant qu'a faire, vous pouvez gagner du temps et vous concentrer sur le vrai pb)) ceci etant dit, je n'ai pas trouve' de moteur SSO convenable. Jasig CAS qui semble etre le standard open source est en Java. Ca marche mais pas facile a configurer et en XML.
* S'ouvrir aux autres applications via les standard tels que OAuth, OpenID, etc.
oui bon la effectivement, un simple moteur SSO suffit pas.
* Keycloak * Gluu * LemonLDAP::NG
sans doute aussi Redhat IdM / FreeIPA et puis Samba4 qui fait tout simplement de l'AD.
Bonjour, https://identityserver4.readthedocs.io/en/latest/ Avec un peu de dev ça fait tout ça est plus XAvier -----Message d'origine----- De : DUVERGIER Claude <frsag.ml@claude.duvergier.fr> Envoyé : jeudi 17 janvier 2019 18:52 À : frsag@frsag.org Objet : [FRsAG] [TECH] Suggestion de serveur IdP ? Keycloak, Gluu, LemonLDAP::NG, ... Pré-scriptum : Premier message sur cette liste, je suis FRnOG depuis quelques temps mais je n'ai découvert FRsAG que récemment. Donc j'en profite pour adresser un *bonjour à tous* et me présenter en quelques mots clés : homme, admin réseau, admin serveur, debian, open-source, lyon, ~120 utilisateurs. Chez mon employeur, pour gérer les informations sur les utilisateurs (nom, prénom, e-mail, uid, nom d'utilisateur, mot de passe, etc.) on dispose d'un serveur LDAP ce qui permet à chacun de n'avoir qu'un seul mot de passe pour accéder à toutes les applications Web qu'on utilise (via connecteur LDAP dans l'application ou via module Apache/Nginx style "mod_authnz_ldap"). Mais pour (enfin) pouvoir : * Proposer du SSO aux utilisateurs ("sign-on" et "sign-out") * Contrôler/gérer/contrôler tout ça (d'un endroit unique) * S'ouvrir aux autres applications via les standard tels que OAuth, OpenID, etc. J'envisage de monter un serveur "IdP", j'ai donc regardé les solutions qu'on pouvait installer sur nos propres serveur et j'ai retenu : * Keycloak * Gluu * LemonLDAP::NG J'ai trouvé la documentation de *Keycloak* est assez bien faite et ça m'a permit d'appréhender l'étendue des possibilités : ça semble bien correspondre à mes besoins. Seul petit hic, c'est en Java. Pour *Gluu*, je trouve la documentation un peu moins précise et il reste quelques points d'ombre sur les possibilités offertes. Point noir : il utilise, en interne, un serveur LDAP et rajouter des métadonnées aux utilisateurs semble compliqué. Bon point : il est distribué sous forme de package .deb. J'avais déjà découvert *LemonLDAP::NG* il y a des années (sans m'en servir) et ça me branchait bien. Je dirais qu'il semble moins joli que Keycloak mais tout aussi performant. A l'époque, l'intégration du SSO sur les applications web maison m'avait paru aisée (Apache seulement). Je vais donc tester Keycloak et LemonLDAP::NG, mais avez-vous d'autres produits à conseiller (tant que je suis lancé) ? J'ajoute que, dans un futur proche, j'aimerais disposer d'un serveur RADIUS. Ça me permettra de faire de la restriction d'accès sur des équipements réseau (eg. bornes WiFi) : mais j'ignore encore quelle passerelle il pourrait y avoir entre RADIUS et un des IdP testé plus haut. Je sais juste que si je n'avais pas ce projet d'IdP, je connecterais tout simplement le serveur RADIUS sur le serveur LDAP. Merci pour votre attention :) -- DUVERGIER Claude _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 17/01/2019 à 18:52, DUVERGIER Claude a écrit : [..]
J'envisage de monter un serveur "IdP", j'ai donc regardé les solutions qu'on pouvait installer sur nos propres serveur et j'ai retenu : * Keycloak * Gluu * LemonLDAP::NG
J'ai trouvé la documentation de *Keycloak* est assez bien faite et ça m'a permit d'appréhender l'étendue des possibilités : ça semble bien correspondre à mes besoins. Seul petit hic, c'est en Java.
Pour *Gluu*, je trouve la documentation un peu moins précise et il reste quelques points d'ombre sur les possibilités offertes. Point noir : il utilise, en interne, un serveur LDAP et rajouter des métadonnées aux utilisateurs semble compliqué. Bon point : il est distribué sous forme de package .deb.
J'avais déjà découvert *LemonLDAP::NG* il y a des années (sans m'en servir) et ça me branchait bien. Je dirais qu'il semble moins joli que Keycloak mais tout aussi performant. A l'époque, l'intégration du SSO sur les applications web maison m'avait paru aisée (Apache seulement).
Je vais donc tester Keycloak et LemonLDAP::NG, mais avez-vous d'autres produits à conseiller (tant que je suis lancé) ?
LemonLDAP::NG est le logiciel ideal pour ce que tu desire faire et qui propose toutes les fonctionnalites dont tu parle Bonne journée -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/ Editeur de FusionDirectory : http://www.fusiondirectory.org/
Bonjour, je suis l'un des développeurs de LemonLDAP::NG, je pense que le logiciel répondra en effet très bien au besoin. Nous avons travaillé un peu sur l'ergonomie, la dernière version est en bootstrap 4, il est facile d'adapter si besoin le thème graphique (voir quelques exemples : https://lemonldap-ng.org/screenshots#external_references). Au niveaux protocoles, le logiciel fait toujours l'envoi d'en-têtes HTTP mais supporte aussi en natif CAS, SAML et OpenID Connect. Les autres logiciels sont également très bien, ma société (Worteks) intégre également KeyCloak ou simpleSAMLphp. J'ai découvert récemment l'existence de fusionauth (https://fusionauth.io/) mais je n'ai pas eu l'occasion de tester. Concernant la gestion des données LDAP, je renvoie la politesse à Benoît en préconisant FusionDirectory : https://www.fusiondirectory.org/ Nous travaillons d'ailleurs à l'intégration de tous ces produits avec le projet FusionIAM : https://fusioniam.org/ Je ne suis évidemment pas très objectif sur le sujet, mais n'hésitez pas si vous avez des questions sur LemonLDAP::NG, je serai ravi d'y répondre. Et c'est du made in France ;) Clément.
Le 18/01/2019 à 14:52, Clément OUDOT a écrit :
je suis l'un des développeurs de LemonLDAP::NG, je pense que le logiciel répondra en effet très bien au besoin. Nous avons travaillé un peu sur l'ergonomie, la dernière version est en bootstrap 4, il est facile d'adapter si besoin le thème graphique (voir quelques exemples : https://lemonldap-ng.org/screenshots#external_references). Au niveaux protocoles, le logiciel fait toujours l'envoi d'en-têtes HTTP mais supporte aussi en natif CAS, SAML et OpenID Connect.
J'avais effectivement découvert LemonLDAP::NG via une captation d'une de tes présentation (https://www.youtube.com/watch?v=KVBl-EEi-3I) et cela avait beaucoup attiré mon attention :)
J'ai découvert récemment l'existence de fusionauth (https://fusionauth.io/) mais je n'ai pas eu l'occasion de tester.
Celui-ci est apparu dans mes recherches et paraissait coller mais a finalement rapidement été écarté car ne peut pas se synchroniser à un serveur LDAP (ni ne supporte le SAML : c'est volontaire de leur part). Le 18/01/2019 à 15:23, lemonnierk@ulrar.net a écrit :
Alors je peux pas commenter sur l'utilisation, parce que je m'en suis pas servis encore, mais pour l'avoir installé hier justement c'est à peu près aussi douloureux que prévu. Beaucoup de temps perdu à changer des trucs dans les patés de config xml illisible jusqu'à ce que ça tombe en marche, et j'ai absolument aucune confiance dans le résultat parce que je comprend pas ce que j'ai fait pour que ça finisse par marcher ...
Bref, du java habituel.
Le 19/01/2019 à 12:51, Mathieu Poussin a écrit :
Hello.
On utilise KeyCloak depuis quelques temps via SAML2 et oAuth/OpenID avec un backend Active Directory. Et rien a redire, ca fonctionne très bien, c'est facile a configurer, mettre a jour et personaliser (On construit notre propre container pour rajouter nos propres templates et quelque custom config pour notre C.A interne). [...]
Voila voila.
C'est justement ma plus grande crainte ! KeyCloak à effectivement l'air complet, fonctionnel, et ergonomique. Mais pour avoir déjà installé et maintenu EJBCA (une PKI open-source) : le Tomcat + XML s'éloigne trop de mes habitudes/compétences en httpd/Nginx + PHP. Donc à choisir, si un autre produit fait tout aussi bien que Keycloak mais se rapproche plus de mes compétences je vais le privilégier. Je n'ai pas vraiment besoin d'interface portail/annuaire pour les utilisateurs car on gère cela via une application maison type Intranet (ce qui explique pourquoi je n'ai jamais pris le temps de tester FusionDirectory) donc je risque de désactiver plusieurs des fonctions correspondantes et c'est pourquoi je peux "sous-évaluer" les produits qui offre ces fonctionnalités. Merci à tous pour ces réponses et propositions : ça me conforte dans ma short-list : LemonLDAP::NG et Keycloak qui sont fonctionnels clé en main. -- DUVERGIER Claude
Le lun. 4 févr. 2019 à 15:24, DUVERGIER Claude <frsag.ml@claude.duvergier.fr> a écrit :
J'avais effectivement découvert LemonLDAP::NG via une captation d'une de tes présentation (https://www.youtube.com/watch?v=KVBl-EEi-3I) et cela avait beaucoup attiré mon attention :)
Salut, pour info j'ai fait une conférence hier au FOSDEM, qui sera un peu plus à jour (ça parle des nouveautés de la version 2.0). Il y a la vidéo et les diapos dans le lien suivant : https://fosdem.org/2019/schedule/event/lemonldap/ Clément.
J'ai trouvé la documentation de *Keycloak* est assez bien faite et ça m'a permit d'appréhender l'étendue des possibilités : ça semble bien correspondre à mes besoins. Seul petit hic, c'est en Java.
Alors je peux pas commenter sur l'utilisation, parce que je m'en suis pas servis encore, mais pour l'avoir installé hier justement c'est à peu près aussi douloureux que prévu. Beaucoup de temps perdu à changer des trucs dans les patés de config xml illisible jusqu'à ce que ça tombe en marche, et j'ai absolument aucune confiance dans le résultat parce que je comprend pas ce que j'ai fait pour que ça finisse par marcher ... Bref, du java habituel.
Hello. On utilise KeyCloak depuis quelques temps via SAML2 et oAuth/OpenID avec un backend Active Directory. Et rien a redire, ca fonctionne très bien, c'est facile a configurer, mettre a jour et personaliser (On construit notre propre container pour rajouter nos propres templates et quelque custom config pour notre C.A interne). Tu a du 2FA intégré par défaut via Google Authenticator et pas mal de plugins pour d'autre systèmes si besoin (genre Duo Login, etc.) Je crois qu'il y a aussi un mode qui permet de l'utiliser comme proxy pour les apps qui ne supportent pas es auth standard genre oAuth/SAML et qui va injecter du BASIC auth aux requetes qui passent par le proxy, mais je n'ai jamais utilisé ce mode. Ca nous sert aussi de portail self-service pour permettre aux users de reset leur password Active Directory si il a expiré ou ils ne s'en rappellent plus (Avec un lien sur leur boite mail corpo), ils ont aussi dans ce même portail la possibilité de voir toutes leurs sessions et de les fermer manuellement par exemple (Ainsi que configurer leur OTP). Voila voila. ---- On Thu, 17 Jan 2019 18:52:20 +0100 DUVERGIER Claude <frsag.ml@claude.duvergier.fr> wrote ---- Pré-scriptum : Premier message sur cette liste, je suis FRnOG depuis quelques temps mais je n'ai découvert FRsAG que récemment. Donc j'en profite pour adresser un *bonjour à tous* et me présenter en quelques mots clés : homme, admin réseau, admin serveur, debian, open-source, lyon, ~120 utilisateurs. Chez mon employeur, pour gérer les informations sur les utilisateurs (nom, prénom, e-mail, uid, nom d'utilisateur, mot de passe, etc.) on dispose d'un serveur LDAP ce qui permet à chacun de n'avoir qu'un seul mot de passe pour accéder à toutes les applications Web qu'on utilise (via connecteur LDAP dans l'application ou via module Apache/Nginx style "mod_authnz_ldap"). Mais pour (enfin) pouvoir : * Proposer du SSO aux utilisateurs ("sign-on" et "sign-out") * Contrôler/gérer/contrôler tout ça (d'un endroit unique) * S'ouvrir aux autres applications via les standard tels que OAuth, OpenID, etc. J'envisage de monter un serveur "IdP", j'ai donc regardé les solutions qu'on pouvait installer sur nos propres serveur et j'ai retenu : * Keycloak * Gluu * LemonLDAP::NG J'ai trouvé la documentation de *Keycloak* est assez bien faite et ça m'a permit d'appréhender l'étendue des possibilités : ça semble bien correspondre à mes besoins. Seul petit hic, c'est en Java. Pour *Gluu*, je trouve la documentation un peu moins précise et il reste quelques points d'ombre sur les possibilités offertes. Point noir : il utilise, en interne, un serveur LDAP et rajouter des métadonnées aux utilisateurs semble compliqué. Bon point : il est distribué sous forme de package .deb. J'avais déjà découvert *LemonLDAP::NG* il y a des années (sans m'en servir) et ça me branchait bien. Je dirais qu'il semble moins joli que Keycloak mais tout aussi performant. A l'époque, l'intégration du SSO sur les applications web maison m'avait paru aisée (Apache seulement). Je vais donc tester Keycloak et LemonLDAP::NG, mais avez-vous d'autres produits à conseiller (tant que je suis lancé) ? J'ajoute que, dans un futur proche, j'aimerais disposer d'un serveur RADIUS. Ça me permettra de faire de la restriction d'accès sur des équipements réseau (eg. bornes WiFi) : mais j'ignore encore quelle passerelle il pourrait y avoir entre RADIUS et un des IdP testé plus haut. Je sais juste que si je n'avais pas ce projet d'IdP, je connecterais tout simplement le serveur RADIUS sur le serveur LDAP. Merci pour votre attention :) -- DUVERGIER Claude _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (7)
-
Benoit Mortier -
Clément OUDOT -
DUVERGIER Claude -
lemonnierk＠ulrar.net -
Mathieu Poussin -
pierre-philipp braun -
Xavier ROCA