the selection criteria with which it was configured. Once it has
retrieved all of these objects, the PDP can then traverse their
various DN references locally to understand the semantic
relationships among them. The PDP should also be prepared to find a
reference to another subtree attached to any of the objects it
retrieves, and to follow this reference first, before it follows any
of the semantically significant references it has received. This
recursion permits a structured approach to identifying related
policies. In Figure 7, for example, if the subtree under B includes
departmental policies and the one under C includes divisional
policies, then there might be a reference from the subtree under C to
an object D that roots the subtree of corporate-level policies.
A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be
capable of retrieving and processing the entries in the subtrees it
references, and SHOULD be capable of doing all of this recursively.
The same requirements apply to any other entity needing to retrieve
policy information from the directory. Thus, a Policy Management
Tool that retrieves policy entries from the directory in order to
perform validation and conflict detection SHOULD also understand and
be capable of using the pcimSubtreesPtrAuxClass. All of these
requirements are "SHOULD"s rather than "MUST"s because an LDAP client
that doesn’t implement them can still access and retrieve the
directory entries it needs. The process of doing so will just be
less efficient than it would have been if the client had implemented
these optimizations.
When it is serving as a tool for creating policy entries in the
directory, a Policy Management Tool SHOULD support creation of
pcimSubtreesPtrAuxClass entries and their references to object
instances.
4.5.1. Aliases and Other DIT-Optimization Techniques
Additional flexibility in DIT structure is available to the policy
administrator via LDAP aliasing and other techniques. Previous
versions of this document have used aliases. However, because
aliases are experimental, the use of aliases has been removed from
this version of this document. This is because the IETF has yet to
produce a specification on how aliases are represented in the
directory or how server implementations are to process aliases.
5. Class Definitions
The semantics for the policy information classes that are to be
mapped directly from the information model to an LDAP representation
are detailed in [1]. Consequently, all that this document presents
for these classes is the specification for how to do the mapping from
the information model (which is independent of repository type and
access protocol) to a form that can be accessed using LDAP. Remember
that some new classes needed to be created (that were not part of
[1]) to implement the LDAP mapping. These new LDAP-only classes are
fully documented in this document.
The formal language for specifying the classes, attributes, and DIT
structure and content rules is that defined in reference [3]. If
your implementation does not support auxiliary class inheritance, you
will have to list auxiliary classes in content rules explicitly or
define them in another (implementation-specific) way.
The following notes apply to this section in its entirety.
Note 1: in the following definitions, the class and attribute
definitions follow RFC 2252 [3] but they are line-wrapped to enhance
human readability.
Note 2: where applicable, the possibilities for specifying DIT
structure and content rules are noted. However, care must be taken
in specifying DIT structure rules. This is because X.501 [4] states
that an entry may only exist in the DIT as a subordinate to another
superior entry (the superior) if a DIT structure rule exists in the
governing subschema which:
1) indicates a name form for the structural object class of the
subordinate entry, and
2) either includes the entry’s superior structure rule as a possible
superior structure rule, or
3) does not specify a superior structure rule.
If this last case (3) applies, then the entry is defined to be a
subschema administrative point. This is not what is desired.
Therefore, care must be taken in defining structure rules, and in
particular, they must be locally augmented.
Note 3: Wherever possible, both an equality and a substring matching
rule are defined for a particular attribute (as well as an ordering
match rule to enable sorting of matching results). This provides two
different choices for the developer for maximum flexibility.
For example, consider the pcimRoles attribute (section 5.3). Suppose
that a PEP has reported that it is interested in pcimRules for three
roles R1, R2, and R3. If the goal is to minimize queries, then the
PDP can supply three substring filters containing the three role
names.
These queries will return all of the pcimRules that apply to the PEP,
but they may also get some that do not apply (e.g., ones that contain
one of the roles R1, R2, or R3 and one or more other roles present in
a role-combination [1]).
Another strategy would be for the PDP to use only equality filters.
This approach eliminates the extraneous replies, but it requires the
PDP to explicitly build the desired role-combinations itself. It
also requires extra queries. Note that this approach is practical
only because the role names in a role combination are required to
appear in alphabetical order.
Note 4: in the following definitions, note that all LDAP matching
rules are defined in [3] and in [9]. The corresponding X.500
matching rules are defined in [8].
Note 5: some of the following attribute definitions specify
additional constraints on various data types (e.g., this integer has
values that are valid from 1..10). Text has been added to instruct
servers and applications what to do if a value outside of this range
is encountered. In all cases, if a constraint is violated, then the
policy rule SHOULD be treated as being disabled, meaning that
execution of the policy rule SHOULD be stopped.
5.1. The Abstract Class pcimPolicy
The abstract class pcimPolicy is a direct mapping of the abstract
class Policy from the PCIM. The class value "pcimPolicy" is also
used as the mechanism for identifying policy-related instances in the
Directory Information Tree. An instance of any class may be "tagged"
with this class value by attaching to it the auxiliary class
pcimElementAuxClass. Since pcimPolicy is derived from the class
dlm1ManagedElement defined in reference [6], this specification has a
normative dependency on that element of reference [6].
The class definition is as follows:
( 1.3.6.1.1.6.1.1 NAME ’pcimPolicy’
DESC ’An abstract class that is the base class for all classes
that describe policy-related instances.’
SUP dlm1ManagedElement
ABSTRACT
MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
pcimKeywords )
)
The attribute cn is defined in RFC 2256 [7]. The dlmCaption,
dlmDescription, and orderedCimKeys attributes are defined in [6].
The pcimKeywords attribute is a multi-valued attribute that contains
a set of keywords to assist directory clients in locating the policy
objects identified by these keywords. It is defined as follows:
( 1.3.6.1.1.6.2.3 NAME ’pcimKeywords’
DESC ’A set of keywords to assist directory clients in
locating the policy objects applicable to them.’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
5.2. The Three Policy Group Classes
PCIM [1] defines the PolicyGroup class to serve as a generalized
aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be
aggregated together. PCLS maps this class into three LDAP classes,
called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is
done in order to provide maximum flexibility for the DIT designer.
The class definitions for the three policy group classes are listed
below. These class definitions do not include attributes to realize
the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations
from the PCIM. This is because a pcimGroup object refers to
instances of pcimGroup and pcimRule via, respectively, the attribute
pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object
class and the attribute pcimRulesAuxContainedSet in the
pcimRuleContainmentAuxClass object class.
To maximize flexibility, the pcimGroup class is defined as abstract.
The subclass pcimGroupAuxClass provides for auxiliary attachment to
another entry, while the structural subclass pcimGroupInstance is
available to represent a policy group as a standalone entry.
The class definitions are as follows. First, the definition of the
abstract class pcimGroup:
( 1.3.6.1.1.6.1.2 NAME ’pcimGroup’
DESC ’A container for a set of related pcimRules and/or
a set of related pcimGroups.’
SUP pcimPolicy
ABSTRACT
MAY ( pcimGroupName )
)
The one attribute of pcimGroup is pcimGroupName. This attribute is
used to define a user-friendly name of this policy group, and may be
used as a naming attribute if desired. It is defined as follows:
( 1.3.6.1.1.6.2.4 NAME ’pcimGroupName’
DESC ’The user-friendly name of this policy group.’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
The two subclasses of pcimGroup are defined as follows. The class
pcimGroupAuxClass is an auxiliary class that can be used to collect a
set of related pcimRule and/or pcimGroup classes. It is defined as
follows:
( 1.3.6.1.1.6.1.3 NAME ’pcimGroupAuxClass’
DESC ’An auxiliary class that collects a set of related
pcimRule and/or pcimGroup entries.’
SUP pcimGroup
AUXILIARY
)
The class pcimGroupInstance is a structural class that can be used to
collect a set of related pcimRule and/or pcimGroup classes. It is
defined as follows:
( 1.3.6.1.1.6.1.4 NAME ’pcimGroupInstance’
DESC ’A structural class that collects a set of related
pcimRule and/or pcimGroup entries.’
SUP pcimGroup
STRUCTURAL
)
A DIT content rule could be written to enable an instance of
pcimGroupInstance to have attached to it either references to one or
more policy groups (using pcimGroupContainmentAuxClass) or references
to one or more policy rules (using pcimRuleContainmentAuxClass).
This would be used to formalize the semantics of the PolicyGroup
class [1]. Since these semantics do not include specifying any
properties of the PolicyGroup class, the content rule would not need
to specify any attributes.
Similarly, three separate DIT structure rules could be written, each
of which would refer to a specific name form that identified one of
the three possible naming attributes (i.e., pcimGroupName, cn, and
orderedCIMKeys) for the pcimGroup object class. This structure rule
SHOULD include a superiorStructureRule (see Note 2 at the beginning
of section 5). The three name forms referenced by the three
structure rules would each define one of the three naming attributes.
5.3. The Three Policy Rule Classes
The information model defines a PolicyRule class to represent the "If
Condition then Action" semantics associated with processing policy
information. For maximum flexibility, the PCLS maps this class into
three LDAP classes.
To maximize flexibility, the pcimRule class is defined as abstract.
The subclass pcimRuleAuxClass provides for auxiliary attachment to
another entry, while the structural subclass pcimRuleInstance is
available to represent a policy rule as a standalone entry.
The conditions and actions associated with a policy rule are modeled,
respectively, with auxiliary subclasses of the auxiliary classes
pcimConditionAuxClass and pcimActionAuxClass. Each of these
auxiliary subclasses is attached to an instance of one of three
structural classes. A subclass of pcimConditionAuxClass is attached
to an instance of pcimRuleInstance, to an instance of
pcimRuleConditionAssociation, or to an instance of
pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is
attached to an instance of pcimRuleInstance, to an instance of
pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.
The pcimRuleValidityPeriodList attribute (defined below) realizes the
PolicyRuleValidityPeriod association defined in the PCIM. Since this
association has no additional properties besides those that tie the
association to its associated objects, this association can be
realized by simply using an attribute. Thus, the
pcimRuleValidityPeriodList attribute is simply a multi-valued
attribute that provides an unordered set of DN references to one or
more instances of the pcimTPCAuxClass, indicating when the policy
rule is scheduled to be active and when it is scheduled to be
inactive. A policy rule is scheduled to be active if it is active
according to AT LEAST ONE of the pcimTPCAuxClass instances referenced
by this attribute.
The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
associations, however, do have additional attributes. The
association PolicyActionInPolicyRule defines an integer attribute to
sequence the actions, and the association PolicyConditionInPolicyRule
has both an integer attribute to group the condition terms as well as
a Boolean property to specify whether a condition is to be negated.
In the PCLS, these additional association attributes are represented
as attributes of two classes introduced specifically to model these
associations. These classes are the pcimRuleConditionAssociation
class and the pcimRuleActionAssociation class, which are defined in
Sections 5.4 and 5.5, respectively. Thus, they do not appear as
attributes of the class pcimRule. Instead, the pcimRuleConditionList
and pcimRuleActionList attributes can be used to reference these
classes.
The class definitions for the three pcimRule classes are as follows.
The abstract class pcimRule is a base class for representing the "If
Condition then Action" semantics associated with a policy rule. It
is defined as follows:
( 1.3.6.1.1.6.1.5 NAME ’pcimRule’
DESC ’The base class for representing the "If Condition
then Action" semantics associated with a policy rule.’
SUP pcimPolicy
ABSTRACT
MAY ( pcimRuleName $ pcimRuleEnabled $
pcimRuleConditionListType $ pcimRuleConditionList $
pcimRuleActionList $ pcimRuleValidityPeriodList $
pcimRuleUsage $ pcimRulePriority $
pcimRuleMandatory $ pcimRuleSequencedActions $
pcimRoles )
)
The PCIM [1] defines seven properties for the PolicyRule class. The
PCLS defines eleven attributes for the pcimRule class, which is the
LDAP equivalent of the PolicyRule class. Of these eleven attributes,
seven are mapped directly from corresponding properties in PCIM’s
PolicyRule class. The remaining four attributes are a class-specific
optional naming attribute, and three attributes used to realize the
three associations that the pcimRule class participates in.
The pcimRuleName attribute is used as a user-friendly name of this
policy rule, and can also serve as the class-specific optional naming
attribute. It is defined as follows:
( 1.3.6.1.1.6.2.5 NAME ’pcimRuleName’
DESC ’The user-friendly name of this policy rule.’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
The pcimRuleEnabled attribute is an integer enumeration indicating
whether a policy rule is administratively enabled (value=1),
administratively disabled (value=2), or enabled for debug (value=3).
It is defined as follows:
( 1.3.6.1.1.6.2.6 NAME ’pcimRuleEnabled’
DESC ’An integer indicating whether a policy rule is
administratively enabled (value=1), disabled
(value=2), or enabled for debug (value=3).’
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
Note: All other values for the pcimRuleEnabled attribute are
considered errors, and the administrator SHOULD treat this rule as
being disabled if an invalid value is found.
The pcimRuleConditionListType attribute is used to indicate whether
the list of policy conditions associated with this policy rule is in
disjunctive normal form (DNF, value=1) or conjunctive normal form
(CNF, value=2). It is defined as follows:
( 1.3.6.1.1.6.2.7 NAME ’pcimRuleConditionListType’
DESC ’A value of 1 means that this policy rule is in
disjunctive normal form; a value of 2 means that this
policy rule is in conjunctive normal form.’
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
Note: any value other than 1 or 2 for the pcimRuleConditionListType
attribute is considered an error. Administrators SHOULD treat this
rule as being disabled if an invalid value is found, since it is
unclear how to structure the condition list.
The pcimRuleConditionList attribute is a multi-valued attribute that
is used to realize the policyRuleInPolicyCondition association
defined in [1]. It contains a set of DNs of
pcimRuleConditionAssociation entries representing associations
between this policy rule and its conditions. No order is implied.
It is defined as follows:
( 1.3.6.1.1.6.2.8 NAME ’pcimRuleConditionList’
DESC ’Unordered set of DNs of pcimRuleConditionAssociation
entries representing associations between this policy
rule and its conditions.’
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
The pcimRuleActionList attribute is a multi-valued attribute that is
used to realize the policyRuleInPolicyAction association defined in
[1]. It contains a set of DNs of pcimRuleActionAssociation entries
representing associations between this policy rule and its actions.
No order is implied. It is defined as follows:
( 1.3.6.1.1.6.2.9 NAME ’pcimRuleActionList’
DESC ’Unordered set of DNs of pcimRuleActionAssociation
entries representing associations between this policy
rule and its actions.’
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
The pcimRuleValidityPeriodList attribute is a multi-valued attribute
that is used to realize the pcimRuleValidityPeriod association that
is defined in [1]. It contains a set of DNs of
pcimRuleValidityAssociation entries that determine when the pcimRule
is scheduled to be active or inactive. No order is implied. It is
defined as follows:
( 1.3.6.1.1.6.2.10 NAME ’pcimRuleValidityPeriodList’
DESC ’Unordered set of DNs of pcimRuleValidityAssociation
entries that determine when the pcimRule is scheduled
to be active or inactive.’
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
The pcimRuleUsage attribute is a free-form string providing
guidelines on how this policy should be used. It is defined as
follows:
( 1.3.6.1.1.6.2.11 NAME ’pcimRuleUsage’
DESC ’This attribute is a free-form sting providing
guidelines on how this policy should be used.’
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
The pcimRulePriority attribute is a non-negative integer that is used
to prioritize this pcimRule relative to other pcimRules. A larger
value indicates a higher priority. It is defined as follows:
( 1.3.6.1.1.6.2.12 NAME ’pcimRulePriority’
DESC ’A non-negative integer for prioritizing this
pcimRule relative to other pcimRules. A larger
value indicates a higher priority.’
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
Note: if the value of the pcimRulePriority field is 0, then it SHOULD
be treated as "don’t care". On the other hand, if the value is
negative, then it SHOULD be treated as an error and Administrators
SHOULD treat this rule as being disabled.
The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE,
indicates that for this policy rule, the evaluation of its conditions
and execution of its actions (if the condition is satisfied) is
required. If it is FALSE, then the evaluation of its conditions and
execution of its actions (if the condition is satisfied) is not
required. This attribute is defined as follows:
( 1.3.6.1.1.6.2.13 NAME ’pcimRuleMandatory’
DESC ’If TRUE, indicates that for this policy rule, the
evaluation of its conditions and execution of its
actions (if the condition is satisfied) is required.’
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
The pcimRuleSequencedActions attribute is an integer enumeration that
is used to indicate that the ordering of actions defined by the
pcimActionOrder attribute is either mandatory(value=1),
recommended(value=2), or dontCare(value=3). It is defined as
follows:
( 1.3.6.1.1.6.2.14 NAME ’pcimRuleSequencedActions’
DESC ’An integer enumeration indicating that the ordering of
actions defined by the pcimActionOrder attribute is
mandatory(1), recommended(2), or dontCare(3).’
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE