Re: OpenLDAP enhancements

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:42 PM 8/9/99 -0400, Mark Valence wrote:
>
>Hello-
>
>I would like to make some changes to OpenLDAP, and I'd like some 
>feedback on my planned enhancements and my approach.
>
>The basic idea is to expose the Schema and ACLs via LDAP, and 
>eventually to allow these configs to be changed via LDAP.  I think 
>that this would be a very useful feature for sites that need to 
>delegate management of an LDAP server to multiple people.  This would 
>also allow programmatic (and dynamic) changes to the schema and ACLs 
>(other than editing the conf files and restarting slapd).

The basic long term goal is to move most configuration information
into the directory and to allow updating of this information via
LDAP.  In some cases, the configuration information will be used
dynamically, in other cases upon (re)initialization.

Schema and ACLs are two most likely configuration items to be moved
into the directory.  Schema and ACL information, in general, are
backend specific.  However, there is also per server schema and
ACL information to be maintained as well.  We may still desire
to have core ACLs and Schemas be statically configurable but allow
dynamic extension to the ACLs and Schema where the administrator
has allowed such to take place.

For example, we might invent a new static ACL that allowed for
the access control information to be read from the directory.  The
static ACL should place limits upon the dynamic ACI.

>There are a few ways to do this while limiting the amount of code 
>that needs to be changed in slapd.

It's a very slippery slope...  just take small steps.

>In fact, one primary goal would 
>be to make these enhancements without modifying the existing source.
>My idea about doing this is to make a new backend that looks at 
>internal lists and structures within slapd, and then present these as 
>entities in the directory (and eventually modifies the internal 
>lists, too).

This wouldn't be a backend... it just be a frontend handler
for that request (like how "cn=schema" is handled).  The existing
handlers only implement SEARCH, but you could implement MODIFY
handler.

>In other words, schema and acl info would be 
>accessed through backend.c, as real objects in the directory, stored 
>wherever the (now minimal) conf file specified.  This would require 
>mods to existing code, but would be more flexible than writing a 
>"slapd.conf" backend.  (One benefit, for example, is that you could 
>have a schema/acl server for a bunch of distributed LDAP servers, and 
>you'd only have to maintain one "master" schema/acl by using the ldap 
>backend as the source for your schema/acl).

This gets quite involved quite fast.  I would suggest small
steps.  That is, implement an extension to the static ACL system
that used dynamic ACI information.

  access *
	by aci=aci dynamic[none|auth|compare|search|read|write]

  if entry has "aci" attribute, grant access based upon access control   information located in the entries ACI attribute.  Access granted
  cannot exceed level specified.

>If the schema and acls are to be part of an LDAP directory, then 
>where would they go?

I would suggest per-entry ACIs instead of per-backend-ACLs.  Hence
the ACI would be stored as the value an attribute type.  (The attribute
type could be defined as user-modifiable, operational attribute
so that it could be added to any existing entry without changing
the entry's objectclass definition... or as a normal attribute type
which would be allowed by an auxilary object class).

For per-backend configuration and monitor information, I was thinking
of using:
	<suffix>, cn=monitor
	<suffix>, cn=config

However, I am not sure this works well for schema.  If schema is
distributed as part of the DIT, than it should be stored within
DIT.  Something like:
	cn=schema, <suffix>

might make more sense.

>What would their DNs look like, and what 
>attributes would they have?

schema must be of and use attribute types required/allowed of
object class "subschema" (see RFC 2256 for details).

For aci attributes, we'd have to invent (or borrow) something.

>How would you manage global vs. backend-specific acls?

This is already implemented.  Backend-specific ACLs are checked
before global ACLs.

>Would you maintain the order in which acls 
>are applied, or change the rules from first-match to a big OR of all 
>acls?

I would add per-entry ACIs to the mix and not change
basic ACL processing.