[Date Prev][Date Next] [Chronological] [Thread] [Top]

Extension for slapd ldbm backend: Aliases at attribute level (ITS#814)

Full_Name: Wolf Lughofer
Version: 1.2.11
OS: Irix 6.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (

		Why do we need aliasses at attribute level in LDAP?

We have a project to introduce "single signon" for all services of the computer
center, i.e. a user can authentificate themself with the same userid and 
password to all services, he is allowed to use. Since nearly all systems have
a LDAP interface, we decided to use a LDAP server to hold authentification and 
other user data. But nearly every system (even different unix systems) needs 
different userid objects to hold the password and some other not system
values of the user. Therefore, if the users password or some of the other
must be changed, they must modified in all objects related to the user. To do
this job, we must have lists of the objects or implement some algorithm to find
the objects and the attributename for the value. 

Why aliasses at attribute level in LDAP are needed? If the same value is used
in more than one object and/or attribute, it simplifies updates and may save
database storage. Since most of the LDAP clients are part of a software system 
and couldn't be changed, dereferencing should be done transparent to the client
by the LDAP server.

		My implementation of alias references in slapd  

I tried to implement an alias attribute feature in the "slapd" server software
with an minimum of changes in the existing procedures. All work is done in
an new program back-ldbm/attralias.c and only few lines must added to the
programs back-ldbm/bind.c, back-ldbm/compare.c, back-ldbm/search.c and 
back-ldbm/modify.c at one (modify at two) places in the code. The code and
modifications are available for Michigan and OpenLDAP slapd and is tested
on an SGI machine under Irix 6.5.

In this implementation a value is treated as an reference to another attribute
of the same object, another object in the same server or an object in another
LDAP server, if the value begins with a special sequence of characters => 
defined as constant in the program attralias.c. It is also possible to include
all attributes of another object in the same server, if an special attribute
name * defined as constant in the program attralias.c is used. Recursive 
dereferencing is also provided and limid to the configured max dereference 
depth. Modification of dereferenced values is restricted to "replace".

		Configuration of attribute alias references 

The recognition of an alias reference through a special sequence of characters 
at the beginning of the value should be replaced by a better solution, because
it doesn't allow real values beginning with the special sequence of characters.
An object with this type of alias references can only manually created. If the
objets are created by a system, they must changed manually to introduce alias
references. In the practical cases the use of attribute aliases is property
of a set of similar objects (not a property of a single object), which has
similar alias references. Similar objects means objects with similar dn names
and/or equal values in one or more attributes. Similar alias references means
that the alias reference can be derived from the dn name and/or an attribute 
value of the object with the same formula.

A better solution seems to me to configure the alias references and the set
of objects in the same manner like access control. Configured aliases are
already known at creation time of the object and can transparent to the
creating client handled by the server. The alias references must not stored
into the object, because it can derived from the dn and/or other attributes
of the object