Re: LDAP utilities (was: the widgets thread)

[James G Smith <JG...@tamu.edu>]

Gunther Birznieks <gu...@extropia.com> wrote:
>At 10:49 AM 5/28/01 -0500, James G Smith wrote:
>>Hmm...  Something I'd like to see is a set of classes in Perl for managing
>>LDAP.  These classes would need to be generic (configurable) enough to work
>>with any LDAP schema.  They would need to provide an audit trail, transaction
>>log, etc., that could be used to replay changes made to LDAP.  They would 
>>need
>>to be able to enforce data consistancy across branches and data 
>>integrity.  If
>>noone gets to it before I do, I'll port my PHP code to Perl :)
>
>I guess it depends on what you store in LDAP. I find that LDAP is useful 
>for simple data structures but it can be much nicer to also have the data 
>in a relational database for most applications to access things in one query.

We use it as a University-wide directory service, but with two branches for 
people (unfortunately -- due to policies and other decisions beyond our 
control) and one for roles and organizations.

We put an abstraction layer between the web account management scripts and 
LDAP so we can easily write scripts that allow customers to manage their entry 
without the scripts having to worry about enforcing policy and keeping data 
consistent across branches.  The username in one branch must equal the 
username in the other branch, for example.  All data policies are pushed down 
into the abstraction layer, making it easier to manage them.

>I think I would like to see a public domain LDAP management console. This 
>is really what you are talking about right? One of my coworkers wrote one 
>in Perl back at Barclays Capital several years ago but he never bothered to 
>open source it. I suspect there are a ton of places like that which custom 
>design something like this and then never open source it due to laziness.

Not sure I understand what this would be.  Could you provide a bit more detail 
or an example of what would be done with it?

>>Oh, and locking mechanisms used must be transferable between machines -- I
>>lock resource A on machine X and then hand off the lock to machine Y -- this
>>code must be useful in a distributed environment (web farm) and robust enough
>>for use in a PKI.
>
>I guess I don't understand. The locking bit sounds slightly odd to me. 
>Wouldn't it be easier to administrate a master LDAP server and have a push 
>model of replication?

This keeps two people from claiming the same username, for example.  We 
identify people with a 32 character uid internally and allow them to select up 
to three usernames.  The locking prevents certain race conditions from 
happening.

>I am not sure what you mean by robust being a prerequisite for 
>PKI?  Passwords are passwords -- just that certificates are larger and the 
>SSL protocol has already decoded it for you.

The PKI stuff is dealing with the integrity of the data in the directory.  We 
must have correct information before we can issue certificates based on that 
information.  Allowing race conditions allows one customer to hijack the 
account of another and obtain a certificate that is not theirs to have.

The audit trail allows us to track changes and find out who did what when.  
Just in case a customer complains that they didn't make a particular change to 
their information or if we lose the disks (raid and mirrored) and the backups 
(both on-site and off-site) with the directory databases.
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix