LDAP backend discussion

[Sam Hartman]

Novell, MIT and Sun  had a conference call to discuss the LDAP backend.  Here are the conclusions of that call:

1) Principal linking and creation.  We realized there are several
different types of links you might care about.  The type of link
Novell has been discussing is an equivalence link.  Imagine that you
have a user object that needs to have principals in multiple realms.
You want all these principals to be equivalent: the same login policy,
same authorization etc.
Novell wants an LDAP attribute that describes that.
We agreed there needs to be  an attribute placed in principals describing equivalence links to objects.

However there are other possible types of links.
Imagine you have principals with more privilege than a user's default: representing administrative roles for example.  In these cases you want  links, but the link is much looser.  You may even want a link only to say that a principal should be deleted when the user is removed.
We did not come to consensus on anything to do about these types of links; they need more discussion and are not likely to impact the LDAP backend.

The administrator will be given flexibility for where the object is
created (or which object the principal is added to) and what object if
any is linked to.


2)  Schema

MIT raised the concern that the schema should not duplicate data in a
manner where one part of the directory can become inconsistent.
Policy refrence counts or two-way links would be problematic.

MIT asked for extensibility markers to be added to inner sequences in
the schema.

MIT expressed a desire that the supported enctypes and supported
salttypes be combined into enctype:salttype tuples just as the default
enctype/salttype.


3) Automatic mapping of principals using rules.

At this time we will not implement a rule based system for determining
where principals live in the directory.

4) Migration and kdb5_util support

We agreed that it is desirable for kdb5_util to work against LDAP.
Sun wants to be able to dump a database, change the backend
configuration and then load that database into LDAP.  We agreed this
is desirable.  This requires implementing the LDAP create DAL
operation as well as removing kdb5_util db2 dependencies.

--Sam