Choix généraux de développement

Le développement d'InterLDAP WUI v2 a été un refactoring majeur, accompagné de nombreux redéveloppement, par rapport au code de la version 1. Ce choix a été effectué afin de pouvoir redéfinir "WUI" comme un framework de développement d'applications de gestion d'identités.

En effet, l'expérience de Linagora dans ce type de projet montre que chaque organisation nécessite un adaptation extrême de la gestion des identités aux process interne de l'entreprise. La première version d'interLDAP tirait une grande partie de sa force de sa capacité à s'adapter à ces process par configuration. En contrepartie, la complexité du logiciel était devenu telle qu'il était devenu quasiment in-maintenable.

Il a été décidé pour InterLDAP v2 de simplifier le logiciel au prix du sacrifice d'une part de sa généricité : une partie de la complexité du code nécessaire pour permettre une adaptation par configuration a été reporter dans la nécessité d'effectuer des développement spécifique.

Il était néanmoins impensable de d'effectuer une refactoring menant à une application plus spécialisé que la version 1, c'est pourquoi il a été choisi de développer un framework générique de développement d'application de gestion d'identité, libre et modulable, sur lequel s'appuieraient des développement spécifique, liés aux besoins très particuliers de chaque client.

Cette nouvelle architecture imposait l'utilisation d'un framework applicatif et d'un framework web flexibles, légers, auxquels il serait aisé d'ajouter ou supprimer des composant. Dans les deux cas, l'utilisation d'un framework d'IoC fournissant de l'injection de dépendance et mettant en exergue le couplage lâche entre les modules de l'application était naturel.

Le choix s'est porté sur Spring, qui est un framework applicatif exceptionnel par sa richesse, sa versatilité et sa maturité, et sur Tapestry 5, dont l'approche "orienté composants" et la simplicitée s'adapte parfaitement aux besoins évoqués.

Au fil des développements, d'autres briques opensources on été ajoutées, choisies à chaque fois pour leur simplicité et leur efficacité, comme par exemple Xstream pour le marshmalling XML, EhCache pour le cache de données.

Architecture générale

Architecture fonctionnelle d'interLDAP WUI

InterLDAP WUI remplie trois grands buts fonctionnels dans la gestion des idendités :

  • c'est un navigateur LDAP "user friendly", dans le sens où il présente des informations LDAP compréhensibles par un utilisateur lambda ;
  • c'est un éditeur LDAP avancé, auquel peut être adjoint la logique métier nécessaire à la gestion du cycle de vie des identités numériques et spécifique à chaque entreprise ;
  • il possède un système de droits suffisamment évolué pour englober les problématiques de consultation, de modification et de délégation propre à la gestion des identités électroniques.

Architecture logicielle

L'architecture générale de l'application est relativement classique et reprend le découpage fonctionnel précédent :

  • une couche basse, interldap-core (en vert), définit les accès aux données LDAP ainsi que la logique concernant les méta-données appliquées aux classes ; C'est elle qui est en charge de l'interprétation des données LDAP afin de les rendre agréables ;
  • une couche médianne (interldap-wui-common, en bleu) s'occupe de la gestion de la logique métier et de la définition des composant générique ;
  • une couche transverse (interldap-authorizations, en violet) prend en charge la gestion de droits d'accès à chacune des ressources mise en jeu.
La dernière couche, en rouge, correspond à l'implémentation spécifique du framework pour un cas particulier. C'est elle qui comportera les composants spécifiques, la configuration de l'application, etc. Comparativement aux trois autres module, celui-ci est beaucoup plus fin.

architecture-interldap.png

Le schema fait également apparaître en jaune le domaine de compétence des deux principaux framework (Spring et Tapestry 5).