Re: Subtree ACIs

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

At 04:29 PM 7/14/2003, Ralf Haferkamp wrote:
>On Mon, Jul 14, 2003 at 06:38:42AM +0200, Kurt D. Zeilenga wrote:
>> At 12:28 PM 7/11/2003, Ralf Haferkamp wrote:
>> >I have recently been looking at the in-directory ACI implementation and
>> >trying to implement subtree ACIs. I've made good progress so far. I am now
>> >wondering about some details of how the evaluation should be peformed.
>> 
>> With the experimental ACI stuff, I think the original intent was
>> for "more specific" ACIs to take precedence.  You likely can look
>> at some of the long-ago expired LDAPext drafts for guidance on
>> this (see doc/drafts for copies).
>>
>> You might also find Steven Legg's drafts on X.500 ACMs in LDAP
>> interesting.
>Thanks for the pointer. I've take a look at the drafts. If I understood
>it correctly it makes use of Subentries when defining ACIs that scope more
>than one entry, is this correct? If yes, is there any subentry support in
>the current HEAD code? 

The X.500 model supports both "entry" and "perspective" ACIs, the
former held in entries the later in subentries.  This separation
is key to supporting access control delegation.

>Additionally, compared to the simple format of OpenLDAPaci the definition of
>the "entryACI"-Attribute from "draft-legg-ldap-acm-bac" looks pretty
>complex. 

Yes, and entryACI needs even more power (complexity) to meet
well requirements of large enterprises... but the real complexity
of the X.500 ACM is in the X.500 admin model (e.g., the subtree
refinement properties of subentries).

>Is it intended to remove the current implementation in favour of a solution
>that implements the ACMs specs in the future?

The current implementation is experimental.  To that extent,
it has fulfilled its purpose (to experiment with in-directory
ACIs).

As far as the future goes, I personally favor* implementing the
X.500 ACM as its complexity is well understood and proven.  I
rather avoid re-inventing the unavoidable complexity of a robust
access control model.  My approach was to first implement
collective attributes (w/ subentries) [as it is a simple X.500
administrative model] and then implement X.500 basic access controls.

As I am swamped with other things, I'm quite open to alternative
approaches offered by those with more time/energy to work in
the access control area.

One other approach which was discussed at ODD/SFO was
solving this problem via a "configuration" backend which
virtualized our current slapd.conf(5) access controls.  That
seems like a fairly pragmatic approach.


>[..]
>> I would argue that in evaluating ACIs for a target entry, the
>> precedence should be:
>>         a) "entry" (base) scoped ACI on target, then
>>         b) subtree scoped ACI on target,
>>         c) subtree scoped ACI on parent,
>>         d) subtree scoped ACI on parent's parent
>>         e) ...
>> 
>> Now, one could argue that "subtree" scope is problematic.  If so,
>> replace it with "children" scope and eliminate b).
>At the moment I implemented the "children" scope. Though it seems not be to
>hard to support "subtree" as well.
>
>-- 
>Ralf Haferkamp
>
>SuSE Linux AG                                    - The Linux Experts -
>Deutschherrnstrasse 15-19                         http://www.suse.com
>D-90429 Nuernberg, Germany                        Tel: +49-911-74053-0