| *** **** | * *
| * * v * *
| * +---+ * *
| * |SA2| +-------+ *
v * | -|-------->|S1+Set2| *
+---+ +---+ +-------+ *
|SA1| +-------+
| -|------------------------------>|S2+Set3|
+---+ +-------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
Set#: pcelsRuleAuxClass or pcelsGroupAuxClass auxiliary class.
SA#: PolicySetAssocation structural class.
S#: structural class.
Figure 5. Policy Set with Reusable Components
The nesting pcelsPolicySet refers to instances of
pcelsPolicySetAssociation using the attribute pcelsPolicySetList.
These structural association classes are subordinated (DIT contained)
to an instance of a non-abstract subclass of pcelsPolicySet and
represent the association between the PolicySet and its nested
rules/groups. The reusable rules/groups are instantiated here as
auxiliary classes and attached to pcimPolicyInstance entries in the
reusable container. Another option is to use the structural
subclasses for defining reusable rules/groups. The association
classes belonging to a nesting policy set are reference the reusable
rules/groups using the attribute pcelsPolicySetDN.
A combination of both specific and reusable components is also
allowed for the same policy set.
4.8. The Aggregation of Actions/Conditions in PolicyRules and
CompoundActions/CompoundConditions
[PCIM_EXT] defines two new classes that allow the designer to create
more complex conditions and actions. CompoundPolicyCondition and
CompoundPolicyAction classes are mapped in this document to
pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass
classes that are subclasses of
pcimConditionAuxClass/pcimActionAuxClass. The compound
conditions/actions defined in [PCIM_EXT] extend the capability of the
rule to associate, group and evaluate conditions or execute actions.
The conditions/actions are associated to compounds conditions/actions
in the same way as they are associated to the rules.
In this section, how to store instances of these classes in an LDAP
Directory is explained. As a general rule, specific
conditions/actions are subordinated (DIT contained) to the rule or
compound condition/action that aggregates them and are attached to
association class instances. Reusable conditions/actions are
subordinated to pcelsReusableContainer instances and attached to
pcimPolicyInstance instances.
The examples below illustrate the four possible cases combining
specific/reusable compound/non-compound condition/action. The rule
has two compound conditions, each one has two different conditions.
The schemes can be extended in order to store actions.
The examples below are based on and extend those illustrated in the
section 4.4 of [PCLS].
First case: Specific compound condition/action with specific
conditions/actions.
+--------------+
+------| Rule |------+
| +--------------+ |
| * * |
| ********* ********* |
v * * v
+---------+ +---------+
+-| CA1+cc1 |-+ +-| CA2+cc2 |-+
| +---------+ | | +---------+ |
| * * | | * * |
| **** **** | | **** **** |
v * * v v * * v
+------+ +------+ +------+ +------+
|CA3+c1| |CA4+c2| |CA5+c3| |CA6+c4|
+------+ +------+ +------+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
#: Number.
CA#: pcelsConditionAssociation structural class.
cc#: pcelsCompoundConditionAuxClass auxiliary class.
c#: subclass of pcimConditionAuxClass.
Figure 6. Specific Compound Conditions with Specific Components
Because the compound conditions/actions are specific to the Rule,
They are auxiliary attachments to instances of the structural classes
pcelsConditionAssociation or pcelsActionAssociation. These
structural classes represent the association between the rule and the
compound condition/action. The rule specific conditions/actions are
therefore subordinated (DIT contained) to the rule entry.
The conditions/actions are tied to the compound conditions/actions in
the same way the compound conditions/actions are tied to rules.
Association classes realize the association between the aggregating
compound conditions/actions and the specific conditions/actions.
Second case: Rule specific compound conditions/actions with
reusable conditions/actions.
+-------------+ +---------------+
+------| Rule |-----+ | ContainerX |
| +-------------+ | +---------------+
| * * | * * * *
| * * | **** * * *
| ********* ******** | * * * ********
| * * v * * * *
| * +---------+ * * **** *
| * +-| CA2+cc2 |-+ * * * *
| * | +---------+ | * * * *
v * | * * | * * * *
+---------+ | **** **** | * * * *
+-| CA1+cc1 |-+ | * * v * * * *
| +---------+ | | * +------+ +-----+ * * *
| * * | v * | CA6 |->|S1+c4| * * *
| **** **** | +------+ +------+ +-----+ +-----+ * *
| * * v | CA5 |------------------>|S2+c3| * *
| * +------+ +------+ +-----+ +-----+ *
v * | CA4 |------------------------------------->|S3+c2| *
+------+ +------+ +-----+ +-----+
| CA3 |------------------------------------------------------>|S4+c1|
+------+ +-----+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
#: Number.
CA#: pcelsConditionAssociation structural class.
cc#: pcelsCompoundConditionAuxClass auxiliary class.
c#: subclass of pcimConditionAuxClass.
S#: structural class
Figure 7. Specific Compound Conditions with Reusable Components
This case is similar to the first one. The conditions/actions are
reusable and are therefore not attached to the association classes,
but rather to structural classes in the reusable container. The
association classes tie the conditions/actions in located in a
reusable container to their aggregators using DN references.
Third case: Reusable compound condition/action with specific
conditions/actions.
+--------------+ +--------------+
| Rule | | RepositoryX |
+---+--------------+----+ +--------------+
| * * | * *
| ******* ******* | ******** ********
| * * v * *
| * +----------+ +---------+ *
| * | CA2 |--->| S1+cc2 | *
| * +----------+ +-+---------+-+ *
| * | * * | *
| * | **** **** | *
| * v * * v *
| * +------+ +------+ *
| * |CA5+c3| |CA6+c4| *
v * +------+ +------+ *
+----------+ +---------+
| CA1 |----------------------------------------->| S2+cc1 |
+----------+ +-+---------+-+
| * * |
| **** **** |
v * * v
+------+ +------+
|CA3+c1| |CA4+c2|
+------+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
#: Number.
CA#: pcelsConditionAssociation structural class.
cc#: pcelsCompoundConditionAuxClass auxiliary class.
c#: subclass of pcimConditionAuxClass.
S#: structural class
Figure 8. Reusable Compound Conditions with Specific Components
Re-usable compound conditions/actions are attached to structural
classes and stored in a reusable policy container. They are related
to the rule through a DN reference attribute in the association
classes.
Specific conditions/actions are attached to association entries and
subordinated (DIT contained) to the aggregating compound
conditions/actions.
Fourth case: Reusable conditions/actions and compound
conditions/actions.
+------+ +---------------+ +---------------+
+-----| Rule |-----+ | ContainerX | | ContainerY |
| +------+ | +---------------+ +---------------+
| * * | * * * * * *
| ****** ****** | *** *** *** * * *****
| * * v * * * * * *
| * +-------+ +------+ * * * *** *
| * | CA2 |->|S1+ca1| * * * * *
| * +-------+ +------+ * * * * *
| * / * * \ * * * * *
| * |** ** | * * * * *
| * |* * v * * * * *
| * |* +---+ * +-----+ * * *
| * |* |CA6|----*--->|S3+c4| * * *
| * v* +---+ * +-----+ * * *
| * +---+ * +-----+ * *
| * |CA5|-----------*--------->|S4+c3| * *
v * +---+ * +-----+ * *
+-------+ +------+ * *
| CA1 |-------------------------->|S2+cc1| * *
+-------+ +------+ * *
/ * * \ * *
| ** ** | * *
| * * v * *
| * +---+ +-----+ *
| * |CA4|---------->|S5+c2| *
v * +---+ +-----+ *
+---+ +-----+
|CA3|--------------------->|S6+c1|
+---+ +-----+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN reference |
+------------------------------+
#: Number.
CA#: pcelsConditionAssociation structural class.
cc#: pcelsCompoundConditionAuxClass auxiliary class.
c#: subclass of pcimConditionAuxClass.
S#: structural class
Figure 9. Reusable Compound Conditions with Reusable Components
All the conditions/actions are reusable so they are stored in
reusable containers. The figure above illustrates two different
reusable policy containers, but the number of containers in the
system is decided based on administrative reasons. The conditions,
actions, etc. may be stored in the same or different containers with
no impact on the policy definition semantics.
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 [PCIM_EXT]. Consequently, this document presents
only a brief reference to those semantics. The focus here is on the
mapping from the information model (which is independent of
repository type and access protocol) to a form that can be accessed
using LDAP. For various reasons including LDAP specific
optimization, this mapping is not always 1:1. Some new classes and
attributes (that were not part of [PCIM] or [PCIM_EXT]) needed to be
created in order to implement the LDAP mapping. These new LDAP-only
classes are fully defined in this document.
The following notes apply to this section in its entirety.
Note 1: The formal language for specifying the classes, attributes,
and DIT structure and content rules is that defined in [LDAP_SYNTAX].
In the following definitions, the class and attribute definitions
follow [LDAP_SYNTAX] but they are line-wrapped to enhance human
readability.
Note 2: Even though not explicitly noted in the following class and
attribute definitions, implementations may define DIT structure and
content rules where applicable and supported by the underlying LDAP
infrastructure. In such cases, the DIT structure rule considerations
discussed in section 5 of [PCLS] must be applied to PCELS
implementations as well. The reasons and details are presented in
[X.501].
Note 3: Wherever possible, an equality, a substrings and an ordering
matching rule are defined for a particular attribute. This provides
additional implementation flexibility. However, in some cases, the
LDAP matching semantics may not cover all the application needs. For
instance, different values of pcelsIPv4AddrList may be semantically
equivalent. The equality matching rule, caseIgnoreMatch, associated
to this attribute type is not suitable for detecting this
equivalence. Implementers should not rely solely on LDAP syntaxes
and matching rules for being consistent with this specification.
Note 4: The following attribute definitions use only LDAP matching
rules and syntax definitions from [LDAP_SYNTAX], [LDAP_SCHEMA] and
[LDAP_MATCH]. The corresponding X.500 matching rules are defined in
[X.520].
Note 5: Some of the following attribute types MUST conform to
additional constraints on various data types (e.g., the only valid
values for pcelsDecisionStrategy are 1 and 2). Just like the
attribute semantics, the definition of the value structures, valid
ranges, etc. is covered by [PCIM_EXT] for the corresponding
properties while such constraints are only briefly mentioned in this
document. In all cases, if a constraint is violated, the entry
SHOULD be treated as invalid and the policy rules or groups that
refer to it SHOULD be treated as being disabled, meaning that the
execution of such policy rules or groups SHOULD be stopped.
Note 6: Some of the object classes defined in this section cannot or
should not be directly instantiated because they are either defined
as abstract or do not implement stand-alone semantics (e.g.,
pcelsValueAuxClass). Regarding instances of objects that inherit
from such classes, the text refers to "instances of <class_name>"