mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-01-06 10:46:21 +08:00
draft-02 (a complete rewrite)
This commit is contained in:
parent
c8f7041c09
commit
e18b9336ee
@ -1,307 +1,405 @@
|
||||
Internet-Draft David Chadwick
|
||||
LDAPExt WG University of Salford
|
||||
Intended Category: Standards Track Sean Mullan
|
||||
Sun
|
||||
Microsystems
|
||||
Expires: 8 March 2000 8 September 1999
|
||||
|
||||
Returning Matched Values with LDAPv3
|
||||
<draft-ietf-ldapext-matchedval-01.txt>
|
||||
|
||||
STATUS OF THIS MEMO
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with
|
||||
all the provisions of Section 10 of RFC2026.
|
||||
|
||||
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
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft expires on 8 March 2000. 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
|
||||
or directly to the authors.
|
||||
|
||||
ABSTRACT
|
||||
|
||||
This document describes a control for the Lightweight Directory
|
||||
Access Protocol v3 that is used to return a subset of attribute
|
||||
values from an entry, specifically, only those values that
|
||||
contributed to the search filter evaluating to TRUE. Without support
|
||||
for this control, a client must retrieve all of an attribute's values
|
||||
and search for specific values locally.
|
||||
|
||||
1. Introduction
|
||||
|
||||
When reading an attribute from an entry using LDAP v2 [1] or LDAPv3
|
||||
[2], it is normally only possible to read either the attribute type,
|
||||
or the attribute type and all its values. It is not possible to
|
||||
selectively read just a few of the attribute values. If an attribute
|
||||
holds many values, for example, the userCertificate attribute, or the
|
||||
subschema publishing operational attributes objectClasses and
|
||||
attributeTypes [3], then it may be desirable for the user to be able
|
||||
to selectively retrieve a subset of the values, specifically, those
|
||||
attribute values that match the selection criteria as specified by
|
||||
the user in the filter. Without the control specified in this
|
||||
[ID/standard] a client must read all of the attribute's values and
|
||||
filter out the unwanted values, necessitating the client to implement
|
||||
the matching rules. It also requires the client to potentially read
|
||||
and process many irrelevant values, which can be inefficient if the
|
||||
values are large or complex, or there are many values stored per
|
||||
attribute.
|
||||
|
||||
This Internet Draft specifies an LDAPv3 control to enable a user to
|
||||
return only those values that matched (i.e. returned TRUE to) one or
|
||||
more elements of the Search filter. This control can be especially
|
||||
useful when used in conjunction with extensible matching rules that
|
||||
match on one or more components of complex binary attribute values.
|
||||
|
||||
The control has been described in such a way as to be fully
|
||||
compatible with the matchedValuesOnly boolean of the X.500 DAP [4]
|
||||
Search argument, as amended in the latest version [6].
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [5].
|
||||
|
||||
2. The matchedValuesOnly Control
|
||||
|
||||
The matchedValuesOnly control MAY be critical or non-critical as
|
||||
determined by the user. It is only applicable to the Search
|
||||
operation, and SHALL be ignored by the server if it is present on any
|
||||
other LDAP operation (even if marked critical on such operations).
|
||||
|
||||
The object identifier for this control is 1.2.826.0.1.3344810.2.2
|
||||
|
||||
The controlValue is absent.
|
||||
|
||||
If the server supports this control, the server MUST make use of the
|
||||
control as follows:
|
||||
|
||||
(1) If the typesOnly parameter of the Search Request is TRUE,
|
||||
the control has no effect and the Search Request SHOULD be
|
||||
processed as if the control had not been specified.
|
||||
|
||||
(2) If the attributes parameter of the Search Request consists
|
||||
of a list containing only the attribute with OID "1.1"
|
||||
(specifying that no attributes are to be returned), the control
|
||||
has no effect and the Search Request SHOULD be processed as if
|
||||
the control had not been specified.
|
||||
|
||||
(3) For each attribute listed in the attributes parameter of the
|
||||
Search Request, the server MUST apply the control as follows:
|
||||
|
||||
i) Every attribute value that evaluates TRUE against one or
|
||||
more filters, excluding the ignored filters (see below),
|
||||
is logically marked by the server as contributing to the
|
||||
filter matching.
|
||||
ii) Attributes that have no values marked as contributing,
|
||||
have all their values returned to the user.
|
||||
iii) Attributes that have one or more values marked as
|
||||
contributing have only the contributing values returned to
|
||||
the user, whilst the other values of the same attribute
|
||||
(if there are any) are not returned.
|
||||
|
||||
Certain filters are ignored for the purposes of marking the attribute
|
||||
values as contributing. These are:
|
||||
|
||||
the ôpresentö filter, since this filter does not test against
|
||||
any attribute values;
|
||||
the ônotö filter, since this would have the effect of marking
|
||||
all the attribute values except the one(s) that matched the
|
||||
non-negated filter.
|
||||
|
||||
3. Relationship to X.500
|
||||
|
||||
The matchedValuesOnly control defined in this document is derived
|
||||
from the matchedValuesOnly boolean parameter of the X.511 (93) DAP
|
||||
Search operation [4]. Note however that in X.511 (93), the
|
||||
matchedValuesOnly parameter is ignored when used with an "equality"
|
||||
match FilterItem, and so the user must use the extensibleMatch filter
|
||||
along with the equality matching rule if only matched values are
|
||||
wanted with equality matching. This slightly spurious equality match
|
||||
restriction has been removed from the 2000 version of X.511 [6]. For
|
||||
LDAP servers acting as a gateway to an X.500 directory, the matched
|
||||
valuesOnly control can be directly mapped onto the X.511
|
||||
matchedValuesOnly Search parameter as follows:
|
||||
|
||||
(1) If the matchedValuesOnly control is specified, the
|
||||
matchedValuesOnly DAP parameter MUST be set to true. If the
|
||||
control criticality value is TRUE then bit 17 of the DAP
|
||||
criticalExtensions MUST be set.
|
||||
|
||||
(2) If an equality matching rule is specified in the filter of
|
||||
the LDAPv3 search operation, then if operating with a pre-2000
|
||||
edition DSA, the corresponding equality FilterItem contained in
|
||||
the X.511 filter parameter MUST NOT be used, but rather the
|
||||
extensibleMatch filter item MUST be used instead (the assertion
|
||||
consisting of the equality matching rule, the attribute type to
|
||||
match on, and the asserted value). When operating with DSAs
|
||||
that support the 2000 DAP enhancement, the equality FilterItem
|
||||
MAY be used.
|
||||
|
||||
4. Examples
|
||||
|
||||
(1) The first example simply shows how the control can be used to
|
||||
selectively read a subset of attribute values.
|
||||
|
||||
The entry below represents a groupOfNames object class containing
|
||||
several members from different organizations.
|
||||
|
||||
cn: Cross Organizational Standards Body
|
||||
member: cn=joe, o=acme
|
||||
member: cn=alice, o=acme
|
||||
member: cn=bob, o=foo
|
||||
member: cn=sue, o=bar
|
||||
|
||||
An LDAP search operation is specified with a baseObject set to the
|
||||
DN of the entry, a baseObject scope, a filter set to
|
||||
"member=*o=acme", and the list of attributes to be returned set to
|
||||
"member". In addition, a matchedValuesOnly control is attached to the
|
||||
search request.
|
||||
|
||||
The search results returned by the server would consist of the
|
||||
following entry:
|
||||
|
||||
cn: Cross Organizational Standards Body
|
||||
member: cn=joe, o=acme
|
||||
member: cn=alice, o=acme
|
||||
|
||||
(2) The second example shows how the control has no effect on
|
||||
attributes that do not participate in the search filter.
|
||||
|
||||
The entries below represent inetOrgPerson [7] object classes located
|
||||
below some distinguished name in the directory.
|
||||
|
||||
cn: Sean Mullan
|
||||
mail: sean.mullan@sun.com
|
||||
mail: mullan@east.sun.com
|
||||
telephoneNumber: +1 781 442 0926
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
cn: David Chadwick
|
||||
mail: d.w.chadwick@salford.ac.uk
|
||||
|
||||
An LDAP search operation is specified with a baseObject set to the
|
||||
DN of the entry, a subtree scope, a filter set to
|
||||
"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and
|
||||
the list of attributes to be returned set to "mail telephoneNumber".
|
||||
In addition, a matchedValuesOnly control is attached to the search
|
||||
request.
|
||||
|
||||
The search results returned by the server would consist of the
|
||||
following entries:
|
||||
|
||||
cn: Sean Mullan
|
||||
mail: sean.mullan@sun.com
|
||||
telephoneNumber: +1 781 442 0926
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
cn: David Chadwick
|
||||
mail: d.w.chadwick@salford.ac.uk
|
||||
|
||||
Note that the control has no effect on the values returned for the
|
||||
"telephoneNumber" attribute (all of the values are returned), since
|
||||
it did not participate in the search filter.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This Internet Draft does not discuss security issues at all.
|
||||
|
||||
Note that attribute values MUST only be returned if the access
|
||||
controls applied by the LDAP server allow them to be returned, and in
|
||||
this respect the effect of the matchedValuesOnly control is of no
|
||||
consequence.
|
||||
|
||||
Note that the matchedValuesOnly control may have a positive effect on
|
||||
the deployment of public key infrastructures. Certain PKI operations,
|
||||
like searching for specific certificates, become more practical (when
|
||||
combined with X.509 certificate matching rules at the server) and
|
||||
more scalable, since the control avoids the downloading of
|
||||
potentially large numbers of irrelevant certificates which would have
|
||||
to be processed and filtered locally (which in some cases is very
|
||||
difficult to perform).
|
||||
|
||||
6. Copyright
|
||||
|
||||
Copyright (C) The Internet Society (date). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
7. References
|
||||
|
||||
[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
|
||||
Protocol", RFC 1777, March 1995.
|
||||
[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
||||
Protocol (v3)", Dec. 1997, RFC 2251
|
||||
[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, ôLightweight Directory
|
||||
Access Protocol (v3): Attribute Syntax Definitionsö, RFC 2252, Dec
|
||||
1997
|
||||
[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
|
||||
1993.
|
||||
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", RFC 2119, March 1997.
|
||||
[6] ôFPDAMs to ISO/IEC 9594 Parts 1, 2, 3, 4, 5, 6, 7 and 9 to
|
||||
support the ITU-T Rec. F.510 "Automated Directory Assistance, White
|
||||
Pages Service Definitions"ö, Collaborative ITU-T/SG7/Q15 and
|
||||
JTC1/SC6/WG7 OSI Directory Meeting 7-15 April 1999, Orlando, USA
|
||||
[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class",
|
||||
Internet Draft <draft-smith-ldap-inetorgperson-03.txt>, April 1999.
|
||||
|
||||
8. Authors Addresses
|
||||
|
||||
David Chadwick
|
||||
IS Institute
|
||||
University of Salford
|
||||
Salford M5 4WT
|
||||
England
|
||||
|
||||
Email: d.w.chadwick@salford.ac.uk
|
||||
|
||||
Sean Mullan
|
||||
Sun Microsystems Laboratories
|
||||
One Network Drive
|
||||
Burlington
|
||||
MA 01803-0902
|
||||
USA
|
||||
|
||||
Tel: +1 781 442-0926 Fax: +1 781 442-1692
|
||||
Email: sean.mullan@sun.com
|
||||
|
||||
Internet-Draft Returning Matched Values with LDAPv3 8 September 1999
|
||||
|
||||
5
|
||||
Internet-Draft David Chadwick
|
||||
LDAPExt WG University of Salford
|
||||
Intended Category: Standards Track Sean Mullan
|
||||
Sun Microsystems
|
||||
Expires: 1 January 2001 1 July 2000
|
||||
|
||||
|
||||
Returning Matched Values with LDAPv3
|
||||
<draft-ietf-ldapext-matchedval-02.txt>
|
||||
|
||||
|
||||
STATUS OF THIS MEMO
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with
|
||||
all the provisions of Section 10 of RFC2026.
|
||||
|
||||
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
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft expires on 1 January 2001. 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
|
||||
or directly to the authors.
|
||||
|
||||
|
||||
ABSTRACT
|
||||
|
||||
This document describes a control for the Lightweight Directory
|
||||
Access Protocol v3 that is used to return a subset of attribute
|
||||
values from an entry, specifically, only those values that match a
|
||||
"values return" filter. Without support for this control, a client
|
||||
must retrieve all of an attribute's values and search for specific
|
||||
values locally.
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
When reading an attribute from an entry using LDAP v2 [1] or LDAPv3
|
||||
[2], it is normally only possible to read either the attribute type,
|
||||
or the attribute type and all its values. It is not possible to
|
||||
selectively read just a few of the attribute values. If an attribute
|
||||
holds many values, for example, the userCertificate attribute, or the
|
||||
subschema publishing operational attributes objectClasses and
|
||||
attributeTypes [3], then it may be desirable for the user to be able
|
||||
to selectively retrieve a subset of the values, specifically, those
|
||||
attribute values that match some user defined selection criteria.
|
||||
Without the control specified in this [ID/standard] a client must
|
||||
read all of the attribute's values and filter out the unwanted
|
||||
values, necessitating the client to implement the matching rules. It
|
||||
also requires the client to potentially read and process many
|
||||
irrelevant values, which can be inefficient if the values are large
|
||||
or complex, or there are many values stored per attribute.
|
||||
|
||||
This Internet Draft specifies an LDAPv3 control to enable a user to
|
||||
return only those values that matched (i.e. returned TRUE to) one or
|
||||
more elements of a newly defined "values return" filter. This control
|
||||
can be especially useful when used in conjunction with extensible
|
||||
matching rules that match on one or more components of complex binary
|
||||
attribute values.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [5].
|
||||
|
||||
|
||||
2. The valuesReturnFilter Control
|
||||
|
||||
The valuesReturnFilter control MAY be critical or non-critical as
|
||||
determined by the user. It is only applicable to the Search
|
||||
operation, and SHALL be ignored by the server if it is present on any
|
||||
other LDAP operation (even if marked critical on such operations).
|
||||
|
||||
The object identifier for this control is 1.2.826.0.1.3344810.2.3
|
||||
|
||||
|
||||
The controlValue is
|
||||
|
||||
ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
|
||||
|
||||
SimpleFilterItem ::= CHOICE {
|
||||
equalityMatch [3] AttributeValueAssertion,
|
||||
substrings [4] SubstringFilter,
|
||||
greaterOrEqual [5] AttributeValueAssertion,
|
||||
lessOrEqual [6] AttributeValueAssertion,
|
||||
present [7] AttributeDescription,
|
||||
approxMatch [8] AttributeValueAssertion,
|
||||
extensibleMatch [9] SimpleMatchingAssertion }
|
||||
|
||||
SimpleMatchingAssertion ::= SEQUENCE {
|
||||
matchingRule [1] MatchingRuleId OPTIONAL,
|
||||
type [2] AttributeDescription OPTIONAL,
|
||||
matchValue [3] AssertionValue}
|
||||
|
||||
All the above data types have their standard meanings as defined in
|
||||
[2].
|
||||
|
||||
If the server supports this control, the server MUST make use of the
|
||||
control as follows:
|
||||
|
||||
(1) The Search Filter is first executed in order to determine
|
||||
which entries satisfy the Search criteria. The control has no
|
||||
impact on this step.
|
||||
|
||||
(2) If the typesOnly parameter of the Search Request is TRUE,
|
||||
the control has no effect and the Search Request SHOULD be
|
||||
processed as if the control had not been specified.
|
||||
|
||||
(3) If the attributes parameter of the Search Request consists
|
||||
of a list containing only the attribute with OID "1.1"
|
||||
(specifying that no attributes are to be returned), the control
|
||||
has no effect and the Search Request SHOULD be processed as if
|
||||
the control had not been specified.
|
||||
|
||||
(4) For each attribute listed in the attributes parameter of the
|
||||
Search Request, the server MUST apply the control as follows:
|
||||
|
||||
i) Every attribute value that evaluates TRUE against one or
|
||||
more elements of the ValuesReturnFilter is placed in the
|
||||
SearchResultEntry.
|
||||
ii) Every attribute value that evaluates FALSE or undefined
|
||||
against all elements of the ValuesReturnFilter is not
|
||||
placed in the SearchResultEntry. An attribute that has no
|
||||
values selected is returned with an empty set of vals.
|
||||
|
||||
Editor's Note. There is possibly a more efficient but slightly more
|
||||
complex way of achieving the value filtering. An alternative is to
|
||||
remove the 'present' SimpleFilterItem (which obviously evaluates true
|
||||
for every attribute value of the 'present' attribute description),
|
||||
and to say that any attribute whose type is not mentioned in the
|
||||
ValuesReturnFilter is not filtered and has all its attribute values
|
||||
returned. Comments please.
|
||||
|
||||
|
||||
3. Relationship to X.500
|
||||
|
||||
The control is a superset of the matchedValuesOnly boolean of the
|
||||
X.500 DAP [4] Search argument, as amended in the latest version [6].
|
||||
Close examination of the matchedValuesOnly boolean by the LDAPExt
|
||||
group revealed ambiguities and complexities in the MVO boolean that
|
||||
could not easily be resolved. For example, are only those attribute
|
||||
values that contributed to the overall truth of the filter governed
|
||||
by the MVO boolean, or all values of attributes in the filter
|
||||
governed by the MVO boolean, even if the filter item containing the
|
||||
attribute evaluated to false. For this reason the LDAP group decided
|
||||
to replace the MVO boolean with a simple filter that removes any
|
||||
uncertainty as to whether an attribute value has been selected or
|
||||
not.
|
||||
|
||||
|
||||
4. Examples
|
||||
|
||||
(1) The first example simply shows how the control can be used to
|
||||
selectively read a subset of attribute values.
|
||||
|
||||
The entry below represents a groupOfNames object class containing
|
||||
several members from different organizations.
|
||||
|
||||
cn: Cross Organizational Standards Body
|
||||
member: cn=joe,o=acme
|
||||
member: cn=alice,o=acme
|
||||
member: cn=bob,o=foo
|
||||
member: cn=sue,o=bar
|
||||
|
||||
An LDAP search operation is specified with a baseObject set to the
|
||||
DN of the entry, a baseObject scope, a filter set to
|
||||
"member=*o=acme", and the list of attributes to be returned set to
|
||||
"member". In addition, a ValuesReturnFilter control is set to
|
||||
"member=*o=acme".
|
||||
|
||||
The search results returned by the server would consist of the
|
||||
following entry:
|
||||
|
||||
cn: Cross Organizational Standards Body
|
||||
member: cn=joe, o=acme
|
||||
member: cn=alice, o=acme
|
||||
|
||||
|
||||
(2) The second example shows how the control can be set to match on
|
||||
attributes that are (mail) and are not (telephoneNumber) part of the
|
||||
search filter. It also shows how a user can filter some attribute
|
||||
values (mail) and not others (telephoneNumber).
|
||||
|
||||
The entries below represent inetOrgPerson [7] object classes located
|
||||
below some distinguished name in the directory.
|
||||
|
||||
cn: Sean Mullan
|
||||
mail: sean.mullan@sun.com
|
||||
mail: mullan@east.sun.com
|
||||
telephoneNumber: +1 781 442 0926
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
cn: David Chadwick
|
||||
mail: d.w.chadwick@salford.ac.uk
|
||||
|
||||
An LDAP search operation is specified with a baseObject set to the
|
||||
DN of the entry, a subtree scope, a filter set to
|
||||
"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and
|
||||
the list of attributes to be returned set to "mail telephoneNumber".
|
||||
In addition, a ValuesReturnFilter control is set to
|
||||
"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk,
|
||||
telephoneNumber=*"
|
||||
|
||||
The search results returned by the server would consist of the
|
||||
following entries:
|
||||
|
||||
cn: Sean Mullan
|
||||
mail: sean.mullan@sun.com
|
||||
telephoneNumber: +1 781 442 0926
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
cn: David Chadwick
|
||||
mail: d.w.chadwick@salford.ac.uk
|
||||
|
||||
Note that the control has no effect on the values returned for the
|
||||
"telephoneNumber" attribute (all of the values are returned), since
|
||||
the control specified that all values should be returned.
|
||||
|
||||
(3) The third example shows how one might retrieve a single attribute
|
||||
type schema definition for the "gunk" attribute with OID 1.2.3.4.5
|
||||
|
||||
Assume the subschema subentry is held somewhere below the root entry
|
||||
with RDN "subschema subentry", and this holds an attributeTypes
|
||||
operational attribute holding the descriptions of the 35 attributes
|
||||
known to this server (each description is held as a single attribute
|
||||
value of the attributeTypes attribute).
|
||||
|
||||
cn: subschema subentry
|
||||
objectClass: subschema
|
||||
attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name )
|
||||
attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
|
||||
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY
|
||||
objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
|
||||
attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY
|
||||
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-
|
||||
MODIFICATION USAGE directoryOperation )
|
||||
attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY
|
||||
objectIdentifierFirstComponentMatch SYNTAX
|
||||
1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
|
||||
attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
|
||||
SUBSTR caseIgnoreSubstringsMatch SYNTAX
|
||||
1.3.6.1.4.1.1466.115.121.1.44{64} )
|
||||
attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY
|
||||
objectIdentifierFirstComponentMatch SYNTAX
|
||||
1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
|
||||
|
||||
plus another 28 - you get the idea.
|
||||
|
||||
|
||||
The user creates an LDAP search operation with a baseObject set to
|
||||
root, a subtree scope, a filter set to "objectClass=subschema", the
|
||||
list of attributes to be returned set to "attributeTypes", and the
|
||||
ValuesReturnFilter set to "attributeTypes=1.2.3.4.5"
|
||||
|
||||
The search result returned by the server would consist of the
|
||||
following entry:
|
||||
|
||||
cn: subschema subentry
|
||||
attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch
|
||||
SUBSTR caseIgnoreSubstringsMatch SYNTAX
|
||||
1.3.6.1.4.1.1466.115.121.1.44{64} )
|
||||
|
||||
(4) The final example shows how the control can be set to match on
|
||||
attributes that are not part of the search filter. For example,
|
||||
searching for all entries that have an email address in the
|
||||
sun.com domain, and returning the telephone number for any attribute
|
||||
values that start with "555".
|
||||
|
||||
The entries below represent inetOrgPerson [7] object classes located
|
||||
below some distinguished name in the directory.
|
||||
|
||||
cn: Sean Mullan
|
||||
mail: sean.mullan@sun.com
|
||||
mail: mullan@east.sun.com
|
||||
telephoneNumber: +1 781 442 0926
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
cn: David Chadwick
|
||||
mail: d.w.chadwick@salford.ac.uk
|
||||
|
||||
An LDAP search operation is specified with a baseObject set to the
|
||||
DN of the entry, a subtree scope, a filter set to "mail=*sun.com",
|
||||
and the list of attributes to be returned set to "telephoneNumber".
|
||||
In addition, a ValuesReturnFilter control is set to
|
||||
"telephoneNumber=555*"
|
||||
|
||||
The search results returned by the server would consist of the
|
||||
following entry:
|
||||
|
||||
cn: Sean Mullan
|
||||
telephoneNumber: 555-9999
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This Internet Draft does not discuss security issues at all.
|
||||
|
||||
Note that attribute values MUST only be returned if the access
|
||||
controls applied by the LDAP server allow them to be returned, and in
|
||||
this respect the effect of the ValuesReturnFilter control is of no
|
||||
consequence.
|
||||
|
||||
Note that the ValuesReturnFilter control may have a positive effect
|
||||
on the deployment of public key infrastructures. Certain PKI
|
||||
operations, like searching for specific certificates, become more
|
||||
practical (when combined with X.509 certificate matching rules at the
|
||||
server) and more scalable, since the control avoids the downloading
|
||||
of potentially large numbers of irrelevant certificates which would
|
||||
have to be processed and filtered locally (which in some cases is
|
||||
very difficult to perform).
|
||||
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
The authors would like to thank members of the LDAPExt list for their
|
||||
constructive comments on earlier versions of this draft, and in
|
||||
particular to Harald Alvestrand who first suggested having an
|
||||
attribute return filter and Bruce Greenblatt who first proposed a
|
||||
syntax for this control.
|
||||
|
||||
7. Copyright
|
||||
|
||||
Copyright (C) The Internet Society (date). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
|
||||
Protocol", RFC 1777, March 1995.
|
||||
[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
||||
Protocol (v3)", Dec. 1997, RFC 2251
|
||||
[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
|
||||
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec
|
||||
1997
|
||||
[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
|
||||
1993.
|
||||
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", RFC 2119, March 1997.
|
||||
[6] ISO/IEC 9594 / ITU-T Rec X.511 (2000) The Directory: Abstract
|
||||
Service Definition.
|
||||
[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class",
|
||||
Internet Draft <draft-smith-ldap-inetorgperson-03.txt>, April 1999.
|
||||
|
||||
|
||||
9. Authors Addresses
|
||||
|
||||
David Chadwick
|
||||
IS Institute
|
||||
University of Salford
|
||||
Salford M5 4WT
|
||||
England
|
||||
|
||||
Email: d.w.chadwick@salford.ac.uk
|
||||
|
||||
|
||||
Sean Mullan
|
||||
Sun Microsystems
|
||||
East Point Business Park
|
||||
Dublin 3
|
||||
Ireland
|
||||
Tel: +353 1 853 0655
|
||||
Email: sean.mullan@sun.com
|
||||
|
||||
Internet-Draft Returning Matched Values with LDAPv3 1 July 2000
|
||||
|
||||
|
||||
1
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user