An informative note to all the ldap-related modules maintainers.
I am working (I am half the way to the goal, ATM) to a "next-generation" version of the ldap integration and provisioning modules, to fit some of the needs of the company I work for.
These needs are mostly the management of multiple entries types, not only persons, and improved functionality in entries management.
The needs
We have person objects, associated with users. Persons are members of organizations (using the memberUid attribute of the organization, or the oRDN on the person). Then each organization has some administrators (defined using the adminUid attribute). Administrators are allowed to make changes to the organization entry, and manage membership. Members are allowed to see the organization entry (and possibily entries of other members of the same company)
How I did that
What I wrote is a module that handles ldap entries in a cck-like way, something similar to what ldapcm module was intended to be.
We have objects defined in the database, and associated with object manager classes (one, at the moment).
Each object has many associated fields, associated with field manager classes (eg. text, password, email, selectbox, entry reference, ..).
The field manager classes provides formatting, editing widget, validation, and everything needed to manage the value of a given attribute.
Then, for each server we can define the base DN in which objects of each type are stored.
The multi-server management mechanism is not very clear at the moment, since there are many ways to handle that, and I first need to know as many needs as possible in terms of multi-server configuration, before writing that in a definitive way.
Any comments / suggestions / questions?
I'm going to release the code as soon I clean it up a bit. At the moment, I'm working on the entries creation/editing support to bring back the provisioning functionality (broken by ldapdata changes).
- Question: Do you think this should be the 6.x-2.x of ldap_integration/ldap_provisioning? There is no direct upgrade procedure at the moment, but it would be possible to write that.
- Question: To ldap and ldap_apimodule maintainers: do you think we could integrate things, to make "the big one" module to be used as a base for all the LDAP-related stuff?
Comments
LDAP
With the LDAP module suite, we are designing for an LDAP API as the base of the suite, with server configuration, authentication, and authorization built into the suite. We are also designing for any likely candidates that could leverage an LDAP API (see http://drupal.org/node/964226); but tyring to keep the core modules (ldap api, ldap authorization, ldap authentication) very solid with features/exportable support, themeable, accessible, full unit test coverage, a group of functional test users with different ldap setups, and good documentation. We see this as "the big one", (but not like in the Sanford and Son's sitcom. ) So there is definately room for your contribution in the project. The thread of roles people are interested in is at: http://drupal.org/node/806068 and a rough look at the class structure is at http://dev.digitalactionsproject.org/wiki/Drupal:LDAP_API
As far as each server configuration, the needs are pretty diverse. I see an instance of a server configuration as a permutation of service account, base ou, and server. We'll see how that plays out as we integrated the api with ldap modules; its really a case of what works. There are use cases for using an identical server configuration with 2 service accounts with different rights. So from a practical point of view, I think its best to avoid thinking of an ldap server configuration as mapping to a single ldap server.
So are you using cck fields + form api built in fields + form api as the user interface with relational tables mapped to classes and properties?
www.johnbarclay.com
So are you using cck fields +
No, although it would be cool for the future. Now, I just made some tests of managing entries by defining a quite complex mapping schema (through object/field manager classes), defined drupal-side, with concepts similar to the ones used by cck. I think that integration with the D7 Fields module would be the big goal, but I didn't already have a proper look at it to say whether it could be done easily or not.