Request for Comments: 3703 Intelliden Corporation
Category: Standards Track B. Moore
IBM Corporation
R. Moats
Lemur Networks, Inc.
E. Ellesson
February 2004
Policy Core Lightweight Directory Access Protocol (LDAP) Schema
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a mapping of the Policy Core Information Model
to a form that can be implemented in a directory that uses
Lightweight Directory Access Protocol (LDAP) as its access protocol.
This model defines two hierarchies of object classes: structural
classes representing information for representing and controlling
policy data as specified in RFC 3060, and relationship classes that
indicate how instances of the structural classes are related to each
other. Classes are also added to the LDAP schema to improve the
performance of a client’s interactions with an LDAP server when the
client is retrieving large amounts of policy-related information.
These classes exist only to optimize LDAP retrievals: there are no
classes in the information model that correspond to them.
Table of Contents
1. Introduction ................................................. 2
2. The Policy Core Information Model ............................ 4
3. Inheritance Hierarchy for the PCLS ........................... 5
4. General Discussion of Mapping the Information Model to LDAP .. 6
4.1. Summary of Class and Association Mappings .............. 7
4.2. Usage of DIT Content and Structure Rules and Name Forms. 9
4.3. Naming Attributes in the PCLS .......................... 10
4.4. Rule-Specific and Reusable Conditions and Actions ...... 11
4.5. Location and Retrieval of Policy Objects in the
Directory .............................................. 16
4.5.1. Aliases and Other DIT-Optimization Techniques .. 19
5. Class Definitions ............................................ 19
5.1. The Abstract Class "pcimPolicy" ........................ 21
5.2. The Three Policy Group Classes ......................... 22
5.3. The Three Policy Rule Classes .......................... 23
5.4. The Class pcimRuleConditionAssociation ................. 30
5.5. The Class pcimRuleValidityAssociation .................. 32
5.6. The Class pcimRuleActionAssociation .................... 34
5.7. The Auxiliary Class pcimConditionAuxClass .............. 36
5.8. The Auxiliary Class pcimTPCAuxClass .................... 36
5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40
5.10. The Auxiliary Class pcimActionAuxClass ................. 41
5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
5.12. The Class pcimPolicyInstance ........................... 43
5.13. The Auxiliary Class pcimElementAuxClass ................ 44
5.14. The Three Policy Repository Classes .................... 45
5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
6. Extending the Classes Defined in This Document ............... 50
6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
6.2. Using the Vendor Policy Attributes ..................... 50
6.3. Using Time Validity Periods ............................ 51
7. Security Considerations ...................................... 51
8. IANA Considerations .......................................... 53
8.1. Object Identifiers ..................................... 53
8.2. Object Identifier Descriptors .......................... 53
9. Acknowledgments .............................................. 56
10. Appendix: Constructing the Value of orderedCIMKeys .......... 57
11. References ................................................... 58
11.1. Normative References ................................... 58
11.2. Informative References ................................. 59
12. Authors’ Addresses ........................................... 60
13. Full Copyright Statement ..................................... 61
1. Introduction
This document takes as its starting point the object-oriented
information model for representing information for representing and
controlling policy data as specified in [1]. Lightweight Directory
Access Protocol (LDAP) [2] implementers, please note that the use of
the term "policy" in this document does not refer to the use of the
term "policy" as defined in X.501 [4]. Rather, the use of the term
"policy" throughout this document is defined as follows:
Policy is defined as a set of rules to administer, manage, and
control access to network resources.
This work is currently under joint development in the IETF’s Policy
Framework working group and in the Policy working group of the
Distributed Management Task Force (DMTF). This model defines two
hierarchies of object classes: structural classes representing policy
information and control of policies, and relationship classes that
indicate how instances of the structural classes are related to each
other. In general, both of these class hierarchies will need to be
mapped to a particular data store.
This document defines the mapping of these information model classes
to a directory that uses LDAP as its access protocol. Two types of
mappings are involved:
- For the structural classes in the information model, the
mapping is basically one-for-one: information model classes map
to LDAP classes, information model properties map to LDAP
attributes.
- For the relationship classes in the information model,
different mappings are possible. In this document, the Policy
Core Information Model’s (PCIM’s) relationship classes and
their properties are mapped in three ways: to LDAP auxiliary
classes, to attributes representing distinguished name (DN)
references, and to superior-subordinate relationships in the
Directory Information Tree (DIT).
Implementations that use an LDAP directory as their policy repository
and want to implement policy information according to RFC 3060 [1]
SHALL use the LDAP schema defined in this document, or a schema that
subclasses from the schema defined in this document. The use of the
information model defined in reference [1] as the starting point
enables the inheritance and the relationship class hierarchies to be
extensible, such that other types of policy repositories, such as
relational databases, can also use this information.
This document fits into the overall framework for representing,
deploying, and managing policies being developed by the Policy
Framework Working Group.
The LDAP schema described in this document uses the prefix "pcim" to
identify its classes and attributes. It consists of ten very general
classes: pcimPolicy (an abstract class), three policy group classes
(pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy
rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and
three special auxiliary classes (pcimConditionAuxClass,
pcimTPCAuxClass, and pcimActionAuxClass). (Note that the
PolicyTimePeriodCondition auxiliary class defined in [1] would
normally have been named pcimTimePeriodConditionAuxClass, but this
name is too long for some directories. Therefore, we have
abbreviated this name to be pcimTPCAuxClass).
The mapping for the PCIM classes pcimGroup and pcimRule is designed
to be as flexible as possible. Three classes are defined for these
two PCIM classes. First, an abstract superclass is defined that
contains all required properties of each PCIM class. Then, both an
auxiliary class as well as a structural class are derived from the
abstract superclass. This provides maximum flexibility for the
developer.
The schema also contains two less general classes:
pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve
the mapping of the information model’s relationships, the schema also
contains two auxiliary classes: pcimGroupContainmentAuxClass and
pcimRuleContainmentAuxClass. Capturing the distinction between
rule-specific and reusable policy conditions and policy actions
introduces seven other classes: pcimRuleConditionAssociation,
pcimRuleValidityAssociation, pcimRuleActionAssociation,
pcimPolicyInstance, and three policy repository classes
(pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance).
Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and
pcimElementAuxClass) for optimizing LDAP retrievals. In all, the
schema contains 23 classes.
Within the context of this document, the term "PCLS" (Policy Core
LDAP Schema) is used to refer to the LDAP class definitions that this
document contains. The term "PCIM" refers to classes defined in [1].
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 [10].
2. The Policy Core Information Model
This document contains an LDAP schema representing the classes
defined in the companion document "Policy Core Information
Model -- Version 1 Specification" [1]. Other documents may
subsequently be produced, with mappings of this same PCIM to other
storage technologies. Since the detailed semantics of the PCIM
classes appear only in [1], that document is a prerequisite for
reading and understanding this document.
3. Inheritance Hierarchy for the PCLS
The following diagram illustrates the class hierarchy for the LDAP
Classes defined in this document:
top
|
+--dlm1ManagedElement (abstract)
| |
| +--pcimPolicy (abstract)
| | |
| | +--pcimGroup (abstract)
| | | |
| | | +--pcimGroupAuxClass (auxiliary)
| | | |
| | | +--pcimGroupInstance (structural)
| | |
| | +--pcimRule (abstract)
| | | |
| | | +--pcimRuleAuxClass (auxiliary)
| | | |
| | | +--pcimRuleInstance (structural)
| | |
| | +--pcimRuleConditionAssociation (structural)
| | |
| | +--pcimRuleValidityAssociation (structural)
| | |
| | +--pcimRuleActionAssociation (structural)
| | |
| | +--pcimPolicyInstance (structural)
| | |
| | +--pcimElementAuxClass (auxiliary)
| |
| +--dlm1ManagedSystemElement (abstract)
| |
| +--dlm1LogicalElement (abstract)
| |
| +--dlm1System (abstract)
| |
| +--dlm1AdminDomain (abstract)
| |
| +--pcimRepository (abstract)
| |
| +--pcimRepositoryAuxClass (auxiliary)
top
| |
| +--pcimRepositoryInstance
| (structural)
|
+--pcimConditionAuxClass (auxiliary)
| |
| +---pcimTPCAuxClass (auxiliary)
| |
| +---pcimConditionVendorAuxClass (auxiliary)
|
+--pcimActionAuxClass (auxiliary)
| |
| +---pcimActionVendorAuxClass (auxiliary)
|
+--pcimSubtreesPtrAuxClass (auxiliary)
|
+--pcimGroupContainmentAuxClass (auxiliary)
|
+--pcimRuleContainmentAuxClass (auxiliary)
Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
4. General Discussion of Mapping the Information Model to LDAP
The classes described in Section 5 below contain certain
optimizations for a directory that uses LDAP as its access protocol.
One example of this is the use of auxiliary classes to represent some
of the associations defined in the information model. Other data
stores might need to implement these associations differently. A
second example is the introduction of classes specifically designed
to optimize retrieval of large amounts of policy-related data from a
directory. This section discusses some general topics related to the
mapping from the information model to LDAP.
The remainder of this section will discuss the following topics.
Section 4.1 will discuss the strategy used in mapping the classes and
associations defined in [1] to a form that can be represented in a
directory that uses LDAP as its access protocol. Section 4.2
discusses DIT content and structure rules, as well as name forms.
Section 4.3 describes the strategy used in defining naming attributes
for the schema described in Section 5 of this document. Section 4.4
defines the strategy recommended for locating and retrieving
PCIM-derived objects in the directory.
4.1. Summary of Class and Association Mappings
Fifteen of the classes in the PCLS come directly from the nine
corresponding classes in the information model. Note that names of
classes begin with an upper case character in the information model
(although for CIM in particular, case is not significant in class and
property names), but with a lower case character in LDAP. This is
because although LDAP doesn’t care, X.500 doesn’t allow class names
to begin with an uppercase character. Note also that the prefix
"pcim" is used to identify these LDAP classes.
+---------------------------+-------------------------------+
| Information Model | LDAP Class(es) |
+---------------------------+-------------------------------+
+---------------------------+-------------------------------+
| Policy | pcimPolicy |
+---------------------------+-------------------------------+
| PolicyGroup | pcimGroup |
| | pcimGroupAuxClass |
| | pcimGroupInstance |
+---------------------------+-------------------------------+
| PolicyRule | pcimRule |
| | pcimRuleAuxClass |
| | pcimRuleInstance |
+---------------------------+-------------------------------+
| PolicyCondition | pcimConditionAuxClass |
+---------------------------+-------------------------------+
| PolicyAction | pcimActionAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyCondition | pcimConditionVendorAuxClass |
+---------------------------+-------------------------------+
| VendorPolicyAction | pcimActionVendorAuxClass |
+---------------------------+-------------------------------+
| PolicyTimePeriodCondition | pcimTPCAuxClass |
+---------------------------+-------------------------------+
| PolicyRepository | pcimRepository |
| | pcimRepositoryAuxClass |
| | pcimRepositoryInstance |
+---------------------------+-------------------------------+
Figure 2. Mapping of Information Model Classes to LDAP
The associations in the information model map to attributes that
reference DNs (Distinguished Names) or to Directory Information Tree
(DIT) containment (i.e., superior-subordinate relationships) in LDAP.
Two of the attributes that reference DNs appear in auxiliary classes,
which allow each of them to represent several relationships from the
information model.
+----------------------------------+----------------------------------+
| Information Model Association | LDAP Attribute / Class |
+-----------------------------------+---------------------------------+
+-----------------------------------+---------------------------------+
| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in |
| | pcimGroupContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in |
| | pcimRuleContainmentAuxClass |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRule | DIT containment or |
| | pcimRuleConditionList in |
| | pcimRule or |
| | pcimConditionDN in |
| | pcimRuleConditionAssociation |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRule | DIT containment or |
| | pcimRuleActionList in |
| | pcimRule or |
| | pcimActionDN in |
| | pcimRuleActionAssociation |
+-----------------------------------+---------------------------------+
| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList |
| | in pcimRule or (if reusable) |
| | referenced through the |
| | pcimTimePeriodConditionDN in |
| | pcimRuleValidityAssociation |
+-----------------------------------+---------------------------------+
| PolicyConditionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyActionInPolicyRepository | DIT containment |
+-----------------------------------+---------------------------------+
| PolicyRepositoryInPolicyRepository| DIT containment |
+-----------------------------------+---------------------------------+
Figure 3. Mapping of Information Model Associations to LDAP
Of the remaining classes in the PCLS, two (pcimElementAuxClass and
pcimSubtreesPtrAuxClass) are included to make navigation through the
DIT and retrieval of the entries found there more efficient. This
topic is discussed below in Section 4.5.
The remaining four classes in the PCLS, pcimRuleConditionAssociation,
pcimRuleValidityAssociation, pcimRuleActionAssociation, and
pcimPolicyInstance, are all involved with the representation of
policy conditions and policy actions in an LDAP directory. This
topic is discussed below in Section 4.4.
4.2. Usage of DIT Content and Structure Rules and Name Forms
There are three powerful tools that can be used to help define
schemata. The first, DIT content rules, is a way of defining the
content of an entry for a structural object class. It can be used to
specify the following characteristics of the entry:
- additional mandatory attributes that the entries are required
to contain
- additional optional attributes the entries are allowed to
contain
- the set of additional auxiliary object classes that these
entries are allowed to be members of
- any optional attributes from the structural and auxiliary
object class definitions that the entries are required to
preclude
DIT content rules are NOT mandatory for any structural object class.
A DIT structure rule, together with a name form, controls the
placement and naming of an entry within the scope of a subschema.
Name forms define which attribute type(s) are required and are
allowed to be used in forming the Relative Distinguished Names (RDNs)
of entries. DIT structure rules specify which entries are allowed to
be superior to other entries, and hence control the way that RDNs are
added together to make DNs.
A name form specifies the following:
- the structural object class of the entries named by this name