-
-
-Application Working Group M. Ansari
-INTERNET-DRAFT Sun Microsystems, Inc.
-Expires Febuary 2003 L. Howard
- PADL Software Pty. Ltd.
- B. Joslin [ed.]
+INTERNET-DRAFT M. Ansari
+draft-joslin-config-schema-10.txt Infoblox
+Category: Informational L. Howard
+Expires: September 2005 PADL Software Pty. Ltd.
+ B. Neal-Joslin, Editor
Hewlett-Packard Company
-
- September 15th, 2003
-Intended Category: Informational
+ 4 March, 2005
A Configuration Schema for LDAP Based
Directory User Agents
- <draft-joslin-config-schema-07.txt>
Status of this Memo
- This memo provides information for the Internet community. This
- memo does not specify an Internet standard of any kind. Distribu-
- tion of this memo is unlimited.
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ This document and the information contained herein are provided on
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
- 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 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 made obsolete
- 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".
+ 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/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+IPR Statement
+
+ By submitting this Internet-Draft, I certify that any applicable
+
+
+
+Neal-Joslin [Page 1]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ patent or other IPR claims of which I am aware have been disclosed,
+ or will be disclosed, and any of which I become aware will be
+ disclosed, in accordance with RFC 3668.
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC
+ documents can be found in BCP 78 and BCP 79.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+
- To learn the current status of any Internet-Draft, please check the
- 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
- Directories on ds.internic.net (US East Coast), nic.nordu.net
- (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
- Rim).
- Distribution of this document is unlimited.
Abstract
- This document describes a mechanism for global configuration of
- similar directory user agents. This document defines a schema for
+ This document describes a mechanism for distributed configuration
+ of similar directory user agents. This document defines a schema
+ for configuration of these DUAs that may be discovered using the
+ Lightweight Directory Access Protocol in RFC 2251[1]. A set of
+ attribute types and an objectclass are proposed, along with
+ specific guidelines for interpreting them. A proposal of using
+ attribute and objectclass mapping allows DUAs to re-configure their
+ schema to that of the end user's environment. This document is
+ intended to be a skeleton for future documents that describe
+ configuration of specific DUA services.
+
+
+
+
-Joslin [Page 1]
+
+
+Neal-Joslin [Page 2]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Table of Contents
+
+ 1. Background & Motivation ...................................... 4
+ 2. General Issues ............................................... 5
+ 2.1 Terminology .................................................. 5
+ 2.2 Attributes ................................................... 5
+ 2.3 Object Classes ............................................... 6
+ 2.4 Syntax Definitions ........................................... 6
+ 3. Attribute Definitions ........................................ 6
+ 4. Class Definition ............................................. 8
+ 5. Implementation Details ....................................... 9
+ 5.1.1 Interpreting the preferredServerList attribute ............. 9
+ 5.1.2 Interpreting the defaultServerList attribute ............... 10
+ 5.1.3 Interpreting the defaultSearchBase attribute ............... 11
+ 5.1.4 Interpreting the authenticationMethod attribute ............ 12
+ 5.1.5 Interpreting the credentialLevel attribute ................. 13
+ 5.1.6 Interpreting the serviceSearchDescriptor attribute ......... 14
+ 5.1.7 Interpreting the attributeMap attribute .................... 17
+ 5.1.8 Interpreting the searchTimeLimit attribute ................. 20
+ 5.1.9 Interpreting the bindTimeLimit attribute ................... 20
+ 5.1.10 Interpreting the followReferrals attribute ................ 21
+ 5.1.11 Interpreting the dereferenceAliases attribute ............. 21
+ 5.1.12 Interpreting the profileTTL attribute ..................... 21
+ 5.1.13 Interpreting the objectclassMap attribute ................. 22
+ 5.1.14 Interpreting the defaultSearchScope attribute ............. 24
+ 5.1.15 Interpreting the serviceAuthenticationMethod attribute .... 24
+ 5.1.16 Interpreting the serviceCredentialLevel attribute ......... 25
+ 5.2 Binding to the Directory Server .............................. 26
+ 6. Security Considerations ...................................... 26
+ 7. Acknowledgments .............................................. 27
+ 8. References ................................................... 27
+ 8.1 Normative References ......................................... 27
+ 8.2 Informative References ....................................... 28
+ 9. Examples ..................................................... 29
+
+
+
+
+
+
+
- configuration of these DUAs that may be discovered using the Light-
- weight Directory Access Protocol in RFC 2251[17]. A set of attri-
- bute types and an objectclass are proposed, along with specific
- guidelines for interpreting them. A significant feature of the
- global configuration policy for DUAs is a mechanism that allows
- DUAs to re-configure their schema to that of the end user's
- environment. This configuration is achieved through attribute and
- objectclass mapping. This document is intended to be a skeleton
- for future documents that describe configuration of specific DUA
- services.
+
+
+
+
+
+
+
+
+Neal-Joslin [Page 3]
+\f
+Internet-Draft DUA Configuration Schema March 2005
1. Background & Motivation
The LDAP protocol has brought about a new and nearly ubiquitous
acceptance of the directory server. Many new client applications
- (DUAs) are being created that use LDAP directories for many dif-
- ferent services. And although the LDAP protocol has eased the
+ (DUAs) are being created that use LDAP directories for many
+ different services. And although the LDAP protocol has eased the
development of these applications, some challenges still exist for
both developers and directory administrators.
The authors of this document are implementers of DUAs described by
- RFC 2307 [14]. In developing these agents, we felt there are
- several issues that still need to be addressed to ease the deploy-
- ment and configuration of a large network of these DUAs.
+ RFC 2307 [2]. In developing these agents, we felt there are
+ several issues that still need to be addressed to ease the
+ deployment and configuration of a large network of these DUAs.
One of these challenges stems from the lack of a utopian schema. A
utopian schema would be one that every application developer could
agree upon and that would support every application. Unfortunately
today, many DUAs define their own schema (like RFC 2307 vs.
- Microsoft's Services for Unix [13]) containing similar attributes,
- but with different attribute names. This can lead to data redun-
- dancy within directory entries and give directory administrators
- unwanted challenges, updating schemas and synchronizing data.
+ Microsoft's Services for Unix [3]) containing similar attributes,
+ but with different attribute names. This can lead to data
+ redundancy within directory entries and give directory
+ administrators unwanted challenges, updating schemas and
+ synchronizing data.
So, one goal of this document is to eliminate data redundancy by
having DUAs configure themselves to the schema of the deployed
- directory, instead of forcing it's own schema on the directory.
+ directory, instead of forcing its own schema on the directory.
Another goal of this document is to provide the DUA with enough
configuration information so that it can discover how to retrieve
Finally, this document intends to describe a configuration method
for DUAs that can be shared among many DUAs, on various platforms,
- providing as such, a configuration profile, the purpose is to cen-
- tralize and simplify management of DUAs.
-
-
-
-Joslin [Page 2]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
+ providing as such, a configuration profile, the purpose is to
+ centralize and simplify management of DUAs.
This document is intended to provide the skeleton framework for
future drafts, which will describe the individual implementation
details for the particular services provided by that DUA. The
authors of this document plan to develop such a document for the
- Network Information Service DUA, described by RFC 2307 or its suc-
- cessor.
+ Network Information Service DUA, described by RFC 2307 or its
+ successor.
We expect that as DUAs take advantage of this configuration scheme,
each DUA will require additional configuration parameters, not
- specified by this document. Thus, we would expect that new auxili-
- ary object classes, containing new configuration attributes will be
- created, and then joined with the structural class defined by this
- document to create a configuration profile for a particular DUA
- service. And that by joining various auxiliary objectclasses for
- different DUA services, that configuration of various DUA services
- can be controlled by a single configuration profile entry.
+ specified by this document. Thus, we would expect that new
+
+
+
+Neal-Joslin [Page 4]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ auxiliary object classes, containing new configuration attributes
+ will be created, and then joined with the structural class defined
+ by this document to create a configuration profile for a particular
+ DUA service. And that by joining various auxiliary objectclasses
+ for different DUA services, that configuration of various DUA
+ services can be controlled by a single configuration profile entry.
2. General Issues
- The schema defined by this document is defined under the "DUA Con-
- figuration Schema." This schema is derived from the OID: iso (1)
- org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett-
- Packard Company (11) directory (1) LDAP-UX Integration Project (3)
- DUA Configuration Schema (1). This OID is represented in this
- document by the keystring "DUAConfSchemaOID"
+ The schema defined by this document is defined under the "DUA
+ Configuration Schema." This schema is derived from the OID: iso
+ (1) org (3) dod (6) internet (1) private (4) enterprises (1)
+ Hewlett-Packard Company (11) directory (1) LDAP-UX Integration
+ Project (3) DUA Configuration Schema (1). This OID is represented
+ in this document by the keystring "DUAConfSchemaOID"
(1.3.6.1.4.1.11.1.3.1).
2.1 Terminology
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 [15].
+ this document are to be interpreted as described in BCP 14 (RFC
+ 2119) [4].
2.2 Attributes
authenticationMethod
credentialLevel
serviceSearchDescriptor
-
-
-
-Joslin [Page 3]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
serviceCredentialLevel
serviceAuthenticationMethod
attributeMap
dereferenceAliases
profileTTL
+
+
+Neal-Joslin [Page 5]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
2.3 Object Classes
The following object class is defined in this document:
The following syntax definitions are used throughout this document.
This document does not define new syntaxes that must be supported
- by the directory server. The string encoding used by the attri-
- butes defined in this document can be found section 5.
+ by the directory server. The string encoding used by the
+ attributes defined in this document can be found section 5.
- keystring as defined by RFC 2252 [2]
+ keystring as defined by RFC 2252 [5]
descr as defined by RFC 2252 section 4.1
a as defined by RFC 2252 section 4.1
d as defined by RFC 2252 section 4.1
space as defined by RFC 2252 section 4.1
whsp as defined by RFC 2252 section 4.1
- base as defined by RFC 2253 [3]
+ base as defined by RFC 2253 [6]
DistinguishedName as defined by RFC 2253 section 2
RelativeDistinguishedName as defined by RFC 2253 section 2
- scope as defined by RFC 2255 [5]
- IPv4address as defined by RFC 2396 [9]
- hostport as defined by RFC 2396 section 3.2.2
- port as defined by RFC 2396 section 3.2.2
- ipv6reference as defined by RFC 2732 [10]
- host as defined by RFC 2732 section 3
+ scope as defined by RFC 2255 [7]
+ host as defined by RFC 3986
+ section 3.2.2 [8]
+ hostport host [":" port ]
+ port as defined by RFC 3986
+ section 3.2.3 [8]
serviceID = keystring
discovering their configuration.
( DUAConfSchemaOID.1.0 NAME 'defaultServerList'
- DESC 'Default LDAP server host address used by a DUA'
-
-
-
-Joslin [Page 4]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
+ DESC 'Default LDAP server host addresses used by a DUA'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
+
+
+
+Neal-Joslin [Page 6]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
DESC 'Preferred LDAP server host addresses to be used by a
DUA'
( DUAConfSchemaOID.1.5 NAME 'followReferrals'
DESC 'Tells DUA if it should follow referrals
- returned by a DSA search result'
- EQUALITY booleanMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
- SINGLE-VALUE )
-
- ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
- DESC 'Tells DUA if it should dereference aliases'
+ returned by a DSA result'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
DESC 'A keystring which identifies the type of
- authentication method used to contact the DSA'
+ authentication methods used to contact the DSA'
EQUALITY caseIgnoreMatch
-
-
-
-Joslin [Page 5]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
- ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
- DESC 'LDAP search descriptor list used by a DUA'
- EQUALITY caseExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
( DUAConfSchemaOID.1.9 NAME 'attributeMap'
DESC 'Attribute mappings used by a DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
+
+
+
+Neal-Joslin [Page 7]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
DESC 'Identifies type of credentials a DUA should
use when binding to the LDAP server'
EQUALITY caseIgnoreIA5Match
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+ ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
+ DESC 'LDAP search descriptor list used by a DUA'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
- DESC 'Authentication method used by a service of the DUA'
+ DESC 'Identifies type of authentication method a DUA
+ should use when binding to the LDAP server for a
+ specific service'
EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
+ DESC 'Tells DUA if it should dereference aliases'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
-Joslin [Page 6]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+4. Class Definition
+ The objectclass below is constructed from the attributes defined in
+ 3, with the exception of the cn attribute, which is defined in RFC
+ 2256 [9]. cn is used to represent the name of the DUA
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-4. Class Definition
+Neal-Joslin [Page 8]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- The objectclass below is constructed from the attributes defined in
- 3, with the exception of the cn attribute, which is defined in RFC
- 2256 [8]. cn is used to represent the name of the DUA configura-
- tion profile.
+
+ configuration profile.
( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile'
SUP top STRUCTURAL
Interpretation:
As described by the syntax, the preferredServerList parameter
- is a white-space separated list of server addresses and asso-
- ciated port numbers. When the DUA needs to contact a DSA, the
- DUA MUST first attempt to contact one of the servers listed in
- the preferredServerList attribute. The DUA MUST contact the
- DSA specified by the first server address in the list. If
- that DSA is unavailable, the remaining DSAs MUST be queried in
- the order provided until a connection is established with a
- DSA. Once a connection with a DSA is established, the DUA
- SHOULD NOT attempt to establish a connection with the remain-
- ing DSAs.
+ is a white-space separated list of server addresses and
+ associated port numbers. When the DUA needs to contact a DSA,
+ the DUA MUST first attempt to contact one of the servers
+ listed in the preferredServerList attribute. The DUA MUST
+ contact the DSA specified by the first server address in the
+ list. If that DSA is unavailable, the remaining DSAs MUST be
+ queried in the order provided (left to right) until a
+ connection is established with a DSA. Once a connection with
+ a DSA is established, the DUA SHOULD NOT attempt to establish
+ a connection with the remaining DSAs. The purpose of
+ enumerating multiple DSAs is not for supplemental data, but
+ for high availability of replicated data. This is also the
+ main reason why an LDAP URL[10] syntax was not selected for
+ this document.
If the DUA is unable to contact any of the DSAs specified by
the preferredServerList, the defaultServerList attribute MUST
the preferredServerList MUST be contacted before attempting to
contact any of the servers specified by the defaultServerList.
+ Syntax:
+ serverList = hostport *(space [hostport])
-Joslin [Page 7]
-\f
-Internet-Draft DUA Configuration Schema October 2002
- Syntax:
+Neal-Joslin [Page 9]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- serverList = host *(space [host])
Default Value:
Other attribute notes:
- This attribute is used in conjunction with the defaultServer-
- List attribute. Please see section 5.1.2 for additional
- implementation notes. Determining how the DUA should query
- the DSAs also depends on the additional configuration attri-
- butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ This attribute is used in conjunction with the
+ defaultServerList attribute. Please see section 5.1.2 for
+ additional implementation notes. Determining how the DUA
+ should query the DSAs also depends on the additional
+ configuration attributes, credentialLevel,
+ serviceCredentialLevel, bindTimeLimit,
serviceAuthenticationMethod and authenticationMethod. Please
- review section 5.2 for details on how a Posix DUA should prop-
- erly bind to a DSA.
+ review section 5.2 for details on how a DUA should properly
+ bind to a DSA.
Example:
- preferredServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
- [1080::8:800:200C:417A]:1389
+ preferredServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:389
5.1.2 Interpreting the defaultServerList attribute
The defaultServerList attribute MUST only be examined if the
preferredServerList attribute is not provided, or the DUA is
- unable to establish a connection with one of the DSAs speci-
- fied by the preferredServerList.
+ unable to establish a connection with one of the DSAs
+ specified by the preferredServerList.
If more than one address is provided, the DUA may choose to
either accept the order provided, or choose to create its own
"load." Interpretation of the "best" server order is entirely
up to the DUA, and not part of this document.
- Once the order of server addresses is determined, the DUA con-
- tacts the DSA specified by the first server address in the
+ Once the order of server addresses is determined, the DUA
+ contacts the DSA specified by the first server address in the
list. If that DSA is unavailable, the remaining DSAs SHOULD
be queried until an available DSA is found or no more DSAs are
+ available. If a server address or port is invalid, the DUA
+ SHOULD proceed to the next server address as described just
+ above.
-Joslin [Page 8]
+Neal-Joslin [Page 10]
\f
-Internet-Draft DUA Configuration Schema October 2002
-
+Internet-Draft DUA Configuration Schema March 2005
- available. If a server address or port is invalid, the DUA
- SHOULD proceed to the next server address as described just
- above.
Syntax:
- serverList = host *(space [host])
+ serverList = hostport *(space [hostport])
Default Value:
- If a defaultServerList attribute is not provided, the DUA
- should xxx attempt to contact the same DSA that provided the
- configuration profile entry itself. The default DSA is con-
- tacted only if the preferredServerList attribute is also not
- provided.
+ If a defaultServerList attribute is not provided, the DUA MAY
+ attempt to contact the same DSA that provided the
+ configuration profile entry itself. The default DSA is
+ contacted only if the preferredServerList attribute is also
+ not provided.
Other attribute notes:
- This attribute is used in conjunction with the preferredSer-
- verList attribute. Please see section 5.1.1 for additional
- implementation notes. Determining how the DUA should query
- the DSAs also depends on the additional configuration attri-
- butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ This attribute is used in conjunction with the
+ preferredServerList attribute. Please see section 5.1.1 for
+ additional implementation notes. Determining how the DUA
+ should query the DSAs also depends on the additional
+ configuration attributes, credentialLevel,
+ serviceCredentialLevel, bindTimeLimit,
serviceAuthenticationMethod and authenticationMethod. Please
review section 5.2 for details on how a DUA should properly
contact a DSA.
Example:
- defaultServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
- [1080::8:800:200C:417A]:1389
+ defaultServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:5912
5.1.3 Interpreting the defaultSearchBase attribute
Interpretation:
When a DUA needs to search the DSA for information, this
- attribute provides the "base" for the search. This parameter
+ attribute provides the base for the search. This parameter
can be overridden or appended by the serviceSearchDescriptor
attribute. See section 5.1.6.
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.12
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [5]
Default Value:
There is no default value for the defaultSearchBase. A DUA
+ MAY define its own method for determining the search base, if
+ the defaultSearchBase is not provided.
-Joslin [Page 9]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+Neal-Joslin [Page 11]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- MAY define its own method for determining the search base, if
- the defaultSearchBase is not provided.
Other attribute notes:
- This attribute is used in conjunction with the serviceSear-
- chDescriptor attribute. See section 5.1.6.
+ This attribute is used in conjunction with the
+ serviceSearchDescriptor attribute. See section 5.1.6.
Example:
The authenticationMethod attribute defines an ordered list of
LDAP bind methods to be used when attempting to contact a
- DSA[1]. The serviceAuthenticationMethod overrides this value
- for a particular service (see 5.1.15.) Each method MUST be
- attempted in the order provided by the attribute, until a suc-
- cessful LDAP bind is performed ("none" is assumed to always be
- successful.) However the DUA MAY skip over one or more
+ DSA[11]. The serviceAuthenticationMethod overrides this
+ value for a particular service (see 5.1.15.) Each method MUST
+ be attempted in the order provided by the attribute, until a
+ successful LDAP bind is performed ("none" is assumed to always
+ be successful.) However the DUA MAY skip over one or more
methods. See section 5.2 for more information.
none - The DUA does not perform an LDAP bind.
simple - The DUA performs an LDAP simple bind.
- sasl - The DUA performs an LDAP SASL bind using the
+ sasl - The DUA performs an LDAP SASL[12] bind using the
specified SASL mechanism and options.
tls - The DUA performs an LDAP StartTLS operation
followed by the specified bind method (for more
- information refer to section 5.1 of RFC 2830 [12]).
+ information refer to section 5.1 of RFC 2830 [13]).
Syntax:
- authMethod = method *(";" method)
- method = none | simple | sasl | tls
- none = "none"
- simple = "simple"
- sasl = "sasl/" saslmech [ ":" sasloption ]
- sasloption = "auth-conf" | "auth-int"
- tls = "tls:" (none | simple | sasl)
- saslmech = SASL mechanism name as defined in
- RFC 2222[7], section 3
+ authMethod = method *(";" method)
+ method = none | simple | sasl | tls
+ none = "none"
+ simple = "simple"
+ sasl = "sasl/" saslmech [ ":" sasloption ]
+ sasloption = "auth-conf" | "auth-int"
+ tls = "tls:" (none | simple | sasl)
+ saslmech = SASL mechanism name as defined in [18]
- Note: Although multiple authentication methods may be speci-
- fied in the syntax, at most one of each type is allowed.
+ Note: Although multiple authentication methods may be
+ specified in the syntax, at most one of each type is allowed.
+ I.E. "simple;simple" is invalid.
+ Default Value:
+
+ If the authenticationMethod or serviceAuthenticationMethod
-Joslin [Page 10]
+Neal-Joslin [Page 12]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- Default Value:
-
- If the authenticationMethod or serviceAuthenticationMethod
(for that particular service) attributes are not provided, the
DUA MAY choose to bind to the DSA using any method defined by
- the DUA. However, if either authenticationMethod or servi-
- ceAuthenticationMethod are provided, the DUA MUST only use the
- methods specified.
+ the DUA. However, if either authenticationMethod or
+ serviceAuthenticationMethod are provided, the DUA MUST only
+ use the methods specified.
Other attribute notes:
When using TLS, the string "tls:sasl/EXTERNAL" implies that
- two way authentication is to be performed. Any other TLS
- authentication method implies one way (DSA side credential)
- authentication.
+ two way (DSA and DUA) authentication is to be performed. Any
+ other TLS authentication method implies one way (DSA side
+ credential) authentication.
Determining how the DUA should bind to the DSAs also depends
on the additional configuration attributes, credentialLevel,
Example:
authenticationMethod: tls:simple;sasl/DIGEST-MD5
- (see [11])
+ (see [14])
5.1.5 Interpreting the credentialLevel attribute
Interpretation:
The credentialLevel attribute defines what type(s) of
- credential(s) the DUA SHOULD use when contacting the DSA. The
+ credential(s) the DUA MUST use when contacting the DSA. The
serviceCredentialLevel overrides this value for a particular
service (5.1.16.) The credentialLevel can contain more than
one credential type, separated by white space.
should determine what the proxy user's credential is. This
functionality is up to each implementation.
- self - When the DUA is acting on behalf of a "real user" the
+ self - When the DUA is acting on behalf of a known identity,
+ the DUA MUST attempt to bind to the DSA as that identity. The
+ DUA should contain methods to determine the identity of the
+ user such that that identity can be authenticated by the
-Joslin [Page 11]
+Neal-Joslin [Page 13]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- DUA SHOULD attempt to bind to the DSA as that user. The DUA
- SHOULD map the user's identity to a credential used in the
- directory.
+ directory server using the defined authentication methods.
If the credentialLevel contains more than one credential type,
the DUA MUST use the credential types in the order specified.
However, the DUA MAY skip over one or more credential types.
As soon as the DUA is able to successfully bind to the DSA,
- the DUA SHOULD NOT attempt to bind using the remaining creden-
- tial types.
+ the DUA SHOULD NOT attempt to bind using the remaining
+ credential types.
Syntax:
Other attribute notes:
Determining how the DUA should bind to the DSAs also depends
- on the additional configuration attributes, authentication-
- Method, serviceAuthenticationMethod, serviceCredentialLevel
- and bindTimeLimit. Please review section 5.2 for details on
- how to properly bind to a DSA.
+ on the additional configuration attributes,
+ authenticationMethod, serviceAuthenticationMethod,
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
Example:
The serviceSearchDescriptor attribute defines how and where a
DUA SHOULD search for information for a particular service.
+ The serviceSearchDescriptor contains a serviceID, followed by
+ one or more base-scope-filter triples. These base-scope-
-Joslin [Page 12]
+Neal-Joslin [Page 14]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- The serviceSearchDescriptor contains a serviceID, followed by
- one or more base-scope-filter triples. These base-scope-
filter triples are used to define searches only for the
specific service. Multiple base-scope-filters allow the DUA
to search for data in multiple locations of the DIT. Although
- this syntax is very similar to the LDAP URL[6], this draft
+ this syntax is very similar to the LDAP URL[8], this draft
requires the ability to supply multiple hosts as part of the
configuration of the DSA. In addition, an ordered list of
- search descritors is required, which can not be specified by
+ search descriptors is required, which can not be specified by
the LDAP URL.
In addition to the triples, serviceSearchDescriptor might also
- contain the DN of an entry that will contain an alternate pro-
- file. The DSA SHOULD re-evaluate the alternate profile and
+ contain the DN of an entry that will contain an alternate
+ profile. The DSA SHOULD re-evaluate the alternate profile and
perform searches as specified by that profile.
If the base, as defined in the serviceSearchDescriptor, is
followed by the "," (ASCII 0x2C) character, this base is known
as a relative base. This relative base may be constructed of
one or more RDN components. The DUA MUST define the search
- base by appending the relative base with the defaultSear-
- chBase.
+ base by appending the relative base with the
+ defaultSearchBase.
Syntax:
0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those
characters MUST be escaped (preceded with the "\" character.)
Alternately the DN may be surrounded by quotes (ASCII 0x22.)
- Refer to RFC 2253, section 4. If the base or filter are sur-
- rounded by quotes, only the """ character needs to be escaped.
- Any character that is preceded by the "\" character, which
- does not need to be escaped results in both "\" character and
- the character itself.
+ Refer to RFC 2253, section 4. If the base or filter are
+ surrounded by quotes, only the """ character needs to be
+ escaped. Any character that is preceded by the "\" character,
+ which does not need to be escaped results in both "\"
+ character and the character itself.
The usage and syntax of the filter string MUST be defined by
the DUA service. A suggested syntax would be that as defined
by RFC 2254.
+ If a DUA is performing a search for a particular service,
+
-Joslin [Page 13]
+Neal-Joslin [Page 15]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- If a DUA is performing a search for a particular service,
which has a serviceSearchDescriptor defined, the DUA MUST set
the base, scope and filter as defined. Each base-scope-filter
triple represents a single LDAP search operation. If multiple
- base-scope-filter triples are provided in the serviceSear-
- chDescriptor, the DUA SHOULD perform multiple search requests
- and in that case it MUST be in the order specified by the ser-
- viceSearchDescriptor.
+ base-scope-filter triples are provided in the
+ serviceSearchDescriptor, the DUA SHOULD perform multiple
+ search requests and in that case it MUST be in the order
+ specified by the serviceSearchDescriptor.
FYI: Service search descriptors do not exactly follow the LDAP
- URL syntax [5]. The reasoning for this difference is to
+ URL syntax [7]. The reasoning for this difference is to
separate the host name(s) from the filter. This allows the
- DUA to have a more flexible solution in choosing its provider.
+ DUA to have a more flexible solution in choosing its DSA.
Default Values:
Other attribute notes:
If a serviceSearchDescriptor exists for a given service, the
- service MUST use at least one base-scope-filter triple in per-
- forming searches. It SHOULD perform multiple searches per
+ service MUST use at least one base-scope-filter triple in
+ performing searches. It SHOULD perform multiple searches per
service if multiple base-scope-filter triples are defined for
that service.
The details of how the "filter" is interpreted by each DUA's
service is defined by that service. This means the filter is
- NOT REQUIRED to be a legal LDAP filter [4]. Furthermore,
+ NOT REQUIRED to be a legal LDAP filter [15]. Furthermore,
determining how attribute and objectclass mapping affects that
search filter MUST be defined by the service. I.E. The DUA
- SHOULD specify if the filter has been assumed to already have
- been mapped, or if it is expected that mapping would be
- applied to the filter. In general practice, implementation
- and usability suggests that attribute and objectclass mapping
- (sections 5.1.7 and 5.1.13) SHOULD NOT be applied to the
+ SHOULD specify if the attributes in the filter have assumed to
+ already have been mapped, or if it is expected that attribute
+ mapping (see 5.1.7) would be applied to the filter. In
+ general practice, implementation and usability suggests that
+ attribute and objectclass mapping (sections 5.1.7 and 5.1.13)
+ SHOULD NOT be applied to the filter defined in the
-Joslin [Page 14]
+Neal-Joslin [Page 16]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- filter defined in the serviceSearchDescriptor.
+ serviceSearchDescriptor.
It is assumed the serviceID is unique to a given service
within the scope of any DUA that might use the given profile.
syntax. I.E. not all DUA services should necessarily perform
the same attribute mapping.
- Attribute mapping in general is expected be used to map attri-
- butes of similar syntaxes as specified by the service sup-
- ported by the DUA. However, a DUA is NOT REQUIRED to verify
- syntaxes of mapped attributes. If the DUA does discover that
- the syntax of the mapped attribute does not match that of the
- original attribute, the DUA MAY perform translation between
- the original syntax and the new syntax. When DUAs do support
- attribute value translation, the list of capabable transla-
- tions SHOULD be documented in a description of the DUA ser-
- vice.
+ Attribute mapping in general is expected be used to map
+ attributes of similar syntaxes as specified by the service
+ supported by the DUA. However, a DUA is NOT REQUIRED to
+ verify syntaxes of mapped attributes. If the DUA does
+ discover that the syntax of the mapped attribute does not
+ match that of the original attribute, the DUA MAY perform
+ translation between the original syntax and the new syntax.
+ When DUAs do support attribute value translation, the list of
+ capable translations SHOULD be documented in a description of
+ the DUA service.
Syntax:
-Joslin [Page 15]
+Neal-Joslin [Page 17]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
attributes = wattribute *( space wattribute )
newAttribute = descr | "*NULL*"
attribute = descr
- Values of the origAttribute are defined by and SHOULD be docu-
- mented for the DUA service, as a list of known supported
+ Values of the origAttribute are defined by and SHOULD be
+ documented for the DUA service, as a list of known supported
attributes.
Default Value:
It is assumed the serviceID is unique to a given service
within the scope of the DSA.
- A DUA SHOULD support attribute mapping. If it does, the fol-
- lowing additional rules apply:
+ A DUA SHOULD support attribute mapping. If it does, the
+ following additional rules apply:
1) The list of attributes that are allowed to be mapped SHOULD
defined by and documented for the service.
3) If an attribute may be mapped to multiple attributes the
DSA SHOULD define a syntax or usage statement for how the new
- attribute value will be evaluated. Furthermore, the resulting
- translated syntax of the combined attributes MUST be the same
- as the attribute being mapped.
+ attribute value will be constructed. Furthermore, the
+ resulting translated syntax of the combined attributes MUST be
+ the same as the attribute being mapped.
- 4) A DUA MUST support mapping of attributes using the attri-
- bute OID. It SHOULD support attribute mapping based on the
- attribute name.
+ 4) A DUA MUST support mapping of attributes using the
+ attribute OID. It SHOULD support attribute mapping based on
+ the attribute name.
5) It is recommended that attribute mapping not be applied to
-Joslin [Page 16]
+Neal-Joslin [Page 18]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
parents of the target entries.
6) Attribute mapping is not recursive. In other words, if an
- attribute has been mapped to a target attribute, that new tar-
- get attribute MUST NOT be mapped to a third attribute.
+ attribute has been mapped to a target attribute, that new
+ target attribute MUST NOT be mapped to a third attribute.
- 7) A given attribute MUST only be mapped once for a given ser-
- vice.
+ 7) A given attribute MUST only be mapped once for a given
+ service.
Example:
Suppose a DUA is acting on behalf of an email service. By
default the "email" service uses the "mail", "cn" and "sn"
attributes to discover mail addresses. However, the email
- service has been deployed in an environment that uses "employ-
- eeName" instead of "cn." And also instead of using the "mail"
- attribute for email addresses, the "email" attribute is used
- for that purpose. In this case, the attribute "cn" can be
- mapped to "employeeName," allowing the DUA to perform searches
- using the "employeeName" attribute as part of the search
- filter, instead of "cn". And "mail" can be mapped to "email"
- when attempting to retrieve the email address. This mapping
- is performed by adding the attributeMap attributes to the con-
- figuration profile entry as follows (represented in LDIF[18]):
+ service has been deployed in an environment that uses
+ "employeeName" instead of "cn." And also instead of using the
+ "mail" attribute for email addresses, the "email" attribute is
+ used for that purpose. In this case, the attribute "cn" can
+ be mapped to "employeeName," allowing the DUA to perform
+ searches using the "employeeName" attribute as part of the
+ search filter, instead of "cn". And "mail" can be mapped to
+ "email" when attempting to retrieve the email address. This
+ mapping is performed by adding the attributeMap attributes to
+ the configuration profile entry as follows (represented in
+ LDIF[16]):
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
attributeMap: email:cn=firstName lastName
- In the above example, the DUA creates the new value by gen-
- erating space separated string using the values of the mapped
- attributes. In this case, a special mapping must be defined
- so that a proper search filter can be created. For further
- information on this example, please refer to section 9.
+ In the above example, the DUA creates the new value by
+ generating space separated string using the values of the
+ mapped attributes. In this case, a special mapping must be
+ defined so that a proper search filter can be created. For
+ further information on this example, please refer to section
+ 9.
Another possibility for multiple attribute mapping might come
in when constructing returned attributes. For example,
perhaps all email addresses are of a guaranteed syntax of
"uid@domain". And in this example, the uid and domain are
- separate attributes in the directory. The email service may
- define that if the "mail" attribute is mapped to two different
-Joslin [Page 17]
+Neal-Joslin [Page 19]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- attributes, it will construct the email address as a concate-
- nation of the uid and domain attributes, placing the "@" char-
- acter between them.
+ separate attributes in the directory. The email service may
+ define that if the "mail" attribute is mapped to two different
+ attributes, it will construct the email address as a
+ concatenation of the uid and domain attributes, placing the
+ "@" character between them.
attributeMap: email:mail=uid domain
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. [5]
Default Value:
Default Value:
- If the bindTimeLimit attribute is not defined or is zero, the
- bind time limit is not enforced by the DUA.
-Joslin [Page 18]
+Neal-Joslin [Page 20]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+ If the bindTimeLimit attribute is not defined or is zero, the
+ bind time limit is not enforced by the DUA.
+
Other attribute notes:
This time limit only includes the amount of time required to
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. [5]
Default Value:
Interpretation:
- If set to TRUE, the DUA SHOULD enable alias dereferening.
+ If set to TRUE, the DUA SHOULD enable alias dereferencing.
If set to FALSE, the DUA MUST NOT enable alias dereferencing.
5.1.12 Interpreting the profileTTL attribute
- Interpretation:
-
- The profileTTL attribute defines how often the DUA SHOULD re-
-Joslin [Page 19]
+Neal-Joslin [Page 21]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ Interpretation:
- load and reconfigure itself using the corresponding configura-
- tion profile entry. The value is represented in seconds.
- Once a DUA reloads the profile entry, it SHOULD re-configure
- itself with the new values.
+ The profileTTL attribute defines how often the DUA SHOULD re-
+ load and reconfigure itself using the corresponding
+ configuration profile entry. The value is represented in
+ seconds. Once a DUA reloads the profile entry, it SHOULD re-
+ configure itself with the new values.
Syntax:
Default Value:
- If not specified the DUA MAY use its own reconfiguration pol-
- icy.
+ If not specified the DUA MAY use its own reconfiguration
+ policy.
Other attribute notes:
- If the profileTTL value is zero, the DUA SHOULD NOT automati-
- cally re-load the configuration profile.
+ If the profileTTL value is zero, the DUA SHOULD NOT
+ automatically re-load the configuration profile.
5.1.13 Interpreting the objectclassMap attribute
objectclassMap syntax. I.E. Not all DUA services should
necessarily perform the same objectclass mapping.
- Objectclass mapping SHOULD be used in conjunction with attri-
- bute mapping to map the required schema by the service to an
- equivalent schema that is available in the directory.
-
- Objectclass mapping may or may not be required by a DUA. In
- general, the objectclass attribute is used primarily in search
- filters. If a service search descriptor is provided, it is
- expected that the search filter contains a "correct" search
- filter (though this is not a requirement,) which does not need
- to be re-mapped. However, when the service search descriptor
- is not provided, and the default search filter for that ser-
- vice contains the objectclass attribute, that search filter
- SHOULD be re-defined by objectclass mapping. If a default
- search filter is not used, it SHOULD be re-defined through the
+ Objectclass mapping SHOULD be used in conjunction with
+ attribute mapping to map the required schema by the service to
+ an equivalent schema that is available in the directory.
+
+ Objectclass mapping may or may not be required by a DUA.
+ Often, the objectclass attribute is used in search filters.
+ If a service search descriptor is provided, it is expected
+ that the search filter contains a "correct" search filter
+ (though this is not a requirement,) which does not need to be
+ re-mapped. However, when the service search descriptor is not
+ provided, and the default search filter for that service
+ contains the objectclass attribute, that search filter SHOULD
+ be re-defined by objectclass mapping. If a default search
+ filter is not used, it SHOULD be re-defined through the
serviceSearchDescriptor. If a serviceSearchDescriptor is
- defined for a particular service, it SHOULD NOT be re-mapped
- by either the objectclassMap or attributeMap values.
-
-Joslin [Page 20]
+Neal-Joslin [Page 22]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+ defined for a particular service, it SHOULD NOT be re-mapped
+ by either the objectclassMap or attributeMap values.
+
One condition where the objectclassMap SHOULD be used is when
the DUA is providing gateway functionality. In this case, the
DUA is acting on behalf of another service, which may pass in
a search filter itself. In this type of DUA, the DUA may
- alter the search filter according to the appropriate attribu-
- teMap and objectclassMap values. And in this case, it is also
- assumed that a serviceSearchDescriptor is not defined.
+ alter the search filter according to the appropriate
+ attributeMap and objectclassMap values. And in this case, it
+ is also assumed that a serviceSearchDescriptor is not defined.
Syntax:
origObjectclass = objectclass
objectclass = keystring
- Values of the origObjectclass depend on the type of DUA Ser-
- vice using the objectclass mapping feature.
+ Values of the origObjectclass depend on the type of DUA
+ Service using the objectclass mapping feature.
Default Value:
Suppose a DUA is acting on behalf of an email service. By
default the "email" service uses the "mail", "cn" and "sn"
attributes to discover mail addresses in entries created using
- inetOrgPerson objectclass [16]. However, the email service
- has been deployed in an environment that uses entries created
+ inetOrgPerson objectclass[17]. However, the email service has
+ been deployed in an environment that uses entries created
using "employee" objectclass. In this case, the attribute
"cn" can be mapped to "employeeName", and "inetOrgPerson" can
be mapped to "employee", allowing the DUA to perform LDAP
operations using the entries that exist in the directory.
This mapping is performed by adding attributeMap and
- objectclassMap attributes to the configuration profile entry
- as follows (represented in LDIF[18]):
-
-Joslin [Page 21]
+Neal-Joslin [Page 23]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ objectclassMap attributes to the configuration profile entry
+ as follows (represented in LDIF[16]):
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
Interpretation:
The serviceAuthenticationMethod attribute defines an ordered
- list of LDAP bind methods to be used when attempting to con-
- tact a DSA for a particular service. Interpretation and use
- of this attribute is the same as 5.1.4, but specific for each
- service.
+ list of LDAP bind methods to be used when attempting to
+ contact a DSA for a particular service. Interpretation and
+ use of this attribute is the same as 5.1.4, but specific for
+ each service.
Syntax:
svAuthMethod = service ":" method *(";" method)
- Note: Although multiple authentication methods may be speci-
- fied in the syntax, at most one of each type is allowed.
+ Note: Although multiple authentication methods may be
+ specified in the syntax, at most one of each type is allowed.
Default Value:
If the serviceAuthenticationMethod attribute is not provided,
- the authenticationMethod SHOULD be followed, or its default.
-
- Other attribute notes:
-Joslin [Page 22]
+Neal-Joslin [Page 24]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ the authenticationMethod SHOULD be followed, or its default.
+
+ Other attribute notes:
Determining how the DUA should bind to the DSAs also depends
on the additional configuration attributes, credentialLevel,
- serviceCredentialLevel and bindTimeLimit. Please review sec-
- tion 5.2 for details on how to properly bind to a DSA.
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
Example:
Other attribute notes:
Determining how the DUA should bind to the DSAs also depends
- on the additional configuration attributes, serviceAuthentica-
- tionMethod, authenticationMethod and bindTimeLimit. Please
- review section 5.2 for details on how to properly bind to a
- DSA.
+ on the additional configuration attributes,
+ serviceAuthenticationMethod, authenticationMethod and
+ bindTimeLimit. Please review section 5.2 for details on how
+ to properly bind to a DSA.
Example:
- serviceCredentialLevel: email:proxy anonymous
-
+Neal-Joslin [Page 25]
+\f
+Internet-Draft DUA Configuration Schema March 2005
-Joslin [Page 23]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+ serviceCredentialLevel: email:proxy anonymous
5.2 Binding to the Directory Server
6. Security Considerations
- The profile entries MUST be protected against unauthorized modifi-
- cation. Since the profile is most useful if its content is avail-
- able broadly, it is recommended that the profile entries will be
- readable anonymously. However, ultimately each service needs to
- consider implications of providing its service configuration as
+ The profile entries MUST be protected against unauthorized
+ modification. Each service needs to consider implications of
-Joslin [Page 24]
+Neal-Joslin [Page 26]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ providing its service configuration as part of this profile and
+ limit access to the profile entries accordingly.
- part of this profile and limit access to the profile entries
- accordingly. Additionally, the management of the authentication
- credentials for the DUA is outside the scope of this document and
- needs to be handled by the DUA.
+ The management of the authentication credentials for the DUA is
+ outside the scope of this document and needs to be handled by the
+ DUA.
- The algorithm described by section 5.2 also has security considera-
- tions. Altering that design will alter the security aspectes of
- the configuration profile.
+ Since the DUA needs to know how to properly bind to the directory
+ server, the access control configuration of the DSA MUST assure
+ that the DSA can view all the elements of the DUAConfigProfile
+ attributes. For example, if the credentialLevel attribute contains
+ "Self" but the DSA is unable to access the credentialLevel
+ attribute, the DUA will instead attempt an anonymous connection to
+ the directory server.
+
+ The algorithm described by section 5.2 also has security
+ considerations. Altering that design will alter the security
+ aspects of the configuration profile.
7. Acknowledgments
8. References
-[1]
- M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
- Methods for LDAP", RFC 2828, May 2000
+8.1 Normative References
-[2]
- M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
+
+[4] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+
+[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,
December 1997.
-[3]
- M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+
+[6] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+
+
+
+Neal-Joslin [Page 27]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
-[4]
- T. Howes, "The String Representation of LDAP Search Filters", RFC
- 2254, December 1997.
-[5]
- T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
+[7] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
-[6]
- T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
+[8] R. Hinden, B. Carpenter, L. Masinter, "Uniform Resource Identifier
+ (URI): Generic Syntax", RFC 3986, January 2005.
-Joslin [Page 25]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+[9] M. Wahl, "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
- Locators (URL)", RFC 1738, December 1994.
+[11] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
+ Methods for LDAP", RFC 2828, May 2000
-[7]
- J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
- 2222, October 1997
-[8]
- M. Wahl, "A Summary of the X.500(96) User Schema for use with
- LDAPv3", RFC 2256, December 1997.
+[13] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
+ Protocol [v3]: Extension for Transport Layer Security", RFC 2830,
+ May 2000
+
-[9]
- T. Berners-Lee, R. Fielding, R. Fielding, "Uniform Resource Iden-
- tifiers (URI): Generic Syntax", RFC 2396, August 1998.
+[18] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS",
+ http://www.iana.org/assignments/sasl-mechanisms, April 2004
-[10]
- R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6
- Addresses in URL's, RFC 2732, December 1999.
-[11]
- P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechan-
- ism", RFC 2831, May 2000
+8.2 Informative References
-[12]
- J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto-
- col [v3]: Extension for Transport Layer Security", RFC 2830, May
- 2000
-[13]
- Microsoft Corporation, "Services for Unix 2.0",
- http://www.microsoft.com/WINDOWS2000/sfu/default.asp
+[1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
+ (v3)", RFC 2251, December 1997.
+
-[14]
- L. Howard, "An Approach for Using LDAP as a Network Information
+[2] L. Howard, "An Approach for Using LDAP as a Network Information
Service", RFC 2307, March 1998.
-[15]
- S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
- els", RFC 2119, March 1997.
-[16]
- M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
- 2789, April 2000
+[3] Microsoft Corporation, "Windows Services for Unix 3.5",
+ http://www.microsoft.com/windows/sfu/default.asp
-[17]
- M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
- (v3)", RFC 2251, December 1997.
-[18]
+[12] J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
+ 2222, October 1997
+
+
+[14] P. Leach, C. Newman, "Using Digest Authentication as a SASL
-Joslin [Page 26]
+Neal-Joslin [Page 28]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Mechanism", RFC 2831, May 2000
- G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
+[15] T. Howes, "The String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
+
+
+[16] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000.
+[17] M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
+ 2789, April 2000
+
+
9. Examples
In this section we will describe a fictional DUA which provides one
service, called the "email" service. This service would be similar
to an email client that uses an LDAP directory to discover email
- addresses based on a textual representation of the recipient's col-
- loquial name.
+ addresses based on a textual representation of the recipient's
+ colloquial name.
This email service is defined by default to expect that users with
email addresses will be of the "inetOrgPerson" objectclass type
- [16]. And by default, the "email" service expects the colloquial
+ [17]. And by default, the "email" service expects the colloquial
name to be stored in the "cn" attribute, while it expects the email
address to be stored in the "mail" attribute (as one would expect
as defined by the inetOrgPerson objectclass.)
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
+
+
+
+Neal-Joslin [Page 29]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
The below examples show how the "email" service builds it search
requests, based on the defined profile. In all cases, the
defaultSearchBase is "o=airius.com" and the defaultSearchScope is
undefined.
In addition, for all examples, we assume that the "email" service
- has been requested to discover the email address for "Jane Hernan-
- dez."
+ has been requested to discover the email address for "Jane
+ Hernandez."
Example 1:
-
-
-Joslin [Page 27]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
serviceSearchDescriptor: email:"ou=marketing,"
base: ou=marketing,o=airius.com
serviceSearchDescriptor: email:ou=\mar\\keting,\"?base
attributeMap: email:cn=name
+
+
+Neal-Joslin [Page 30]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
base: ou=\mar\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
This example is invalid, since the quote was not a leading quote,
and thus should have been escaped.
-
-
-
-Joslin [Page 28]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
Example 6:
serviceSearchDescriptor: email:??(&(objectclass=person)
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
-10. Author's Addresses
+Author's Addresses
Luke Howard
PADL Software Pty. Ltd.
EMail: lukeh@padl.com
- Bob Joslin
+ Bob Neal-Joslin
Hewlett-Packard Company
19420 Homestead RD MS43-LF
Cupertino, CA 95014
USA
Phone: +1 408 447-3044
- EMail: bob_joslin@hp.com
-
-
- Morteza Ansari
- Sun Microsystems, Inc.
- 901 San Antonio RD MS MPK17-203
- Palo Alto, CA 94303
- USA
-
- Phone: +1 650 786-6178
- EMail: morteza.ansari@sun.com
-Joslin [Page 29]
+Neal-Joslin [Page 31]
\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
-
-
-
-
-
-
-
+Internet-Draft DUA Configuration Schema March 2005
+ EMail: bob_joslin@hp.com
+ Morteza Ansari
+ Infoblox
+ 475 Potrero Avenue
+ Sunnyvale, CA 94085
+ USA
+ Phone: +1 408-716-4300
+ EMail: morteza@infoblox.com
+ Expires September 2005
-Joslin [Page 30]
+Neal-Joslin [Page 32]
\f
projects / openldap / blobdiff