A general obligation model and continuity: enhanced policy enforcement engine for usage control.
ABSTRACT The usage control model (UCON) has been proposed to aug- ment traditional access control models by integrating au- thorizations, obligations, and conditions and providing the properties of decision continuity and attribute mutability. Several recent work have applied UCON to support secu- rity requirements in dierent computing environments such as resource sharing in collaborative computing systems and data control in remote platforms. In this paper we iden- tify two individual but interrelated problems of the origi- nal UCON model and recent implementations: oversimpli- fying the concept of usage session of the model, and the lack of comprehensive ongoing enforcement mechanism of imple- mentations. We extend the core UCON model with con- tinuous usage sessions thus extensively augment the expres- siveness of obligations in UCON, and then propose a gen- eral, continuity-enhanced and configurable usage control en- forcement engine. Finally we explain how our approach can satisfy flexible security requirements with an implemented prototype for a healthcare information system.
- [show abstract] [hide abstract]
ABSTRACT: Policies in modern systems and applications play an essential role. We argue that de- cisions based on policy rules should take into account the possibility for the users to enable specific policy rules, by performing actions at the time when decisions are being rendered, and/or by promising to perform other actions in the future. Decisions should also consider preferences among different sets of actions enabling different rules. We adopt a formalism and mechanism devised for policy rule management in this con- text, and investigate in detail the notion of obligations, which are those actions users promise to perform in the future upon firing of a specific policy rule. We also investigate how obligations can be monitored and how the policy rules should be affected when obligations are either fulfilled or defaulted.Journal of Network and Systems Management 01/2003; 11:351-372. · 0.43 Impact Factor
- [show abstract] [hide abstract]
ABSTRACT: Policies are widely used in many different systems and applications. Recently, it has been recognized that a "yes/no" response to every scenario is just not enough for many modern systems and applications. Many policies require certain conditions to be satisfied and actions to be performed before or after a decision is made in accordance with the policy. To address this need, this paper introduces the notions of provisions and obligations.04/2002;
- [show abstract] [hide abstract]
ABSTRACT: The Ponder language provides a common means of speciing security policies that map onto various access control implementation mechanisms for firewalls, operating systems, databases and Java. It supports obligation policies that are event triggered conditionaction rules for policy based management of networks and distributed systems. Ponder can also be used for security management activities such as registration of users or logging and auditing events for dealing with access to critical resources or security violations.09/2000;
A General Obligation Model and Continuity-Enhanced
Policy Enforcement Engine for Usage Control
University of Innsbruck
Samsung Information Systems
America, San Jose, CA, USA
University of Innsbruck
University of Innsbruck
Samsung Information Systems
America, San Jose, CA, USA
The usage control model (UCON) has been proposed to aug-
ment traditional access control models by integrating au-
thorizations, obligations, and conditions and providing the
properties of decision continuity and attribute mutability.
Several recent work have applied UCON to support secu-
rity requirements in different computing environments such
as resource sharing in collaborative computing systems and
data control in remote platforms. In this paper we iden-
tify two individual but interrelated problems of the origi-
nal UCON model and recent implementations: oversimpli-
fying the concept of usage session of the model, and the lack
of comprehensive ongoing enforcement mechanism of imple-
mentations. We extend the core UCON model with con-
tinuous usage sessions thus extensively augment the expres-
siveness of obligations in UCON, and then propose a gen-
eral, continuity-enhanced and configurable usage control en-
forcement engine. Finally we explain how our approach can
satisfy flexible security requirements with an implemented
prototype for a healthcare information system.
Categories and Subject Descriptors
H.1 [Models and Principles]: General; D.2.11 [Software
Engineering]: Software Architectures—Domain-specific ar-
Access control mechanisms aim to restrict access to sensi-
tive resources (objects) from users and processes (subjects).
Traditional enforcement of access control rules applies in-
stantly on access requests, and after an access is granted
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SACMAT’08, June 11–12, 2008, Estes Park, Colorado, USA.
Copyright 2008 ACM 978-1-60558-129-3/08/06 ...$5.00.
there is no control on the resource. The growing involve-
ment of information technologies in all sectors of human life
like eHealth, eGovernance, eCommerce, and others, results
in a dramatic increase of data flow between different actors
in distributed environments, where the processing of data is
carried out on clients as well as on servers. Consequently,
new requirements have risen going beyond traditional access
control mechanisms. They demand the control of resources
after an access has been granted.
To overcome the shortcomings of traditional access con-
trol mechanisms, a usage control (UCON) concept has been
introduced with the unique properties of decision continuity
and attribute mutability. These features satisfy the secu-
rity requirements of many contemporary information sys-
tems. Different approaches have been proposed to describe
the UCON model formally. UCONABC family model con-
sists of the following core models: Authorization (A), oBli-
gation (B) and Condition (C), with sub-models representing
whether an access decision is made before (pre-) or during
(on-) a usage session. This leads to the following UCON
sub-models: authorization core models preA and onA, obli-
gation core models preB and onB, and condition core models
preC and onC [14, 15, 22].
In our work we investigate usage and access control re-
quirements in healthcare systems. Based on some practical
studies in the eHealth domain [10, 25] and studies that deal
with authorization  and privacy  issues in eHealth sys-
tems, we summarize some example security requirements in
• Only authorized actors with recognized certificates are
allowed to retrieve patient records. Access rights are
based on the roles of the actors. For example, pharma-
cists are allowed only to access the part of the health-
care record containing prescriptions.
• 4-eyes principle: the presence of a patient should be
checked during the access session to the record .
• Retention time: a patient record should be saved in
the doctor’s machine for a maximum one month.
• Patient consent: after the end of a treating session,
the retrieved document should be stored in the local
machine of the doctor in case the patient approves it;
otherwise it should be deleted from the system.
• In case the patient is not present before the normal
termination of a treating session, the document must
be deleted and an abnormal session notification should
be reported to the service provider.
These requirements show clearly the importance of us-
age control: the whole usage of a patient’s record should
be controlled and multiple authorization checks are needed
during this usage. However, from the last two requirements
we conclude that some decisions and actions must be taken
and executed after each usage session. Such actions are not
supported in the current UCON model as it only consists of
(pre-) and (on-) core models. To meet these new require-
ments the current UCON model and its policy specification
have to be extended. First, the family of UCONABC core
models are extended by adding post obligations. We ar-
gue that only obligations should be checked after the usage
session while (post-) authorizations and conditions are not
needed. Second, the sequence of system states that are used
to define the context of a resource usage control are ex-
tended. Ongoing obligation trigger actions are illustrated
with the ongoing-check state.
Our extension is based on the principle that a security
model should support as many enforceable security poli-
cies as possible. By augmenting UCON core models with
post-obligations, we can enforce recently proposed obliga-
tion policies in literature [17, 12, 4, 6, 5, 7]. We claim that
these policies can be supported by UCON in multi-usage-
session environments. For example, the obligation requiring
that a user has to pay an amount of money after getting a
service is regarded as a post-obligation in UCON. We ar-
gue that these obligations are not enforceable with original
core UCON models which focus on a single usage session.
We consider the scenario that the user has further service
access requests after the current usage session, which is the
natural and typical usage pattern in real world. Thus, the
obligation can be enforced, e.g., by providing different qual-
ity of service to the user if the obligation is not satisfied. In
the above eHealth usage scenarios, typically the client (e.g.,
a doctor) needs to access patients’ records frequently, (e.g.,
everyday); therefore the obligations can be enforced. On the
other side, we believe that authorizations and conditions are
single-session oriented naturally, which means that pre- and
ongoing authorizations and conditions are expressive enough
to specify most (if not all) usage control policies.
As aforementioned, UCON has the novel features of deci-
sion continuity and attribute mutability. At the same time
it can support many traditional access control policies in
one model. However, not much work has been done to fully
utilize UCON properties in a practical framework. The fun-
damental problem is that UCON enforcement mechanism
lacks a general ongoing and post decision checking and en-
forcement engine.This drawback keeps UCON far away
from practical and real systems. To cope with this prob-
lem, our second novel contribution in this work, is to in-
troduce a comprehensive usage control enforcement engine.
The corresponding enforcement engine is configurable using
a proposed enforcement-focused usage control policy specifi-
cation. A proof-of-concept prototype of the engine is imple-
mented and tested for an eHealth application scenario. This
implementation is based on XACML that has established it-
self as a de-facto mature standard for access control. Doing
so the well standardized and implemented XACML access
control policy and enforcement architecture are utilized.
We develop our work by following the recently proposed
PEI security engineering framework . In a security sys-
tem, PEI distinguishes the problems of what the security
requirements and how these requirements can be satisfied
or enforced with different model layers. Particularly, in the
policy model layer, we augment UCON core models with
post-obligation considerations and extend the state transi-
tion of UCON (cf. Section 4); in the enforcement model
layer, we distinguish two main functional modules to handle
attributes and actions in a UCON system (cf. Section 5);
finally, in the implementation model layer, we consider differ-
ent implementation variants and develop our strategy based
on standardized XACML policy specification and enforce-
ment engine (cf. Section 6).
Outline:Background and related work are present in
Section 2. We discuss our model extensions in Section 4.
Regarding the enforcement model, we introduce a general
continuity-enhanced usage control enforcement framework
in Section 5. In Section 6 we propose the implementation
model and discuss our proof-of-concept prototype and show
how it leverages the capabilities of our enforcement model.
We conclude this paper and present our ongoing work in
Park et al.[15, 14, 16] systematically treat the usage
control concept and develop a comprehensive model. The
introduced UCONABC model integrates Authorization (A),
oBligation (B) and Condition (C) components in usage con-
trol decisions.Because of its session-based nature it has
two remarkable features that distinguish it from the tra-
ditional access control models: decision continuity and at-
tribute mutability. Given that, the model is divided into
three core models: (1) Authorizations, where the access de-
cision is made based on the requesting subject’s and tar-
get object’s attributes. (2) Obligations, in which the ful-
fillment of some actions by specific subjects on specific ob-
jects (the obligation’s subjects and objects may differ from
the authorization’s pair) should be checked. (3) Conditions,
where environmental information (also called environment
attributes) are checked. To introduce the two main features
in the model, it is further classified according to decision
continuity and attribute mutability.
continuity factor, it can be distinguished between decisions
made before an access has been started (pre-) or the deci-
sions that are taken during the access session (on-). While
considering the mutability factor, update actions are intro-
duced before, during, or after an access session. Our policy
model is based on the proposed UCON model by Park et al.
with the extensions in core model to include decisions that
are made after an access session, i.e. post- sub models and
augment the expressiveness of obligation to include system
based obligations. Furthermore, we investigate obligations
in more details and introduce general obligation model.
Zhang et al.  have defined a formal model and pol-
icy specification for UCONABC based on an extension of
the Temporal Logic of Actions (TLA). Figure 1 shows the
system’s state transition of a single usage , which distin-
guishes actions done by the system (tryaccess and endaccess)
and actions done by a subject (the others).
The following states have been defined in original UCON
With respect to the
Figure 1: Traditional UCON state transition dia-
in a usage process: initial, requesting, accessing, denied,
revoked and end. Initial state means that access request
is not generated; requesting state indicates that the access
has been generated and is waiting for the system’s usage
decision; denied state refers to the state where the system
has denied access; the accessing state means that the system
has permitted access and the subject is accessing the object
immediately after; the termination of the access done either
when the system revokes the access after it has been granted
in requesting state or it is ended normally by the user.
We identify one problem of this state transition, shown in
Figure 1, related to ongoing decision checks. UCON sup-
ports decision continuity, which means that during a usage
session multiple ongoing checks can occur.
state transition diagram does not show the ongoing checks
and the ongoing transitions. Hence, the state transition is
extended by adding one state and showing the ongoing trig-
ger actions (cf. Section 4). The extended state transition is
used in designing our enforcement framework.
2.2 Obligations and Enforcement Framework
Pretschner et al. [17, 18] deal with distributed usage con-
trol policies, i.e. the loss of control over a data item af-
ter giving it away. Their work distinguishes “observation
based enforcement” vs. “enforcement by direct control over
the service provider action” by using compensating actions.
Their work maps to the post obligations in our model. How-
ever, they do not consider usage sessions and related aspects.
The policy proposed is at abstract level and no practical ap-
proach to leverage the enforcement engine is discussed.
Hilty et al. [12, 11] deal with usage control requirements
with respect to obligations and conditions. Two kinds of
obligations are defined: usage restrictions and action re-
quirements. They express mandatory actions that must be
executed either unconditionally or after a specified usage
has been performed. From the policy model point of view,
conditions and usage restrictions can be mapped to UCON
core models of obligations, authorizations, and conditions
together. Furthermore, action requirements can be covered
in our extended UCON model by adding post obligations.
They argue that their policy language can be mapped to
DRM (Digital Right Management) policies. However they
do not provide a configurable enforcement engine that uti-
lizes their policy language apart from DRM systems.
Irwin et al.  define formal model of obligation, and
distinguish secure and insecure system states based on the
concept of accountability. The paper does not mention how
to check obligation fulfillment, rather it deals with the for-
mal specification and analysis of obligations and explains
the complexity of checking accountability properties. The
formal model is similar to our obligation model. We assume
that the obligation’s subject is the only entity responsible
for the fulfillment of an obligation without any further obli-
gation interferences. Additionally, we propose a comprehen-
sive enforcement model for the obligation-extended UCON,
and test it on a prototypical enforcement engine.
Gama et al. [8, 9] worked with an obligation enforcement
engine. In the first paper they developed Heimdall as an
enforcement platform for obligations using an obligation-
enabled policy language xSPL, an extension of SPL .
In the second the authors showed the feasibility of their en-
gine by integrating Heimdall with practical grid platform
for resource usage management. In this paper reevaluation
mechanism was added by extending xSPL. Comparing to
our approach, additionally to supporting obligations in the
context of a usage session and realted aspects of compensat-
ing actions and re-evaluation , we propose a new concept of
obligation PDP. We believe that some kind of untrusted obli-
gations need a fulfillment check upon receiving the obliga-
tion event. For example, the obligation that a user provides
her valid email address requires that the enforcement system
checks the validity of the address upon receiving it. Further-
more, tracing and recording a sequence of history events re-
lated to a specific usage of a resource is better achieved by
state machine based engine.
Various other obligation concepts have been introduced in
literature. In the Ponder policy language , an obligation
is more like a duty that a subject has to perform. This obli-
gation is not directly required by an access control purpose.
Bettini et al. [6, 5] introduce the concept of provisions that
should be done before an access is granted, and obligations
that must be done after an access has been granted. These
can be regarded as pre-obligations and post-obligations in
UCON, respectively. However, they also do not propose an
enforcement engine to support their policies.
With regard to UCON model, Zhang et al.  use XACML
as a policy language and extend the XACML policy enforce-
ment architecture with some extra components like “Usage
Monitor” to monitor the updates of subject, object, and
environment attributes. This framework lacks obligations
handling, does not consider updates for denied and revoked
states, and finally, does not distinguish between constraints
applied in different states.
3. MOTIVATING EXAMPLE
In order to illustrate some of our framework’s functional-
ity, we take an application scenario from the medical domain
(cf. the main requirements illustrated in Section 1). In this
scenario, a patient’s electronic health record (EHR) is stored
and managed by a distributed Hospital Information System
(HIS). Different actors are trying to get access to this record
(or part of it), such as insurance companies, general practi-
tioners, pharmacists, research institutes and others. Let us
take the general practitioner (GP) as an example. In this
scenario the usage requirement of our specific healthcare sys-
tem states that patient attendance should be checked at the
beginning and during a treatment (according to the 4-eyes
principle). At the end of the treatment session, the patient
admission should be given before the GP saves the patient’s
record permanently; i.e. the patient has accepted to trust
this GP for future treatments, or the record must be deleted.
This is because of the fact that the record should only be
stored by trusted and personal GP of the patient. In more
details the work flow is as follows:
1. First, the doctor should have installed a document
reader with UCON enforcement mechanisms.
2. While the patient is visiting the doctor for treatment,
the doctor requests the document from the HIS (or its
3. At the HIS’s side (service provider), the doctor is au-
thenticated and authorized to access to the document,
for example, based on his role in the system.
4. Upon authorization, the required document is released
with the corresponding UCON policy in one encrypted
5. At the doctor’s system, the document and the UCON
policy are verified (for integrity), decrypted, and stored
6. The UCON policy includes the usage requirements men-
tioned before. When the doctor tries to use the docu-
ment, the policy is enforced by the enforcement mecha-
nism that we are proposing in this work. This occurs in
such a way that: (1) The “4-eyes principle” is checked
before and during the usage session; (2) The document
must be stored in the doctor’s machine under the con-
sent of the patient at the end of the treating session,
otherwise the document must be deleted.
Note that we only describe here one instance of the work
flow scheme. Variants exist in many implementation aspects
such as object and policy distribution, integrity verification,
and so on. For example, a UCON policy can be defined
based on the type of healthcare records (e.g., according to
different diseases), such that individual records and policies
are distributed separately, and a doctor only needs to down-
load a single copy of the same type of records.
Privacy is another example requirement applicable to us-
age control policies: each patient presents her/his prefer-
retention time, the location, or the purpose of the usage .
4.OBLIGATION MODEL AND UCON EX-
As aforementioned, the main drawback of the original
UCON model is the inability to handle actions after the
usage of the resources in a specific session1. In this section
we deal with this problem to enable the model to handle
this requirement by introducing post-obligations in UCON.
Instead of simply introducing a postB core model, we con-
sider how to specify obligations (including pre- and ongoing
1The original UCON core models can enforce update ac-
tions after a single usage session– post-updates, which are
system actions–performed by systems . This is different
from post-obligations that we discuss in this paper, which
include actions that must be performed by subjects and were
regarded as non-enforceable in original UCON model.
obligations in UCON) in a general and formalized way. We
then extend the original UCON state transition scheme by
exploring more detailed obligation trigger actions.
4.1 Obligation Model
An obligation in UCON is a predicate that utilizes some
functions to check whether a certain activity has been ful-
filled or not. For example, before downloading a white paper
of a company, a user is required to give her/his valid email
address and accept the privacy terms and conditions of the
company. The obligation subject in this case is the same sub-
ject that tries to access the object. In general, an obligation
subject can be any other subject, even the security system
itself, e.g., the reference monitor and supporting components
of a system. For example, watching an online video requires
that streaming video data is stored in a temporary folder,
and is required to be deleted after being watched. This obli-
gation should be performed by the system (e.g., the media
player or DRM agent that enforces usage policies) on the
video data (obligation object). The current UCON model
includes two obligation core models, namely preB and onB,
where the first is the one applied before the access and the
second during the access. In this paper, we generalize the
requirement of obligations, which include actions that must
be performed by a subject or the system and the fulfillment
can be checked after the access.
Taking the mentioned healthcare scenario into considera-
tion, the client software should delete the record in the re-
voked state or store the record in the end state when the pa-
tient gives her/his permission, where the deleting and stor-
ing of the record are considered obligations that should be
done and the “fulfillment” should be checked by the system
after the end of the session.
In general the purpose of post obligations is twofold: First,
it can be used to execute obligation actions that are related
to the current usage despite it has no affect on the decision
making of the current usage.
required to be executed and a notification of the fulfillment
of these action can be send to the service provider of the
data owner (e.g., storing the patient’s record after normal
ending of a treatment session). Secondly, it can affect future
usage sessions, which can be done, for example, by sending a
request to the usage control policy repository to change the
UCON policy related to this subject when trying to access
this object or any other objects in the future.
We consider an obligation from four points of view: (1)
Who must perform the action; (2) What the obligation must
be applied to; (3) When it should be performed; and (4) For
how long it should be carried out.
However these actions are
• Who means which entity is obligated to fulfill the ac-
tion. Here we distinguish system-performed obliga-
tions and subject-performed obligations. This distinc-
tion is important because of the fact that typically a
security enforcement system is trusted while we do not
have any influence on other subjects. Doing so we are
augmenting the expressiveness of obligations in origi-
nal UCON, where updates are considered as the only
actions that must be done by the system.
• What refers to the obligation object. Here we can dis-
tinguish objects that the system controls and objects
that are out of the control of the system. Control-
lable objects are those that are within a target system’s
domain, while non-controllable objects are outside the
system’s domain. For example, deleting a file that is
controlled by the system differs from deleting a file that
is stored in a remote file server. In the latter case we
should commit additional actions to ensure that the
file server is up, the file exists, the network connec-
tion is working, and the file is really deleted after the
In conjunction with the aforementioned subject/system
distinction, we can conclude the following obligation
classifications: system obligations on controllable ob-
jects, system obligations on non-controllable objects and
subject obligations. We argue that the first obligation
type does not need fulfillment check, as it is done by
a trusted system on controllable objects. However the
second and third types need fulfillment check, either
because the object is not controllable or the subject is
not trusted. Updates can be classified as system obli-
gations on controllable objects, in case the updated ob-
jects are controllable. Hence, updates are considered
in the original UCON model as actions rather than
a predicate because they do not need further check.
Nevertheless, it has been mentioned that when a tar-
get object is not available, e.g., because of network
problem or storage problem, the update process should
be monitored without capturing these aspects in the
model . In our approach we are dealing with this is-
sue systematically by this classification. Therefore we
are considering the updates as a special type of system
obligations, either on controllable or non-controllable
• When means whether the obligation should be fulfilled:
before a usage control session is finished (e.g., before
the access or during the access) or after the session is
ended. It is important to distinguish between obliga-
tions after the usage session and obligation before the
session is finished. This is crucial because after the us-
age session is finished, the result of the obligation can
not affect any more the usage decisions, while it does
before the access is granted or during the usage. Note
that the post obligation can affect the usage decisions
of future sessions.
• Durability means that the obligation should be fulfilled
within specific period of time. For example, a user
must pay his fee within one month, and whenever he
pays he can get access to offered services. In this case
the fulfillment should be checked continuously to start
the service. In some cases there is a need for instant
fulfillment check. For example, when a user must give
his valid email address before requesting the white pa-
per of a company, the system should check the validity
of the email instantly after the request is generated and
before the user is given the access. Similar aspects are
also mentioned by Hilty et al. .
Based on these considerations, we define an obligation as a
tuple of OBL = (OBS,OBO,OBA,WHEN,DURATION),
where OBS is the obligation subject or system, OBO is
the obligation object (e.g., healthcare record), OBA is the
action that has to be performed (e.g., delete), WHEN =
pre|on|post|, and DURATION is the time point or pe-
riod to check the fulfillment of the obligation.The con-
cept of fulfillment check and compensating actions associ-
ated with each obligation will be discussed in the implemen-
4.2 State Transition of UCON
Figure 1 shows the original UCON state transition schema,
in which pre-decision components (preA, preB, preC or any
combination of them) are evaluated at the requesting state.
Once the access request is granted, the system comes to the
accessing state, in which the subject is accessing the object.
From the accessing state the system moves either into end
state when the users ends the session, or revoked state when
policy rules are violated during the session. We argue that
the original UCON does not show the actions that trigger an
ongoing decision check during the usage session. The state
in which the system is checking the policy rules during the
session, analogy to the requesting state, is not mentioned as
well. That means, the accessing state and the state where
the ongoing policy rules are checked are merged in one state
called accessing, and the trigger action that triggers the re-
evaluation of attributes is hidden.
To express these subtle but critical state transitions in
UCON, we divide the accessing state in original UCON
into two states, namely accessing and ongoingCheck, respec-
tively. A trigger action transits the system state from ac-
cessing to ongingCheck.
Figure 2: Expanded UCON state transitions.
Figure 2 shows our extended UCON state transition scheme.
Comparing to the state transitions shown in Figure 1, we
omit in our new state transition diagram the update ac-
tions/transitions: We consider updates as system obliga-
tions (as discussed before). That means, the needed updates
are stated in the obligation rules of the corresponding state.
When the object of the update obligation is controllable,
there is no need for fulfillment check. This case maps to the
original update actions in [14, 29].
Secondly, one new state, ongoingCheck state, and two
transitions, ongoingRequest and ongoingPermit, are added
in our new scheme. When the subject is exercising the ac-
cess to the resource, the system is in the accessing state.
Any changes or updates of subject, object, or environment
attributes trigger ongoingRequest transition and the system
moves to the ongoingCheck state. In this state the decision
(onA, onB, onC or any combination of them) is made and
the new set of attributes should be evaluated. Accordingly,
either the system revokes the usage, i.e., revokAccess transi-
tion, or it continuously grants the access to the subject, i.e.,
the ongoingPermit transition, and the system goes back to