Policy frameworks 30 

This sections briefly reviews four important policy-based management frameworks: Ponder, Rei, KaoS, and XACML. Important aspects of the Rei, Ponder, and KaoS policy models and the XACML policy management architecture are highlighted.

2.3.2.1 Ponder

Ponder is a policy management framework consisting of the Ponder specification language, a general architecture, a policy deployment model, and extensions for QoS and access control management. The Ponder language is declarative, object-oriented, and allows specifying security and management policies for distributed object systems [32]. It supports specifying authorisation, delegation, information filtering, refrain policies, and obligation policies; and also supports the concept of domains for the grouping and partitioning of objects. In addition,

Policy Management Tool Policy Decision Point Policy Enforcement Point Policy Repository Admin Policy Management Tool Policy Decision Point Policy Enforcement Point Policy Repository Admin Monitoring Module

31

Ponder supports specifying meta-policies, or i.e. policies about policies. Meta-policies allow specifying management policies that scope other policies.

2.3.2.2 Rei

Rei [33] is a policy management framework developed by Hewlett Packard (HP). It is aimed at providing domain-independent policy specification. The policy language uses constructs based on deontic concepts. These constructs allow the domain-independent specification of rights, prohibition, obligations and dispensation policies, and the flexibility to easily add domain-dependent information without additional modifications. The Rei framework is ontology-based and incorporates a reasoner based on the F-OWL inference engine [34]. Ontology subclasses can be created and added to the existing hierarchical structure of Rei classes. Additionally, Rei supports meta-policies to describe the default behaviour of policies and constraints between meta-policies, e.g. precedence rules.

2.3.2.3 KaoS

KaoS provides an ontology-based language [35, 36]. In KaoS, system concepts are defined in ontologies and KaoS policies are expressed using the Web Ontology Language (OWL). This enables runtime extensibility, adaptability of the system, and policy analysis relating to entities at different levels of abstraction. KaoS supports 4 types of policies, each associated to an ontology class: positive authorisations, negative authorisations, positive obligations, and negative obligations; also new policy types can be created by defining new ontology classes. KaoS provides domain services for the hierarchical grouping and management of entities. Policies can be associated to and grouped by management properties such as e.g. priority.

32

Each of the above frameworks provides its own policy language and covers several general PBM aspects, as shown in Figure 5, that include policy specification, analysis and enforcement; language’s semantics and extensibility; domains for structuring and grouping, distributed policy enforcement, and meta-policies to ease management. The following subsection describes the XACML framework.

2.3.2.4 Extensible Access Control Markup Language (XACML)

The eXtensible Access Control Markup Language or XACML 3.0 [16] is a XML-based declarative access control policy language that provides interoperability for decentralised cross-domain policies. In addition to the language, XACML defines both an architecture for policy evaluation and a message exchange communication protocol. The primary architectural components are: the Policy Enforcement Point (PEP) that performs access control, makes decision requests and enforces authorisation decisions; the Policy Decision Point (PDP) that evaluates applicable policies and makes an authorisation decision; the Policy Administration Point (PAP) that creates/writes policies or policy sets; the Policy Information Point (PIP) that acts as a source of attribute values; and the context handler that translates decision requests and authorisation decisions into the XACML canonical format and into the native response format, respectively. The data-flow model is shown in Figure 6 and operates as follows:

- The requester makes an access request to the policy enforcement point (PEP) component (step 2), which enforces decisions made by the policy decision point (PDP).

- The PEP sends the request to the context handler component (step 3), whose function is to convert the request into a canonical format and passes it to the PDP (step 4).

- The PDP obtains from the policy administration point (PAP) component the applicable policy/policies. The PAP writes policies and makes them available to the PDP (step 1)

- The PDP requests any additional attributes required for policy evaluation from the context handler (step 5), which in turn requests the attributes from the policy information point (PIP) (step 6). The PIP obtains the requested (resource/environment/subjects) attributes (steps 7a, 7b, and 7c), and then sends them to the context handler (step 8).

- Optionally, the resource is included in the context (step 9). The context handler sends the attributes to the PDP (step 10).

- The PDP evaluates the policies against the attributes and sends a response context with the authorisation decision to the context handler (step 11), which in turn converts the response context into the native format of the PEP and send it to the PEP (optionally) including some obligations (step 12).

33

- The PEP fulfils the obligations (13) and then grants/ denies access to the resource.

Figure 6 XACML Data-flow diagram

Ponder, Rei, KaoS, and XACML are representative frameworks in the area of PBM. However, research in PBM encompasses more than the aspects covered by the abovementioned frameworks. Looking into the lifecycle of management policies provides a broader view of what PBM entails.

2.3.2.5 Management policies lifecycle

In [38], the authors present a methodology for the management of management policies. They propose a policy lifecycle model that aligns with software engineering concepts – see Figure 7. It consists of several phases that include: system requirement analysis to support systematic policy definition and the identification of constraints; policy definition and specification at a high-level of abstraction written in natural language; policy refinement to transform high-level policies into low-level enforceable policies; policy analysis covering syntactic and semantic validation, conflict detection and resolution, and completeness and feasibility validation; policy distribution and enforcement; and policy monitoring and maintenance covering logging, policy violations checking, auditing, and policy recovery.

34

Figure 7 depicts the relationships that exist among the different phases above mentioned in terms of process flows, data flows, and reverse flows.

Figure 7 A Policy lifecycle model[38]

This research focuses primarily (in varying levels of detail) on the operational aspects (rather than semantics and syntax) of policy definition and specification, policy refinement, policy enforcement, and policy monitoring (in Chapter 4) phases; and proposes a method for policy transformation for adaptation.