All,
I spent some time looking at an OpenLDAP implementation for us at TelaScience. Frank reminded me that our new admin would be taking on LDAP duties once he/she comes online in early November. I'm posting this as some notes to that person and a description of the things we would probably want.
Ideally, our LDAP would be very simple, a user would only be created one time, and permissions would be mostly determined by group membership. The LDAP should avoid creating custom object types/schemas if at all possible, and be implemented in OpenLDAP to provide the greatest opportunity for an LDAP initiate to familiarize themselves with the software and get things done if they needed to.
At TelaScience, we were running Fedora Directory Server as a stop-gap for serving LDAP for the TelaScience systems. It had a few problems for us. First, it wasn't that user friendly, and the only way we could figure out how to create a user in the system was through the GUI (and through me). This created a major choke point, and limited any development to myself. Second, it had a non-standard schema, so client applications expecting to utilize it for authentication and authorization needed to either have support for FDS, be modified, or be forgotten about.
Here is a listing of some LDAP-enabled applications we might want to run for supporting OSGeo operations:
- Apache (for SVN access mostly, but maybe for other items like a project-specific portion of a website)
- Unix shell logins, group permissions, VNC access, sudo privileges (solaris, linux, and maybe others)
- Content management system authentication/authorization
- Database (postgresql, etc) users and groups
- maillist/mailmain integration?
- others
<http://wiki.osgeo.org/index.php/Proposed_LDAP_Layout> has a link to an ldif and a picture of some of the stuff I prototyped. I created three major areas, and a structure that closely follows OSGeo's organizational structure. "Projects" contains the major projects of OSGeo, including things like GeoData, and each DN contains the members of each respective project. "SVN" follows almost exactly, but with membership numbers much less than the groups within Projects. "Shell" is a groupOfNames that contains those members with unix login ability (this is used by PAM's pam_groupdn flag in ldap.conf on *nix systems). "People" contains the posixAccounts that define everybody, and finally, "Posix-Groups" contain posixGroup definitions for groups that would be used at the system level for defining ownership permissions, etc.
If any other LDAP'ers out there have some ideas or some thinking about codifying our organizational structure in our LDAP, please let me know.
Howard