draft-ietf-ldup-inheritance-00.txt

["Ed Reed" <eer@OnCallDBA.COM>]

Please publish the attached new internet draft.

Abstract:

There are several possible ways to manage inheritance of policy 
information in a directory service.  This document describes several 
known mechanisms and recommends one for general use that can be 
implemented using [LDUP]. 

To the LDUP and LDAPEXT working groups:

This is the draftified version of my notes on inheritance mechanisms
for which there is already discussion taking place on the mailing lists.
I've broken out this inheritance discussion from the LDAP Subentries
internet draft so as to keep the two discussions separate and on-track.

To the LDUP and LDAPEXT chairs:

I'd appreciate a short time to discuss this document in one or both
work group meetings in Minneapolis, if you think that appropriate.

To Rick:

Here's wondering if it arrives in base64 encoding for you ;-)

Regards,
Ed

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






INTERNET-DRAFT 
draft-ietf-ldup-inheritance-00.txt 
                                                     Ed Reed 
                                         Reed-Matthews, Inc. 
                                           February 21, 2001 
 
           Policy Inheritance Mechanisms for LDAP 
 


1  Status of this Memo 

 
This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC2026. 
 
Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and its working groups. Note that other groups 
may also distribute working documents as Internet-Drafts.  
 
Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet-Drafts as reference material 
or to cite them other than as "work in progress."  
 
The list of current Internet-Drafts can be accessed at 
http://www.ietf.org/ietf/1id-abstracts.txt.  
 
The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html. 
 
This Internet-Draft expires on August 21, 2001. 
 


2  Abstract / Description 

There are several possible ways to manage inheritance of policy 
information in a directory service.  This document describes several 
known mechanisms and recommends one for general use that can be 
implemented using [LDUP]. 


3  Preamble 

At the San Diego IETF (49) in December 2000 a bar boff (1 round = $89 
or so USD so there were 20-30 people in attendance) 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.   
 


Reed                                           [Page 1 of 5] 
                  Expires August 21, 2001 


INTERNET DRAFT                               February 21, 2001 
             draft-ietf-ldup-inheritance-00.txt 

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 the directory information tree in 
X.500 for a country, a governmental agency or any other sort of large 
organization. 


4  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 co-reside 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? 


5  Possible Approaches (incomplete list) 

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 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 implementations generally handle it. [Editor:  change 
this to an affirmative statement when verified] 
 
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.   


Reed                                           [Page 2 of 5] 
                  Expires August 21, 2001 


INTERNET DRAFT                               February 21, 2001 
             draft-ietf-ldup-inheritance-00.txt 

 
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 caching it locally for future use.  The walk would 
take place at server startup time, 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.  [Editor:  change this to an affirmative statement when 
verified]  
 
[Editorial note - this note already 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 that 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.   
 

Reed                                           [Page 3 of 5] 
                  Expires August 21, 2001 


INTERNET DRAFT                               February 21, 2001 
             draft-ietf-ldup-inheritance-00.txt 

Being "read-only" replicas, the LDUP house keeping is kept to a minimum 
(because there will never be changes flowing from the subordinate 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.   
 
This is effectively how Novell manages schema policy propagation 
through their trees, and [may ? Editor: verify] also how Microsoft 
handles schema propagation through their forests. 
 
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. 


6  Conclusion and Recommendation 

The result of the bar boff was the publication of this note.   
 
The recommendation of this note is that mechanism #5 above be used to 
propagate policy information using LDUP when subordinate partitions of 
a directory information tree need to know about inherited policy that 
affects them.  The approach has the benefits of having considerable 
operational experience in enterprise-scale directory deployments, uses 
[LDUP] in a manner consistent with its intended usage, avoids trying to 
create a new generalized description of inheritance aggregation (and 
leaves that to the applications who will define their own required 
semantics, anyway), and generally accomplishes the (limited) objectives 
set out in the requirement statement above. 
 


7  References 

[LDUP] refers to the collection of Internet drafts and RFCs which 
describe the requirements, architecture, schema, conflict resolution 
procedures, etc. that are available from the LDUP home page: 
     http://www.ietf.org/html.charters/ldup-charter.html 


8  Copyright Notice 

Copyright (C) The Internet Society (2001). All Rights Reserved.  
 
This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it or 
assist in its implementation may be prepared, copied, published and 

Reed                                           [Page 4 of 5] 
                  Expires August 21, 2001 


INTERNET DRAFT                               February 21, 2001 
             draft-ietf-ldup-inheritance-00.txt 

distributed, in whole or in part, without restriction of any kind, 
provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing the 
copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of developing 
Internet standards in which case the procedures for copyrights defined 
in the Internet Standards process must be followed, or as required to 
translate it into languages other than English. 
 
The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 
 
This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 
FITNESS FOR A PARTICULAR PURPOSE." 
 


9  Author?s Address 

Edwards E. Reed 
Reed-Matthews, Inc. 
1064 E 140 North 
Lindon, UT  84042 
USA 
E-mail: eer@oncalldba.com  
      
LDUP Mailing List: ietf-ldup@imc.org  
LDAPEXT Mailing List: ietf-ldapext@netscape.com 























Reed                                           [Page 5 of 5] 
                  Expires August 21, 2001