Architectural Pattern - Policy
This is the second in an architectural pattern set. The first (Information Models) can be found here.
Intent
Provide a controlled environment in which decisions can be made and enforced.
Problem
Whilst it is obviously possible to make and enforce any arbitrary decision in any arbitrary programming language it is difficult to control, manage, deploy, modify, inspect and verify those policies.
The policy pattern provides a way of adding those characteristics to the basic requirement of decision and enforcement.
A policy is defined as a condition-action tuple. Various taxonomies have been proposed that refine and formalize this concept. For example by adding policy composition, policy inheritance and categorization. However the end the result of such operations is still identifiable as a policy.
One useful distinction that can be made, however, is between authorization policies and obligation policies: The only action that an authorization policy can perform is to render a decision, whereas an obligation policy can perform an arbitrary action.
Policy models tend to focus on one of several aspects of policies – none of which is actually unique to policies. Namely:
- Definition
- Distribution
- Execution
Policy definition models define an information model for policies: They define the structure of a policy – including the participants and the composition mechanisms -and rules for how policies are evaluated.
Policy distribution models focus on defining transport mechanisms and semantics for policies.
Policy execution models define how decisions are rendered, communicated and enforced.
Typically an information model includes the following items:
| Event | Something that causes a policy to be evaluated. |
| Resource | An entity that is the target of the policy |
| Operation | The operation that is being performed on the target |
| Subject | The entity that wishes to perform the operation on the target |
| Condition | An arbitrary condition. |
| Action | An action to perform depending on what the policy evaluates to. |
| Decision | One of allowed/disallowed/unknown |
These items are explicitly identified only because they occur frequently in situations where policy is used and explicitly identifying them allows an actual implementation to be optimized. As a result most of these items are optional, most may be multi-valued so as to reduce the number of discrete policies that may be required in any given situation and Condition provides a mechanism to include an arbitrary number of other items in the decision making process.
Policy execution models typically define the some or all of the following actors:
| PDP | Policy Decision Point. The entity that evaluates a policy. |
| PEP | Policy Enforcement Point. The entity that enforces the policy decision or performs the obligation. |
| PIP | Policy Information Point. The entity that provides persistence services for the policies. |
| PAP | Policy Administration Point. The entity that provides management of the policies. |
In addition collections of such entities could be said to exist in a peering relationship.
A policy execution framework should provide a level of de-coupling between the users of the framework and the implementation of the various actors by defining a common and extensible interface that can be implemented in a variety of ways. The following design patterns are useful in this regard:
- Façade
- Decorator
- Factory
Policy distribution models generally work in one of two ways:
- Requesting policy evaluation remotely using a policy decision request (PDR) protocol (e.g. COPS)
- Provisioning protocols to PDPs using a provisioning protocol (e.g. COPS-PR)
Known Uses
