[netbsd-mini2440.git] / external / bsd / openldap / dist / doc / drafts / draft-joslin-config-schema-xx.txt
| blob | 6fc65ec8df0e2d793e62625c8ccd05983b32fa56 |
2 INTERNET-DRAFT M. Ansari
3 draft-joslin-config-schema-10.txt Infoblox
4 Category: Informational L. Howard
5 Expires: September 2005 PADL Software Pty. Ltd.
6 B. Neal-Joslin, Editor
7 Hewlett-Packard Company
8 4 March, 2005
11 A Configuration Schema for LDAP Based
12 Directory User Agents
15 Status of this Memo
17 Copyright (C) The Internet Society (2005). This document is subject
18 to the rights, licenses and restrictions contained in BCP 78, and
19 except as set forth therein, the authors retain all their rights.
21 This document and the information contained herein are provided on
22 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
23 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
24 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
25 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
26 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
27 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
28 PARTICULAR PURPOSE.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF), its areas, and its working groups. Note that
32 other groups may also distribute working documents as Internet-
33 Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six
36 months and may be updated, replaced, or obsoleted by other
37 documents at any time. It is inappropriate to use Internet-Drafts
38 as reference material or to cite them other than as "work in
39 progress."
41 The list of current Internet-Drafts can be accessed at
42 http://www.ietf.org/1id-abstracts.html
44 The list of Internet-Draft Shadow Directories can be accessed at
45 http://www.ietf.org/shadow.html
47 IPR Statement
49 By submitting this Internet-Draft, I certify that any applicable
53 Neal-Joslin [Page 1]
54 \f
55 Internet-Draft DUA Configuration Schema March 2005
58 patent or other IPR claims of which I am aware have been disclosed,
59 or will be disclosed, and any of which I become aware will be
60 disclosed, in accordance with RFC 3668.
62 The IETF takes no position regarding the validity or scope of any
63 Intellectual Property Rights or other rights that might be claimed
64 to pertain to the implementation or use of the technology described
65 in this document or the extent to which any license under such
66 rights might or might not be available; nor does it represent that
67 it has made any independent effort to identify any such rights.
68 Information on the procedures with respect to rights in RFC
69 documents can be found in BCP 78 and BCP 79.
71 The IETF invites any interested party to bring to its attention any
72 copyrights, patents or patent applications, or other proprietary
73 rights that may cover technology that may be required to implement
74 this standard. Please address the information to the IETF at
75 ietf-ipr@ietf.org.
77 Copies of IPR disclosures made to the IETF Secretariat and any
78 assurances of licenses to be made available, or the result of an
79 attempt made to obtain a general license or permission for the use
80 of such proprietary rights by implementers or users of this
81 specification can be obtained from the IETF on-line IPR repository
82 at http://www.ietf.org/ipr.
88 Abstract
90 This document describes a mechanism for distributed configuration
91 of similar directory user agents. This document defines a schema
92 for configuration of these DUAs that may be discovered using the
93 Lightweight Directory Access Protocol in RFC 2251[1]. A set of
94 attribute types and an objectclass are proposed, along with
95 specific guidelines for interpreting them. A proposal of using
96 attribute and objectclass mapping allows DUAs to re-configure their
97 schema to that of the end user's environment. This document is
98 intended to be a skeleton for future documents that describe
99 configuration of specific DUA services.
109 Neal-Joslin [Page 2]
110 \f
111 Internet-Draft DUA Configuration Schema March 2005
114 Table of Contents
116 1. Background & Motivation ...................................... 4
117 2. General Issues ............................................... 5
118 2.1 Terminology .................................................. 5
119 2.2 Attributes ................................................... 5
120 2.3 Object Classes ............................................... 6
121 2.4 Syntax Definitions ........................................... 6
122 3. Attribute Definitions ........................................ 6
123 4. Class Definition ............................................. 8
124 5. Implementation Details ....................................... 9
125 5.1.1 Interpreting the preferredServerList attribute ............. 9
126 5.1.2 Interpreting the defaultServerList attribute ............... 10
127 5.1.3 Interpreting the defaultSearchBase attribute ............... 11
128 5.1.4 Interpreting the authenticationMethod attribute ............ 12
129 5.1.5 Interpreting the credentialLevel attribute ................. 13
130 5.1.6 Interpreting the serviceSearchDescriptor attribute ......... 14
131 5.1.7 Interpreting the attributeMap attribute .................... 17
132 5.1.8 Interpreting the searchTimeLimit attribute ................. 20
133 5.1.9 Interpreting the bindTimeLimit attribute ................... 20
134 5.1.10 Interpreting the followReferrals attribute ................ 21
135 5.1.11 Interpreting the dereferenceAliases attribute ............. 21
136 5.1.12 Interpreting the profileTTL attribute ..................... 21
137 5.1.13 Interpreting the objectclassMap attribute ................. 22
138 5.1.14 Interpreting the defaultSearchScope attribute ............. 24
139 5.1.15 Interpreting the serviceAuthenticationMethod attribute .... 24
140 5.1.16 Interpreting the serviceCredentialLevel attribute ......... 25
141 5.2 Binding to the Directory Server .............................. 26
142 6. Security Considerations ...................................... 26
143 7. Acknowledgments .............................................. 27
144 8. References ................................................... 27
145 8.1 Normative References ......................................... 27
146 8.2 Informative References ....................................... 28
147 9. Examples ..................................................... 29
165 Neal-Joslin [Page 3]
166 \f
167 Internet-Draft DUA Configuration Schema March 2005
170 1. Background & Motivation
172 The LDAP protocol has brought about a new and nearly ubiquitous
173 acceptance of the directory server. Many new client applications
174 (DUAs) are being created that use LDAP directories for many
175 different services. And although the LDAP protocol has eased the
176 development of these applications, some challenges still exist for
177 both developers and directory administrators.
179 The authors of this document are implementers of DUAs described by
180 RFC 2307 [2]. In developing these agents, we felt there are
181 several issues that still need to be addressed to ease the
182 deployment and configuration of a large network of these DUAs.
184 One of these challenges stems from the lack of a utopian schema. A
185 utopian schema would be one that every application developer could
186 agree upon and that would support every application. Unfortunately
187 today, many DUAs define their own schema (like RFC 2307 vs.
188 Microsoft's Services for Unix [3]) containing similar attributes,
189 but with different attribute names. This can lead to data
190 redundancy within directory entries and give directory
191 administrators unwanted challenges, updating schemas and
192 synchronizing data.
194 So, one goal of this document is to eliminate data redundancy by
195 having DUAs configure themselves to the schema of the deployed
196 directory, instead of forcing its own schema on the directory.
198 Another goal of this document is to provide the DUA with enough
199 configuration information so that it can discover how to retrieve
200 its data in the directory, such as what locations to search in the
201 directory tree.
203 Finally, this document intends to describe a configuration method
204 for DUAs that can be shared among many DUAs, on various platforms,
205 providing as such, a configuration profile, the purpose is to
206 centralize and simplify management of DUAs.
208 This document is intended to provide the skeleton framework for
209 future drafts, which will describe the individual implementation
210 details for the particular services provided by that DUA. The
211 authors of this document plan to develop such a document for the
212 Network Information Service DUA, described by RFC 2307 or its
213 successor.
215 We expect that as DUAs take advantage of this configuration scheme,
216 each DUA will require additional configuration parameters, not
217 specified by this document. Thus, we would expect that new
221 Neal-Joslin [Page 4]
222 \f
223 Internet-Draft DUA Configuration Schema March 2005
226 auxiliary object classes, containing new configuration attributes
227 will be created, and then joined with the structural class defined
228 by this document to create a configuration profile for a particular
229 DUA service. And that by joining various auxiliary objectclasses
230 for different DUA services, that configuration of various DUA
231 services can be controlled by a single configuration profile entry.
234 2. General Issues
236 The schema defined by this document is defined under the "DUA
237 Configuration Schema." This schema is derived from the OID: iso
238 (1) org (3) dod (6) internet (1) private (4) enterprises (1)
239 Hewlett-Packard Company (11) directory (1) LDAP-UX Integration
240 Project (3) DUA Configuration Schema (1). This OID is represented
241 in this document by the keystring "DUAConfSchemaOID"
242 (1.3.6.1.4.1.11.1.3.1).
244 2.1 Terminology
246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
248 this document are to be interpreted as described in BCP 14 (RFC
249 2119) [4].
251 2.2 Attributes
253 The attributes and classes defined in this document are summarized
254 below.
256 The following attributes are defined in this document:
258 preferredServerList
259 defaultServerList
260 defaultSearchBase
261 defaultSearchScope
262 authenticationMethod
263 credentialLevel
264 serviceSearchDescriptor
265 serviceCredentialLevel
266 serviceAuthenticationMethod
267 attributeMap
268 objectclassMap
269 searchTimeLimit
270 bindTimeLimit
271 followReferrals
272 dereferenceAliases
273 profileTTL
277 Neal-Joslin [Page 5]
278 \f
279 Internet-Draft DUA Configuration Schema March 2005
282 2.3 Object Classes
284 The following object class is defined in this document:
286 DUAConfigProfile
288 2.4 Syntax Definitions
290 The following syntax definitions are used throughout this document.
291 This document does not define new syntaxes that must be supported
292 by the directory server. The string encoding used by the
293 attributes defined in this document can be found section 5.
295 keystring as defined by RFC 2252 [5]
296 descr as defined by RFC 2252 section 4.1
297 a as defined by RFC 2252 section 4.1
298 d as defined by RFC 2252 section 4.1
299 space as defined by RFC 2252 section 4.1
300 whsp as defined by RFC 2252 section 4.1
301 base as defined by RFC 2253 [6]
302 DistinguishedName as defined by RFC 2253 section 2
303 RelativeDistinguishedName as defined by RFC 2253 section 2
304 scope as defined by RFC 2255 [7]
305 host as defined by RFC 3986
306 section 3.2.2 [8]
307 hostport host [":" port ]
308 port as defined by RFC 3986
309 section 3.2.3 [8]
310 serviceID = keystring
313 3. Attribute Definitions
315 This section contains attribute definitions to be used by DUAs when
316 discovering their configuration.
318 ( DUAConfSchemaOID.1.0 NAME 'defaultServerList'
319 DESC 'Default LDAP server host addresses used by a DUA'
320 EQUALITY caseIgnoreMatch
321 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
322 SINGLE-VALUE )
324 ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase'
325 DESC 'Default LDAP base DN used by a DUA'
326 EQUALITY distinguishedNameMatch
327 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
328 SINGLE-VALUE )
333 Neal-Joslin [Page 6]
334 \f
335 Internet-Draft DUA Configuration Schema March 2005
338 ( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
339 DESC 'Preferred LDAP server host addresses to be used by a
340 DUA'
341 EQUALITY caseIgnoreMatch
342 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
343 SINGLE-VALUE )
345 ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit'
346 DESC 'Maximum time in seconds a DUA should allow for a
347 search to complete'
348 EQUALITY integerMatch
349 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
350 SINGLE-VALUE )
352 ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit'
353 DESC 'Maximum time in seconds a DUA should allow for the
354 bind operation to complete'
355 EQUALITY integerMatch
356 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
357 SINGLE-VALUE )
359 ( DUAConfSchemaOID.1.5 NAME 'followReferrals'
360 DESC 'Tells DUA if it should follow referrals
361 returned by a DSA result'
362 EQUALITY booleanMatch
363 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
364 SINGLE-VALUE )
366 ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
367 DESC 'A keystring which identifies the type of
368 authentication methods used to contact the DSA'
369 EQUALITY caseIgnoreMatch
370 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
371 SINGLE-VALUE )
373 ( DUAConfSchemaOID.1.7 NAME 'profileTTL'
374 DESC 'Time to live, in seconds, before a client DUA
375 should re-read this configuration profile'
376 EQUALITY integerMatch
377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
378 SINGLE-VALUE )
380 ( DUAConfSchemaOID.1.9 NAME 'attributeMap'
381 DESC 'Attribute mappings used by a DUA'
382 EQUALITY caseIgnoreIA5Match
383 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
385 ( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
389 Neal-Joslin [Page 7]
390 \f
391 Internet-Draft DUA Configuration Schema March 2005
394 DESC 'Identifies type of credentials a DUA should
395 use when binding to the LDAP server'
396 EQUALITY caseIgnoreIA5Match
397 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
398 SINGLE-VALUE )
400 ( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
401 DESC 'Objectclass mappings used by a DUA'
402 EQUALITY caseIgnoreIA5Match
403 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
405 ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope'
406 DESC 'Default search scope used by a DUA'
407 EQUALITY caseIgnoreIA5Match
408 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
409 SINGLE-VALUE )
411 ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
412 DESC 'Identifies type of credentials a DUA
413 should use when binding to the LDAP server for a
414 specific service'
415 EQUALITY caseIgnoreIA5Match
416 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
418 ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
419 DESC 'LDAP search descriptor list used by a DUA'
420 EQUALITY caseExactMatch
421 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
423 ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
424 DESC 'Identifies type of authentication method a DUA
425 should use when binding to the LDAP server for a
426 specific service'
427 EQUALITY caseIgnoreMatch
428 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
430 ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
431 DESC 'Tells DUA if it should dereference aliases'
432 EQUALITY booleanMatch
433 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
434 SINGLE-VALUE )
437 4. Class Definition
439 The objectclass below is constructed from the attributes defined in
440 3, with the exception of the cn attribute, which is defined in RFC
441 2256 [9]. cn is used to represent the name of the DUA
445 Neal-Joslin [Page 8]
446 \f
447 Internet-Draft DUA Configuration Schema March 2005
450 configuration profile.
452 ( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile'
453 SUP top STRUCTURAL
454 DESC 'Abstraction of a base configuration for a DUA'
455 MUST ( cn )
456 MAY ( defaultServerList $ preferredServerList $
457 defaultSearchBase $ defaultSearchScope $
458 searchTimeLimit $ bindTimeLimit $
459 credentialLevel $ authenticationMethod $
460 followReferrals $ dereferenceAliases $
461 serviceSearchDescriptor $ serviceCredentialLevel $
462 serviceAuthenticationMethod $ objectclassMap $
463 attributeMap $ profileTTL ) )
466 5. Implementation Details
468 5.1.1 Interpreting the preferredServerList attribute
470 Interpretation:
472 As described by the syntax, the preferredServerList parameter
473 is a white-space separated list of server addresses and
474 associated port numbers. When the DUA needs to contact a DSA,
475 the DUA MUST first attempt to contact one of the servers
476 listed in the preferredServerList attribute. The DUA MUST
477 contact the DSA specified by the first server address in the
478 list. If that DSA is unavailable, the remaining DSAs MUST be
479 queried in the order provided (left to right) until a
480 connection is established with a DSA. Once a connection with
481 a DSA is established, the DUA SHOULD NOT attempt to establish
482 a connection with the remaining DSAs. The purpose of
483 enumerating multiple DSAs is not for supplemental data, but
484 for high availability of replicated data. This is also the
485 main reason why an LDAP URL[10] syntax was not selected for
486 this document.
488 If the DUA is unable to contact any of the DSAs specified by
489 the preferredServerList, the defaultServerList attribute MUST
490 be examined, as described in 5.1.2. The servers identified by
491 the preferredServerList MUST be contacted before attempting to
492 contact any of the servers specified by the defaultServerList.
494 Syntax:
496 serverList = hostport *(space [hostport])
501 Neal-Joslin [Page 9]
502 \f
503 Internet-Draft DUA Configuration Schema March 2005
506 Default Value:
508 The preferredServerList attribute does not have a default
509 value. Instead a DUA MUST examine the defaultServerList
510 attribute.
512 Other attribute notes:
514 This attribute is used in conjunction with the
515 defaultServerList attribute. Please see section 5.1.2 for
516 additional implementation notes. Determining how the DUA
517 should query the DSAs also depends on the additional
518 configuration attributes, credentialLevel,
519 serviceCredentialLevel, bindTimeLimit,
520 serviceAuthenticationMethod and authenticationMethod. Please
521 review section 5.2 for details on how a DUA should properly
522 bind to a DSA.
524 Example:
526 preferredServerList: 192.168.169.170 ldap1.mycorp.com
527 ldap2:1389 [1080::8:800:200C:417A]:389
529 5.1.2 Interpreting the defaultServerList attribute
531 Interpretation:
533 The defaultServerList attribute MUST only be examined if the
534 preferredServerList attribute is not provided, or the DUA is
535 unable to establish a connection with one of the DSAs
536 specified by the preferredServerList.
538 If more than one address is provided, the DUA may choose to
539 either accept the order provided, or choose to create its own
540 order, based on what the DUA determines is the "best" order of
541 servers to query. For example, the DUA may choose to examine
542 the server list and choose to query the DSAs in order based on
543 the "closest" server or the server with the least amount of
544 "load." Interpretation of the "best" server order is entirely
545 up to the DUA, and not part of this document.
547 Once the order of server addresses is determined, the DUA
548 contacts the DSA specified by the first server address in the
549 list. If that DSA is unavailable, the remaining DSAs SHOULD
550 be queried until an available DSA is found or no more DSAs are
551 available. If a server address or port is invalid, the DUA
552 SHOULD proceed to the next server address as described just
553 above.
557 Neal-Joslin [Page 10]
558 \f
559 Internet-Draft DUA Configuration Schema March 2005
562 Syntax:
564 serverList = hostport *(space [hostport])
566 Default Value:
568 If a defaultServerList attribute is not provided, the DUA MAY
569 attempt to contact the same DSA that provided the
570 configuration profile entry itself. The default DSA is
571 contacted only if the preferredServerList attribute is also
572 not provided.
574 Other attribute notes:
576 This attribute is used in conjunction with the
577 preferredServerList attribute. Please see section 5.1.1 for
578 additional implementation notes. Determining how the DUA
579 should query the DSAs also depends on the additional
580 configuration attributes, credentialLevel,
581 serviceCredentialLevel, bindTimeLimit,
582 serviceAuthenticationMethod and authenticationMethod. Please
583 review section 5.2 for details on how a DUA should properly
584 contact a DSA.
586 Example:
588 defaultServerList: 192.168.169.170 ldap1.mycorp.com
589 ldap2:1389 [1080::8:800:200C:417A]:5912
591 5.1.3 Interpreting the defaultSearchBase attribute
593 Interpretation:
595 When a DUA needs to search the DSA for information, this
596 attribute provides the base for the search. This parameter
597 can be overridden or appended by the serviceSearchDescriptor
598 attribute. See section 5.1.6.
600 Syntax:
602 Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [5]
604 Default Value:
606 There is no default value for the defaultSearchBase. A DUA
607 MAY define its own method for determining the search base, if
608 the defaultSearchBase is not provided.
613 Neal-Joslin [Page 11]
614 \f
615 Internet-Draft DUA Configuration Schema March 2005
618 Other attribute notes:
620 This attribute is used in conjunction with the
621 serviceSearchDescriptor attribute. See section 5.1.6.
623 Example:
625 defaultSearchBase: dc=mycompany,dc=com
627 5.1.4 Interpreting the authenticationMethod attribute
629 Interpretation:
631 The authenticationMethod attribute defines an ordered list of
632 LDAP bind methods to be used when attempting to contact a
633 DSA[11]. The serviceAuthenticationMethod overrides this
634 value for a particular service (see 5.1.15.) Each method MUST
635 be attempted in the order provided by the attribute, until a
636 successful LDAP bind is performed ("none" is assumed to always
637 be successful.) However the DUA MAY skip over one or more
638 methods. See section 5.2 for more information.
640 none - The DUA does not perform an LDAP bind.
641 simple - The DUA performs an LDAP simple bind.
642 sasl - The DUA performs an LDAP SASL[12] bind using the
643 specified SASL mechanism and options.
644 tls - The DUA performs an LDAP StartTLS operation
645 followed by the specified bind method (for more
646 information refer to section 5.1 of RFC 2830 [13]).
648 Syntax:
650 authMethod = method *(";" method)
651 method = none | simple | sasl | tls
652 none = "none"
653 simple = "simple"
654 sasl = "sasl/" saslmech [ ":" sasloption ]
655 sasloption = "auth-conf" | "auth-int"
656 tls = "tls:" (none | simple | sasl)
657 saslmech = SASL mechanism name as defined in [18]
659 Note: Although multiple authentication methods may be
660 specified in the syntax, at most one of each type is allowed.
661 I.E. "simple;simple" is invalid.
663 Default Value:
665 If the authenticationMethod or serviceAuthenticationMethod
669 Neal-Joslin [Page 12]
670 \f
671 Internet-Draft DUA Configuration Schema March 2005
674 (for that particular service) attributes are not provided, the
675 DUA MAY choose to bind to the DSA using any method defined by
676 the DUA. However, if either authenticationMethod or
677 serviceAuthenticationMethod are provided, the DUA MUST only
678 use the methods specified.
680 Other attribute notes:
682 When using TLS, the string "tls:sasl/EXTERNAL" implies that
683 two way (DSA and DUA) authentication is to be performed. Any
684 other TLS authentication method implies one way (DSA side
685 credential) authentication.
687 Determining how the DUA should bind to the DSAs also depends
688 on the additional configuration attributes, credentialLevel,
689 serviceCredentialLevel, serviceAuthenticationMethod and
690 bindTimeLimit. Please review section 5.2 for details on how
691 to properly bind to a DSA.
693 Example:
695 authenticationMethod: tls:simple;sasl/DIGEST-MD5
696 (see [14])
698 5.1.5 Interpreting the credentialLevel attribute
700 Interpretation:
702 The credentialLevel attribute defines what type(s) of
703 credential(s) the DUA MUST use when contacting the DSA. The
704 serviceCredentialLevel overrides this value for a particular
705 service (5.1.16.) The credentialLevel can contain more than
706 one credential type, separated by white space.
708 anonymous - The DUA SHOULD NOT use a credential when binding
709 to the DSA.
711 proxy - The DUA SHOULD use a known proxy identity when binding
712 to the DSA. A proxy identity is a specific credential that
713 was created to represent the DUA. This document does not
714 define how the proxy user should be created, or how the DUA
715 should determine what the proxy user's credential is. This
716 functionality is up to each implementation.
718 self - When the DUA is acting on behalf of a known identity,
719 the DUA MUST attempt to bind to the DSA as that identity. The
720 DUA should contain methods to determine the identity of the
721 user such that that identity can be authenticated by the
725 Neal-Joslin [Page 13]
726 \f
727 Internet-Draft DUA Configuration Schema March 2005
730 directory server using the defined authentication methods.
732 If the credentialLevel contains more than one credential type,
733 the DUA MUST use the credential types in the order specified.
734 However, the DUA MAY skip over one or more credential types.
735 As soon as the DUA is able to successfully bind to the DSA,
736 the DUA SHOULD NOT attempt to bind using the remaining
737 credential types.
739 Syntax:
741 credentialLevel = level *(space level)
742 level = self | proxy | anonymous
743 self = "self"
744 proxy = "proxy"
745 anonymous = "anonymous"
747 Note: Although multiple credential levels may be specified in
748 the syntax, at most one of each type is allowed. Refer to
749 implementation notes in section 5.2 for additional syntax
750 requirements for the credentialLevel attribute.
752 Default Value:
754 If the credentialLevel attribute is not defined, the DUA
755 SHOULD NOT use a credential when binding to the DSA (also
756 known as anonymous.)
758 Other attribute notes:
760 Determining how the DUA should bind to the DSAs also depends
761 on the additional configuration attributes,
762 authenticationMethod, serviceAuthenticationMethod,
763 serviceCredentialLevel and bindTimeLimit. Please review
764 section 5.2 for details on how to properly bind to a DSA.
766 Example:
768 credentialLevel: proxy anonymous
770 5.1.6 Interpreting the serviceSearchDescriptor attribute
772 Interpretation:
774 The serviceSearchDescriptor attribute defines how and where a
775 DUA SHOULD search for information for a particular service.
776 The serviceSearchDescriptor contains a serviceID, followed by
777 one or more base-scope-filter triples. These base-scope-
781 Neal-Joslin [Page 14]
782 \f
783 Internet-Draft DUA Configuration Schema March 2005
786 filter triples are used to define searches only for the
787 specific service. Multiple base-scope-filters allow the DUA
788 to search for data in multiple locations of the DIT. Although
789 this syntax is very similar to the LDAP URL[8], this draft
790 requires the ability to supply multiple hosts as part of the
791 configuration of the DSA. In addition, an ordered list of
792 search descriptors is required, which can not be specified by
793 the LDAP URL.
795 In addition to the triples, serviceSearchDescriptor might also
796 contain the DN of an entry that will contain an alternate
797 profile. The DSA SHOULD re-evaluate the alternate profile and
798 perform searches as specified by that profile.
800 If the base, as defined in the serviceSearchDescriptor, is
801 followed by the "," (ASCII 0x2C) character, this base is known
802 as a relative base. This relative base may be constructed of
803 one or more RDN components. The DUA MUST define the search
804 base by appending the relative base with the
805 defaultSearchBase.
807 Syntax:
809 serviceSearchList = serviceID ":" serviceSearchDesc
810 *(";" serviceSearchDesc)
811 serviceSearchDesc = confReferral | searchDescriptor
812 searchDescriptor = [base] ["?" [scope] ["?" [filter]]]
813 confReferral = "ref:" DistinguishedName
814 base = DistinguishedName |
815 RelativeBaseName
816 RelativeBaseName = 1*(RelativeDistinguishedName ",")
817 filter = UTF-8 encoded string
819 If the base or filter contains the ";" (ASCII 0x3B) "?" (ASCII
820 0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those
821 characters MUST be escaped (preceded with the "\" character.)
822 Alternately the DN may be surrounded by quotes (ASCII 0x22.)
823 Refer to RFC 2253, section 4. If the base or filter are
824 surrounded by quotes, only the """ character needs to be
825 escaped. Any character that is preceded by the "\" character,
826 which does not need to be escaped results in both "\"
827 character and the character itself.
829 The usage and syntax of the filter string MUST be defined by
830 the DUA service. A suggested syntax would be that as defined
831 by RFC 2254.
833 If a DUA is performing a search for a particular service,
837 Neal-Joslin [Page 15]
838 \f
839 Internet-Draft DUA Configuration Schema March 2005
842 which has a serviceSearchDescriptor defined, the DUA MUST set
843 the base, scope and filter as defined. Each base-scope-filter
844 triple represents a single LDAP search operation. If multiple
845 base-scope-filter triples are provided in the
846 serviceSearchDescriptor, the DUA SHOULD perform multiple
847 search requests and in that case it MUST be in the order
848 specified by the serviceSearchDescriptor.
850 FYI: Service search descriptors do not exactly follow the LDAP
851 URL syntax [7]. The reasoning for this difference is to
852 separate the host name(s) from the filter. This allows the
853 DUA to have a more flexible solution in choosing its DSA.
855 Default Values:
857 If a serviceSearchDescriptor, or an element their-of, is not
858 defined for a particular service, the DUA SHOULD create the
859 base, scope and filter as follows:
861 base - Same as the defaultSearchBase or as
862 defined by the DUA service.
863 scope - Same as the defaultSearchScope or as
864 defined by the DUA service.
865 filter - Use defaults as defined by DUAs service.
867 If the defaultSearchBase or defaultSearchScope are not
868 defined, then the DUA service may use its own default.
871 Other attribute notes:
873 If a serviceSearchDescriptor exists for a given service, the
874 service MUST use at least one base-scope-filter triple in
875 performing searches. It SHOULD perform multiple searches per
876 service if multiple base-scope-filter triples are defined for
877 that service.
879 The details of how the "filter" is interpreted by each DUA's
880 service is defined by that service. This means the filter is
881 NOT REQUIRED to be a legal LDAP filter [15]. Furthermore,
882 determining how attribute and objectclass mapping affects that
883 search filter MUST be defined by the service. I.E. The DUA
884 SHOULD specify if the attributes in the filter have assumed to
885 already have been mapped, or if it is expected that attribute
886 mapping (see 5.1.7) would be applied to the filter. In
887 general practice, implementation and usability suggests that
888 attribute and objectclass mapping (sections 5.1.7 and 5.1.13)
889 SHOULD NOT be applied to the filter defined in the
893 Neal-Joslin [Page 16]
894 \f
895 Internet-Draft DUA Configuration Schema March 2005
898 serviceSearchDescriptor.
900 It is assumed the serviceID is unique to a given service
901 within the scope of any DUA that might use the given profile.
903 Example:
905 defaultSearchBase: dc=mycompany,dc=com
907 serviceSearchDescriptor: email:ou=people,ou=org1,?
908 one;ou=contractor,?one;
909 ref:cn=profile,dc=mycompany,dc=com
911 In this example, the DUA MUST search in
912 "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then
913 SHOULD search in "ou=contractor,dc=mycompany,dc=com", and
914 finally it SHOULD search other locations as specified in the
915 profile described at "cn=profile,dc=mycompany,dc=com". For
916 more examples, see section 9.
919 5.1.7 Interpreting the attributeMap attribute
921 Interpretation:
923 A DUA SHOULD perform attribute mapping for all LDAP operations
924 performed for a service that has an attributeMap entry.
925 Because attribute mapping is specific to each service within
926 the DUA, a "serviceID" is required as part of the attributeMap
927 syntax. I.E. not all DUA services should necessarily perform
928 the same attribute mapping.
930 Attribute mapping in general is expected be used to map
931 attributes of similar syntaxes as specified by the service
932 supported by the DUA. However, a DUA is NOT REQUIRED to
933 verify syntaxes of mapped attributes. If the DUA does
934 discover that the syntax of the mapped attribute does not
935 match that of the original attribute, the DUA MAY perform
936 translation between the original syntax and the new syntax.
937 When DUAs do support attribute value translation, the list of
938 capable translations SHOULD be documented in a description of
939 the DUA service.
941 Syntax:
943 attributeMap = serviceID ":" origAttribute "="
944 attributes
945 origAttribute = attribute
949 Neal-Joslin [Page 17]
950 \f
951 Internet-Draft DUA Configuration Schema March 2005
954 attributes = wattribute *( space wattribute )
955 wattribute = whsp newAttribute whsp
956 newAttribute = descr | "*NULL*"
957 attribute = descr
959 Values of the origAttribute are defined by and SHOULD be
960 documented for the DUA service, as a list of known supported
961 attributes.
963 Default Value:
965 By default, attributes that are used by a DUA service are not
966 mapped unless mapped by the attributeMap attributes. The DUA
967 MUST NOT map an attribute unless it is explicitly defined by
968 an attributeMap attribute.
970 Other attribute notes:
972 When an attribute is mapped to the special keystring "*NULL*",
973 the DUA SHOULD NOT request that attribute from the DSA, when
974 performing a search or compare request. If the DUA is also
975 capable of performing modification on the DSA, the DUA SHOULD
976 NOT attempt to modify any attribute which has been mapped to
977 "*NULL*".
979 It is assumed the serviceID is unique to a given service
980 within the scope of the DSA.
982 A DUA SHOULD support attribute mapping. If it does, the
983 following additional rules apply:
985 1) The list of attributes that are allowed to be mapped SHOULD
986 defined by and documented for the service.
988 2) Any supported translation of mapping from attributes of
989 dissimilar syntax SHOULD also be defined and documented.
991 3) If an attribute may be mapped to multiple attributes the
992 DSA SHOULD define a syntax or usage statement for how the new
993 attribute value will be constructed. Furthermore, the
994 resulting translated syntax of the combined attributes MUST be
995 the same as the attribute being mapped.
997 4) A DUA MUST support mapping of attributes using the
998 attribute OID. It SHOULD support attribute mapping based on
999 the attribute name.
1001 5) It is recommended that attribute mapping not be applied to
1005 Neal-Joslin [Page 18]
1006 \f
1007 Internet-Draft DUA Configuration Schema March 2005
1010 parents of the target entries.
1012 6) Attribute mapping is not recursive. In other words, if an
1013 attribute has been mapped to a target attribute, that new
1014 target attribute MUST NOT be mapped to a third attribute.
1016 7) A given attribute MUST only be mapped once for a given
1017 service.
1020 Example:
1022 Suppose a DUA is acting on behalf of an email service. By
1023 default the "email" service uses the "mail", "cn" and "sn"
1024 attributes to discover mail addresses. However, the email
1025 service has been deployed in an environment that uses
1026 "employeeName" instead of "cn." And also instead of using the
1027 "mail" attribute for email addresses, the "email" attribute is
1028 used for that purpose. In this case, the attribute "cn" can
1029 be mapped to "employeeName," allowing the DUA to perform
1030 searches using the "employeeName" attribute as part of the
1031 search filter, instead of "cn". And "mail" can be mapped to
1032 "email" when attempting to retrieve the email address. This
1033 mapping is performed by adding the attributeMap attributes to
1034 the configuration profile entry as follows (represented in
1035 LDIF[16]):
1037 attributeMap: email:cn=employeeName
1038 attributeMap: email:mail=email
1040 As described above, the DUA MAY also map a single attribute to
1041 multiple attributes. When mapping a single attribute to more
1042 than one attribute, the new syntax or usage of the mapped
1043 attribute must be intrinsically defined by the DUAs service.
1045 attributeMap: email:cn=firstName lastName
1047 In the above example, the DUA creates the new value by
1048 generating space separated string using the values of the
1049 mapped attributes. In this case, a special mapping must be
1050 defined so that a proper search filter can be created. For
1051 further information on this example, please refer to section
1052 9.
1054 Another possibility for multiple attribute mapping might come
1055 in when constructing returned attributes. For example,
1056 perhaps all email addresses are of a guaranteed syntax of
1057 "uid@domain". And in this example, the uid and domain are
1061 Neal-Joslin [Page 19]
1062 \f
1063 Internet-Draft DUA Configuration Schema March 2005
1066 separate attributes in the directory. The email service may
1067 define that if the "mail" attribute is mapped to two different
1068 attributes, it will construct the email address as a
1069 concatenation of the uid and domain attributes, placing the
1070 "@" character between them.
1072 attributeMap: email:mail=uid domain
1075 5.1.8 Interpreting the searchTimeLimit attribute
1077 Interpretation:
1079 The searchTimeLimit attribute defines the maximum time, in
1080 seconds, that a DUA SHOULD allow to perform a search request.
1082 Syntax:
1084 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. [5]
1086 Default Value:
1088 If the searchTimeLimit attribute is not defined or is zero,
1089 the search time limit is not enforced by the DUA.
1091 Other attribute notes:
1093 This time limit only includes the amount of time required to
1094 perform the LDAP search operation. If other operations are
1095 required, those operations do not need to be considered part
1096 of the search time. See bindTimeLimit for the LDAP bind
1097 operation.
1099 5.1.9 Interpreting the bindTimeLimit attribute
1101 Interpretation:
1103 The bindTimeLimit attribute defines the maximum time, in
1104 seconds, that a DUA SHOULD allow to perform an LDAP bind
1105 request against each server on the preferredServerList or
1106 defaultServerList.
1108 Syntax:
1110 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
1112 Default Value:
1117 Neal-Joslin [Page 20]
1118 \f
1119 Internet-Draft DUA Configuration Schema March 2005
1122 If the bindTimeLimit attribute is not defined or is zero, the
1123 bind time limit is not enforced by the DUA.
1125 Other attribute notes:
1127 This time limit only includes the amount of time required to
1128 perform the LDAP bind operation. If other operations are
1129 required, those operations do not need to be considered part
1130 of the bind time. See searchTimeLimit for the LDAP search
1131 operation.
1133 5.1.10 Interpreting the followReferrals attribute
1135 Interpretation:
1137 If set to TRUE, the DUA SHOULD follow any referrals if
1138 discovered.
1140 If set to FALSE, the DUA MUST NOT follow referrals.
1142 Syntax:
1144 Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. [5]
1146 Default Value:
1148 If the followReferrals attribute is not set or set to an
1149 invalid value the default value is TRUE.
1151 5.1.11 Interpreting the dereferenceAliases attribute
1153 Interpretation:
1155 If set to TRUE, the DUA SHOULD enable alias dereferencing.
1157 If set to FALSE, the DUA MUST NOT enable alias dereferencing.
1159 Syntax:
1161 Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
1163 Default Value:
1165 If the dereferenceAliases attribute is not set or set to an
1166 invalid value the default value is TRUE.
1168 5.1.12 Interpreting the profileTTL attribute
1173 Neal-Joslin [Page 21]
1174 \f
1175 Internet-Draft DUA Configuration Schema March 2005
1178 Interpretation:
1180 The profileTTL attribute defines how often the DUA SHOULD re-
1181 load and reconfigure itself using the corresponding
1182 configuration profile entry. The value is represented in
1183 seconds. Once a DUA reloads the profile entry, it SHOULD re-
1184 configure itself with the new values.
1186 Syntax:
1188 Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
1190 Default Value:
1192 If not specified the DUA MAY use its own reconfiguration
1193 policy.
1195 Other attribute notes:
1197 If the profileTTL value is zero, the DUA SHOULD NOT
1198 automatically re-load the configuration profile.
1200 5.1.13 Interpreting the objectclassMap attribute
1202 Interpretation:
1204 A DUA MAY perform objectclass mapping for all LDAP operations
1205 performed for a service that has an objectclassMap entry.
1206 Because objectclass mapping is specific for each service
1207 within the DUA, a "serviceID" is required as part of the
1208 objectclassMap syntax. I.E. Not all DUA services should
1209 necessarily perform the same objectclass mapping.
1211 Objectclass mapping SHOULD be used in conjunction with
1212 attribute mapping to map the required schema by the service to
1213 an equivalent schema that is available in the directory.
1215 Objectclass mapping may or may not be required by a DUA.
1216 Often, the objectclass attribute is used in search filters.
1217 If a service search descriptor is provided, it is expected
1218 that the search filter contains a "correct" search filter
1219 (though this is not a requirement,) which does not need to be
1220 re-mapped. However, when the service search descriptor is not
1221 provided, and the default search filter for that service
1222 contains the objectclass attribute, that search filter SHOULD
1223 be re-defined by objectclass mapping. If a default search
1224 filter is not used, it SHOULD be re-defined through the
1225 serviceSearchDescriptor. If a serviceSearchDescriptor is
1229 Neal-Joslin [Page 22]
1230 \f
1231 Internet-Draft DUA Configuration Schema March 2005
1234 defined for a particular service, it SHOULD NOT be re-mapped
1235 by either the objectclassMap or attributeMap values.
1237 One condition where the objectclassMap SHOULD be used is when
1238 the DUA is providing gateway functionality. In this case, the
1239 DUA is acting on behalf of another service, which may pass in
1240 a search filter itself. In this type of DUA, the DUA may
1241 alter the search filter according to the appropriate
1242 attributeMap and objectclassMap values. And in this case, it
1243 is also assumed that a serviceSearchDescriptor is not defined.
1245 Syntax:
1247 objectclassMap = serviceID ":" origObjectclass "="
1248 objectclass
1249 origObjectclass = objectclass
1250 objectclass = keystring
1252 Values of the origObjectclass depend on the type of DUA
1253 Service using the objectclass mapping feature.
1255 Default Value:
1257 The DUA MUST NOT remap an objectclass unless it is explicitly
1258 defined by an objectclassMap attribute.
1260 Other attribute notes:
1262 A DUA SHOULD support objectclass mapping. If it does, the DUA
1263 MUST support mapping of objectclasses using the objectclass
1264 OID. It SHOULD support objectclass mapping based on the
1265 objectclass name.
1267 It is assumed the serviceID is unique to a given service
1268 within the scope of the DSA.
1270 Example:
1272 Suppose a DUA is acting on behalf of an email service. By
1273 default the "email" service uses the "mail", "cn" and "sn"
1274 attributes to discover mail addresses in entries created using
1275 inetOrgPerson objectclass[17]. However, the email service has
1276 been deployed in an environment that uses entries created
1277 using "employee" objectclass. In this case, the attribute
1278 "cn" can be mapped to "employeeName", and "inetOrgPerson" can
1279 be mapped to "employee", allowing the DUA to perform LDAP
1280 operations using the entries that exist in the directory.
1281 This mapping is performed by adding attributeMap and
1285 Neal-Joslin [Page 23]
1286 \f
1287 Internet-Draft DUA Configuration Schema March 2005
1290 objectclassMap attributes to the configuration profile entry
1291 as follows (represented in LDIF[16]):
1293 attributeMap: email:cn=employeeName
1294 objectclassMap: email:inetOrgPerson=employee
1297 5.1.14 Interpreting the defaultSearchScope attribute
1299 Interpretation:
1301 When a DUA needs to search the DSA for information, this
1302 attribute provides the "scope" for the search. This parameter
1303 can be overridden by the serviceSearchDescriptor attribute.
1304 See section 5.1.6.
1306 Syntax:
1308 scopeSyntax = "base" | "one" | "sub"
1310 Default Value:
1312 The default value for the defaultSearchScope SHOULD be defined
1313 by the DUA service. If the default search scope for a service
1314 is not defined then the scope SHOULD be for the DUA to perform
1315 a subtree search.
1318 5.1.15 Interpreting the serviceAuthenticationMethod attribute
1320 Interpretation:
1322 The serviceAuthenticationMethod attribute defines an ordered
1323 list of LDAP bind methods to be used when attempting to
1324 contact a DSA for a particular service. Interpretation and
1325 use of this attribute is the same as 5.1.4, but specific for
1326 each service.
1328 Syntax:
1330 svAuthMethod = service ":" method *(";" method)
1332 Note: Although multiple authentication methods may be
1333 specified in the syntax, at most one of each type is allowed.
1335 Default Value:
1337 If the serviceAuthenticationMethod attribute is not provided,
1341 Neal-Joslin [Page 24]
1342 \f
1343 Internet-Draft DUA Configuration Schema March 2005
1346 the authenticationMethod SHOULD be followed, or its default.
1348 Other attribute notes:
1350 Determining how the DUA should bind to the DSAs also depends
1351 on the additional configuration attributes, credentialLevel,
1352 serviceCredentialLevel and bindTimeLimit. Please review
1353 section 5.2 for details on how to properly bind to a DSA.
1355 Example:
1357 serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
1360 5.1.16 Interpreting the serviceCredentialLevel attribute
1362 Interpretation:
1364 The serviceCredentialLevel attribute defines what type(s) of
1365 credential(s) the DUA SHOULD use when contacting the DSA for a
1366 particular service. Interpretation and used of this attribute
1367 are the same as 5.1.5.
1369 Syntax:
1371 svCredentialLevel = service ":" level *(space level)
1373 Refer to implementation notes in section 5.2 for additional
1374 syntax requirements for the credentialLevel attribute.
1376 Note: Although multiple credential levels may be specified in
1377 the syntax, at most one of each type is allowed.
1379 Default Value:
1381 If the serviceCredentialLevel attribute is not defined, the
1382 DUA MUST examine the credentialLevel attribute, or follow its
1383 default if not provided.
1385 Other attribute notes:
1387 Determining how the DUA should bind to the DSAs also depends
1388 on the additional configuration attributes,
1389 serviceAuthenticationMethod, authenticationMethod and
1390 bindTimeLimit. Please review section 5.2 for details on how
1391 to properly bind to a DSA.
1393 Example:
1397 Neal-Joslin [Page 25]
1398 \f
1399 Internet-Draft DUA Configuration Schema March 2005
1402 serviceCredentialLevel: email:proxy anonymous
1405 5.2 Binding to the Directory Server
1407 The DUA SHOULD use the following algorithm when binding to the
1408 server:
1410 for (clevel in credLevel) [see note 1]
1411 if (clevel is "anonymous")
1412 for (host in hostnames) [see note 2]
1413 if (server is responding)
1414 return success
1415 return failure
1416 else
1417 for (amethod in authMethod) [see note 3]
1418 if (amethod is none)
1419 for (host in hostnames)
1420 if (server is responding)
1421 return success
1422 return failure
1423 else
1424 for (host in hostnames)
1425 authenticate using amethod and clevel
1426 if (authentication passed)
1427 return success
1428 return failure
1430 Note 1: The credLevel is a list of credential levels as defined
1431 in serviceCredentialLevel (section 5.1.16) for a given
1432 service. If the serviceCredentialLevel is not defined,
1433 the DUA MUST examine the credentialLevel attribute.
1435 Note 2: hostnames is the list of servers to contact as defined
1436 in 5.1.1 & 5.1.2.
1438 Note 3: The authMethod a list of authentication methods as defined
1439 in serviceAuthenticationMethod (section 5.1.15) for a
1440 given service. If the serviceAuthenticationMethod is not
1441 defined, the DUA MUST examine the authenticationMethod
1442 attribute.
1446 6. Security Considerations
1448 The profile entries MUST be protected against unauthorized
1449 modification. Each service needs to consider implications of
1453 Neal-Joslin [Page 26]
1454 \f
1455 Internet-Draft DUA Configuration Schema March 2005
1458 providing its service configuration as part of this profile and
1459 limit access to the profile entries accordingly.
1461 The management of the authentication credentials for the DUA is
1462 outside the scope of this document and needs to be handled by the
1463 DUA.
1465 Since the DUA needs to know how to properly bind to the directory
1466 server, the access control configuration of the DSA MUST assure
1467 that the DSA can view all the elements of the DUAConfigProfile
1468 attributes. For example, if the credentialLevel attribute contains
1469 "Self" but the DSA is unable to access the credentialLevel
1470 attribute, the DUA will instead attempt an anonymous connection to
1471 the directory server.
1473 The algorithm described by section 5.2 also has security
1474 considerations. Altering that design will alter the security
1475 aspects of the configuration profile.
1478 7. Acknowledgments
1480 There were several additional authors of this document. However we
1481 chose to represent only one author per company in the heading.
1482 From Sun we also would like to acknowledge Roberto Tam for his
1483 design work on Sun's first LDAP name service product and his input
1484 for this document. From Hewlett-Packard we'd like to acknowledge
1485 Dave Binder for his work architecting Hewlett-Packard's LDAP name
1486 service product as well as his design guidance on this document.
1487 We'd also like to acknowledge Grace Lu from HP, for her input and
1488 implementation of HP's configuration profile manager code.
1491 8. References
1493 8.1 Normative References
1496 [4] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
1497 Levels", RFC 2119, March 1997.
1500 [5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
1501 Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,
1502 December 1997.
1505 [6] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
1509 Neal-Joslin [Page 27]
1510 \f
1511 Internet-Draft DUA Configuration Schema March 2005
1514 (v3): UTF-8 String Representation of Distinguished Names", RFC
1515 2253, December 1997.
1518 [7] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
1521 [8] R. Hinden, B. Carpenter, L. Masinter, "Uniform Resource Identifier
1522 (URI): Generic Syntax", RFC 3986, January 2005.
1525 [9] M. Wahl, "A Summary of the X.500(96) User Schema for use with
1526 LDAPv3", RFC 2256, December 1997.
1529 [11] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
1530 Methods for LDAP", RFC 2828, May 2000
1533 [13] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
1534 Protocol [v3]: Extension for Transport Layer Security", RFC 2830,
1535 May 2000
1538 [18] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS",
1539 http://www.iana.org/assignments/sasl-mechanisms, April 2004
1542 8.2 Informative References
1545 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
1546 (v3)", RFC 2251, December 1997.
1549 [2] L. Howard, "An Approach for Using LDAP as a Network Information
1550 Service", RFC 2307, March 1998.
1553 [3] Microsoft Corporation, "Windows Services for Unix 3.5",
1554 http://www.microsoft.com/windows/sfu/default.asp
1557 [12] J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
1558 2222, October 1997
1561 [14] P. Leach, C. Newman, "Using Digest Authentication as a SASL
1565 Neal-Joslin [Page 28]
1566 \f
1567 Internet-Draft DUA Configuration Schema March 2005
1570 Mechanism", RFC 2831, May 2000
1573 [15] T. Howes, "The String Representation of LDAP Search Filters", RFC
1574 2254, December 1997.
1577 [16] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
1578 Specification", RFC 2849, June 2000.
1581 [17] M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
1582 2789, April 2000
1585 9. Examples
1587 In this section we will describe a fictional DUA which provides one
1588 service, called the "email" service. This service would be similar
1589 to an email client that uses an LDAP directory to discover email
1590 addresses based on a textual representation of the recipient's
1591 colloquial name.
1593 This email service is defined by default to expect that users with
1594 email addresses will be of the "inetOrgPerson" objectclass type
1595 [17]. And by default, the "email" service expects the colloquial
1596 name to be stored in the "cn" attribute, while it expects the email
1597 address to be stored in the "mail" attribute (as one would expect
1598 as defined by the inetOrgPerson objectclass.)
1600 As a special feature, the "email" service will perform a special
1601 type of attribute mapping, when performing searches. If the "cn"
1602 attribute has been mapped to two or more attributes, the "email"
1603 service will parse the requested search string and map each white-
1604 space separated token into the mapped attributes, respectively.
1606 The default search filter for the "email" service is
1607 "(objectclass=inetOrgPerson)". The email service also defines that
1608 when it performs a name to address discovery, it will wrap the
1609 search filter inside a complex search filter as follows:
1611 (&(<filter>)(cn~=<name string>)
1613 or if "cn" has been mapped to multiple attributes, that wrapping
1614 would appear as follows:
1616 (&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
1621 Neal-Joslin [Page 29]
1622 \f
1623 Internet-Draft DUA Configuration Schema March 2005
1626 The below examples show how the "email" service builds it search
1627 requests, based on the defined profile. In all cases, the
1628 defaultSearchBase is "o=airius.com" and the defaultSearchScope is
1629 undefined.
1631 In addition, for all examples, we assume that the "email" service
1632 has been requested to discover the email address for "Jane
1633 Hernandez."
1636 Example 1:
1638 serviceSearchDescriptor: email:"ou=marketing,"
1640 base: ou=marketing,o=airius.com
1641 scope: sub
1642 filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
1644 Example 2:
1646 serviceSearchDescriptor: email:"ou=marketing,"?one?
1647 (&(objectclass=inetOrgPerson)(c=us))
1648 attributeMap: email:cn=2.5.4.42 sn
1650 Note: 2.5.4.42 is the OID that represents the "givenName"
1651 attribute.
1653 In this example, the email service performs <name string> parsing
1654 as described above to generate a complex search filter. The above
1655 example results in one search.
1657 base: ou=marketing,o=airius.com
1658 scope: one
1659 filter: (&(&(objectclass=inetOrgPerson)(c=us))
1660 (2.5.4.42~=Jane)(sn~=Hernandez))
1662 Example 3:
1664 serviceSearchDescriptor: email:ou=marketing,"?base
1665 attributeMap: email:cn=name
1667 This example is invalid, because either the quote should have been
1668 escaped, or there should have been a leading quote.
1670 Example 4:
1672 serviceSearchDescriptor: email:ou=\mar\\keting,\"?base
1673 attributeMap: email:cn=name
1677 Neal-Joslin [Page 30]
1678 \f
1679 Internet-Draft DUA Configuration Schema March 2005
1682 base: ou=\mar\keting,"
1683 scope: base
1684 filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
1686 Example 5:
1688 serviceSearchDescriptor: email:ou="marketing",o=supercom
1690 This example is invalid, since the quote was not a leading quote,
1691 and thus should have been escaped.
1693 Example 6:
1695 serviceSearchDescriptor: email:??(&(objectclass=person)
1696 (ou=Org1 \\(temporary\\)))
1698 base: o=airius.com
1699 scope: sub
1700 filter: (&((&(objectclass=person)(ou=Org1 \(Temporary\)))
1701 (cn~=Jane Henderson)))
1703 Example 7:
1705 serviceSearchDescriptor: email:"ou=funny?org,"
1707 base: ou=funny?org,o=airius.com
1708 scope: sub
1709 filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
1712 Author's Addresses
1714 Luke Howard
1715 PADL Software Pty. Ltd.
1716 PO Box 59
1717 Central Park Vic 3145
1718 Australia
1720 EMail: lukeh@padl.com
1723 Bob Neal-Joslin
1724 Hewlett-Packard Company
1725 19420 Homestead RD MS43-LF
1726 Cupertino, CA 95014
1727 USA
1729 Phone: +1 408 447-3044
1733 Neal-Joslin [Page 31]
1734 \f
1735 Internet-Draft DUA Configuration Schema March 2005
1738 EMail: bob_joslin@hp.com
1741 Morteza Ansari
1742 Infoblox
1743 475 Potrero Avenue
1744 Sunnyvale, CA 94085
1745 USA
1747 Phone: +1 408-716-4300
1748 EMail: morteza@infoblox.com
1750 Expires September 2005
1789 Neal-Joslin [Page 32]
1790 \f