KPTN a écrit 100 commentaires

Pour ceux que ça intéresse, j'ai rédigé un petit article, principalement sur le thème Sécurité : http://blog.savoirfairelinux.com/2015/theme-securite-rmll-2015/

Bonjour,

il est possible de créer son propre Handler. Nous en avons d'ailleurs créés quelques-uns pour des besoins spécifiques, voir :

• http://lemonldap-ng.org/documentation/latest/applications/zimbra
• http://lemonldap-ng.org/documentation/latest/securetoken
• http://lemonldap-ng.org/documentation/latest/handlerauthbasic

Toute la documentation est traduite en Français à l'aide du logiciel omegaT. Elle est disponible dans les paquets Debian et RPM.

Comment c'est fait ? Via un polling ? Si oui il regarde des méta information du type numéro de révision des données ?

Si OpenLDAP est en source, on peut utiliser Syncrepl et se comporter comme un client de réplication OpenLDAP standard pour obtenir les infos. Sinon, on fait des requêtes régulièrement (par défaut toutes les 5 secondes) en se basant sur modifyTimeStamp pour récupérer les dernières modifications.

Un mécanisme similaire existe aussi pour interroger une base de données source en faisant un SELECT sur une table.

LSC est en effet une application Java. Nous fournissons des scripts Shell permettant de lancer facilement les connecteurs. Il y a deux types de connecteurs :
- Synchrone : le connecteur est lancé manuellement ou via cron et s'arrête une fois toutes les entrées synchronisées
- Asynchrone : le connecteur est lancé manuellement ou via un script d'init et reste en attente des modifications effectuées sur la source

Plus de détails à ce sujet ici : http://lsc-project.org/wiki/documentation/latest/execution/start

Concernant la supervision, des scripts sont fournis : http://lsc-project.org/wiki/documentation/latest/monitoring/start

Enfin, il est possible d'avoir un LDIF, il suffit de lancer le connecteur en mode dry-run (lecture seule) et de configurer un logger LDIF qui contiendra toutes les modifications qui auraient été faites par le connecteur: http://lsc-project.org/wiki/documentation/latest/configuration/logging#outputting_the_synchronization_in_ldif_files

Oui, on veut bien de l'aide pour la doc :)

On a quand même essayé de décrire toutes les options : http://lsc-project.org/wiki/documentation/latest/configuration/start et publié quelques tutoriels, dont celui OpenLDAP -> AD : http://lsc-project.org/wiki/documentation/tutorial/openldaptoactivedirectory

Bonjour,

Voici par exemple comment se connecter à une base de données : http://lsc-project.org/wiki/documentation/latest/configuration/connections/database, ou à Google Apps : http://lsc-project.org/wiki/documentation/latest/configuration/connections/googleapps

La déclaration des services est ensuite expliquée ici : http://lsc-project.org/wiki/documentation/latest/configuration/service

Pour la partie REST, il faut en général écrire son propre plugin (chaque API est spécifique à un produit). Le plugin OBM peut service d'exemple pour écrire son propre plugin : http://lsc-project.org/wiki/documentation/plugins/obm

Oui, il y a une fonction SOAP getCookies qui permet de faire ça, activable dans le backend de sessions SOAP:

##@method SOAP::Data getCookies(string user,string password, string sessionid)
# Called in SOAP context, returns cookies in an array.
# This subroutine works only for portals working with user and password
#@param user uid
#@param password password
#@param sessionid optional session identifier
#@return session => { error => code , cookies => { cookieName1 => value ,... } }

C'est le format Doxygen.

Bonjour,

je vais essayer de répondre aux différentes questions :

1) CAS est avant tout un protocole (http://www.jasig.org/cas/protocol), c'est aussi un logiciel implémentant ce protocole. LemonLDAP::NG implémente également ce protocole. Côté logiciel, LemonLDAP::NG a de nombreux avantages sur CAS, comme le support de nombreux moyens d'authentifications, de la politique des mots de passe LDAP, du contrôle d'accès, etc.

2) C'est en effet le principe. Dans le fonctionnement standard de LemonLDAP::NG toutefois, la transmission de l'identifiant se fait par en-tête HTTP vers l'application, alors que CAS nécessite d'intégrer un bibliothèque cliente (on parle de cassification).

a) C'est moins simple car le système SSO doit positionner un cookie. LemonLDAP::NG propose toutefois un WebService permettant de le faire.

b) C'est standard, LemonLDAP::NG possède un mode d'authentification Apache, et également un Handler AuthBasic permettant de le faire pour certaines applications en particulier.

La documentation est faite sur le wiki du projet (http://lemonldap-ng.org) et copiée par un script sur le dépôt de code, ce qui permet d'avoir une version déconnectée, intégrée directement dans l'interface d'administration.

Le plus simple pour synchroniser les deux est d'utiliser LSC

Sinon OpenLDAP pourra certainement bientôt devenir le backend LDAP de Samba 4, les travaux sont en cours. Il y aura sans doutes des annonces importantes à la LDAPCon cette année ;)

Je me permets de répondre car je suis l'un des organisateurs.

Pour l'édition précédente en 2011, le tarif était plutôt de l'ordre de 500 €, on a réduit de moitié.

L'objectif de cette conférence n'est pas de faire de l'argent sur le dos des participants (parce que c'est ce que le commentaire insinue), mais d'accueillir dans les meilleurs conditions des conférenciers et des participants du monde entier.

Les organisateurs de cette conférence sont bénévoles, toute aide est la bienvenue !

Pour ceux qui sont intéressés par cette technologie, sachez que ce moyen d'authentification est implémenté dans différents logiciels libres de WebSSO comme LemonLDAP::NG et OpenAM.

Voici le ticket que j'ai ouvert : https://redmine.linid.org/issues/153

En cherchant un peu, j'ai vu que le packaging Ubuntu préconfigurait OpenLDAP pour que la configuration passe par LDAPI : https://help.ubuntu.com/11.04/serverguide/C/openldap-server.html

Je n'ai pas testé LDAPI pour l'instant mais ça sera intéressant de le faire.

Pour le mini how-to, il fonctionne parfaitement à partir d'un OpenLDAP compilé depuis les sources trouvées sur http://www.openldap.org

J'ouvre un ticket dans la forge du projet pour étudier le support d'OpenLDAP fourni par Ubuntu (ce sera plus efficace que des commentaires ici).

Bonjour,

je confirme que cette conférence était très intéressante. J'avais prévu de faire un article de blog dessus, mais il s'est perdu dans une faille spatio-temporelle. Voici ce que j'en ai retenu personnellement :
- LDAP n'est pas mort ! La conférence d'entrée de Ludovic Poitou (Is LDAP dead?) a eu l'effet escompté : faire un bilan de l'utilisation de LDAP et proposer des pistes pour améliorer son adoption. Parmi ces pistes, la révision de certaines contraintes du standards comme l'impossibilité de créer des groupes vides, ou la validation de brouillons (drafts) en RFC.
- Les communautés libres étaient bien présentes : OpenDJ, OpenLDAP, Apache DS (server et studio), LSC, LemonLDAP::NG. On regrette de ne pas avoir vu les gens de port 389 (Fedora DS), ni aucun représentant des produits propriétaires (Microsoft, Oracle, IBM, Novell, ...)
- OpenDS est bien mort (vf. les graphiques Ohloh du projet), son successeur OpenDJ a pris le relai et est très actif avec en prévision dans les prochaines versions la synchronisation des mots de passe Samba et du packaging RPM et Debian.
- OpenLDAP reste le serveur de référence quand on aborde les sujets de la sécurité et des performances. H. Chu a pu présenter le dernier backend MDB, très prometteur en performance et en exploitation (on s'affranchit enfin de BerkeleyDB)
- Une nouvelle API LDAP, initiée il y a deux ans par les projets OpenDS et ApacheDS, et qui sort bientôt en version stable chez ApacheDS (OpenDJ n'est pas loin non plus)
- Un framework de test étendant JUnit, appelé LDAPUnit, fait par ApacheDS
- La sortie prochaine de Apache Directory Studio 2.0, incluant des templates d'édition d'entrée et l'utilisation de la nouvelle API LDAP
- Les gestion par LSC des connexions persistantes vers OpenLDAP, permettant la mise à jour en temps réel d'autres annuaires LDAP ou bases de données
- Le support de la ppolicy dans LemonLDAP::NG, avec la gestion en particulier de la réinitialisation forcée du mot de passe

Voilà, j'oublie certainement beaucoup de choses ! Quelques photos ici pour ceux que ça intéresse : https://picasaweb.google.com/107065235254176813843/LDAPCon2011AHeidelberg

Si tu veux faire du SAML 2, Shibboleth n'est pas la seule solution. En libre tu trouveras au moins :
- LemonLDAP::NG
- Authentic
- OpenAM

ça vaut le coup d'y jeter un œil.

Salut Julien,

le support Kerberos est pour l'instant assez léger : LemonLDAP::NG se repose sur le mod_auth_kerb d'Apache pour authentifier de manière transparente les utilisateurs : http://lemonldap-ng.org/documentation/latest/authapache

Faire fournisseur Kerberos est une très bonne idée, ce n'est pas officiellement dans la feuille de route, mais en se basant sur les modules CAS, OpenID ou SAML, il est relativement simple de créer un nouveau module fournisseur. Bien entendu il faut y consacrer un peu de temps, toute aide est la bienvenue :)

Tous les sites du monde compatibles OpenID (et acceptant ton serveur OpenID) : oui

Bienvenue dans le monde du SSO !

Cela dit, il existe des fournisseurs OpenID qui savent faire autre chose que du login/mot de passe. On parle plutôt de problème d'authentification forte dans ce cas.

Je serai également à cette conférence pour présenter LemonLDAP::NG : http://lemonldap-ng.org

J'espère pouvoir retrouver certains compatriotes du vieux continent là-bas !

Pour Flex, il a l'air d'être possible de récupérer le REMOTE_USER :
http://www.mail-archive.com/flexcoders@yahoogroups.com/msg15(...)

C'est très intéressant ça ! Est-ce que ce serait possible d'avoir plus d'information sur la migration Siteminder -> LemonLDAP::NG ? Pourrait-on mettre ça sur le site du projet, dans les références ?

En plus d'Authentic, il existe d'autres IDP SAML2 libres :
* simpleSAMLphp
* OpenSSO

La prochaine version de LemonLDAP::NG sera également fournisseur SAML2 (en plus de fournisseur OpenID et CAS).

Bref, on a l'embarras du choix :)

En réalité, Shibboleth a évolué en version 2 pour se fondre dans le standard SAML2 (modulo il me semble la gestion des formats d'attributs).

Il existe un module Apache basé sur Lasso qui s'appelle mod_mellon. L'intégration est donc la même qu'avec le module Apache Shibboleth.

Il existe ensuite plusieurs façons d'intégrer une application :
* Implémenter SAML2 directement dans l'application (en utilisant les bindings Lasso, ou d'autres bibliothèques)
* Utiliser un mandataire qui se charge de la couche SAML2. Le module Apache rentre dans cette catégorie. On peut également citer LARPE (édité également par Entr'ouvert), et désormais LemonLDAP::NG qui compte SAML2 parmi ses modules d'authentification.