RE: LDAP subentry alignment with X.500 subentry

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

Steven,

Thanks for:

a) The correction below.
b) The explanation of why the non-restriction to structural classes is
useful.
c) The explanation of why general filters would be more useful.

Clearly I was wrong about the restriction to object class avoiding any need
to dynamically track which DACDs an entry is in, though I still think it
might be simpler and more efficient than for a general filter, eg some
implementations only having to recalculate when an entry changes its object
class attribute (rarely), rather than for any change.

I'm still not convinced about the advantage of c) over b), although this
certainly does at least diminish one argument against c).

Other reasons are:

1. General principle that LDAP should remain "lighter" than X.500 and
compatible with it. Therefore any superset variations should be demonstrably
necessary, eg to simplify something else, not just desirable. Proper
subentries are demonstrably necessary to simplify access control. As Kurt
pointed out, not providing them will just result in more complex ways of
doing the same thing being required anyway. But "enhanced" subentries are
not demonstrably necessary.

2. What kinds of DACD can be specified should be a matter for schema
administrators (ie "manually" in practice), not for access control
administrators. It really is an issue of maintaining consistent schema (in
this case for access control) so that there is a common understanding of
what each type of DACD actually means. Maintaining that commonality of
understanding of the schema is inevitably and intentionally less flexible
than the changes that other kinds of administrators and end users should be
allowed to make to the directory.

The concept of a DACD is currently less familiar to LDAP administrators, who
are often both schema and access control administrators (whether or not they
understand much about either).  The concept of a general filter is more
familiar to them, but the relative rigidity of DACDs will actually make it
easier for administrators and end users to understand in the long run, as
the point of standardizing these things is to enable full interoperability
over much larger areas than most LDAP administrators are currently
administering, with delegation within those areas.

eg "Allow printer administers to administer printers within this part of the
tree" is easily understood. If it turns out that a different set of
permissions should be granted with respect to color printers, then they are
entries with a different type of behaviour from other printers and should
have their own object class, even if they don't need extra attributes. If
they do not need recognition in the common schema applicable organization
wide as a distinct type of entry, then any variations in types of access
control should be local to the particular part of the tree that perceives
the need for this.

Authority over types of access control should not be delegated unless one is
also willing to delegate authority over schema. Delegation is rapidly moving
down to end users and lower level administrators need a clear and stable
conceptual framework.

If its really inconvenient, lower level administrators can ask schema
administrators to define a new object class. The standards do not prevent
them tagging entries with auxiliary object classes once those classes have
been defined, but only from introducing new ones without coordination. An
implementation might make such tagging unnecessarily "manual", but that it
is not a standards problem.

The goal here is to reduce variation in conceptual framework, not facilitate
it. General filters are intended to, and would succeed in, enabling easy ad
hoc changes to the conceptual framework for administering access controls.
If that was desirable, then general filters would be desirable. As it is
undesirable, they are a bad idea.

3. I suspect that the interaction between general filters, permissions and
priorities is likely to not be well understood, and result in errors when
people are given permission to change an attribute value without
understanding that this will have side effects on access controls.

4. Even with atomicity, I don't think its going to be at all easy to cope
with the interactions between ACI and replication. My error regarding
structural object classes may have resulted from wishful thinking, since it
will be even harder to cope, given that an object can move in and out of a
DACD as a result of a change in its auxiliary object classes. But at least
that only adds one kind of replicated change to worry about, on top of
changes to entry and prescriptive ACI themselves (not to mention group
membership and changes in distinguished name prefixes that can also affect
access controls). Adding potential surprises in permissions resulting from
unsynchronized replication of other attribute values would not be helpful.

In earlier discussions on the LDUP list it was recognized that this problem
of entries moving in and out of the scope of a filter made it undesirable to
allow general filters for specifying fractional replicated areas.

5. Its clear that there is a strong reluctance to introduce proper
subentries at all, despite their obvious necessity for ACI, which goes far
beyond what is immediately needed for LDUP. I would rather see a successful
quick resolution by acceptance of existing standards for subentries, or a
viable subset of them, than a protracted delay in achieving any reasonable
support for ACI at all. (The arguments raised against the current draft by
others already establish that at least some specification of the base and a
filter on object class will be necessary before final call. Adding chop
specifications does not really complicate implementation much, whereas
general filters still does to at least some extent, and would therefore
increase the resistance and consequently the delay for accepting the
necessity for having proper subentries).

BTW If the reference to manual maintenance of tagging below means that your
customers *want* the DACD applicable to an entry to change dynamically with
the ordinary contents of the entry, and you are having to change the object
classes in synchronization with other changes to the entry, then I can only
suggest seeking more sensible customers ;-)

I have assumed above that you were only referring to the manual difficulties
of tagging entries when the customer's conceptual framework changes, not
when the entries change. Implementation tools should allow administrators to
apply a general filter to re-tag entries, without a need for
standardization. A standard DUA should be able to do that just by scripting
to apply the change desired to each entry within the scope of the filter. If
standards were required for directory operations that apply to more than
entry, they would be be for more general changes, not just in relation to
access controls.

Seeya, Albert

[original below]

> [Robert]
> Albert, doesn't an entry know the other attributes that it
> contains as well
> and so could evaluate an arbitrary filter ?
> [Albert]
> Sorry, I should have said "the (structural) object class of
> an entry is
> fixed and therefore the set of applicable subentries does not
> need to be
> recalculated on every search". With general filters such a
> calculation would
> be needed on every search, for every subentry that has a
> parent within the
> base of the search applied to every entry within the scope of
> the search.
> This is multiplying the cost of a search by the number of potentially
> applicable subentries (not just the number of actually applicable
> subentries).

[Steven]
The specificationFilter of a SubtreeSpecification applies to the
objectClass attribute rather than the structuralObjectClass. Since the
objectClass can contain optional auxiliary object classes that come
and go, a conformant X.500 implementation already has to deal with the
situation where the set of applicable subentries changes.

Some of our customers need to be able to set access controls based on
the non-objectClass attributes of the entry. The way we have achieved
this with X.500 basic access control is to define an auxiliary object
class, with no mandatory or optional attributes, that we use to tag
entries satisfying an implied filter on the entry contents.
SubtreeSpecifications then reference the auxiliary class in their
specificationFilters. The auxiliary class tagging has to be maintained
manually. Being able to filter on arbitrary entry contents in the
specificationFilter would be better.

[snip]

>
> Please send or CC any comments to LDUP as I won't see them in LDAP-EXT.
>
> Seeya, Albert

Regards,
Steven