Re: OpenLDAP enhancements

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

At 04:36 PM 8/9/99 -0400, Mark Valence wrote:
>>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.
>This raises a question (for me) about the dn's being of the form 
>"<suffix>, cn=config" vs. "cn=monitor, <suffix>".  In private e-mail, 
>it has been suggested that using the former method is limiting, 
>especially when you want to have different configs for separate 
>back-ends (or dir subtrees, I suppose).  I think you touch on this in 
>your mail, but I'm new to some of this jargon.

The choice of "<suffix>, cn=FOO" vs. "cn=FOO, <suffix>" depends
on whether or not the FOO information is apart of the 
Directory Informaton Tree (DIT) or separate (and per-server).
Monitor information is clearily separate.  Basic configuration
information (database type, disk location, cache parameters) is
server-specific (it could be in the directory, but it's separate
from the DIT it describes how to host).  Schema information could
be placed within the DIT or could be considered configuration
information.  Likewise for ACLs.

I think a key point that needs to made with ACLs is that there
are times with a configuration based ACL is quite valuable.  So
are per-entry ACIs.  (and likewise other forms of ACLs).  A
flexible access control system would allow flexible use of both
ACLs and ACIs.

>ACIs are nice, in that they are very fine-grained.

They need not be.  You can define an ACI model which supports
having aci attributes which describe not only the entry its
contained within but also subordinate entries.

>This is something 
>I'd like to see, too.  However, how would you apply (change) access 
>controls for a definable set of entries?  Like:
>
>     access to dn=".*, o=Company, c=XX" by * read
>
>So you'd still want to be able to change the acls, even if you add 
>per-object acis.

Even with feature rich ACI model, you may want to extend the
ACL model to support dynamic ACLs.  However, I argue that the
addition of a strong ACI model will reduce the need for ACLs
to the point where their main use is best left "static" (that
is, the ACLs depend on other per-server configuration information).

>> >How would you manage global vs. backend-specific acls?
>>
>>This is already implemented.  Backend-specific ACLs are checked
>>before global ACLs.
>
>I guess what I meant was, how would an acl's DN reflect its 
>global/backend scope?  One way is to have global acls look like 
>"something, cn=ACL", and backend acls look like "something, cn=ACL, 
>o=Company, c=XX" (putting aside other issues for the moment).

I think ACLs should be left per-server.  I'd suggest:
	<suffix>, cn=AccessControls	(per backend Access Control DSE)
	cn=AccessControls (global Access Control DSE)

>> >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.
>
>If acls are modifiable, though, then I have to preserver their "conf 
>order" in order to keep the current behavior.  That's fine, but how 
>does this affect their DNs, attributes, etc.?  One approach is to 
>store all the acls in one big acl object/attribute.  This is the 
>simplest approach, but gets resource-intesive as the acl data grows. 
>Maybe the assumption is that acls don't grow too large, and acis are 
>where you do most fine-tuning.
>
>Another approach is to have every ACL entry in a separate object (or 
>separate attribute of the same object).  In this case, there needs to 
>be some way to maintain the order of the acls, either by an ordered 
>cn convention, or a separate attribute, or one of a zillion other 
>ways.

I'd problably represent each set (one set for each backend, one
global set) within a single entry as the value of a single-value
attribute type.  That is, a blob.

>Storing all acls in one big object/attribute gets rid of a lot of 
>issues, for sure, and does suggest a starting point for 
>implementation.  However, I think having an object for each acl has 
>its advantages.  Perhaps the ordering issues make this more trouble 
>than it is worth.

Before digging in, I suggest doing some background reading first.
In particular,
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-reqts-02.txt
http://developer.netscape.com/quickfind.cgi?cp=dev01qfin