Articles : Sortie de Lemonldap::NG 0.9
Posté par Xavier Guimard (page perso, ). Modéré le 10 mars 2008.
Principale innovation : l'intégration d'un portail d'authentification compatible Liberty-Alliance. Cette composante « service provider » permet à un utilisateur de se trouver authentifié sur le service protégé par Lemonldap::NG tout en étant authentifié auprès d'un fournisseur d'identité de son choix. Au menu également quelques corrections de bugs et de nombreuses améliorations des API.
Dernière nouvelle enfin et pas des moindres, Lemonldap::NG est désormais intégré à Debian (la version 0.9 passera de « unstable » à « testing » dans quelques jours).
![[fr]](../images/fr.png)
Lemonldap::NG (592 hits)-
Démo FederID (286 hits)
![[en]](../images/en.png)
Portail Liberty-Alliance (189 hits)-
FederID (167 hits)
-
Démo de l'interface d'administration le Lemonldap::NG (330 hits)
> Lire la dépêche (3 commentaires, moyenne: 2,3).
Vous avez demandé le commentaire #912058.
Run by 
Cette page a été générée par Templeet en 0.0468s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Liberty Alliance
Le support Liberty Alliance est en effet une fonctionnalité intéressante, apportée grâce au projet FederID.
En effet, une application Web peut être facilement transformée pour venir s'inscrire dans le WebSSO de LemonLDAP::NG : il suffit qu'elle récupère l'identifiant de l'utilisateur (et d'autres informations si nécessaires) dans les en-têtes HTTP au lieu de présenter le formulaire d'authentification. Coût d'intégration : très faible.
Faire du Liberty Alliance est plus complexe : l'application doit pouvoir dialoguer avec un fournisseur d'identités en utilisant des assertions SAML. La bibliothèque Lasso[1] (utilisée dans les différents composants de FederID, dont LemonLDAP::NG), permet de réaliser cette intégration, mais prend plus de temps (et nécessite plus de connaissances).
L'idée ici est de transformer LemonLDAP::NG en fournisseur de service (donc vu comme une application client vis à vis d'un fournisseur d'identités), qui saura créer automatiquement une session SSO sur les applications qu'il protège déjà : c'est donc une solution très simple d'intégrer une application Web dans un cercle de confiance Liberty Alliance.
[1] http://lasso.entrouvert.org/
[^]Re: Liberty Alliance
Je suis pas spécialiste des applications webs, mais par exemple, si je prends un forum php classique ( genre punbb ), il faut quand même gerer la base de compte quelque part, et donc tu te retrouves à quand même dupliquer la base des comptes et à devoir désactiver des fonctionnalités comme le changement de mot de passe, etc.
Donc j'irais pas dire que c'est facile de transformer une appli, ou alors, il faut rajouter "c'est facile de transformer sans se soucier du reste et sans avoir peur de faire un truc pas trés propre".
[^]Re: Liberty Alliance
Je suis un des développeurs de Lasso et je suis justement en train d'écrire un kit simple pour "libertyser" des applications PHP à partir du binding
PHP de lasso (qui est nouveau lui aussi) . Il est tout à fait possible de se passer complètement de la base utilisateur locale si l'application ne demande pas une customisation trop importante i.e s'il faut
juste stocker un email et un pseudo l'IdP peut s'en charger et le fournir à chaque login dans l'assertion SAML. Il suffit ensuite de le stocker
dans le cookie de session. Ça supprime tout le code de session utilisateur. Ça suppose de prévoir SAML 2.0 comme unique technique d'authentification
dés le départ ce qui est je l'avoue rarement le cas. Même s'il faut stocker un peu de parmétrage (recevoir les email d'info, afficher les pages avec
le thème xyz, etc...) ça permet de limiter les informations critiques stocker en permanence localement comme les emails ou des numéros de CB. Le site
peut se procurer ces informations (on dit des attributs dans le jargon liberty) au coup par coups avec autorisation explicite de l'utilisateur chez
un fournisseur d'attributs.