GSoC 2008 - Proposal for WUI

Project summary

InterLDAP-WUI is a J2EE program intended to offer an advanced LDAP directory content management system. It uses recent frameworks and tools like Tapestry 5, Spring 2 and Maven 2. It is designed to be very modular:

InterLDAP-WUI-Software-Architecture.png

How to reach us

Please use :

  • IRC: #interldap@freenode.net
  • Mailing list: interldap-dev@objectweb.org

Proposals - Ideas list

We need help on the following items:

  • Create an ACEGI module for LemonLDAP::NG WebSSO
  • Create an ACEGI module for Liberty Alliance authentication
  • Improve interaction with Ajax components (in forms essentially)
  • Formalise LQL and develop a reference implementation
  • Add an authorization rules editor (+ LQL editor)
  • Have LDAP as a backend for enhanced schema and authorization rules
  • Manage photos (with a choice of using a photo as an LDAP attribute or a link to a file on disk)
  • Improve the search component
  • Separate the generic/dynamic form engine from InterLDAP
Of course, all ideas are welcome!

Feel free to get in touch to define your own project amongst these, or consult some of the more detailed ideas below.

LDAP Query Language (LQL)

While this is heavily used in the WUI, the scope of this project may be wider than InterLDAP itself

Retrieving information from an LDAP directory currently relies on the LDAP search operation using just 3 parameters - base, scope and filter. Queries that are simple to express in everyday spoken language may require complex filters and multiple successive search operations to retrieve their results from a directory server.

LDAP Query Language (LQL) aims to provide a simple but powerful language to formalize the expression of such queries. This includes a standard translation mechanism to elementary LDAP operations. In short, LQL is to a directory what SQL is to a relational database.

For example: "Get the name and emails of all the project managers I've worked with" (this assumes projects and their teams are in your directory).

This language currently has various uses in InterLDAP projects including:

  • Authorization rules for the WUI (authorizing display items, search types, etc)
  • ACLs in OpenLDAP (via a converter in Java)
  • Advanced referrals in InterLDAP (ie, referrals with a search specified in LQL)
The aim of the project would be to:
  1. Write a detailed specification of the language
  2. Implement a reference parser/interpreter engine (preferably in Java by extending the current implementation)
  3. Extend such an engine to include caching of results and intermediate results

Add an authorization rules editor (+ LQL editor)

Authorization rules in the WUI are written in LQL (a simple but powerful language to express complex queries in LDAP directories - see above). A visual interface to edit these rules would greatly improve their usability.

Such an editor could include:

  • Syntax coloring and checking
  • A test mode to see a list of entries returned by a given rule
  • A graphical representation of the different parts in a rule
  • A magical button to read the rules straight from your brain via a USB interface (OK, maybe that's for another year's SoC...)

Have LDAP as a backend for enhanced schema and authorization rules

The standard LDAP schema contains basic information such as a name, syntax, multi-valuation. This allows dynamic generation of a simple user interface, as is done in the InterLDAP WUI. A more advanced and user-friendly interface needs more: a list of possible values, a default, the translation of "Yes" and "No" in booleans according to context, etc. InterLDAP stores this information in an 'enhanced schema', closly linked to the standard LDAP schema.

Currently, the WUI uses XML files to store the enhanced schema data. We would like to store this in the LDAP directory itself (to allow sharing with other applications and LDAP replication). A few solutions to do this could be explored:

  1. Integrate extra information in standard schema description using custom fields
  2. Create a LDAP schema (the standard kind) to store this information in special objects, and define a hierarchy.
Similarly, authorization rules for the WUI (written in LQL - see previous subject) are currently in LQL files but could benefit from being integrated in the directory.

The Java code has been written to allow easy transition to this mecanism, so this is a good project to ease into the code base.

Separate the generic/dynamic form engine from InterLDAP

One of the great strengths of InterLDAP is its capability to automagically build forms to edit LDAP entries, given user rights and metadata configuration. The cool features are that this metadata may be changed at run time by an admin (and so are the forms, of course) and that the engine is quite generic: it only needs a data model and metadata describing it.

So, it would be really cool if we can split this generic engine out of InterLDAP, and give it life on its own as "generic form framework for Tapestry 5". Moreover, Tapestry 5, as a component oriented framework fits really well for this kind of purpose.

The big picture is to be able to have a kind of "beanEditForm" component, configurable at run time (so, we have that), and pluggable on top of any kind of domain model (that's new).

To achieve this goal, at least two points should be improved or reshaped:

  • One the central idea of the InterLDAP engine layer is that it's the domain objects that matter, and that the form engine is just a way to Create/Update/View them. But today the only one that supports data/domain model is LDAP entries, and we fear that this sole support brought some tight coupling.
  • We use our built-in metadata model to describe the form behavior. Actually, it describes a little more than that. So, it would be great to look at the work done in Xforms, Xforms-tiny, WebForms, etc to see:
    • what exactly is the purpose of these standards, and if it matches our own;
    • if we can use one of them in place of our metadata.
The idea is clearly not to gain a "blablabla compliant" stamp, but to have the best possible solution, build on the shoulders of others giants if there is a giant available for that.