openldap/doc/drafts/draft-byrne-ldap-alias-xx.txt

          Internet-Draft                                    D. Byrne, IBM
          LDAP Extensions WG                                L. Poitou, Sun
          Intended Category: Standards Track                E. Stokes, IBM
          Expires: 20 October 1998

           20 April 1998

                             Use of Aliases within LDAP
                          <draft-byrne-ldap-alias-00.txt>

          STATUS OF THIS MEMO

             This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted
             by other documents at any time. It is not appropriate to use
             Internet Drafts as reference material or to cite them other
             than as a "working draft" or "work in progress."

             To view the entire list of current Internet-Drafts, please
             check the "1id-abstracts.txt" listing contained in the
             Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
             ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
             Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
             Coast), or ftp.isi.edu (US West Coast).

             Comments and suggestions on this document are encouraged.
             Comments on this document should be sent to the  LDAPEXT
             working group discussion list:

                    ietf-ldapext@netscape.com

          ABSTRACT

             This document describes the suggested behavior for aliases for
             LDAPv3 and above to improve LDAP server interoperability .

             The key words "MUST", "SHOULD", and "MAY" used in this
             document are to be interpreted as described in [Bradner97].


          1. Objectives


             Aliases may be used within LDAP to reference entries anywhere
             within the directory tree. Conceptually, an alias is simply a
             pointer to the DIT entry it represents. It does not contain
             additional information about that entry; only the location of
             the entry.

             The behavior of the alias object within LDAP is not well-
             defined, both in creation of the alias object and the behavior
             when dereferencing the alias.

             For successful interoperability, the expected behavior of
             servers when encountering alias objects SHOULD be consistent.

             Additionally, it MUST be possible to use aliases without
             changing the LDAPv3 schema as defined in [Wahl] and without
             adding server-dependent data.


          2. Schema Definition


          2.1 Schema Expansion

             The alias objectclass definitions presented in the LDAPv3
             Schema [Wahl] are   the basis for aliasing within ldap. The
             alias objectclass is a Structural objectclass with a single
             required attribute; the single valued aliasObjectName.

             This definition of the alias objectclass does not allow for
             any attribute other than 'aliasedObjectName' to be used as the
             naming attribute within the RDN. The resulting dn for the
             alias object must therefore be of the form
             "aliasedObjectName=<dn>, <rdn>, <rdn>..."   This is not a
             user-friendly name for a directory entry, and quite possibly
             corrupts the naming hierarchy within the directory tree.

             In order to remain true the concept of an alias; that it is
             merely a pointer to another entry, an entry of objectclass
             alias SHOULD NOT be combined with any other objectclass. If
             multiple objectclasses are combined, it becomes possible to
             add information to the alias entry without violating the
             schema rules.

             While not explicitly specified as either a 'required' or
             'may', any naming attribute MUST be allowed to form the RDN of
             the alias. Restricting the possible naming attributes would
             potentially corrupt the hierarchy. For example, it would be
             impossible to distinguish between a person alias and an
             organisation alias.

          2.2 AliasObject Objectclass

             In order to create an alias object which can be appropriately
             named to that which it represents, the definition of the alias
             object MUST be expanded. A new objectclass must be defined
             which inherits from the current definition of alias but
             extends the attributes allowed within the RDN.

              ( 1.3.6.1.4.1.42.2.27.1.2.1
                 NAME      'aliasObject'
                 DESC      objectclass for all alias objects
                 SUP           'ALIAS'
                 MAY         *
              )

             The '*' allows any naming attribute to be used in forming the
             RDN of the object.

             For example, the following is a correct LDIF:
             dn: cn=John Doe, ou=myOrg, c=US
             objectclass: alias
             objectclass: aliasObject
             aliasedObjectName: cn=President, ou=myOrg, c=US
             cn: John Doe

             To prevent the alias from containing extra information about
             the object, the naming attribute SHOULD contain only a single
             value.

             For example, the following is  not a correct LDIF:
             dn: cn=John Doe, ou=myOrg, c=US
             objectclass: alias
             objectclass: aliasObject
             aliasedObjectName: cn=President, ou=myOrg, c=US
             cn: John Doe
             cn: Doe

             Similarly, the following would not be a correct LDIF file
             because it adds extra information to the alias object.

             dn: cn=John Doe, ou=myOrg, c=US
             objectclass: alias
             objectclass: aliasObject
             aliasedObjectName: cn=President, ou=myOrg, c=US
             cn: John Doe
             title: President

             The naming attribute used to form the RDN of the object SHOULD
             reflect the naming attribute of the referenced object.
             However, there are some cases where the naming attribute MAY
             be different.

             Within the X.501 [ITU-T], the attribute used to described the
             aliased object is 'aliasedEntryName'. Since the OID for
             'aliasedEntryName' and 'aliasedObjectName' are the same for
             both X.500 and LDAP, LDAP servers SHOULD treat the
             'aliasedEntryName' as a synonym for 'aliasedObjectName'.


          3. Alias Behavior

             In general alias objects SHOULD NOT be dereferenced during any
             operation other than search unless requested to do so by the
             client.

             Since an alias points to another section of the tree, it MUST
             NOT be possible to add an object under an alias object; alias
             objects MUST always be leaf nodes.

             During the dereferencing of aliases, a loop is detected if the
             server visits the same alias entry more than once. In this
             case a data integrity error has occurred and the server MUST
             return an error of 'aliasProblem'

             If an alias is dereferenced, and the resulting directory entry
             does not exists, a data integrity problem has occurred, and
             the server MUST return an  error code of
             'aliasDereferencingProblem'

             If the base entry for an ldapsearch is an alias, and alias
             dereferencing is set to either derefFindBaseObj, or
             derefAlways, the base entry MUST be dereferenced before the
             search is performed. The new base for the search will become
             the entry to which the alias resolves. The search is then
             performed.

             If multiple aliases are chained, the alias for the first
             object MUST resolve to the last entry in the chain. For
             example, A, B, and C are alias objects. If A points to B which
             points to C which points to D, A resolves to D when
             dereferencing the alias.

             If an alias is dereferenced as part of a search, the alias
             entry itself SHOULD NOT be returned as part of the search.

             If an alias matches the search filter, and dereferencing is
             set to 'searching' or 'always', the dereferenced object SHOULD
             be returned, even if it does not match the filter.

             If the alias is not dereferenced during the search, and it
             matches the filter, then it SHOULD be returned within the
             search result.

             Each directory object matching a filter SHOULD be returned
             only once during a search. If an entry is found twice because
             of aliases pointing to a part of the tree already searched,
             the entry SHOULD NOT be returned to the client a second time.

          4. Scenarios

             Using the following LDIF, the scenarios would return the
             expected information as follows:

             dn: c=myCountry
             c: myCountry
             objectclass: country

             dn: ou=Area1, c=myCountry
             ou: Area1
             aliasedObjectName: o=myCorporation, c=myCountry
             objectclass: alias
             objectclass:aliasObject

             dn: o=myCorporation, c=myCountry
             ou: myCorporation
             objectclass:organization

             dn: cn=President, o=myCorporation, c=myCountry
             cn: President
             aliasObjectName:  cn=John Doe, o=myCorporation, c=myCountry
             objectclass: alias
             objectclass: aliasObject

             dn: cn=John Doe, o=myCorporation, c=myCountry
             cn: John Doe
             objectclass: person


                      c = myCountry
                     /            |
              ou = Area1 ----->  o = myCorporation
                                  |               \
                             cn=President --->  cn = John Doe

             Performing a base search of 'ou = Area1, c=myCountry' with a
             filter of 'objectclass=aliasObject'
             NeverDerefAlias would return 'ou=Area1, c=myCountry'
             DerefFinding would return 'cn=President, o=myCorporation,
             c=myCountry'
             DerefSearching would return 'o=myCorporation,
             c=myCountry'
             DerefAlways would return 'cn=John Doe, o=myCorporation,
             c=myCountry'

             Performing a one level search of 'c=myCountry' with a filter
             of 'ou = * '
             NeverDerefAlias would return  'ou=Area1, c=myCountry'
             DerefFinding would return  'ou=Area1, c=myCountry'
             DerefSearching would return 'o=myCorporation,
             c=myCountry'
             DerefAlways would return ' o=myCorporation, c=myCountry'

             Performing a full tree search of 'c=myCountry' with a filter
             of ' cn = President '
             NeverDerefAlias would return  'cn=President, o=myCorporation,
             c=myCountry'
             DerefFinding would return  'cn=President, o=myCorporation,
             c=myCountry'
             DerefSearching would return 'cn=John Doe, o=myCorporation,
             c=myCountry'
             DerefAlways would return 'cn=John Doe, o=myCorporation,
             c=myCountry'


          6. Security Considerations

             Permissions to dereferencing an alias, adding, deleting or
             returning alias entries are decided by the directory server's
             ACL administration policy.


          7. References

             [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
             Access Protocol (v3)", RFC 2251, December 1997.

             [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
             Directory Access Protocol (v3)": Attribute Syntax Definitions,
             RFC 2252, December 1997.

             [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
             Indicate Requirement Levels", RFC 2119.

             [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993


          AUTHOR(S) ADDRESS


              Debbie Byrne
              IBM
              11400 Burnet Rd
              Austin, TX 78758
              USA
              mail-to: djbyrne@us.ibm.com
              phone: +1 512 838 1930

              Ludovic Poitou
              Sun Microsystems
              32, Chemin du vieux Chene
              38240 Meylan
              France
              Phone: +33.(0)4.76.41.42.12
              email: ludovic.poitou@france.sun.com

              Ellen Stokes
              IBM
              11400 Burnet Rd
              Austin, TX 78758
              USA
              mail-to: stokes@austin.ibm.com
              phone: +1 512 838 3725