[Fedora-directory-users] I'm feeling like I'm drowning!

[Jeff Clowser]

Ben Steeves wrote:

> On 7/21/06, Per Kristiansen <perk at funcom.com> wrote:
>
>> I had hoped to let the people at HR do the data entry on the "soft"
>> information , while the operations people do the "hard" information.
>
> If people are going to need access to just a few attributes, or you
> need to apply business rules to the process before it hits the
> directory, you're probably best off building your own interfaces (or a
> framework on which to build multiple interfaces).  In our case I built
> a PERL module that our devs use to talk to the directory that
> implements our directory organization principles, neatly abstracting
> it out so that they don't have to worry about mundate directory
> matters but can concentrate on the business rules and user interface.

I like to think of LDAP as a building block toward creating an 
infrastructure.  Think of it like an SQL database, if you are familiar 
with that - you can set it up, but the structure of the data, as well as 
permissions on who can do what with the data, is more or less external 
to the directory/db server.  Creating a useful LDAP service, esp if you 
are integrating lots of end user services against it, is sometimes a bit 
of an art.

You can write a custom interface in perl, java, etc - I prefer php, but 
that's just me (actually, php's LDAP api is pretty primitive, but php is 
simple to code in, and has just enough api to do most things you'll 
want)...  Anyway, that lets me create an interface that looks exactly 
the way I want it to, covers all the components I have working against 
LDAP, allows me to apply business logic against it, etc.

You can find prebuilt generic ldap browsers, but these tend to either 
not include business logic (see below), or aren't "aware" enough about 
apps you have (for example, if you are using samba, there may be certain 
restrictions of the values you put in ldap that a generic browser that 
just lets you edit fields doesn't know about).

Interfaces that ARE aware of some apps you use tend to not know about 
others - i.e. you might find one that creates users for samba, but knows 
nothing about your other apps and how they use LDAP, so you may not get 
a single "complete" admin tool.

ACI's in ldap can be used to restrict who can do what - i.e. an ops 
group that can create users, and HR group that can edit address, phone, 
etc info on existing users, etc.  However, if you want to incorporate 
business logic (i.e. make uid's all lower case, restrict the state field 
to only upper case/valid US state abbreviations, etc), you have to have 
an admin tool that enforces this - there is nothing inherent in LDAP to 
do this.

 - Jeff