RE: Database vs Directory Service

[Adam Tauno Williams <adam@morrison-ind.com>]

>Our (fed gov't) agency is in the throes of a discussion on this topic,
>and
>I'm sure we're not unusual in that we want to add substantially to the

Nope, your normal (at least in that regards).

>information base that's available currently in a the agency-wide mail
>directory system.  But the information in that directory is partially
>duplicated and somewhat extended in a RDBMS-based web application.
>I think we need to keep both, rendering unto Caesar ... .  That is,

Your probably right.  We have both an RDBMS and an LDAP system.  A web front end
brings those together tied by either employee ID (for people in general) or
"uid" for things relating to accounts.  One of the BIG diffrences between LDAP &
RDBMS is in how they handle security.  RDBMS security is table oriented write,
read, or nothing on the whole ball of wax.  LDAP has attribute oriented
security,  so I can let personell see/update things like home phone numbers,
etc...,   management can see them, and rank-and-file don't even know their in
there.  And it's not the apps problem to enforce security (a generally bad and
painful idead).  

Also LDAP's ability to multivalue attributes (not possible in a traditional
RDBMS) is more like the reality of phone numbers, etc....  It's almost a
religious issue with me, but how the data is handled should be like how the data
exists in the real world, everything will just be easier if that is so.  Leave
invoice information to invoice line items (header-detail) to an RDBMS and
information about people (fluid, not-so-structured) to a directory service.  In
the best situation you'll always have both.

And where are their PAM modules to authenticate a login or use of a web page
against and Oracle or Informix RDBMS.
>retain the inherent directory information/schema where it is, and also 
>provide a linkage mechanism to the RDBMS data.  A GUID appears key to 
>doing that effectively, extending both schema to accommodate that item.  
>The overall application would draw on both information sources for 
>end-user interaction, presenting a unified appearance.

>System requirements include protected/authenticated end-user update of
>some of the directory information, and maintenance of personal information
>with a tabular organization probably best managed by the RDBMS.

Directories (IMHO) are for data that doesn't fit a neat tabular model.  The
person who doesn't have a cell phone shouldn't have a "mobile" attribute,  if
they have a house, and an cottage, "homephone" should have two values.  And if
diffrent systems want differently encrypted passwords than "userpassword" should
be allowed to have as many values as needed (prefixed with {hash} of course).

Binding to a directory as a given user takes care of all the "authentication" by
itself if you make intelligent ACLs.

Something like payroll information that is tabular, and gets regular updates,
obviously makes more sense in an RDBMS context.

With middleware such as PHP joining a RDBMS and an LDAP service is quite simple.

>I'll appreciate hearing the
>thoughts/opinions/experiences/recommendations of
>anyone with some insights here.  Thanks, people.

Systems and Network Administrator
Morrison Industries
1825 Monroe Ave NW.
Grand Rapids, MI. 49505