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

[Kurt@OpenLDAP.org]

You should provide a URI to your extension.

Also note that 1.2 is currently feature frozen.  However, your
ITS will remain in the system for those who wish to make use
of your changes.

If you are interested in developing such for 2.X-devel, please
discuss and coordinate on our developer list.

Kurt

At 07:44 AM 10/10/00 +0000, lughofer@uni-freiburg.de wrote:
>Full_Name: Wolf Lughofer
>Version: 1.2.11
>OS: Irix 6.5
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (132.230.6.30)
>
>
>                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
>depended
>values of the user. Therefore, if the users password or some of the other
>values
>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