New Developments in Ontology-Based Policy Management:
Increasing the Practicality and Comprehensiveness of KAoS
Andrzej Uszok, Jeffrey M. Bradshaw, James Lott, Maggie Breedy, Larry Bunch,
Paul Feltovich, Matthew Johnson, and Hyuckchul Jung
Florida Institute for Human and Machine Cognition (IHMC), 40 S. Alcaniz, Pensacola, FL 32502
{auszok, jbradshaw, jlott, mbreedy, lbunch, pfeltovich, mjohnson, hjung}@ihmc.us
Abstract
The KAoS policy management framework pioneered the
use of semantically-rich ontological representation and
reasoning to specify, analyze, deconflict, and enforce
policies [9, 10]. The framework has continued to evolve
over the last five years, inspired by both technological
advances and the practical needs of its varied
applications. In this paper, we describe how these
applications have motivated the partitioning of
components into a well-defined three-layer policy
management architecture that hides ontology complexity
from the human user and from the policy-governed
system. The power of semantic reasoning is embedded in
the middle layer of the architecture where it can provide
the most benefit. We also describe how the policy
semantics of the core KAoS Policy Ontology has grown in
its comprehensiveness. The flexible and mature
architecture of KAoS enables straightforward integration
with a variety of deployment platforms, ranging from
highly distributed systems, such as the AFRL Information
Management System, to human-robotic interaction, to
dynamic management of quality-of-service and cross-
domain information management of wireless networks in
resource-constrained or security-sensitive environments.
Keywords: policy, ontology, OWL, KAoS, policy
management
1. Introduction
Over the past five years, the use of W3C’s Web Ontology
Language (OWL) has expanded from its primary use in
representing Semantic Web content and services to
important roles in a variety of additional applications.
Given the trend toward increasing complexity and
dynamics in applications requiring policy services, and
the high desirability of open and extensible standards for
distributed systems, OWL occupies an attractive niche for
policy representation.
The flexibility and power of a policy management
framework is to a large degree determined by the
expressivity of its policy representation, provided it is
also computationally efficient. In our experience, OWL
has not only proven to be remarkably expressive and
efficient but is also straightforwardly extensible and
adaptable, even at runtime when sophisticated real-time
management and analysis of new or existing policies may
be required [8, 10]. As an additional benefit, ontologies
provide a natural means for supporting alternate sets of
policy vocabulary for different applications.
Despite these advantages, our reliance on OWL for
policy representation has provided its share of challenges.
For example, thinking about policies in terms of
sophisticated ontologies and reasoning mechanisms can
be a daunting task for new users. Among the important
things we have learned is that a general purpose
ontology-based policy framework such as KAoS needs to
make the sophistication, flexibility, and power of
ontological representation and reasoning available to
people in a simple and understandable manner. In
response to this requirement, we have developed a three-
layer policy management architecture that ensures
consistency among these separate but interdependent
components. Experience in a wide variety of applications
and settings has helped us smooth many of the initial
rough edges of the approach.
In this article, we describe many of the interesting
new features of KAoS, including: details of the three-
layer architecture, the hypertext policy editor and policy
wizard, support for representing and reasoning about
history, state, and spatial properties as they relate to
policy, support for logical policy precedence, network-
efficient policy distribution methods, a revamped Guard
architecture, and additional mechanisms to support
obligation policies.
2. Related Work
Ponder was the forerunner of modern policy languages
and management systems, and significant work continues
on its development ([1], www.ponder2.net). Recent years
have witnessed the development of additional
approaches—some based on XML (e.g., XACML [7])
and others, like KAoS, based on Semantic Web
representations (e.g., Rei [4], PolicyTab [6]). There have
also been attempts to recode XML-based policies into
ontology-based policy representations [5]. Languages
tailored for specific applications have also appeared (e.g.,
CoRaL [3] for radio spectrum control).
We believe that the increasingly demanding
requirements of new applications (see e.g., [2]) will be
difficult to meet without the advantages afforded by
semantically-rich representations such as OWL, coupled
with practical, usable, and efficient policy management
systems that can make use of them. While special-
purpose languages for narrow application deployment
may sometimes outperform more general approaches in
their particular niche, policy is being increasingly used in
ways that cut across traditional domains (as described in
section 8 and [2, 11]), making a more comprehensive
approach to policy management extremely desirable.
3. KAoS Overview
The KAoS policy services framework [9, 10] has been
adapted to run on a variety of agent, robotic, Web
services, Grid computing (e.g., Globus), and traditional
distributed computing platforms, and across a variety of
industrial, military, and space applications [11]. In
addition to services directly related to policy
management, KAoS also provides the basic services for
distributed computing, including message transport and
directory services. Because the services are accessed
through a well-defined Common Services Interface (CSI),
application developers can use whatever subset of its
capabilities (e.g., registration, transport, publish-
subscribe, domain management, remote request
forwarding, queries) are appropriate for a given situation.
3.1. Three-Layered Architecture
Two important requirements for the KAoS architecture
are modularity and extensibility. These requirements are
supported through a framework with well-defined
interfaces that can be extended, if necessary, with the
components required to support application-specific
policies. The basic elements of the KAoS architecture are
shown in Figure 1; its three layers of functionality
correspond to three different policy representations:
• Human interface layer: This layer uses a hypertext-
like graphical interface for policy specification in the
form of natural English sentences. The vocabulary is
automatically provided from the relevant ontologies,
consisting of highly-reusable core concepts
augmented by application-specific ones.
• Policy Management layer: Within this layer, OWL
(http://www.w3.org/TR/owl-features) is used to
encode and manage policy-related information. The
Distributed Directory Service (DDS) encapsulates a
set of OWL reasoning mechanisms.
• Policy Monitoring and Enforcement layer: KAoS
automatically “compiles” OWL policies to an
efficient format that can be used for monitoring and
enforcement. This representation provides the
grounding for abstract ontology terms, connecting
them to the instances in the runtime environment and
to other policy-related information.
Figure 1: KAoS Policy Services Architecture
Maintaining consistency among these layers is handled
automatically by KAoS, a task made more challenging
because each layer implements its functionality in a
distributed rather than a centralized manner. The three
layers are described in more detail in sections 5, 6, and 7.
Within each of the layers, the end user may plug-in
specialized extension components if needed, as described
in more detail throughout the paper. Such components are
typically developed as Java classes and described using
ontology concepts in the configuration file. They can then
be used by KAoS in policy specification, reasoning and
enforcement processes.
Figure 1 shows one of many ways in which KAoS
may be deployed. Developers can pick and choose
whatever elements of KAoS they deem useful for a given
application. For instance, some applications may only
require a single guard while others may use several
distributed guards. Some applications may not use guards
at all, in this case using KAoS only as a policy
specification and management tool.
3.2. Ontologies in KAoS Policy Definition
The KAoS core policy ontology consists of a set of
independent OWL files (available at:
http://ontology.ihmc.us/ontology.html). They define the
root concepts for policy-governed actions, actors, places,
states, history, situations, environmental properties
related to actions (e.g., computing or network resources),
groups (e.g., domains, roles, teams), and so forth. In
addition, the ontology contains the concepts needed to
define the policies themselves. There are currently more
than 100 classes and properties defined in this basic
ontology.
Application developers normally extend the core
ontology with additional application-specific classes,
properties, and individuals that can be used as vocabulary
in policy definitions. Such ontologies define concepts that
will enable information sharing between KAoS and the
application itself. For example, in an application of KAoS
to dynamic configuration of military radios, the
application required runtime information about
transmission parameters from the ontology. Using KAoS,
policy developers are not only able to refer to application-
specific concepts but also to link these concepts with
more abstract ones in the core ontology.
The following types of ontologies are typically
createdby application developers as extensions to the
KAoS core ontology:
• ApplicationAction.owl – defines application action
classes and their properties. New Action classes must
be subclassed from the core class
http://ontology.ihmc.us/Action.owl#Action. Examples
of application-specific action classes might include
radio transmission actions, actions describing the
movement of robots, or actions relating to the issuance
of weather reports.
• ApplicationActor.owl - defines application actor classes
(or roles) and their properties. New Actor classes must
be subclassed from
http://ontology.ihmc.us/Actor.owl#Actor. Examples of
application-specific actor classes might include radio
operator, quadripedal robot, or producer of news report.
• ApplicationEntity.owl – defines application specific
entities and their properties. These are used to define
contexts for application actions. New Entity classes
must be subclassed from
http://ontology.ihmc.us/Entity.owl#Entity. Examples of
application-specific entity classes might include
transmission area, weather, or wind.
It is also possible to link application-defined
concepts to any number of pre-existing ontologies. By
subclassing new concepts as appropriate subclasses to
existing concepts in the KAoS core ontology, the new
concepts can be used in policy vocabulary, reasoning, and
enforcement. New ontologies (and related policies) can
be defined, imported, or modified at runtime as needed.
3.3. Grounding Ontologies in the World
Ontology-based policy services dynamically define
mappings between class definitions and entities in the
controlled environment and in the world. This can be
accomplished in several ways.
First, static elements of the environment may be
defined as individuals in application-specific ontologies.
For instance, we might describe specific instances of
robots, a range of existing radio spectrums, or a set of
producers of weather reports for a given area. In addition,
dynamic elements of the environment may be registered
within KAoS through the Guard interface, or information
about them can be provided to a guard at policy
enforcement time. For instance, at runtime, new areas of
robot operation can be defined, new weather reports can
be produced, new radios can be introduced, and new
domains, roles, or teams can be formed or removed.
Extension components added to KAoS can be used to
collect the history of actions, sense the state of the
environment, or access external databases to provide
information needed for policy enforcement.
4. KAoS Policy Semantics
4.1. The Basic Form of KAoS Policies
Like Ponder and Rei, KAoS supports two main types of
policy: authorization and obligation [8]. The set of
permitted actions is determined by authorization policies
that specify which actions an actor or set of actors is
allowed (positive authorization policies) or not allowed
(negative authorization policies) to perform in a given
context. Obligation policies specify actions that an actor
or set of actors is required to perform (positive
obligations) or for which such a requirement is waived
(negative obligations). All other kinds of policies (e.g.,
delegation, teamwork coordination) are built from these
two primitive types, combined with other aspects of
KAoS policy semantics (e.g., domains, history, state).
The basic form of KAoS policies is as follows:
[Actor] is [constrained] to perform [controlled
action] which has [any attributes]
[Actor] is a variable that refers to the subject of the
policy-controlled action. Any of the following can be
defined as actors:
• A single actor instance (e.g. Robot32);
• An actor class or a role (as in role-based access
control) using an actor class name (e.g. members of
class Robot, Weather Producer, Team A; all Robots
within 50 feet of my current location);
• The complement of some instance or set of instances
(e.g. any Robot except Robot324);
• The complement of actor class or set of classes (e.g.
any Robot that is not Pioneer).
[constrained] is a variable that refers to the basic
type of the policy (i.e., positive or negative authorization,
positive or negative obligation).
[controlled action] is a variable that refers to the
action class that will be controlled by the policy (e.g.
Radio Transmission, Movement).
[any attributes] is an optional variable referring to
one or more attributes of the controlled action. For
example, a Radio Transmission action may have
attributes defining configuration parameters, the
destination of the transmission, and so forth. These
attributes will typically be used to describe aspects of
context relating to the controlled action.
Attributes can be used either as part of simple value
restrictions or to define a test that dynamically relates two
or more separate attributes. A simple restriction typically
has the form:
[all | some] [attribute] values are [within the set of
enumerated instances | of a given type]
For example, such a restriction allows a policy to say
that:
• A valid credential for a given user must be one of the
set of recognized credentials.
• Receivers of a given radio transmission must all be
holders of a particular security clearance.
Some policies require the definition of dynamic
attributes whose values must be tested relative to the
values of some other attribute. Support in KAoS for this
feature allows users to define policies that relate to the
local context of the action or actor. For example:
• A robot is authorized to request assistance only from
current members of its team,
• Employees are forbidden from using printers
belonging to departments other than their own.
• Users are authorized to share documents only if they
share a common credential.
4.2. Role-Value Maps
OWL semantics do not allow the expression of the
constraints on attributes described above. The KAoS role-
value-map reasoner [10] solves this problem. The
reasoner can handle any of the following forms:
• Attribute values must equal the values of another
action attribute (e.g., user department membership
must equal the ownership property of the printer used
in the print action).
• Attribute values must contain all values of another
action attribute (e.g., receivers of a radio
transmission must all be members of the set of
security clearance holders).
• At least one attribute value must equal the value of
another action attribute (e.g., at least one of the
credentials of the user initiating communication must
be in the set of credentials of the receiver of the
message).
• None of the attribute values is equal to the values of
another action attribute.
4.3. Spatial Relations
Spatial relations (http://ontology.ihmc.us/spatial/) have
been useful in policies such as: requiring a robot to stay
to the right of an astronaut, restricting robot movement
through a given area, or restricting radio transmission to
authorized power levels within a given political zone.
For such purposes, we have implemented the KAoS
Spatial Reasoning Component (KSPARC
1
). KSPARC
can reason about the location and orientation of objects
relative to an arbitrary coordinate system and any number
of dynamically-definable regions described as polygons.
KSPARC can reason with any mix of absolute and
egocentric references, allowing the following sorts of
policy reasoning:
• Queries for relative positions between objects (e.g.,
in front / behind, to the left / right, inside / outside);
• Translation between reference orientations (e.g., my
right = your left);
• Listing spatial relations between two objects;
1
Pronounced “KAY-spark.”
• Spatial relationships between two objects in relation
to a reference object (e.g., further to the left or right
of, higher than);
• Calculating whether or not an object can be seen
from a given position and orientation;
• Calculating specific values associated with any
spatial relations (distance, rotation).
4.5. Obligation Policy Triggers
Unlike authorization policies, obligation policies include
triggers that specify the conditions under which the
required action will be activated (e.g., When two hours
have elapsed, the operator must terminate the
transmission). Trigger actions are specified in a manner
that is similar to controlled actions.
Relative attributes are typically used to relate the
trigger to the obliged action (e.g., “If [some robot] fails,
then [some robot] must notify its teammates; “If [some
message] is of class ‘secret’ or greater, [some message]
must be logged to the audit queue).”
4.4. History and Current State of a Situation
All policies are defined in the context of a Situation,
which possesses a history and a set of variables
describing its current state.
History is used to qualify the applicability of the
policy relative to past events, i.e.:
This policy applies when [actor] has performed
[action] which has [any attributes] _at least [#]
times_ _within the last [x] [minutes|hours|days…]
For example, this feature could be used in a policy to
forbid system access to anyone who has a history of two
or more failed logon attempts in the last five days.
State information is used to qualify the applicability
of a policy relative to values representing the current state
of one or more variables, i.e.:
This policy applies when the [situation element] [has
any state | is] [state] has [attributes]
For instance, a given policy governing the frequency
of weather reports might apply only when the Weather is
Bad Weather. Another policy might apply when the
Weather has the following attributes: temperature is > 75
and sunlight is bright.
4.6. Policy Precedence
The ranking of policies by order of importance is used in
two important phases of policy management. In the first
case, when a policy is created or updated, the policy
service must determine whether the new policy is
consistent with the existing set of policies. If the new
policy and an existing policy have the same ranking in
importance, cover overlapping actor, action, and context
classes, and have conflicting modalities (i.e.,
authorized/forbidden, required/forbidden, required/not
required), the new policy is rejected and deconfliction
recommendations are given to the user [9]. If the new
policy overlaps with an existing policy and has a
conflicting modality, but one of the two policies has a
higher ranking than the other, no deconfliction is
required.
The second case occurs during authorization policy
decisions (i.e., determining whether or not an action is
permitted). As part of this process, KAoS collects a set of
policies with action classes positively classifying the
action instance being tested. Policy ranking allows KAoS
to group applicable policies into sets of decreasing
importance. At policy creation time, the consistency
checking mechanism has already assured that the sets are
not in conflict. At policy decision time, within the policy
set with the highest priority for a given action, a single
positive or negative authorization policy will determine
whether the action is permitted or forbidden.
KAoS originally relied on numeric policy priority
assignments by users to determine how policies should be
ranked. This mechanism has important advantages. For
example, at policy commitment time it is immediately
evident that only policies with the same numeric priorities
must be tested for consistency with the new policy. When
policy decisions are made, policy applicability is
analyzed according to the partially-sorted priority
sequence. Thus, the numeric policy ranking approach
executes quickly. Unfortunately, a disadvantage of this
approach has been that people may have difficulty
assigning meaningful priorities and tracking how a given
policy’s priority relates to the priorities of other policies.
For this reason, we are extending the priority mechanism
in KAoS to use a logical precedence mechanism in
addition to numeric priorities. The following relations are
supported:
• Name or role of the person who authorized the policy
(e.g., Jim Hanna’s policies take precedence over
anyone else’s policies, policies of the domain
administrator take precedence over user policies);
• Time when the policy was created (e.g., more recent
policies take precedence over older policies);
• Relative scope of class of the policy subject (e.g.,
superdomain policies take precedence over
subdomain policies; policies for Pioneer robots take
precedence over policies for the general robot class);
• Relative scope of the class of policy action (e.g.,
policies about writing to a specific directory take
precedence over policies about writing to the
volume);
• Modality of the policy (e.g., Negative authorizations
take precedence over Positive authorizations);
• Priority level of the policy (e.g., high-medium-low).
These levels will allow users to define any number of
arbitrarily-ordered priority categories and associate
them with names of their own choice. These priority
levels can be used in conjunction with any of the
precedence relations described above.
The user is also allowed to manually change the location
of any policy in the ranked list.
When the policy service does not find any policy
applicable to the current situation, it must still provide an
answer to the authorization question. For this reason,
users can specify a default authorization mode on a per
domain basis. A domain is considered tyrannical if it is
configured such that nothing is permitted unless explicitly
authorized, and laissez-faire in the opposite case.
5. KAoS Human Interface Layer
The KAoS Policy Administration Tool (KPAT
2
)
implements a graphical user interface for policy
management functionality. Besides its use in policy
specification and analysis, it is used for administration
tasks such as browsing and loading ontologies, and
domain and Guard management.
Figure 2: Authorization Policy in Hypertext Mode
KPAT’s generic Policy Editor (Fig. 2) presents an
administrator with a starting point for policy
construction—essentially, a very generic policy statement
shown as hypertext (see the generic policy statement in
section 4.1). Clicking on a specific link that represents a
variable provides the user with choices allowing him to
make a more specific policy statement. During use,
KPAT accesses the ontology loaded into the DDS and
always provides the user with the list of choices narrowed
to the current context of the policy construction. New
classes and instances can also be created from KPAT.
To further simplify policy construction, KPAT
provides two additional policy creation interfaces:
• The Policy Wizard (Fig. 3) takes a user step-by-step
through the policy creation process. Information
selected for presentation is conditioned on whatever
has been selected previously, making the experience
as simple and foolproof as possible.
• The Policy Template Editor allows custom policy
editors for a given kind of policies to be created by
point-and-click methods. For instance, if an
application will require the definition of several
2
Pronounced “KAY-pat.”
