Ben Steeves wrote:
On 7/21/06, Per Kristiansen <perk@xxxxxxxxxx> 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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
