mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
325 lines
13 KiB
Plaintext
325 lines
13 KiB
Plaintext
|
|
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
|
|
|
|
|