Subject: Inheriting / Cacheing / Replicating policy from superior administrative areas

From: "Ed Reed" <[email-masked]>
Date: Wed, 21 Feb 2001 10:16:58 -0700

Preamble

At the San Diego IETF in December a bar boff (1 round = $89 or so USD) was convened to consider how to deal with inheritance of policy down through a tree from superior to subordinate contexts.  The topic came up because it's an issue for access control policy, which many of us would like to see be able to be inheritable from parents to children, so that an access granted to a parent or superior organizational unit, for instance, could be interpreted correctly as being implicitly granted to all the subordinate entries of that parent.  Other policy information could benefit from such inheritance, and the general case is that policy set at the root of an enterprise (for instance) administrative area is applied to the whole of the administrative area, even if the administrative area is partitioned and distributed among several servers (or groups of servers) throughout the enterprise.  Real world examples include Novell NDS trees, Microsoft ADS Forests, and probably things like th!
e directory information tree in X.500 for a country, a governmental agency or any other sort of large organization.

Since this discussion grew out of the LDAPSubentry internet draft discussion about inheritance, I've copied both the ldup and ldapext distribution lists.

The requirement

To support the kind of top-down policy inheritance described above, servers holding subordinate partitions of the administrative area (in other words, simple subtrees rooted below the root of the administrative area where the policy is set) need to be informed of the policy that they are supposed to inherit from above.

Note that I've not said anything about how the policy is represented yet.  It may be via attributes on the root of the administrative area, or it may be via subentries located immediately subordinate to the root of the administrative area, or by some other means.  In fact, for the general case that includes the full X.500 subentry definition with subtree specifications in the subentry, it's only necessary that the policy subentry applies to the entry and its attributes being governed (I think - David?  Helmut?  Richard?  Others?)

So the question is how to make the subordinate partition of the namespace, that does not necessarily coreside on a server where the administrative  area is rooted and where the inheritable governing policy is asserted, how does that subordinate namespace "know" about the inherited policy so that it can enforce it?

Possible approaches

There are several ways this has been approached in the past, and one can imagine many others.

1) the inheritable policy could be asserted when the superior/subordinate references are being administratively set to glue the two namespaces together, either manually by the administrators or programmatically via some hierarchical operational binding protocol, for instance.  I think this is how X.500 implementation generally handle it.

2) a specialized form of replication that knows of the need to maintain cached information aggregated from superior administrative areas in the directory information tree takes responsibility to identify inheritable information and to maintain copies of it on or near subordinate partition roots.  This makes the information available locally to the subordinate namespace in a "read-only" fashion that facilitates decision making and makes the specialized replication scheme responsible for propagating policy changes to all the subordinates when needed.  This is how Novell's NDS does it.  

3) servers holding subordinate partitions of an administrative area can "opportunistically cache" policy information locally.  In this scenario, the access control policy engine (probably, as the direct consumer of the inherited policy information in one example) knows that policy information may be defined in superior areas of the directory information tree that it needs to know about, and so it "walks the tree" until it finds what is clearly the "top" of the authoritative administrative area within which it is supposed to operate.  (I say it this way to highlight that the subordinate may well know its not supposed to walk the tree all the way to "dc=com", for instance, if the root of the organizations administrative area is "dc=oncalldba, dc=com", for instance)  At any rate, the policy engine walks the tree "as far as its supposed to go" accumulating policy information that applies to it and cacheing it locally for future use.  The walk would take place at server startup tim!
e, or when the partition is placed "in service" (if it ever goes off line), or on scheduled "has anything changed I need to know about" walkabouts.  Each policy engine would be responsible for its own cache of information and its own walkabouts (I like that term for this...)

4) whenever policy is defined at an administrative point that applies to subordinate entries, a process (either client or server-based, or some combination of both) performs the inverse to the walkabout described in #3 above - that is, it descends the tree depositing policy information (or changing policy information it finds there) on subordinate entries (either on partition roots or on each leaf entry itself) as it goes.  This approach has the benefit of "pushing" changes from the point of administrative action to all the areas subject to the policy change, rather than relying on the "opportunistic cache" of #3.  With some care, it need not be any more bandwidth consuming than the specialized replication scheme described in #2 above.  And is more dynamic than the static configuration of #1 above.  I think this is generally how Microsoft handles inheritable policy for access controls.  (and yes, in professional contexts of previous lives I've dinged them for how they do it, b!
ut that was nit picking over implementation approaches of what to decorate, not over the general concept of how to propagate changes).

["Ed"itorial note - this note alread covers more than we discussed at the bar boff]

There are probably other approaches.  In fact, we came up with one more at the bar boff.

5) each server holding a subordinate partition of an administrative area could also hold a "sparse replica" of the otherwise non-resident superior administrative areas which hold policy information relevant to the partition it does hold.  This approach would allow LDUP to be responsible for propagating changes to policy "as written" to subordinate servers that need it, avoids creating specialized mechanisms that need to know how to aggregate policy information through multiple tiers of administrative area roots (something both #2 and #4 require, and something I for one really, really, really don't want to try to generalize for a standard), leaves interpretation of superior policy entirely up to the local policy decision functions (where it belongs) and "only" requires read-only replicas of the superior administrative root entry and its subentries.  Being "read-only" replicas, the LDUP house keeping is kept to a minimum (because there will never be changes flowing from the subo!
rdinate copy to the administrative area root "master" replica).  There will be replication traffic, which can be scheduled or event driven.  The sparse replica replication agreements can be set via administrators to control how or what subentries are replicated (maybe only those flagged "inheritable").  As a read-only replica, it can be configured via transitive synch to take its changes from another read-only replica so you don't HAVE to have the situation where every server in the enterprise is banging away at the root-most master server for policy information, so we should be able to manage the network traffic scaling issues in large trees (though its true that using transitive synch lengthens the time it takes for changes to propagate to all servers).  And, if you don't need it, don't use it.  

The cool thing is that this approach works for any number of inheritable policy information, including schema, password policy, etc. as well as for access control information.

Anyway, that's the idea we came up with.  Discussion is invited, if only to cause a change in subject on the mailing list ;-)

Does this need to be an RFC?  If the chairs think so, let me know whether to submit it as an internet draft under the ldup group name or as an individual submission.

Thanks,
Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

---

From: "Albert Langer" <[email-masked]>
Date: Thu, 22 Feb 2001 06:59:40 +1100

[Ed]
Anyway, that's the idea we came up with.  Discussion is invited, if only to
cause a change in subject on the mailing list ;-)

[Albert]
Quick response for similar reason, as a break while still working on LDUP
final call issues.

I think it should be based directly on X.500 framework for administrative
areas with whatever
LDAP style simplifications can be achieved in those aspects that relate to
operational bindings etc but no departures at all from a common conceptual
framework as to how policy is inherited.

Seems to me that the standards themselves and David Chadwick's online book
about them point to a "natural" description that is very similar your option
5 "sparse replica".

That is to treat admin points very much like "glue" entries necessary to
maintain a connection from a subordinate context to the global tree. You
simply replicate all superior admin points that a replicated area is nested
within like any other glue. Then you use the glue style entries for those
admin points at the replica to drive whatever implementation specific
machinery is used to prioritize and enforce policy in strict accordance with
the X.500 conceptual framework.

If I understood correctly that seems to be what you saying about a "sparse
replica", but integrates it with what's also needed in this context (and has
been all along before dealing
with multi-master) - a framework for directory distribution based on X.500
with detailed
specification of operational bindings, glue entries etc. Administrative
areas can't be defined
independently of that framework without running into the fact that they are
closely connected
to it.

Interesting issue relevant to current other discussions is that I suspect
this replication could be an example where multi-master may be inapplicable
due to the extreme hairiness of allowing for policy update conflicts. That
in turn raises hairy issues about how one could combine single master
partitions (even if only containing such "admin points" and other "glue"),
with multi-master replicas subordinate to them on the same DSA
implementation, with an overlap between
the two at the innermost nested admin point. It also points to the necessity
for actually implementing the LDUP WG charter to provide for single master
as well as multi-master replication (the difference isn't just a "topology"
but involves both conformance levels for DSAs and directory service
replication requirements). Also points to need for replication management
to be standardized with provisions for creating and merging replication
areas etc.

This may also closely relate to schema replication (for which X.500 defines
similar admin
points in the same conceptual framework). There are requirements about
schema replication in the current requirements draft and machinery is needed
to be able to coordinate schema changes with the replication of entries
dependent on the schema changes - but there is no such machinery in the
current architecture drafts. Similar machinery could be needed for
coordination of policy changes.

Any such coordination machinery has to be enforced by the conflict
resolution mechanism and since none is currently specified, none is
currently implemented by URP (whether or not it could do so, given that it
does not retain log information that might be necessary).

Then coordination machinery for any of these aspects is likely to involve
something like the concepts of a "floating" or "failover" single master for
that specific aspect as in the "schema master" and "infrastructure master"
for AD. This is also needed to achieve eventual convegence as there is of
course no way to guarantee that without some means of specifying which DSAs
are currently authoritatively considered to be part of the replication
network and which are excluded from it - otherwise meta-data would grow
without bound while waiting for a failed DSA that isn't
going to come back. Again there is no such machinery in the current
architecture, consequently none in URP and no eventual convergence possible.

Hmm, ... oh well, *some* of that was a "break" and it *is* all relevant to
your original posting, which I have at least refrained from dissecting line
by line ;-)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Feb 2001 12:15:27 -0800

>framework as to how policy is inherited.

I concur.  I would prefer to keep the directory's administrative model
simple and as consistent as possible with the X.500 models.  Such
features as policy inheritance can be push into the administration
application space.  I note that one must be careful not to assume
that naming relationships have any particular significance to
the policy in force.

Also, I note (like Albert) that the administrative model in X.500 does
not to address the needs of multiple-master replication and hence may
require significant adaptation.  This may be difficult to engineer
by itself, however it will be much harder to engineer if numerous
unnecessary requirements are added to the mix.

Kurt