KPTN a écrit 100 commentaires

Oui, on peut l'ajouter dans les liens sous la dépêche, ou dans le corps de l'article

Vous trouverez ici un compte-rendu complet de la conférence : https://www.worteks.com/fr/2019/11/19/retour-sur-la-7e-ldapcon-a-sofia/

Si certains d'entre vous sont motivés pour faire le déplacement, Worteks peut vous offrir l'entrée à la conférence. Contactez-moi si cela vous intéresse !

Dans l'écosystème Perl on peut également citer LemonLDAP::NG, une solution libre de WebSSO, contrôle d'accès et fédération d'identité, massivement déployée dans le secteur public en France.

J'aurai le plaisir d'y animer un atelier sur LemonLDAP::NG, merci encore aux organisateurs !

Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?

Un paramètre permet de lister les hôtes de confiance (vers qui une redirection est autorisée). On peut autoriser tout un sous-domaine par exemple.

Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.

Pour être précis, le scope "openid" est obligatoire, sinon tu fais du OAuth2 et pas du OpenID Connect. Et donc l'utilisateur doit accepter ce scope.

Toutes les solutions que je connais permet de bypasser cette étape au besoin

En effet, LL::NG le permet aussi, mais c'est contraire au protocole.

Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?

Attention, un ID Token est un JWT qui n'a pas vocation à être utilisé en authentification Bearer, c'est l'access token qui est prévu pour ça. Pour être bref, oui OpenID Connect peut marcher pour protéger applications et API, mais ce n'est pas la seule solution et elle nécessite que les applications et API implémentent le protocole.

Pour ngnix il y a https://github.com/zmartzone/lua-resty-openidc (lui aussi certifié)

Merci, je ne connaissais pas.

Tiens, d'ailleurs, puisqu'on en parle : ça donne quoi LemonLDAP avec autre chose qu'Apache? Nginx c'est bon? Traefik? Caddy? Y'a des retours d'expérience sur ce type de choses?

LemonLDAP::NG est compatible Apache, Nginx et tout serveur Plack. C'est désormais Nginx qui est recommandé, car le support de mod_perl dans Apache 2.4 ne permet pas d'avoir des performances correctes.

Bonjour Mathieu,

en effet OpenID connect apporte à peu près la même fonctionnalité, à ceci près qu'il faut en effet déployer un agent sur le client et le configurer (tu as ici la doc dédié à LemonLDAP::NG : https://github.com/zmartzone/mod_auth_openidc/wiki/LemonLDAP::NG).

Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx. D'autre part, OpenID Connect exige que le client soit déclaré au niveau du serveur pour obtenir en particulier un client_id et un client_secret. Avec le mode SSOaaS de LL::NG, pas de déclaration nécessaire dans le serveur. Enfin OpenID Connect impose l'utilisation de scope et de claims, avec validation du consentement de l'utilisateur, ce qui est plutôt une bonne chose mais pas forcément souhaité dans le déploiement de micro services.

En effet le nom est peu trompeur, il ne s'agit pas d'un annuaire LDAP mais d'un service Web, équivalent à des logiciels comme CAS, KeyCloak, simpleSAMLphp, etc.

Le terme LDAP était présent à l'origine car le logiciel ne savait utiliser qu'un annuaire LDAP pour l'authentification, mais ce n'est plus d'actualité car on supporte désormais de nombreuses méthodes : https://lemonldap-ng.org/documentation/latest/start#authentication_users_and_password_databases

Merci pour ces retours, très content que ça vous plaise !

En fait c'est un peu le contraire : l'attribut unicodePwd est en écriture seule. Il est donc possible de modifier sa valeur, mais impossible de la lire, donc de sauvegarder la valeur initiale.

Il semblerait que l'attribut userPassword dans AD ait à peu près les mêmes propriétés : https://msdn.microsoft.com/en-us/library/cc223249.aspx

Quoi qu'il en soit, cela n'empêche pas le logiciel Self Service Password de faire son travail : l'utilisateur peut modifier le mot de passe de son compte dans AD via une interface Web.

Les mots de passe sont bien stockés dans Active Directory (attribut unicodePwd), il est donc possible de les modifier par une requête LDAP.

Pour information la suppression de schéma dans le backend cn=config (comme la suppression de n'importe quel nœud de configuration d'ailleurs) devrait être possible dans OpenLDAP 2.5, ou alors dans OpenLDAP 2.4 à condition de le compiler avec l'option SLAP_CONFIG_DELETE.

Sinon bravo pour cet excellent outil !

En effet il y avait un problème de configuration sur la démo, cela fonctionne désormais. Merci pour la remarque.

Pour ceux qui veulent voir à quoi ça ressemble sans installer le logiciel, une démonstration est en ligne : http://ltb-project.org/star-pages/

Merci !

L'objectif est justement de supprimer les petits développements internes que personne ne maintient :)

N'hésite pas à faire des demandes de fonctionnalités s'il manquait des choses dans l'outil.

Il existe un mécanisme de posthook: http://ltb-project.org/wiki/documentation/self-service-password/latest/config_posthook

Cela permet de propager le nouveau mot de passe sur d'autres référentiels, comme des bases de données.

Il faut bien que tu mettes le DN complet du groupe dans ta configuration Apache :

Require ldap-group cn=mongroupe,ou=Groups,dc=maboite,dc=fr


En effet le module ppolicy est fait pour ça. Il va gérer plusieurs choses :
- Contrôle lors de l'authentification : blocage de compte en cas d'authentifications ratées, expiration du mot de passe, réinitialisation forcée
- Contrôle lors du changement de mot de passe : taille, présence dans un historique, robustesse, etc

Concernant ta question initiale, tu peux configurer ppolicy pour bloquer un compte après par exemple 5 authentifications ratées dans un intervalle de 60 secondes, pour une durée de 10 minutes. Tout cela est paramétrable. Et tu peux associer des politiques différentes à des comptes différents.

Je me permets d'ajouter également le mien : https://blog.savoirfairelinux.com/2016/openid-kinect-nouveau-standard-rapprocher-sso-utilisateurs/

Nous avons démarré une liste ici : http://lemonldap-ng.org/documentation/latest/applications

Mais en effet n'importe quelle application compatible avec une authentification Apache (REMOTE_USER) ou CAS est compatible avec LemonLDAP::NG.

En effet, je ne comprends pas bien ce qu'il se passe. Les images ont bien été chargées sur le hub docker.

Il reste la possibilité de construire l'image depuis le Dokerfile : https://github.com/coudot/lemonldap-ng-docker

En effet, le mot de passe est stocké dans l'attribut unicodePwd. Il est accessible en écriture si la connexion est en LDAPS. Il n'est jamais accessible en lecture.

Ce serait avec plaisir. J'avais intégré reCaptacha suite à une contribution sur le sujet mais je suis preneur d'autres solutions de captcha libres.