Julian Sch¨utte
Fraunhofer Institute for Secure Information Technology SIT, Parkring 4, Garching, Munich, Germany
Access control, Semantic web, Software architecture.
Pervasive systems with ad hoc connectivity and semantic service discovery are a challenging environment
when it comes to dynamically managing access rights and security settings. Most policy frameworks come
with a pre-defined policy model whose expressiveness can usually not be extended and is thus not adaptable
to a high-level security model as it might be predetermined by a company or a specific application. In order to
overcome these limitations we designed Apollon, a policy framework featuring a modular policy model which
can be extended or reduced as required by an application. In this paper, we present the software architecture of
Apollon, and show by the example of a DRBAC-model how the expressiveness of Apollon can be successively
Context-aware and “intelligent” environments are on
the rise, promoted by the advent of powerful and mo-
bile devices like smartphones. These systems are
characterized by a distributed software architecture
and heterogeneous devices which join the network
in an ad hoc fashion and are discovered at run time.
While more and more applications based on such sys-
tems occur, controlling access rights and security set-
tings throughout the whole application is still a chal-
lenge. Some of the open issues in that area are:
Most frameworks (Twidle et al., 2009; Lalana Ka-
gal, 2006; Uszok et al., 2003) feature a specific policy
model which may or may not be suited for a system.
As the applications in a distributed system evolve, ad-
ditional demands on the security model might arise
and in case the policy framework does not support
them, re-deployment of a new suited framework or
other workarounds become necessary. Furthermore,
there is a demand to express high-level security mod-
els. Many policy languages feature low-level and
fine-granular rules, which often results in the actual
security model being buried in a huge set of com-
plex rules, mixing up the security model with domain
knowledge, which makes it on the one hand very hard
to recognize the actual security model from the pol-
icy and requires on the other hand that policies need
to be modified whenever the domain knowledge has
changed. Therefore, it must be possible to specify
policies at a more abstract level which is closer to the
actual security model and easier to understand for de-
velopers. These policies must then automatically be
mapped into concrete enforceable actions at run time.
Finally, verifiability of security properties should
be supported. Whenever the policy needs to be mod-
ified, developers must be able to verify that the secu-
rity model is still effective as intended. For example,
it should be possible to verify that a certain constraint,
such as separation of duty, is still in effect after adding
further rules to the policy.
In this paper we present Apollon, a policy frame-
work which addresses the aforementioned challenges.
It provides an extensible software architecture which
allows to integrate various access control and obliga-
tion models whose expressiveness can be increased
by means of plug-ins according to the needs of an ap-
plication. As an exemplary policy model, we describe
a dynamic role based access control (DRBAC) model
which is fully expressed in Description Logics (DL)
so that a formalization of the policies used is inher-
ently provided, and allows verification and analysis
of policies. In section 2, we introduce the Apollon
framework, the policy decision engine, as well as the
concept of using DL to represent security policies. An
exemplary basic authorization model, based on DL is
then introduced in section 3 and an example of a high-
level security model on top is given in section 4, along
with results from our prototype implementation. Sec-
tion 5 concludes the paper and outlines future work.
Schütte J..
DOI: 10.5220/0003523603910395
In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2011), pages 391-395
ISBN: 978-989-8425-71-3
2011 SCITEPRESS (Science and Technology Publications, Lda.)
Figure 1: High-level overview of framework components.
Figure 1 provides an overview of the main compo-
nents of the Apollon framework. The core compo-
nents are a semantic knowledge base in which the pol-
icy model is represented and a decision engine which
evaluates access requests and events against the poli-
cies stored in that knowledge base. The knowledge
base is realized in an individual component which
manages a set of OWL2 ontologies and provides
reasoning functions to the other components of the
framework. The decision engine maintains the actual
policies and evaluates access requests and events by
following the decision process described below. Any
decision is triggered by either event listeners or policy
enforcement points (PEP). Event listeners can react on
any kind of event, such as devices joining and leaving
the network or any contextual changes, for example.
PEPs intercept outgoing and incoming service calls
and responses (i.e., a single message round-trip in-
volves four PEPs), convert them in an access request
format and then send them to the decision engine and
enforce the resulting decision. How event listeners
and PEPs have to be integrated into an existing mid-
dleware is not specified by Apollon, however, in our
prototype we use the OSGi event admin service as an
event listener and service hooks to non-intrusively at-
tach PEPs to any OSGi service.
Policy Modules. The decision engine can be ex-
tended in a plug-in manner by means of Policy mod-
ules. A policy module can contribute to any of the de-
cision phases, described in the following paragraph,
by extending the policy specification or decision logic
itself, by adding facts to the knowledge base, register-
ing further event listeners or by providing a composi-
tion strategy for merging policy decisions from mul-
tiple domains. Due to the monotonicity property of
DL, facts can be added to the knowledge base with-
out invalidating any of the conclusions taken before.
Policy modules can depend on each other and thus
serve as building blocks for increasingly abstract pol-
icy models based on previously loaded modules. The
benefit of this modular approach is thus twofold: by
removing unneeded models, the footprint of the Apol-
lon framework can be scaled to the actual needs of an
application and by adding modules building on other
existing modules, more abstract and easy to under-
stand policies can be realized.
Decision Process. The decision engine is responsi-
ble for reacting to incoming events or access requests
from PEPs, evaluate policies and return a decision or
trigger the execution of obligations. For the sake of
extensibility, the decision process has been structured
by different phases, which the engine passes for ev-
ery policy decision and which we will only sketch
here, due to lack of space. For synchronously evalu-
ated access requests the engine decides in a Decision
phase whether the access should be granted or not by
evaluating the access request, its metadata, the pol-
icy model stored in the knowledge base and specific
rules. As a result of this phase, a single decision, con-
taining either permit or deny as an effect and a set of
high-level obligations is found and passed on to the
next phase, called PostDecision. In that phase, pol-
icy modules cannot modify the decision anymore, but
merely log access requests and resulting decisions
for example in order to realize history-based access
control models. As a final step in the synchronous
evaluation branch, the Classification phase is passed.
During this phase, policy modules can annotate the
decision which has been taken with metadata, for ex-
ample to implement composition strategies, as used in
(Lee et al., 2006). Besides access requests which are
evaluated in a synchronous way, Apollon also sup-
ports asynchronously evaluated ECA policies which
are the basis for situation-specific access rights and
obligations. They are triggered by events which are
received by event listeners and routed into the deci-
sion engine, which then evaluates the policy’s ECA
rules. If the policy specifies any obligations which
must be enforced upon the occurrence of the received
event, the respective high-level actions are refined to
applicable mechanisms and executed during the fol-
lowing Action phase. This decision process is part
of the Apollon core and is not supposed to be modi-
fied. Policy modules can make contributions to each
of these phases in the form of plug-ins, as described
in the next subsection.
We will now describe an exemplary basic policy mo-
SECRYPT 2011 - International Conference on Security and Cryptography
del supported by Apollon and show how further, more
high-level models can be realized on top of it. De-
scription logics was chosen for formalization, as it
is the underlying logic of OWL, which is commonly
used to model domain knowledge in pervasive sys-
tems. Thus, by implementing the policy model in
OWL, already existing domain knowledge can eas-
ily be integrated into security policies. Further, the
implementation in OWL is kept close to description
logic formalization and thereby facilitates checking
the implementation for correctness. A further benefit
is that standard semantic web reasoners can be used
for evaluating and analyzing policies. As one of the
main challenges in the context of security policies is
to make policies understandable for non-security ex-
perts, we expect a DL-based policy model, and the
analysis and explanation features that come with it, to
receive better user acceptance.
However, as stated in (Toninelli et al., 2005), DL
alone is not expressive enough, for example because
it lacks support for variables, does not support non-
monotonic reasoning, and, as a result, does not allow
negation by failure. Therefore, we will complement
the DL model by the decision plug-ins from section
2 in order to implement a hybrid policy decision pro-
cess. The basic authorization module provides simple
access control rules based on subjects, resources and
actions, similar to that of XACML. These rules are
formalized as follows (for details on the notation we
refer to (Baader et al., 2007)):
Policy ≡ ∀hasRule.RulehasRulePref.String
Rule ≡ ∀hasSubject.Subject
hasE f fect.E f fect
= 1hasNumber.n
E f f ect ≡ {deny, permit} Obligation
A policy comprises a set of rules and a rule prefer-
ence, determining which rule should be preferred in
the case of contradicting rules. The rules assign either
deny or permit and an optional obligation to a triple of
Subject, Resource, Action and are ordered by assign-
ing distinct numbers to them, using the hasNumber
relation. An access request consists of a description of
the subject which initiated the request s (Subject)
the resource which is to be accessed r (Resource)
and the action which is to be performed on the re-
source a (Action)
. Given the request and a set
of rules (Rule)
, the decision engine returns an ef-
fect e (E f fect)
, depending on the set of applicable
rules and the rule preference, as follows: a rule rule
is applicable if
rule (Rule hasSubject.{s}
and the final decision is selected among them accord-
ing to the rule preference, being either first, last, per-
mit or deny. When using the first preference, the deci-
sion engine selects the effect of the first rule out of the
set of all applicable rules, i.e. e
is chosen as effect
if r
(Rule hasE f fect.{e
} hasNumber.{x})
and x less than the number of all other applicable
rules. The last preference is applied likewise, select-
ing the last applicable rule, respectively. The per-
mit preference selects the first applicable rule r with
r (Rule hasE f fect{permit})
, otherwise returns
deny and the deny preference acts equally, selecting
the first denying rule. A detailed discussion of obli-
gations is omitted here, as it is not in the main focus
of the paper. In general, obligations specify actions
which have to be carried out whenever a respective
rule has either been triggered by an access request
or asynchronously by an event. In case of access re-
quests, the obligation is carried out by the PEP before
the actual decision is applied, otherwise the access re-
quest has to be refused, regardless of the policy deci-
sion. In the current OSGi-based prototype, such an
obligation refers to the URL of an OSGi bundle that
implements the respective action.
To show how more complex access control mod-
els can be built by means of additional policy mod-
ules, we describe a dynamic role-based access con-
trol model (DRBAC) with hierarchical roles that takes
into account separation-of-duty (SoD) constraints in
order to guarantee that a subject cannot be assigned
to conflicting roles coevally. Many frameworks for
RBAC exist and a plethora of slightly different in-
terpretations of the model are in use (Bacon et al.,
2002; OASIS, 2005; Becker and Sewell, 2004). The
purpose of this section is thus not to add yet another
RBAC implementation but to illustrate how increas-
ingly abstract policy models can be realized in Apol-
The respective policy module will comprise an
ontology fragment, modeling the policy structure, an
event adapter, which triggers the activation of rules, a
retrieval plug-in which allows using roles as attributes
of a subject and a decision plug-in for evaluation of
RBAC policies.
Mapping DRBAC to OWL. Various authors have
proposed representations of RBAC in OWL and while
most of the suggested approaches are feasible, they
have different drawbacks which we aim to overcome.
In (Finin et al., 2008), two approaches are proposed
and compared: the first one models subjects as in-
dividuals and roles as classes. Role membership is
then modeled by assigning a subject to the classes of
its active roles. The second approach models roles
as individuals and assigns them to subjects using a
hasRole property, but has the drawback that addi-
tional rules are needed to express role hierarchies.
The authors of (Finin et al., 2008) consider the first
approach more attractive as it provides more options
to analyze the model and allows to directly evaluate
role hierarchies using subsumption checking. How-
ever, as identified in (Ferrini and Bertino, 2009), the
deficit of the first approach is that it does not allow
to define SoD constraints over hierarchical roles as
this would result in an inconsistent model (two hier-
archical classes would be modeled as being disjunct,
which is not feasible). In (Ferrini and Bertino, 2009),
the authors try to overcome the deficits from (Finin
et al., 2008) by adapting the second approach such
that SoD can be directly checked by a standard rea-
soner. However, the proposed model assigns permis-
sions directly to subjects instead of roles, which does
not comply with the core RBAC specification from
(Ferraiolo et al., 2001) we wanted to implement in
this case. We therefore adopt in essence the represen-
tation from (Ferrini and Bertino, 2009) and adapt it
to meet the RBAC specification as follows. We ex-
Figure 2: Property chains for role hierarchies.
tend subjects from the model in section 3 by a User
class. Users are defined as individuals of that class
and assigned to roles by a hasActiveRole property. By
changing this assignment from hasActiveRole to has-
Role, the respective role can be deactivated for the
user. Role hierarchy is implemented, as proposed in
(Ferrini and Bertino, 2009), by subRoleOf and super-
RoleOf properties. In contrast to (Ferrini and Bertino,
2009), we do not require dedicated rules to evaluate
hierarchical roles but rather define a property chain
hasActiveRole subRoleOf hasActiveRole. This
way, the reasoner can infer role memberships of a
subject for all its super roles, as depicted by Figure
2. Permissions, finally, consist of an action and a re-
source and are assigned to roles by a hasPermission
property. To summarize, the ontology of the DRBAC
module is defined as in the following equations. Note
that due to usage of property chains, access requests
can be decided in the DRBAC model using only DL,
and only the activation of roles has to be done from
outside the ontology.
User Sub ject
User hasRole.Role
Role hasPermission.Permission
Permission hasResource.Resource
ActiveRole Role
superRoleOf = (subRoleOf)
hasActiveRole hasActiveRole subRoleOf
subRoleOf subRoleOf subRoleOf
Adding Separation of Duty. A common use case
of RBAC models is to apply separation-of-duty con-
straints in order to avoid that users adopt conflicting
roles, such as the roles of an applicant and a fund-
ing body. Depending on whether these roles must
only not be adopted at the same time or must never
be assigned to the same subject at all, the terms dy-
namic (DSoD) or static separation of duty (SSoD) are
used. As in (Ferrini and Bertino, 2009), the authors
haveproposed an OWL implementation of both types,
which we can adopt without changes, we refer to (Fer-
rini and Bertino, 2009) for more details and provide
only the formalization of the applicant/funder exam-
ple as a DSoD:
0 DSod
Runtime Results. As the complexity of reasoning
over OWL2 is up to NexpTime, it is interesting to test
whether an ontology-based policy decision engine
achieves satisfying performance for practical use. We
measured the computing time for deciding access re-
quests using the DRBAC model with a reasonably
populated ontology with 205 roles, 1003 users and
200 permissions, which has A L C O I (D) expressivity
and results after classification with the Pellet reasoner
in 4279 individuals, 19 classes, 46 object properties
and 7 data properties. The average response time for
SECRYPT 2011 - International Conference on Security and Cryptography
an access request was 20.47 ms, where the first re-
quest amounts to 25.02 ms and further requests can
get as fast as 10.87 ms
. This shows that even for
policies of reasonable size, the time required for de-
ciding access requests is satisfying and the DL-based
DRBAC model can be considered to be suited for use
in real-world applications.
We have introduced the Apollon framework, an ex-
tensible policy framework which makes use of on-
tologies for representing and reasoning over security
policies. Apollon has been built to meet in particular
the challenges of pervasive systems, stated in the in-
troduction of this paper: by describing entities in DL
and in combination with easy-to-write syntaxes such
as Manchester DL or Turtle, policy specification is fa-
cilitated and the author’s actual intent, in terms of the
security model, becomes more visible. The DL rep-
resentation of the exemplary policy model described
in this paper allows us to separate the actual policy,
reflecting the security model, from domain knowl-
edge, reflecting assumptions about security mecha-
nisms and devices. Further, by example of a DRBAC
model, we have shown that DL reasoning can be used
to decide acces requests and verify security properties
like SoD. However, we acknowledge that DL alone is
not expressive enough for most policies and should
thus mainly be used for modeling domain knowledge
and reasoning over policies rather than performing the
actual policy decision process.
The modular software architecture allows to only
load the required policy modules, thereby reducing
the footprint of the policy framework to the actually
needed functionality. As part of our future work, we
will take into account context-specific access rights,
add features for security negotiations between peers
in order to support self-protecting systems and con-
tinue our research on policy analysis based on OWL
and reasoning.
Baader, F., Horrocks, I., and Sattle, U. (2007). Handbook
of Knowledge Representation, chapter 3 Description
Logics, pages 135–180. Elsevier. ISBN 0444522115.
On Intel Core 2 Duo 2GHz, Ubuntu 10.04, Sun Java, leaving Pellet’s default optimization settings un-
Bacon, J., Moody, K., and Yao, W. (2002). A model of oa-
sis role-based access control and its support for active
security. ACM Trans. Inf. Syst. Secur., 5:492–540.
Becker, M. Y. and Sewell, P. (2004). Cassandra: Distributed
access control policies with tunable expressiveness. In
Proc. 5th IEEE Int’l Workshop on Policies for Dis-
tributed Systems and Networks (POLICY), pages 159
168. IEEE Computer Society.
Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., and
Chandramouli, R. (2001). Proposed NIST Standard
for Role-Based Access Control.
Ferrini, R. and Bertino, E. (2009). Supporting rbac with
xacml+owl. In Proceedings of the 14th ACM sym-
posium on Access control models and technologies
(SACMAT ’09), pages 145–154, New York, NY, USA.
Finin, T., Joshi, A., Kagal, L., Niu, J., Sandhu, R., Winsbor-
ough, W. H., and Thuraisingham, B. (2008). ROWL-
BAC - Representing Role Based Access Control in
OWL. In Proceedings of the 13th Symposium on Ac-
cess control Models and Technologies. ACM Press.
Lalana Kagal (2006). The Rein Policy Framework for the
Semantic Web. http://dig.csail.mit.edu/2006/06/rein/.
Lee, A., Boyer, J. P., Olson, L. E., and Gunter, C. A. (2006).
Defeasible security policy composition for web ser-
vices. In Proceedings of the fourth ACM workshop on
Formal methods in security, FMSE ’06, pages 45–54,
New York, NY, USA. ACM.
OASIS (2005). Core and hierarchical role based access con-
trol (rbac) profile of xacml v2.0. OASIS.
Toninelli, A., Bradshaw, J. M., Kagal, L., and Montanari,
R. (2005). Rule-based and ontology-based policies:
Toward a hybrid approach to control agents in perva-
sive environments. In Proc. of the Semantic Web and
Policy Workshop.
Twidle, K., Dulay, N., Lupu, E., and Sloman, M. (2009).
Ponder2: A policy system for autonomous pervasive
environments. In The Fifth International Conference
on Autonomic and Autonomous Systems (ICAS), pages
330–335. IEEE Computer Society Press.
Uszok, A., Bradshaw, J. M., Jeffers, R., Suri, N., Hayes,
P. J., Breedy, M. R., Bunch, L., Johnson, M., Kulka-
rni, S., and Lott, J. (2003). Kaos policy and do-
main services: Toward a description-logic approach
to policy representation, deconfliction, and enforce-
ment. In Third International Workshop on Policies for
Distributed Systems and Networks (POLICY), pages