home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / ldapsdk.zip / doc / drafts / draft-byrne-ldap-alias-xx.txt next >
Text File  |  1999-08-20  |  13KB  |  325 lines
  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.  
  325.