Some LDAP musings

[Howard Butler]

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