princ to DN mapping rules (was Re: concerns with ldap plugin and 1.5

[Will Fiveash]

On Tue, Jun 13, 2006 at 12:10:39PM +0530, S Rahul wrote:
> You have captured most of the idea. But there are other ways a Kerberos 
> principal can be mapped to a directory object.
> 1. Based on an attribute like 'cn' which may not be the naming attribute 
> of the user object's DN.
>
> 2. Part of an attribute value matching part of a principal name. For 
> example, if  the directory has an 'email' attribute defined, I will have 
> to map a principal 'srahul at REALM' to a user object containing the email 
> ID 'srahul at something.com'. Here, the rule will be "match the first part 
> of the principal name with anything before '@something.com' in the email 
> attribute'.

A rule syntax that allows for a princ to directory entry mapping using
search criteria other than the DN would be useful.

> 3. Rules like <user>@REALM matches the directory object with 
> 'cn=<user>*'. This type of rule will require a substring based search 
> filter to be constructed and used in an 'ldapsearch'.
> 
> In addition to this, collisions must be resolved by the admin. For 
> example consider the case where 'cn=user1,o=abc' and 
> 'cn=user1,ou=def,o=abc' both exist and the principal name is 
> 'user1 at REALM'. If the plugin implements this, we have to provide a 
> mechanism by which the plugin gets admin input.
>
> I think it is not good to put all this functionality inside the LDAP 
> plugin. It is not a straightforward database write. Multiple LDAP 
> searches (possibly substring matches) are performed and each search is 
> followed by a series of comparisons. The LDAP plugin's 
> 'db_put_principal' implementation should just add the principal using an 
> LDAP modify operation and not be concerned with all this logic.

I'm not convinced.  My feeling is that if the rule semantics/syntax is
well designed then admin interaction should be rare unless the directory
DIT is poorly designed.  The DAL interfaces should be such that
ambiguity errors as you describe should be passed back to the utility
(kadmin, kdb5_util) and at that point the admin will have to sort it
out.  This would allow existing KDB user interfaces to work in a more
plugin transparent way.

Besides, db_put_principal() isn't done that often compared to
db_get_principal().

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)