form
- attributes that are required to be used in forming the RDNs of
these entries
- attributes that are allowed to be used in forming the RDNs of
these entries
- an object identifier to uniquely identify this name form
Note that name forms can only be specified for structural object
classes. However, every entry in the DIT must have a name form
controlling it.
Unfortunately, current LDAP servers vary quite a lot in their support
of these features. There are also three crucial implementation
points that must be followed. First, X.500 use of structure rules
requires that a structural object class with no superior structure
rule be a subschema administrative point. This is exactly NOT what
we want for policy information. Second, when an auxiliary class is
subclassed, if a content rule exists for the structural class that
the auxiliary class refers to, then that content rule needs to be
augmented. Finally, most LDAP servers unfortunately do not support
inheritance of structure and content rules.
Given these concerns, DIT structure and content rules have been
removed from the PCLS. This is because, if included, they would be
normative references and would require OIDs. However, we don’t want
to lose the insight gained in building the structure and content
rules of the previous version of the schema. Therefore, we describe
where such rules could be used in this schema, what they would
control, and what their effect would be.
4.3. Naming Attributes in the PCLS
Instances in a directory are identified by distinguished names (DNs),
which provide the same type of hierarchical organization that a file
system provides in a computer system. A distinguished name is a
sequence of RDNs. An RDN provides a unique identifier for an
instance within the context of its immediate superior, in the same
way that a filename provides a unique identifier for a file within
the context of the folder in which it resides.
To preserve maximum naming flexibility for policy administrators,
three optional (i.e., "MAY") naming attributes have been defined.
They are:
- Each of the structural classes defined in this schema has its
own unique ("MAY") naming attribute. Since the naming
attributes are different, a policy administrator can, by using
these attributes, guarantee that there will be no name
collisions between instances of different classes, even if the
same value is assigned to the instances’ respective naming
attributes.
- The LDAP attribute cn (corresponding to X.500’s commonName) is
included as a MAY attribute in the abstract class pcimPolicy,
and thus by inheritance in all of its subclasses. In X.500,
commonName typically functions as an RDN attribute, for naming
instances of many classes (e.g., X.500’s person class).
- A special attribute is provided for implementations that expect
to map between native CIM and LDAP representations of policy
information. This attribute, called orderedCimKeys, is defined
in the class dlm1ManagedElement [6]. The value of this
attribute is derived algorithmically from values that are
already present in a CIM policy instance. The normative
reference for this algorithm is contained in [6]. See the
appendix of this document for a description of the algorithm.
Since any of these naming attributes MAY be used for naming an
instance of a PCLS class, implementations MUST be able to accommodate
instances named in any of these ways.
Note that it is recommended that two or more of these attributes
SHOULD NOT be used together to form a multi-part RDN, since support
for multi-part RDNs is limited among existing directory
implementations.
4.4. Rule-Specific and Reusable Conditions and Actions
The PCIM [1] distinguishes between two types of policy conditions and
policy actions: those associated with a single policy rule, and
those that are reusable, in the sense that they may be associated
with more than one policy rule. While there is no inherent
functional difference between a rule-specific condition or action and
a reusable one, there is both a usage, as well as, an implementation
difference between them.
Defining a condition or action as reusable vs. rule-specific reflects
a conscious decision on the part of the administrator in defining how
they are used. In addition, there are variations that reflect
implementing rule-specific vs. reusable policy conditions and actions
and how they are treated in a policy repository. The major
implementation differences between a rule-specific and a reusable
condition or action are delineated below:
1. It is natural for a rule-specific condition or action to be
removed from the policy repository at the same time the rule is.
It is just the opposite for reusable conditions and actions.
This is because the condition or action is conceptually attached
to the rule in the rule-specific case, whereas it is referenced
(e.g., pointed at) in the reusable case. The persistence of a
pcimRepository instance is independent of the persistence of a
pcimRule instance.
2. Access permissions for a rule-specific condition or action are
usually identical to those for the rule itself. On the other
hand, access permissions of reusable conditions and actions must
be expressible without reference to a policy rule.
3. Rule-specific conditions and actions require fewer accesses,
because the conditions and actions are "attached" to the rule.
In contrast, reusable conditions and actions require more
accesses, because each condition or action that is reusable
requires a separate access.
4. Rule-specific conditions and actions are designed for use by a
single rule. As the number of rules that use the same
rule-specific condition increase, subtle problems are created
(the most obvious being how to keep the rule-specific conditions
and actions updated to reflect the same value). Reusable
conditions and actions lend themselves for use by multiple
independent rules.
5. Reusable conditions and actions offer an optimization when
multiple rules are using the same condition or action. This is
because the reusable condition or action only needs be updated
once, and by virtue of DN reference, the policy rules will be
automatically updated.
The preceding paragraph does not contain an exhaustive list of the
ways in which reusable and rule-specific conditions should be treated
differently. Its purpose is merely to justify making a semantic
distinction between rule-specific and reusable, and then reflecting
this distinction in the policy repository itself.
When the policy repository is realized in an LDAP-accessible
directory, the distinction between rule-specific and reusable
conditions and actions is realized via placement of auxiliary classes
and via DIT containment. Figure 4 illustrates a policy rule Rule1
with one rule-specific condition CA and one rule-specific action AB.
+-----+
|Rule1|
| |
+-----|- -|-----+
| +-----+ |
| * * |
| * * |
| **** **** |
| * * |
v * * v
+--------+ +--------+
| CA+ca | | AB+ab |
+--------+ +--------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
Figure 4 Rule-Specific Policy Conditions and Actions
Because the condition and action are specific to Rule1, the auxiliary
classes ca and ab that represent them are attached, respectively, to
the structural classes CA and AB. These structural classes represent
not the condition ca and action ab themselves, but rather the
associations between Rule1 and ca, and between Rule1 and ab.
As Figure 4 illustrates, Rule1 contains DN references to the
structural classes CA and AB that appear below it in the DIT. At
first glance it might appear that these DN references are
unnecessary, since a subtree search below Rule1 would find all of the
structural classes representing the associations between Rule1 and
its conditions and actions. Relying only on a subtree search,
though, runs the risk of missing conditions or actions that should
have appeared in the subtree, but for some reason did not, or of
finding conditions or actions that were inadvertently placed in the
subtree, or that should have been removed from the subtree, but for
some reason were not. Implementation experience has suggested that
many (but not all) of these risks are eliminated.
However, it must be noted that this comes at a price. The use of DN
references, as shown in Figure 4 above, thwarts inheritance of access
control information as well as existence dependency information. It
also is subject to referential integrity considerations. Therefore,
it is being included as an option for the designer.
Figure 5 illustrates a second way of representing rule-specific
conditions and actions in an LDAP-accessible directory: attachment of
the auxiliary classes directly to the instance representing the
policy rule. When all of the conditions and actions are attached to
a policy rule in this way, the rule is termed a "simple" policy rule.
When conditions and actions are not attached directly to a policy
rule, the rule is termed a "complex" policy rule.
+-----------+
|Rule1+ca+ab|
| |
+-----------+
+------------------------------+
|LEGEND: |
| + auxiliary attachment |
+------------------------------+
Figure 5. A Simple Policy Rule
The simple/complex distinction for a policy rule is not all or
nothing. A policy rule may have its conditions attached to itself
and its actions attached to other entries, or it may have its actions
attached to itself and its conditions attached to other entries.
However, it SHALL NOT have either its conditions or its actions
attached both to itself and to other entries, with one exception: a
policy rule may reference its validity periods with the
pcimRuleValidityPeriodList attribute, but have its other conditions
attached to itself.
The tradeoffs between simple and complex policy rules are between the
efficiency of simple rules and the flexibility and greater potential
for reuse of complex rules. With a simple policy rule, the semantic
options are limited:
- All conditions are ANDed together. This combination can be
represented in two ways in the Disjunctive Normal Form (DNF)/
Conjunctive Normal Form (CNF) (please see [1] for definitions of
these terms) expressions characteristic of policy conditions: as
a DNF expression with a single AND group, or as a CNF expression
with multiple single-condition OR groups. The first of these is
arbitrarily chosen as the representation for the ANDed conditions
in a simple policy rule.
- If multiple actions are included, no order can be specified for
them.
If a policy administrator needs to combine conditions in some other
way, or if there is a set of actions that must be ordered, then the
only option is to use a complex policy rule.
Finally, Figure 6 illustrates the same policy rule Rule1, but this
time its condition and action are reusable. The association classes
CA and AB are still present, and they are still DIT contained under
Rule1. But rather than having the auxiliary classes ca and ab
attached directly to the association classes CA and AB, each now
contains DN references to other entries to which these auxiliary
classes are attached. These other entries, CIA and AIB, are DIT
contained under RepositoryX, which is an instance of the class
pcimRepository. Because they are named under an instance of
pcimRepository, ca and ab are clearly identified as reusable.
+-----+ +-------------+
|Rule1| | RepositoryX |
+-|- -|--+ | |
| +-----+ | +-------------+
| * * | * *
| * * | * *
| *** **** | * *
| * * v * *
| * +---+ * *
| * |AB | +------+ *
v * | -|-------->|AIB+ab| *
+---+ +---+ +------+ *
|CA | +------+
| -|------------------------>|CIA+ca|
+---+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
Figure 6. Reusable Policy Conditions and Actions
The classes pcimConditionAuxClass and pcimActionAuxClass do not
themselves represent actual conditions and actions: these are
introduced in their subclasses. What pcimConditionAuxClass and
pcimActionAuxClass do introduce are the semantics of being a policy
condition or a policy action. These are the semantics that all the
subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit.
Among these semantics are those of representing either a
rule-specific or a reusable policy condition or policy action.
In order to preserve the ability to represent a rule-specific or a
reusable condition or action, as well as a simple policy rule, all
the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST
also be auxiliary classes.
4.5. Location and Retrieval of Policy Objects in the Directory
When a Policy Decision Point (PDP) goes to an LDAP directory to
retrieve the policy object instances relevant to the Policy
Enforcement Points (PEPs) it serves, it is faced with two related
problems:
- How does it locate and retrieve the directory entries that apply
to its PEPs? These entries may include instances of the PCLS
classes, instances of domain-specific subclasses of these
classes, and instances of other classes modeling such resources
as user groups, interfaces, and address ranges.
- How does it retrieve the directory entries it needs in an
efficient manner, so that retrieval of policy information from
the directory does not become a roadblock to scalability? There
are two facets to this efficiency: retrieving only the relevant
directory entries, and retrieving these entries using as few LDAP
calls as possible.
The placement of objects in the Directory Information Tree (DIT)
involves considerations other than how the policy-related objects
will be retrieved by a PDP. Consequently, all that the PCLS can do
is to provide a "toolkit" of classes to assist the policy
administrator as the DIT is being designed and built. A PDP SHOULD
be able to take advantage of any tools that the policy administrator
is able to build into the DIT, but it MUST be able to use a less
efficient means of retrieval if that is all it has available to it.
The basic idea behind the LDAP optimization classes is a simple one:
make it possible for a PDP to retrieve all the policy-related objects
it needs, and only those objects, using as few LDAP calls as
possible. An important assumption underlying this approach is that
the policy administrator has sufficient control over the underlying
DIT structure to define subtrees for storing policy information. If
the policy administrator does not have this level of control over DIT
structure, a PDP can still retrieve the policy-related objects it
needs individually. But it will require more LDAP access operations
to do the retrieval in this way. Figure 7 illustrates how LDAP
optimization is accomplished.
+-----+
---------------->| A |
DN reference to | | DN references to subtrees +---+
starting object +-----+ +-------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / ... \
Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies
The PDP is configured initially with a DN reference to some entry in
the DIT. The structural class of this entry is not important; the
PDP is interested only in the pcimSubtreesPtrAuxClass attached to it.
This auxiliary class contains a multi-valued attribute with DN
references to objects that anchor subtrees containing policy-related
objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an
auxiliary class, it can be attached to an entry that the PDP would
need to access anyway - perhaps an entry containing initial
configuration settings for the PDP, or for a PEP that uses the PDP.
Once it has retrieved the DN references, the PDP will direct to each
of the objects identified by them an LDAP request that all entries in
its subtree be evaluated against the selection criteria specified in
the request. The LDAP-enabled directory then returns all entries in
that subtree that satisfy the specified criteria.
The selection criteria always specify that object class="pcimPolicy".
Since all classes representing policy rules, policy conditions, and
policy actions, both in the PCLS and in any domain-specific schema
derived from it, are subclasses of the abstract class policy, this
criterion evaluates to TRUE for all instances of these classes. To
accommodate special cases where a PDP needs to retrieve objects that
are not inherently policy-related (for example, an IP address range
object referenced by a subclass of pcimActionAuxClass representing
the DHCP action "assign from this address range"), the auxiliary
class pcimElementAuxClass can be used to "tag" an entry, so that it
will be found by the selection criterion "object class=pcimPolicy".
The approach described in the preceding paragraph will not work for
certain directory implementations, because these implementations do
not support matching of auxiliary classes in the objectClass
attribute. For environments where these implementations are expected
to be present, the "tagging" of entries as relevant to policy can be
accomplished by inserting the special value "POLICY" into the list of
values contained in the pcimKeywords attribute (provided by the
pcimPolicy class).
If a PDP needs only a subset of the policy-related objects in the
indicated subtrees, then it can be configured with additional
selection criteria based on the pcimKeywords attribute defined in the
pcimPolicy class. This attribute supports both standardized and
administrator- defined values. For example, a PDP could be
configured to request only those policy-related objects containing
the keywords "DHCP" and "Eastern US".
To optimize what is expected to be a typical case, the initial
request from the client includes not only the object to which its
"seed" DN references, but also the subtree contained under this
object. The filter for searching this subtree is whatever the client
is going to use later to search the other subtrees: object
class="pcimPolicy" or the presence of the keyword "POLICY", and/or
presence of a more specific value of pcimKeywords (e.g., "QoS Edge
Policy").
Returning to the example in Figure 7, we see that in the best case, a
PDP can get all the policy-related objects it needs, and only those
objects, with exactly three LDAP requests: one to its starting
object A to get the references to B and C, as well as the
policy-related objects it needs from the subtree under A, and then
one each to B and C to get all the policy-related objects that pass