RE: LDAP subentry alignment with X.500 subentry

["Albert Langer" <Albert.Langer@Directory-Designs.org>]

[RB]

Stephen,

If we were to use subentries to store aci items then your
"restriction" proposal sounds like a good approach.

However, it could be argued that it would be useful to extend the X.500
subtree specifier to allow the refinement to be a generic filter (not just
on the objectclass attribute).

So, on the subject of a subtree specifier for LDAP, then wrt the X.500
specifier I would venture something like: drop the chops (in favour of a
start point and base, onelevel and subtree) and allow the refinement to be
a generic filter (not just on the objectclass).

However, I would also like to see a discussion of why we should put acis
into subentries rather than just store them as ldapACI attributes in
entries.  What are the pros and cons ?

Cheers,
Rob.

[AL]
Extending X.500 subtree specifier to allow a generic filter (not just on
objectclass attribute) would be a bad idea, for reasons explained below. I
agree with Steve's proposal to use a subset of X.500, not a superset. This
subset should be the minimum necessary to support replication subentries
(which isn't much), but using the generic standard so that implementors
needing more (eg for ACI) don't have to duplicate effort.

First, apologies to all, and especially to Steve, for long delay responding
to Steve's careful response re MDCR etc. Will be replying in detail but had
to put it aside and will still have to do so for at least another week due
to other priorities. (Got an excuse though, also waiting for authors reply
re requirements ;-)

Meanwhile, a quick point re this thread, as I can write about ACI and
subentries from off the top of my head, whereas multi-master replication is
HARD.

>From above and other messages I suspect there may be some talking at cross
purposes re implementation issues vs protocol issues.

X.500 style subentries with chop sepecifications (by minimum and maximum
depth, plus named lower boundaries, plus arbitrary boolean filters on object
class only, can be implemented either by logic applied to traversal of the
path from the (administrative point of) the subentry or by logic applied to
COPIES of the subentry aci physically stored with the affected entry aci as
part of the entry. Both implementation methods can conform to the same
protocol standards that separate the administration of entry aci from the
administration of subentry aci.

The second method has all the administrative advantages mentioned by Alan,
because the subentry aci stored within an entry is administered from the
subentry point, independently of the entry aci. But it provides much greater
efficiency for read dominated directories at the expense of slower
application of changes to subentry aci (which are relatively infrequent).

eg Active Directory uses inheritance (from Admin points, not true named
subentries) to propagate the admin point aci downwards from the minimum
depth of the chop spec (limited to 0 or 1), to the maximum depth (limited to
0, 1 or infinite) with limited specification of object classes. Whenever the
inherited aci is changed, a write has to be made to EVERY affected entry,
which can be very slow for changes applied from high up, but the whole idea
of delegation is that such changes should be infrequent.

This is effectively the same as "base, one level and subtree" but with the
important addition of "below one level only". That enables the vitally
important specification of ACI that does not become effective until
propagated BELOW the point of application - effectively allowing a form of
unaffected subentries even when applied from an admin point (because
subentries have their own object class). The mechanism used in Active
Directory simply uses a bit to specify whether inherited aci is "inherit
only", in which case it is "dead" at the entry but becomes "live" when
copied to entries below. By changing this to an integer instead of a bit you
would get a chop min. Likewise a "don't propagate" bit cuts off further
copying for inheritance below. Changing that to an integer would give a chop
max.

There is no reason why the same general "inheritance by copy" approach could
not be used for true named subentry ACI (calculating inheritance from the
base instead of the subentry, even though the specification is named by the
subentry). Also the Active Directory limitation on chop specs and object
class filters seems related to transition from historical* NT/DCE security
descriptors rather than any inherent limitation in this model. (* Your
spelling of "historical" may vary, however the use of admin points instead
of named subentries can only be spelled one way, "hysterical").

The first method also has all the administrative advantages mentioned by
Alan, is simpler to implement and allows much faster changes since a change
only has to be written once, where it is physically stored only at the
subentry (or admin point). However it slows down reads and writes and
especially searches to the affected entries themselves and is therefore in
my view precisely the wrong optimization for directories. (Except where
there is so little delegation that all the non-entry ACI can be kept in RAM
anyway, as with many LDAP servers based on the U Michigan release with
highly centralized administration, even editing config files to change ACI).

It is also very intertwined with the naming structure. A regexp on naming
path for access control in a search would severely complicate the use of
aliases. That is why X.500 specifies ACI controls based on the unique
primary distinguished name of an entry, not on path names.

LDAP standards must not unnecessarily limit implementation choices. Filter
specifications on object classes work with either model, since every entry
knows its object classes and can easily calculate an arbitrary filter on
them quickly when determining visibility during searches. General filters
really only work with a traversal based implementation and are basically
just an attempt to substitute regexp evaluation on path names familiar to
centralized web administrators for a serious admin model that can actually
be delegated. The apparant additional flexibility is illusory since it
doesn't scale with real delegation, whereas the combination of min and max
depth, base, named lower bounds and object class filters does allow for
adequate delegation of directory access control domains independently of the
naming structure. Independence from the naming structure is essential for
scalable delegation.

This is also relevant to replication management issues when we move beyond
current scope and need to support opportunistic delegated replication
agreements for subsets of a replicated area, as mentioned in Alison's
contribution.

Most of this thread is more related to LDAP ACI extensions than to
replication. However the mechanism used for replication subentries should be
consistent with that used for any other purpose and should therefore be a
subset, not a superset.

Also, the generalization of subentries to families of related entries is
very relevant to dealing with atomicity and replication granularity issues.
As mentioned in MDCR attributes that need to be changeable independently and
concurrently at multiple replicas can be in separate subentries or child
entries of a parent family entry. Any such generalization of subentries need
only rely on object classes.

Most importantly, the multi-master replication of subentries MUST have
sufficient consistency properties to support their use for ACI. If the
replication mechanism is so broken that one has to rely on per replica
subentries to administer it, I don't see how it could possibly support
replicated access controls of any useful kind at all. This was also
mentioned in MDCR:

http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt