git.sur5r.net Git - openldap/blob - doc/drafts/draft-byrne-ldap-alias-xx.txt

   1
   2           Internet-Draft                                    D. Byrne, IBM
   3           LDAP Extensions WG                                L. Poitou, Sun
   4           Intended Category: Standards Track                E. Stokes, IBM
   5           Expires: 20 October 1998
   6
   7            20 April 1998
   8
   9                              Use of Aliases within LDAP
  10                           <draft-byrne-ldap-alias-00.txt>
  11
  12           STATUS OF THIS MEMO
  13
  14              This document is an Internet Draft. Internet Drafts are
  15              working documents of the Internet Engineering Task Force
  16              (IETF), its Areas, and its Working Groups. Note that other
  17              groups may also distribute working documents as Internet
  18              Drafts.
  19
  20              Internet Drafts are draft documents valid for a maximum of six
  21              months. Internet Drafts may be updated, replaced, or obsoleted
  22              by other documents at any time. It is not appropriate to use
  23              Internet Drafts as reference material or to cite them other
  24              than as a "working draft" or "work in progress."
  25
  26              To view the entire list of current Internet-Drafts, please
  27              check the "1id-abstracts.txt" listing contained in the
  28              Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
  29              ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
  30              Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
  31              Coast), or ftp.isi.edu (US West Coast).
  32
  33              Comments and suggestions on this document are encouraged.
  34              Comments on this document should be sent to the  LDAPEXT
  35              working group discussion list:
  36
  37                     ietf-ldapext@netscape.com
  38
  39           ABSTRACT
  40
  41              This document describes the suggested behavior for aliases for
  42              LDAPv3 and above to improve LDAP server interoperability .
  43
  44              The key words "MUST", "SHOULD", and "MAY" used in this
  45              document are to be interpreted as described in [Bradner97].
  46
  47
  48           1. Objectives
  49
  50
  51              Aliases may be used within LDAP to reference entries anywhere
  52              within the directory tree. Conceptually, an alias is simply a
  53              pointer to the DIT entry it represents. It does not contain
  54              additional information about that entry; only the location of
  55              the entry.
  56
  57              The behavior of the alias object within LDAP is not well-
  58              defined, both in creation of the alias object and the behavior
  59              when dereferencing the alias.
  60
  61              For successful interoperability, the expected behavior of
  62              servers when encountering alias objects SHOULD be consistent.
  63
  64              Additionally, it MUST be possible to use aliases without
  65              changing the LDAPv3 schema as defined in [Wahl] and without
  66              adding server-dependent data.
  67
  68
  69           2. Schema Definition
  70
  71
  72           2.1 Schema Expansion
  73
  74              The alias objectclass definitions presented in the LDAPv3
  75              Schema [Wahl] are   the basis for aliasing within ldap. The
  76              alias objectclass is a Structural objectclass with a single
  77              required attribute; the single valued aliasObjectName.
  78
  79              This definition of the alias objectclass does not allow for
  80              any attribute other than 'aliasedObjectName' to be used as the
  81              naming attribute within the RDN. The resulting dn for the
  82              alias object must therefore be of the form
  83              "aliasedObjectName=<dn>, <rdn>, <rdn>..."   This is not a
  84              user-friendly name for a directory entry, and quite possibly
  85              corrupts the naming hierarchy within the directory tree.
  86
  87              In order to remain true the concept of an alias; that it is
  88              merely a pointer to another entry, an entry of objectclass
  89              alias SHOULD NOT be combined with any other objectclass. If
  90              multiple objectclasses are combined, it becomes possible to
  91              add information to the alias entry without violating the
  92              schema rules.
  93
  94              While not explicitly specified as either a 'required' or
  95              'may', any naming attribute MUST be allowed to form the RDN of
  96              the alias. Restricting the possible naming attributes would
  97              potentially corrupt the hierarchy. For example, it would be
  98              impossible to distinguish between a person alias and an
  99              organisation alias.
 100
 101           2.2 AliasObject Objectclass
 102
 103              In order to create an alias object which can be appropriately
 104              named to that which it represents, the definition of the alias
 105              object MUST be expanded. A new objectclass must be defined
 106              which inherits from the current definition of alias but
 107              extends the attributes allowed within the RDN.
 108
 109               ( 1.3.6.1.4.1.42.2.27.1.2.1
 110                  NAME      'aliasObject'
 111                  DESC      objectclass for all alias objects
 112                  SUP           'ALIAS'
 113                  MAY         *
 114               )
 115
 116              The '*' allows any naming attribute to be used in forming the
 117              RDN of the object.
 118
 119              For example, the following is a correct LDIF:
 120              dn: cn=John Doe, ou=myOrg, c=US
 121              objectclass: alias
 122              objectclass: aliasObject
 123              aliasedObjectName: cn=President, ou=myOrg, c=US
 124              cn: John Doe
 125
 126              To prevent the alias from containing extra information about
 127              the object, the naming attribute SHOULD contain only a single
 128              value.
 129
 130              For example, the following is  not a correct LDIF:
 131              dn: cn=John Doe, ou=myOrg, c=US
 132              objectclass: alias
 133              objectclass: aliasObject
 134              aliasedObjectName: cn=President, ou=myOrg, c=US
 135              cn: John Doe
 136              cn: Doe
 137
 138              Similarly, the following would not be a correct LDIF file
 139              because it adds extra information to the alias object.
 140
 141              dn: cn=John Doe, ou=myOrg, c=US
 142              objectclass: alias
 143              objectclass: aliasObject
 144              aliasedObjectName: cn=President, ou=myOrg, c=US
 145              cn: John Doe
 146              title: President
 147
 148              The naming attribute used to form the RDN of the object SHOULD
 149              reflect the naming attribute of the referenced object.
 150              However, there are some cases where the naming attribute MAY
 151              be different.
 152
 153              Within the X.501 [ITU-T], the attribute used to described the
 154              aliased object is 'aliasedEntryName'. Since the OID for
 155              'aliasedEntryName' and 'aliasedObjectName' are the same for
 156              both X.500 and LDAP, LDAP servers SHOULD treat the
 157              'aliasedEntryName' as a synonym for 'aliasedObjectName'.
 158
 159
 160           3. Alias Behavior
 161
 162              In general alias objects SHOULD NOT be dereferenced during any
 163              operation other than search unless requested to do so by the
 164              client.
 165
 166              Since an alias points to another section of the tree, it MUST
 167              NOT be possible to add an object under an alias object; alias
 168              objects MUST always be leaf nodes.
 169
 170              During the dereferencing of aliases, a loop is detected if the
 171              server visits the same alias entry more than once. In this
 172              case a data integrity error has occurred and the server MUST
 173              return an error of 'aliasProblem'
 174
 175              If an alias is dereferenced, and the resulting directory entry
 176              does not exists, a data integrity problem has occurred, and
 177              the server MUST return an  error code of
 178              'aliasDereferencingProblem'
 179
 180              If the base entry for an ldapsearch is an alias, and alias
 181              dereferencing is set to either derefFindBaseObj, or
 182              derefAlways, the base entry MUST be dereferenced before the
 183              search is performed. The new base for the search will become
 184              the entry to which the alias resolves. The search is then
 185              performed.
 186
 187              If multiple aliases are chained, the alias for the first
 188              object MUST resolve to the last entry in the chain. For
 189              example, A, B, and C are alias objects. If A points to B which
 190              points to C which points to D, A resolves to D when
 191              dereferencing the alias.
 192
 193              If an alias is dereferenced as part of a search, the alias
 194              entry itself SHOULD NOT be returned as part of the search.
 195
 196              If an alias matches the search filter, and dereferencing is
 197              set to 'searching' or 'always', the dereferenced object SHOULD
 198              be returned, even if it does not match the filter.
 199
 200              If the alias is not dereferenced during the search, and it
 201              matches the filter, then it SHOULD be returned within the
 202              search result.
 203
 204              Each directory object matching a filter SHOULD be returned
 205              only once during a search. If an entry is found twice because
 206              of aliases pointing to a part of the tree already searched,
 207              the entry SHOULD NOT be returned to the client a second time.
 208
 209           4. Scenarios
 210
 211              Using the following LDIF, the scenarios would return the
 212              expected information as follows:
 213
 214              dn: c=myCountry
 215              c: myCountry
 216              objectclass: country
 217
 218              dn: ou=Area1, c=myCountry
 219              ou: Area1
 220              aliasedObjectName: o=myCorporation, c=myCountry
 221              objectclass: alias
 222              objectclass:aliasObject
 223
 224              dn: o=myCorporation, c=myCountry
 225              ou: myCorporation
 226              objectclass:organization
 227
 228              dn: cn=President, o=myCorporation, c=myCountry
 229              cn: President
 230              aliasObjectName:  cn=John Doe, o=myCorporation, c=myCountry
 231              objectclass: alias
 232              objectclass: aliasObject
 233
 234              dn: cn=John Doe, o=myCorporation, c=myCountry
 235              cn: John Doe
 236              objectclass: person
 237
 238
 239                       c = myCountry
 240                      /            |
 241               ou = Area1 ----->  o = myCorporation
 242                                   |               \
 243                              cn=President --->  cn = John Doe
 244
 245              Performing a base search of 'ou = Area1, c=myCountry' with a
 246              filter of 'objectclass=aliasObject'
 247              NeverDerefAlias would return 'ou=Area1, c=myCountry'
 248              DerefFinding would return 'cn=President, o=myCorporation,
 249              c=myCountry'
 250              DerefSearching would return 'o=myCorporation,
 251              c=myCountry'
 252              DerefAlways would return 'cn=John Doe, o=myCorporation,
 253              c=myCountry'
 254
 255              Performing a one level search of 'c=myCountry' with a filter
 256              of 'ou = * '
 257              NeverDerefAlias would return  'ou=Area1, c=myCountry'
 258              DerefFinding would return  'ou=Area1, c=myCountry'
 259              DerefSearching would return 'o=myCorporation,
 260              c=myCountry'
 261              DerefAlways would return ' o=myCorporation, c=myCountry'
 262
 263              Performing a full tree search of 'c=myCountry' with a filter
 264              of ' cn = President '
 265              NeverDerefAlias would return  'cn=President, o=myCorporation,
 266              c=myCountry'
 267              DerefFinding would return  'cn=President, o=myCorporation,
 268              c=myCountry'
 269              DerefSearching would return 'cn=John Doe, o=myCorporation,
 270              c=myCountry'
 271              DerefAlways would return 'cn=John Doe, o=myCorporation,
 272              c=myCountry'
 273
 274
 275           6. Security Considerations
 276
 277              Permissions to dereferencing an alias, adding, deleting or
 278              returning alias entries are decided by the directory server's
 279              ACL administration policy.
 280
 281
 282           7. References
 283
 284              [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
 285              Access Protocol (v3)", RFC 2251, December 1997.
 286
 287              [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
 288              Directory Access Protocol (v3)": Attribute Syntax Definitions,
 289              RFC 2252, December 1997.
 290
 291              [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
 292              Indicate Requirement Levels", RFC 2119.
 293
 294              [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993
 295
 296
 297           AUTHOR(S) ADDRESS
 298
 299
 300               Debbie Byrne
 301               IBM
 302               11400 Burnet Rd
 303               Austin, TX 78758
 304               USA
 305               mail-to: djbyrne@us.ibm.com
 306               phone: +1 512 838 1930
 307
 308               Ludovic Poitou
 309               Sun Microsystems
 310               32, Chemin du vieux Chene
 311               38240 Meylan
 312               France
 313               Phone: +33.(0)4.76.41.42.12
 314               email: ludovic.poitou@france.sun.com
 315
 316               Ellen Stokes
 317               IBM
 318               11400 Burnet Rd
 319               Austin, TX 78758
 320               USA
 321               mail-to: stokes@austin.ibm.com
 322               phone: +1 512 838 3725
 323
 324