git.sur5r.net Git - openldap/blob - doc/drafts/draft-legg-ldap-admin-xx.txt

   1 INTERNET-DRAFT                                                   S. Legg
   2 draft-legg-ldap-admin-02.txt                         Adacel Technologies
   3 Intended Category: Standards Track                         June 16, 2004
   4
   5
   6              Lightweight Directory Access Protocol (LDAP):
   7                      Directory Administrative Model
   8
   9     Copyright (C) The Internet Society (2004). All Rights Reserved.
  10
  11    Status of this Memo
  12
  13
  14    This document is an Internet-Draft and is in full conformance with
  15    all provisions of Section 10 of RFC2026.
  16
  17    Internet-Drafts are working documents of the Internet Engineering
  18    Task Force (IETF), its areas, and its working groups.  Note that
  19    other groups may also distribute working documents as
  20    Internet-Drafts.
  21
  22    Internet-Drafts are draft documents valid for a maximum of six months
  23    and may be updated, replaced, or obsoleted by other documents at any
  24    time.  It is inappropriate to use Internet-Drafts as reference
  25    material or to cite them other than as "work in progress".
  26
  27    The list of current Internet-Drafts can be accessed at
  28    http://www.ietf.org/ietf/1id-abstracts.txt
  29
  30    The list of Internet-Draft Shadow Directories can be accessed at
  31    http://www.ietf.org/shadow.html.
  32
  33    Distribution of this document is unlimited.  Comments should be sent
  34    to the author.
  35
  36    This Internet-Draft expires on 16 December 2004.
  37
  38
  39 Abstract
  40
  41    This document adapts the X.500 directory administrative model for use
  42    by the Lightweight Directory Access Protocol.  The administrative
  43    model partitions the Directory Information Tree for various aspects
  44    of directory data administration, e.g., subschema, access control and
  45    collective attributes.  The generic framework that applies to every
  46    aspect of administration is described in this document.  The
  47    definitions that apply for a specific aspect of administration, e.g.,
  48    access control administration, are described in other documents.
  49
  50
  51
  52 Legg                    Expires 16 December 2004                [Page 1]
  53 \f
  54 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
  55
  56
  57 Table of Contents
  58
  59    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  60    2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
  61    3.  Administrative Areas . . . . . . . . . . . . . . . . . . . . .  2
  62    4.  Autonomous Administrative Areas. . . . . . . . . . . . . . . .  3
  63    5.  Specific Administrative Areas. . . . . . . . . . . . . . . . .  3
  64    6.  Inner Administrative Areas . . . . . . . . . . . . . . . . . .  4
  65    7.  Administrative Entries . . . . . . . . . . . . . . . . . . . .  4
  66    8.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
  67    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
  68    10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  69        10.1.  Normative References. . . . . . . . . . . . . . . . . .  5
  70        10.2.  Informative References. . . . . . . . . . . . . . . . .  5
  71    11. Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
  72    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  6
  73
  74 1.  Introduction
  75
  76    This document adapts the X.500 directory administrative model [X501]
  77    for use by the Lightweight Directory Access Protocol (LDAP) [LDAP].
  78    The administrative model partitions the Directory Information Tree
  79    (DIT) for various aspects of directory data administration, e.g.,
  80    subschema, access control and collective attributes.  This document
  81    provides the definitions for the generic parts of the administrative
  82    model that apply to every aspect of directory data administration.
  83
  84    Sections 3 to 7, in conjunction with [SUBENTRY], describe the means
  85    by which administrative authority is aportioned and exercised in the
  86    DIT.
  87
  88    Aspects of administration that conform to the administrative model
  89    described in this document are detailed elsewhere, e.g., access
  90    control administration is described in [ACA] and collective attribute
  91    administration is described in [COLLECT].
  92
  93    This document is derived from, and duplicates substantial portions
  94    of, Sections 4 and 8 of X.501 [X501].
  95
  96 2.  Conventions
  97
  98    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  99    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
 100    document are to be interpreted as described in BCP 14, RFC 2119
 101    [RFC2119].
 102
 103 3.  Administrative Areas
 104
 105
 106
 107
 108 Legg                    Expires 16 December 2004                [Page 2]
 109 \f
 110 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
 111
 112
 113    An administrative area is a subtree of the DIT considered from the
 114    perspective of administration.  The root entry of the subtree is an
 115    administrative point.  An administrative point is represented by an
 116    entry holding an administrativeRole attribute [SUBENTRY].  The values
 117    of this attribute identify the kind of administrative point.
 118
 119 4.  Autonomous Administrative Areas
 120
 121    The DIT may be partitioned into one or more non-overlapping subtrees
 122    termed autonomous administrative areas.  It is expected that the
 123    entries in an autonomous administrative area are all administered by
 124    the same administrative authority.
 125
 126    An administrative authority may be responsible for several autonomous
 127    administrative areas in separated parts of the DIT but it SHOULD NOT
 128    arbitrarily partition the collection of entries under its control
 129    into autonomous administrative areas (thus creating adjacent
 130    autonomous areas administered by the same authority).
 131
 132    The root entry of an autonomous administrative area's subtree is
 133    called an autonomous administrative point.  An autonomous
 134    administrative area extends from its autonomous administrative point
 135    downwards until another autonomous administrative point is
 136    encountered, at which point another autonomous administrative area
 137    begins.
 138
 139 5.  Specific Administrative Areas
 140
 141    Entries in an administrative area may be considered in terms of a
 142    specific administrative function.  When viewed in this context, an
 143    administrative area is termed a specific administrative area.
 144
 145    Examples of specific administrative areas are subschema specific
 146    administrative areas, access control specific areas and collective
 147    attribute specific areas.
 148
 149    An autonomous administrative area may be considered as implicitly
 150    defining a single specific administrative area for each specific
 151    aspect of administration.  In this case, there is a precise
 152    correspondence between each such specific administrative area and the
 153    autonomous administrative area.
 154
 155    Alternatively, for each specific aspect of administration, the
 156    autonomous administrative area may be partitioned into
 157    non-overlapping specific administrative areas.
 158
 159    If so partitioned for a particular aspect of administration, each
 160    entry of the autonomous administrative area is contained in one and
 161
 162
 163
 164 Legg                    Expires 16 December 2004                [Page 3]
 165 \f
 166 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
 167
 168
 169    only one specific administrative area for that aspect, i.e., specific
 170    administrative areas do not overlap.
 171
 172    The root entry of a specific administrative area's subtree is called
 173    a specific administrative point.  A specific administrative area
 174    extends from its specific administrative point downwards until
 175    another specific administrative point of the same administrative
 176    aspect is encountered, at which point another specific administrative
 177    area begins.  Specific administrative areas are always bounded by the
 178    autonomous administrative area they partition.
 179
 180    Where an autonomous administrative area is not partitioned for a
 181    specific aspect of administration, the specific administrative area
 182    for that aspect coincides with the autonomous administrative area.
 183    In this case, the autonomous administrative point is also the
 184    specific administrative point for this aspect of administration.  A
 185    particular administrative point may be the root of an autonomous
 186    administrative area and may be the root of one or more specific
 187    administrative areas for different aspects of administration.
 188
 189    It is not necessary for an administrative point to represent each
 190    specific aspect of administrative authority.  For example, there
 191    might be an administrative point, subordinate to the root of the
 192    autonomous administrative area, which is used for access control
 193    purposes only.
 194
 195 6.  Inner Administrative Areas
 196
 197    For some aspects of administration, e.g., access control or
 198    collective attributes, inner administrative areas may be defined
 199    within the specific administrative areas, to allow a limited form of
 200    delegation, or for administrative or operational convenience.
 201
 202    An inner administrative area may be nested within another inner
 203    administrative area.  The rules for nested inner areas are defined as
 204    part of the definition of the specific administrative aspect for
 205    which they are allowed.
 206
 207    The root entry of an inner administrative area's subtree is called an
 208    inner administrative point.  An inner administrative area (within a
 209    specific administrative area) extends from its inner administrative
 210    point downwards until a specific administrative point of the same
 211    administrative aspect is encountered.  An inner administrative area
 212    is bounded by the specific administrative area within which it is
 213    defined.
 214
 215 7.  Administrative Entries
 216
 217
 218
 219
 220 Legg                    Expires 16 December 2004                [Page 4]
 221 \f
 222 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
 223
 224
 225    An entry located at an administrative point is an administrative
 226    entry.  Administrative entries MAY have subentries [SUBENTRY] as
 227    immediate subordinates.  The administrative entry and its associated
 228    subentries are used to control the entries encompassed by the
 229    associated administrative area.  Where inner administrative areas are
 230    used, the scopes of these areas may overlap.  Therefore, for each
 231    specific aspect of administrative authority, a definition is required
 232    of the method of combination of administrative information when it is
 233    possible for entries to be included in more than one subtree or
 234    subtree refinement associated with an inner area defined for that
 235    aspect.
 236
 237 8.  Security Considerations
 238
 239    This document defines a generic framework for employing policy of
 240    various kinds, e.g., access controls, to entries in the DIT.  Such
 241    policy can only be correctly enforced at a directory server holding a
 242    replica of a portion of the DIT if the administrative entries for
 243    administrative areas that overlap the portion of the DIT being
 244    replicated, and the subentries of those administrative entries
 245    relevant to any aspect of policy that is required to be enforced at
 246    the replica, are included in the replicated information.
 247
 248    Administrative entries and subentries SHOULD be protected from
 249    unauthorized examination or changes by appropriate access controls.
 250
 251 9.  Acknowledgements
 252
 253    This document is derived from, and duplicates substantial portions
 254    of, Sections 4 and 8 of X.501 [X501].
 255
 256 10.  References
 257
 258 10.1.  Normative References
 259
 260    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 261               Requirement Levels", BCP 14, RFC 2119, March 1997.
 262
 263    [LDAP]     Hodges, J. and R. Morgan, "Lightweight Directory Access
 264               Protocol (v3): Technical Specification", RFC 3377,
 265               September 2002.
 266
 267    [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
 268               Directory Access Protocol (LDAP)", RFC 3672, December
 269               2003.
 270
 271 10.2.  Informative References
 272
 273
 274
 275
 276 Legg                    Expires 16 December 2004                [Page 5]
 277 \f
 278 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
 279
 280
 281    [COLLECT]  Zeilenga, K., "Collective Attributes in the Lightweight
 282               Directory Access Protocol (LDAP)", RFC 3671, December
 283               2003.
 284
 285    [ACA]      Legg, S., "Lightweight Directory Access Protocol (LDAP):
 286               Access Control Administration",
 287               draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
 288               2004.
 289
 290    [X501]     ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
 291               Information technology - Open Systems Interconnection -
 292               The Directory: Models
 293
 294 11.  Author's Address
 295
 296    Steven Legg
 297    Adacel Technologies Ltd.
 298    250 Bay Street
 299    Brighton, Victoria 3186
 300    AUSTRALIA
 301
 302    Phone: +61 3 8530 7710
 303      Fax: +61 3 8530 7888
 304    EMail: steven.legg@adacel.com.au
 305
 306 Full Copyright Statement
 307
 308    Copyright (C) The Internet Society (2004).  This document is subject
 309    to the rights, licenses and restrictions contained in BCP 78, and
 310    except as set forth therein, the authors retain all their rights.
 311
 312    This document and the information contained herein are provided on an
 313    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 314    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 315    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 316    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 317    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 318    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 319
 320 Intellectual Property
 321
 322    The IETF takes no position regarding the validity or scope of any
 323    Intellectual Property Rights or other rights that might be claimed to
 324    pertain to the implementation or use of the technology described in
 325    this document or the extent to which any license under such rights
 326    might or might not be available; nor does it represent that it has
 327    made any independent effort to identify any such rights.  Information
 328    on the procedures with respect to rights in RFC documents can be
 329
 330
 331
 332 Legg                    Expires 16 December 2004                [Page 6]
 333 \f
 334 INTERNET-DRAFT       Directory Administrative Model        June 16, 2004
 335
 336
 337    found in BCP 78 and BCP 79.
 338
 339    Copies of IPR disclosures made to the IETF Secretariat and any
 340    assurances of licenses to be made available, or the result of an
 341    attempt made to obtain a general license or permission for the use of
 342    such proprietary rights by implementers or users of this
 343    specification can be obtained from the IETF on-line IPR repository at
 344    http://www.ietf.org/ipr.
 345
 346    The IETF invites any interested party to bring to its attention any
 347    copyrights, patents or patent applications, or other proprietary
 348    rights that may cover technology that may be required to implement
 349    this standard.  Please address the information to the IETF at
 350    ietf-ipr@ietf.org.
 351
 352 Changes in Draft 00
 353
 354    This document reproduces Section 4 from
 355    draft-legg-ldap-acm-admin-00.txt as a standalone document.  All
 356    changes made are purely editorial.  No technical changes have been
 357    introduced.
 358
 359 Changes in Draft 01
 360
 361    RFC 3377 replaces RFC 2251 as the reference for LDAP.
 362
 363 Changes in Draft 02
 364
 365    The document has been reformatted in line with current practice.
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388 Legg                    Expires 16 December 2004                [Page 7]
 389 \f
 390