Compositional Refinement of Policies in UML –
Exemplified for Access Control
Bjørnar Solhaug1,2 and Ketil Stølen2,3
1
Dep. of Information Science and Media Studies, University of Bergen
2
SINTEF ICT
3
Dep. of Informatics, University of Oslo
{bjornar.solhaug,ketil.stolen}@sintef.no
Abstract. The UML is the de facto standard for system specification,
but offers little specialized support for the specification and analysis of
policies. This paper presents Deontic STAIRS, an extension of the UML
sequence diagram notation with customized constructs for policy specification. The notation is underpinned by a denotational trace semantics.
We formally define what it means that a system satisfies a policy specification, and introduce a notion of policy refinement. We prove that the
refinement relation is transitive and compositional, thus supporting a
stepwise and modular specification process. The approach is exemplified
with access control policies.
Keywords: Policy specification, policy refinement, policy adherence,
UML sequence diagrams, access control.
1
Introduction
Policy based management of information systems has the last decade been subject to increased attention, and several frameworks, see e.g. [1], have been introduced for the purpose of policy specification, analysis and enforcement. At the
same time the UML 2.1 [2] has emerged as the de facto standard for the modeling and specification of information systems. However, the UML offers little
specialized support for the specification and analysis of policies.
Policy specifications are used in policy based management of systems. The domain of management may vary, but typical purposes are access control, security
and trust management, and management of networks and services. Whatever the
management domain, the purpose is to control behavioral aspects of a system.
This is reflected in our definition of a policy, adopted from [3], viz. that a policy
is a set of rules governing the choices in the behavior of a system.
A key feature of policies is that they “define choices in behavior in terms of the
conditions under which predefined operations or actions can be invoked rather
than changing the functionality of the actual operations themselves” [1]. This
means that the capabilities or potential behavior of the system generally span
wider than what is prescribed by the policy, i.e. the system can potentially violate
the policy. A policy can therefore be understood as a set of normative rules about
S. Jajodia, and J. Lopez (Eds.): ESORICS 2008, LNCS 5283, pp. 300–316, 2008.
c Springer-Verlag Berlin Heidelberg 2008
Compositional Refinement of Policies in UML
301
a system, defining the ideal, desirable or acceptable behavior of the system. In
our approach, each rule is classified as either a permission, an obligation or a
prohibition. This classification is based on standard deontic logic [4], and several
of the existing approaches to policy specification have language constructs of such
a deontic type, e.g. [3, 5, 6, 7]. This categorization is furthermore implemented in
the ISO/IEC standard for open distributed processing [8].
The contribution of this paper is firstly an extension of the UML sequence diagram notation suitable for specifying policies. In [9] we evaluated UML sequence
diagrams as a notation for policy specification, and argued that although the
notation to a large extent is sufficiently expressive, it is not suitable for policy
specification. The reason for this lies heavily in the fact that there are no constructs for expressing deontic modalities. In this paper we propose a customized
notation, referred to as Deontic STAIRS, which is underpinned by the denotational trace semantics of the STAIRS approach to system development with
UML sequence diagrams [10, 11]. The notation is not tailored for a specific type
of policy, thus allowing the specification of policies for access control, security
management, trust management, etc. In this paper the approach is exemplified
with access control policies, whereas the work presented in [12] demonstrates the
suitability of the notation to express trust management policies.
Secondly, this paper contributes by introducing a notion of policy adherence
that formally defines what it means that a system satisfies a policy specification.
As pointed out also elsewhere [13, 14], although recognized as an important
research issue, policy refinement still remains poorly explored in the literature.
This paper contributes thirdly by proposing a notion of policy refinement that
supports an incremental policy specification process from the more abstract and
high-level to the more concrete and low-level. We show that the refinement
relation is transitive, which is an important property as it allows a stepwise
development process. We also show that each of a set of composition operators
is monotonic with respect to the refinement relation. In the literature this is
often referred to as compositionality, and means that a policy specification can
be refined by refining individual parts of the specification separately.
Through refinement more details are added, and the specification is typically tailored towards an intended system (possibly including an enforcement
mechanism). The set of systems that adhere to the policy specification thereby
decreases. We show that the refinement relation ensures that if a system adheres
to a concrete, refined policy specification, it also adheres to the more abstract
specifications. Enforcement of the final specification thus implies the enforcement
of the specifications from the earlier phases.
For specific domains a special purpose policy language, e.g. XACML [15] for
access control, will typically have tailored constructs for its domain. A general
purpose language such as Deontic STAIRS is, however, advantageous as it offers
techniques for policy capturing, specification, development and analysis across
domains and at various abstraction levels.
The next section introduces UML sequence diagrams and the STAIRS denotational semantics. In Sect. 3 we propose the customized syntax and semantics
302
B. Solhaug and K. Stølen
for policy specification with sequence diagrams. Sect. 4 formalizes the notion of
policy adherence, whereas policy refinement is defined and analyzed in Sect. 5.
Related work is discussed in Sect. 6 before we conclude in Sect. 7.
2
UML Sequence Diagrams and STAIRS
In this section we introduce the UML 2.1 sequence diagram notation and give
a brief introduction to the denotational semantics as defined in the STAIRS
approach. STAIRS formalizes, and thus precisely defines, the trace semantics
that is only informally described in the UML 2.1 standard.
UML interactions describe system behavior by showing how entities interact
by the exchange of messages. The behavior is described by traces which are
sequences of event occurrences ordered by time. Several UML diagrams can
specify interactions, and in this paper we focus on sequence diagrams where
each entity is represented with a lifeline. To illustrate language constructs and
central notions, we use a running example throughout the paper in which the
interaction between a user U and an application A is defined. The diagram M to
the left in Fig. 1 is very basic and has only two events, the sending of the message
login(id) on U (which we denote !l) and the reception of the same message on A
(denoted ?l). The send event must occur before the receive event. The semantics
of the diagram M is given by the single trace of these two events, denoted !l, ?l.
The diagram W to the right in Fig. 1 shows the sending of the two messages
l and r from U to A, where r denotes read(doc). The order of the events on each
lifeline is given by their vertical positions, but the two lifelines are independent.
The semantics for each of the messages is as for the message in diagram M ,
and the semantics of W is given by weak sequencing of the two messages. Weak
sequencing takes into account the independence of lifelines, so the semantics for
the diagram W is given by the set {!l, ?l, !r, ?r, !l, !r, ?l, ?r}. The two traces
represents the valid interpretations of the diagram; the sending of l is the first
event to occur, but after that both the reception of l and the sending of r may
occur.
sd M
U
A
login(id)
sd W
U
A
login(id)
read(doc)
Fig. 1. Sequence diagrams
The UML sequence diagram notation has further constructs for combining diagrams, most notably alt for specifying alternatives, par for parallel composition,
and loop for several sequential compositions of one diagram with itself.
Compositional Refinement of Policies in UML
303
The traces of events defined by a diagram are understood as representing
system runs. In each trace a send event is ordered before the corresponding
receive event, and H denotes the trace universe, i.e. the set of all traces that
complies with this requirement. A message is in the STAIRS denotational semantics given by a triple (s, tr, re) of a signal s, a transmitter tr and a receiver
re. The transmitter and receiver are lifelines. L denotes the set of all lifelines
and M denotes the set of all messages. An event is a pair of kind and message,
(k, m) ∈ {!, ?} × M. By E we denote the set of all events, and we define the
functions k. ∈ E → {!, ?}, tr. , re. ∈ E → L to yield the kind, transmitter and
receiver of an event, respectively.
S and T are for concatenation of sequences, filtering of
The functions , sequences and filtering of pairs of sequences, respectively. Concatenation is to
glue sequences together, so h1 h2 is the sequence that equals h1 if h1 is infinite.
Otherwise it denotes the sequence that has h1 as prefix and h2 as suffix, where
the length equals the sum of the length of h1 and h2 .
S a we denote the sequence obtained from the sequence a by removBy E ing all elements from a that are not in the set of elements E. For example,
S 1, 1, 2, 1, 3, 2 = 1, 1, 1, 3.
{1, 3} T is described as follows. For any set of pairs of elThe filtering function T t we denote the pair of sequences
ements F and pair of sequences t, by F obtained from t by truncating the longest sequence in t at the length of the
shortest sequence in t if the two sequences are of unequal length; for each
j ∈ {1, . . . , k}, where k is the length of the shortest sequence in t, selecting
or deleting the two elements at index j in the two sequences, depending on
whether the pair of these elements is in the set F . For example, we have that
T (1, 1, 2, 1, 2, f, f, f, g, g) = (1, 1, 1, f, f, g).
{(1, f ), (1, g)} Parallel composition () of trace sets corresponds to the pointwise interleaving of their individual traces. The ordering of the events within each trace is
maintained in the result. Weak sequencing () is implicitly present in sequence
diagrams and defines the partial ordering of the events in the diagram. For trace
sets H1 and H2 , the formal definitions are as follows.
def
– H1 H2 = {h ∈ H | ∃s ∈ {1, 2}∞ :
T (s, h)) ∈ H1 ∧
π2 (({1} × E) T (s, h)) ∈ H2 }
π2 (({2} × E) def
S h = e.l S h1 e.l S h2 }
– H1 H2 = {h ∈ H | ∃h1 ∈ H1 , h2 ∈ H2 : ∀l ∈ L : e.l
{1, 2}∞ is the set of all infinite sequences over the set {1, 2}, and π2 is a projection
operator returning the second element of a pair. The infinite sequence s in the
definition can be understood as an oracle that determines which of the events in
h that are filtered away. The expression e.l denotes the set of events that may
take place on the lifeline l. Formally
def
e.l = {e ∈ E | (k.e = ! ∧ tr.e = l) ∨ (k.e = ? ∧ re.e = l)}
304
B. Solhaug and K. Stølen
The semantics of a sequence diagram is defined by the function [[ ]] that for
a sequence diagram d yields a set of traces [[d]] ⊆ H representing the behavior
described by the diagram.
Definition 1. Semantics of sequence diagrams.
def
[[e]] = {e} for any e ∈ E
def
[[d1 par d2 ]] = [[d1 ]] [[d2 ]]
def
[[d1 seq d2 ]] = [[d1 ]] [[d2 ]]
def
[[d1 alt d2 ]] = [[d1 ]] ∪ [[d2 ]]
For the formal definition of further constructs and the motivation behind the
definitions, see [10, 11].
3
Specifying Policies
In this section we present Deontic STAIRS, a customized notation for specifying policies with sequence diagrams. The notation is defined as a conservative
extension of UML 2.1 sequence diagrams. We furthermore define a denotational
trace semantics.
The notation constructs are illustrated by the examples of policy rules depicted in Fig. 2. We consider a policy that administrates the access of users U
to an application A.
A policy rule is defined as a sequence diagram that consists of two parts, a
trigger and a deontic expression. The trigger is a scenario that specifies the condition under which the given rule applies and is captured with the keyword trigger.
The body of the deontic expression describes the behavior that is constrained
by the rule, and the keywords permission, obligation and prohibition indicate the
modality of the rule. The name of the rule consists of two parts, where the former
part is the keyword rule, and the latter part is any chosen name for the rule.
The rule access to the left in Fig. 2 is a permission stating that by the sending
the message loginOK from the application to the user, i.e. the id of the user has
been verified, the user is permitted to retrieve documents from the system. In
case of login failure, the rule bar to the right in Fig. 2 specifies that document
retrieval is prohibited, i.e. the user is barred from accessing the application.
Generally, a diagram specifying a policy rule contains one or more lifelines,
each representing a participating entity. There can be any number of entities,
but at least one. In the examples we have for simplicity shown only two lifelines,
U and A. We also allow the trigger to be omitted. In that case the rule applies
under all circumstances and is referred to as a standing rule.
By definition of a policy, a policy specification is given as a set of rules, each
specified in the form shown in Fig. 2.
The extension of the sequence diagram notation presented in this section is
conservative with respect to the UML standard, so people that are familiar with
Compositional Refinement of Policies in UML
rule access
rule bar
U
trigger
305
A
loginOK
permission
U
trigger
A
loginFail
prohibition
read(doc)
doc
read(doc)
doc
Fig. 2. Policy rules
UML should be able to understand and use the notation. All the constructs that
are available in the UML for specification of sequence diagrams can furthermore
freely be used in the specification of the body of a policy rule.
Semantically, the triggering scenario and the body of a rule are given by trace
sets T ⊆ H and B ⊆ H, respectively. Additionally, the semantics must capture
the deontic modality, which we denote by dm ∈ {pe, ob, pr}. The semantics of a
policy rule is then given by the tuple r = (dm, T, B). Notice that for standing
rules, the trigger is represented by the set of all traces, i.e. T = H. Since a policy
is a set of policy rules, the semantics of a policy specification is given by a set
P = {r1 , . . . , rm }, where each ri is the semantic representation of a policy rule.
4
Policy Adherence
In this section we define the adherence relation →a that for a given policy specification P and a given system S defines what it means that S satisfies P , denoted
P →a S. We assume a system model in which the system is represented by a
(possibly infinite) set of traces S, where each trace describes a possible system
execution. In order to define P →a S, we first define what is means that a system
adheres to a rule r ∈ P , denoted r →a S.
A policy rule applies if and when a prefix h of an execution h ∈ S triggers
the rule, i.e. the prefix h h fulfills the triggering scenario T . The function is a predicate that takes two traces as operand and yields true iff the former is
equal to or a prefix of the latter. Since the trace set T represents the various
executions under which the rule applies, it suffices that at least one trace t ∈ T
is fulfilled by h for the rule to trigger. Furthermore, for h to fulfill t, the trace
t must be a sub-trace of h , denoted t h .
For traces h1 , h2 ∈ H, if h1 h2 we say that h1 is a sub-trace of h2 and,
equivalently, that h2 is a super-trace of h1 . Formally, the sub-trace relation is
defined as follows.
h1 h2 = ∃s ∈ {1, 2}∞ : π2 (({1} × E)
def
T
(s, h2 )) = h1
306
B. Solhaug and K. Stølen
The expression h1 h2 evaluates to true iff there exists a filtering such
that when applied to h2 the resulting trace equals h1 . For example, a, b, c e, a, b, e, f, c.
Formally, the triggering of a rule (dm, T, B) by a trace h ∈ S is defined as
follows.
Definition 2. The rule (dm, T, B) is triggered by the trace h iff ∃t ∈ T : t h.
To check whether a system S adheres to a rule (dm, T, B) we first need to
identify all the triggering prefixes of traces of S. Then, for each triggering prefix,
we need to check the possible continuations. As an example, consider the system
S = {h1 , h2 , h3 }. Assume that h1 and h2 have a common prefix ha that triggers
the rule, i.e. h1 and h2 can be represented by the concatenations ha hb and
ha hc , respectively, such that ∃t ∈ T : t ha . Assume, furthermore, that the
system trace h3 does not trigger the rule, i.e. ¬∃t ∈ T : t h3 .
The three runs can be structured into a tree as depicted in Fig. 3. Adherence to a policy rule intuitively means the following. The system adheres to
the permission (pe, T, B) if at least one of the traces hb and hc fulfills B; so
a permission requires the existence of a continuation that fulfills the behavior.
The system adheres to the obligation (ob, T, B) if both of hb and hc fulfill B;
so an obligation requires that all possible continuations fulfill the behavior. The
system adheres to the prohibition (pr, T, B) if neither hb nor hc fulfill B; so a
prohibition requires that none of the possible continuations fulfill the behavior.
Notice that to fulfill the behavior given by the trace set B, it suffices to fulfill
one of the traces since each element of B represents a valid way of executing the
behavior described by the rule body. As for the trace h3 , since the rule is not
triggered, the rule is trivially satisfied.
h1
h2
hb
hc
h3
ha
Fig. 3. Structured traces
A rule body is described by a set of traces B, so the super-traces of the
elements of B represent the various ways of fulfilling this behavior. This set is
defined by {h ∈ H | ∃h ∈ B : h h} and denoted B.
Adherence to policy rule r of system S, denoted r →a S is defined as follows,
where h|k is a truncation operation that yields the prefix of h of length k ∈ N.
Compositional Refinement of Policies in UML
307
Definition 3. Adherence to policy rule of system S:
def
– (pe, T, B) →a S = ∀h ∈ S : h ∈ T ⇒
∃h ∈ S : ∃k ∈ N : h|k h ∧ h|k ∈ T ∧ h ∈ (T B)
def
– (ob, T, B) →a A = ∀h ∈ S : h ∈ T ⇒ h ∈ (T B)
def
– (pr, T, B) →a A = ∀h ∈ S : h ∈ T ⇒ h ∈
/ (T B)
With these definitions of adherence to policy rule of a system S, we define
adherence to a policy specification P as follows.
def
Definition 4. P →a S = ∀r ∈ P : r →a S
Example 1. As an example of policy rule adherence, consider the permission rule
access to the left in Fig. 2 stating that users U are allowed to retrieve documents
from the application A after a valid login. Semantically, we have access = (pe, T, B),
where T is the singleton set {(!, (loginOK,A,U)), (?, (loginOK,A,U))} and B is the
singleton set containing the sequence of events depicted to the left in Fig. 4.
Trace of rule access Partial trace of S
(!, (read(doc),U,A))
(?, (read(doc),U,A))
(!, (doc,A,U))
(?, (doc,A,U))
···
(!, (login(id),U,A))
(?, (login(id),U,A))
(!, (query(id),A,SA))
(?, (query(id),A,SA))
(!, (valid(id),SA,A))
(?, (valid(id),SA,A))
(!, (loginOK,A,U))
(?, (loginOK,A,U))
(!, (read(doc),U,A))
(?, (read(doc),U,A))
(!, (doc,A,U))
(?, (doc,A,U))
(!, (store(doc’),U,A))
(?, (store(doc’),U,A))
···
Fig. 4. Traces of rule and system
To the right in Fig. 4 we have shown a partial trace of S in the case that
access →a S. The user U sends a login message to the application A, after which
the application sends a query to the security administrator SA to verify the id
of the user. At some point in the execution the events (!, (loginOK,A,U)) and
(?, (loginOK,A,U)) triggering the rule occur. The user then retrieves a document
and finally stores a modified version. Since there exists a filtering of the system
trace that equals the trace representing the body of the permission rule, the
system adheres to the rule. Other system traces with the same triggering prefix
need not fulfill the trace of the rule since the rule is a permission.
308
B. Solhaug and K. Stølen
The definition of policy adherence is based the satisfiability relation of deontic
logic which defines what it means that a model satisfies a deontic expression.
Standard deontic logic is a modal logic that is distinguished by the axiom OBp ⊃
PEp, stating that all that is obligated is also permitted. The next theorem states
that this property as well as the definitions OBp ≡ ¬PE¬p (p is obligated iff the
negation of p is not permitted) and OBp ≡ PR¬p (p is obligated iff the negation
of p is prohibited) of deontic logic are preserved by our definition of adherence.
Theorem 1
– (ob, T, B) →a S ⇒ (pe, T, B) →a S
– (ob, T, B) →a S ⇔ (¬pe, T, ¬B) →a S
– (ob, T, B) →a S ⇔ (pr, T, ¬B) →a S
Notice that the use of negation in the theorem is pseudo-notation. The precise
definitions are as follows, where H denotes the complement H\H for H ⊆ H.
def
– (¬pe, T, ¬B) →a S = ∀h ∈ S : h ∈ T ⇒
¬∃h ∈ S : ∃k ∈ N : h|k h ∧ h|k ∈ T ∧ h ∈ (T B)
– (pr, T, ¬B) →a A
def
= ∀h ∈ S : h ∈ T ⇒ h ∈
/ (T B)
The first clause of Theorem 1 follows immediately from the definition of adherence, whereas the second and third clause are shown by manipulation of
quantifiers, negations and set inclusions.
Generally, the inter-definability axioms of deontic logic linking obligations
to permissions are not adequate for policy based management of distributed
systems since permissions may be specified independently of obligations and by
different administrators. An obligation rule of a network configuration policy,
for example, does not imply the authorization to conduct the given behavior if
authorizations are specified in the form of permission rules of a security policy.
However, an obligation for which there is no corresponding permission represents a policy conflict which must be resolved for the policy to be enforceable.
A policy specification P is consistent, or conflict free, iff there exists a system
S such that P →a S. Theorem 1 reflects properties of consistent policy specifications, and if any of these properties are not satisfied there are occurrences of
modality conflicts, and the policy cannot be enforced.
There are five types of modality conflicts. First, obligation to conduct the
behavior represented by the set of traces B, while the complement B is also
obligated; second, prohibiting B while prohibiting the complement B; third,
prohibiting B while obligating B; four, permitting B while obligating B; five,
prohibiting B while also permitting B.
In policies for distributed systems conflicts are likely to occur since different
rules may be specified by different managers, and since multiple policy rules may
apply to the same system entities. The problem of detecting and resolving policy
conflicts is outside the scope of this paper, but existing solutions to resolving
modality conflicts, see e.g. [16], can be applied.
Compositional Refinement of Policies in UML
5
309
Policy Refinement
We aim for a notion of refinement that allows policy specifications to be developed in a stepwise and modular way. Stepwise refinement is ensured by transitivity, which means that a policy specification that is the result of a number
of refinement steps is a valid refinement of the initial, most abstract specification. Modularity means that a policy specification can be refined by refining
individual parts of the specification separately.
Refinement of a policy rule means to weaken the trigger or strengthen the
body. A policy specification may also be refined by adding new rules to the
specification. Weakening the trigger means to increase the set of traces that
trigger the rule. For permissions and obligations, the body is strengthened by
reducing the set of traces representing the behavior, whereas the body of a prohibition is strengthened by increasing the set of prohibited traces. The refinement
relation tr for the triggering scenario, and the refinement relations pe , ob
and pr for the body of permissions, obligations and prohibitions, respectively,
are defined as follows.
Definition 5. Refinement of policy trigger and body:
def
– T tr T = T ⊇ T
def
– B pe B = B ⊆ B
def
– B ob B = B ⊆ B
def
– B pr B = B ⊇ B
Obviously, these relations are transitive and reflexive. The relations are furthermore compositional, which means that the different parts of a sequence diagram
d can be refined separately. Compositionality is ensured by monotonicity of the
composition operators with respect to refinement as expressed in the following
theorem. The instances of the relation denote any of the above four refinement
relations.
Theorem 2. If d1 d1 and d2 d2 , then the following hold.
– d1 seq d2 d1 seq d2
– d1 alt d2 d1 alt d2
– d1 par d2 d1 par d2
The theorem follows directly from the definition of the composition operators.
Since the refinement relations are defined by the subset and the superset relations, the theorem is proven by showing that the operators , ∪ and on trace
sets (defining sequential, alternative and parallel composition, respectively) are
monotonic with respect to ⊆ and ⊇. For seq and ⊆, the result
[[d1 ]] ⊆ [[d1 ]] ∧ [[d2 ]] ⊆ [[d2 ]] ⇒ [[d1 ]] [[d2 ]] ⊆ [[d1 ]] [[d2 ]]
holds since the removal of elements from [[d1 ]] or [[d2 ]] yields a reduction of set of
traces that results from applying the operator. The case of monotonicity of 310
B. Solhaug and K. Stølen
with respect to ⊇ is symmetric. The argument for par, i.e. monotonicity of , is
similar to seq, whereas the case of the union operator ∪ defining alt is trivial.
We now define refinement of a policy rule as follows.
def
Definition 6. (dm, T, B) (dm , T , B ) = dm = dm ∧ T tr T ∧ B dm B It follows immediately from reflexivity and transitivity of the refinement relations
tr and dm that the refinement relation for policy rules is also reflexive
and transitive.
A policy is a set of rules, and for a policy specification P to be a refinement
of policy specification P , we require that each rule in P must be refined by a
rule in P .
def
Definition 7. P P = ∀r ∈ P : ∃r ∈ P : r r
Theorem 2 address composition of interactions within a policy rule r. At the
level of policy specifications, composition is simply the union of rule sets P . It
follows straightforwardly that policy composition is monotonic with respect to
refinement, i.e. P1 P1 ∧ P2 P2 ⇒ P1 ∪ P2 P1 ∪ P2 . Refinement of policy
specifications is furthermore transitive, i.e. P1 P2 ∧ P2 P3 ⇒ P1 P3 .
Development of policy specifications through refinement allows an abstract
and general view of the system in the initial phases, ignoring details of system
behavior, design and architecture. Since the specification is strengthened through
refinement and more detailed aspects of the system are considered, the set of
systems that adhere to the policy specification decreases. However, a system that
adheres to a concrete, refined specification also adheres to the initial, abstract
specification. This means that if a policy specification is further refined before
it is enforced, the enforcement ensures that the initial, abstract specification is
also enforced. This is expressed in the next theorem.
Theorem 3. Given a system S and policy specifications P and P , if P P and P →a S, then P →a S.
Policy composition and refinement do not rely on the assumption that the rules
are mutually consistent or conflict free, which means that inconsistencies may
be introduced during the development process. However, potential conflicts are
generally inherent in policies for distributed systems [16]. Development of policy
specification with refinement is in this respect desirable since conflicts and other
errors are generally easier to detect and correct at abstract levels.
Example 2. In the following we give an example of policy specification refinement. Let, first, P1 = {access, bar} be the policy specification given by the permission and the prohibition depicted in Fig. 2. Refinement allows adding rules
to the specification, so assume the obligation rule loginFail to the left in Fig. 5
and the obligation rule disable in Fig. 6 are added to the rule set such that
P2 = {access, bar, loginFail, disable}.
The former rule states that the application is obligated to alert the user in
case of a login failure, i.e. when the user id is invalid. The latter rule, adapted
Compositional Refinement of Policies in UML
rule loginFail
rule loginFail2
U
trigger
311
A
U
SA
trigger
invalid(id)
obligation
invalid(id)
loginFail(id)
obligation
loginFail
L
loginFail(n,id)
loginFail
Fig. 5. Login failure
from [7], states that in case of three consecutive login failures, the application is
obligated to disable the user, log the incident and alert the user.
The body of the rule to the left in Fig. 6 is specified with the UML 2.1 sequence diagram construct called interaction use which is a reference to another
diagram. The interaction use covers the lifelines that are included in the referenced diagram. The body is defined by the parallel composition of the three
diagrams d (disable the user), l (log the incident) and a (alert the user) to the
right in Fig. 6. Equivalently, the referenced diagrams can be specified directly in
place of the respective interaction uses.
By reflexivity, the permission and prohibition of P2 are refinements of the
same rules in P1 . Since adding rules is valid in refinement, P2 is a refinement of
P1 . Obviously, a system that adheres to P2 also adheres to P1 .
The rules in both P1 and P2 refer to interactions only between the application
and the users, which may be suitable at the initial development phases. At later
rule disable
U
A
A
disable(id)
trigger
loginFail(3,id)
obligation
par
sd d
sd l
ref
sd d
ref
sd l
ref
sd a
A
log(disabled,id)
sd a
U
A
disabled
Fig. 6. Disable user
312
B. Solhaug and K. Stølen
stages, however, the policy specification is typically specialized towards a specific
system, and more details about the system architecture is taken into account.
This is supported through refinement by decomposition of a single entity into
several entities, thus allowing behavior to be specified in more detail. Due to
space limits refinement by detailing is only exemplified in this paper. See [10]
for a formal definition.
The rule loginFail2 to the right in Fig. 5 shows a refinement of the rule loginFail
to the left in the same figure. Here, the application A has been decomposed
into the entities security administrator SA and log L. The refined obligation
rule states that by the event of login failure, the security administrator must
log the incident before alerting the user. The log also reports to the security
administrator the current number n of consecutive login failures. Observe that
the modality as well as the trigger are the same in both loginFail and loginFail2,
and that the interactions between the application and the user are identical. This
implies that loginFail2 is a detailing of loginFail. Hence, loginFail loginFail2.
It is easily seen that adherence to the latter rule implies adherence to the former.
Compositionality of refinement means that for a given policy specification,
the individual rules can be refined separately. This means that for the policy
specification P3 = {access, bar, loginFail2, disable} we have P2 P3 and that for
all systems S, P3 →a S implies P2 →a S. By transitivity of refinement we also
have that P1 P3 and that adherence to P3 implies adherence to P1 .
Compositionality of refinement also means that in order to refine a policy rule,
the individual parts of the body of a rule can be refined separately. We illustrate
this by showing a refinement of the body of the rule disable of Fig. 6. The body
shows the parallel composition of three diagrams, denoted d par l par a.
Fig. 7 shows refinement of the diagram elements d and l into d2 and l2, respectively. In d2 the lifeline A has been decomposed into the components security
administrator SA and user store US and shows the security administrator disabling a user by sending a message to the user store. We now have that d d2
and, similarly, that l l2 for the other diagram element. By compositionality
of refinement of rule body, we get that (d par l par a) (d2 par l2 par a).
sd d2
SA
US
sd l2
SA
L
disable(id)
log(disabled,id)
ok
ok
Fig. 7. Refined diagrams
Let the obligation rule disable2 be defined by replacing the references to d and
l in disable of Fig. 6 with references to d2 and l2, respectively, of Fig. 7. We now
have that disable disable2. The policy specification P4 = {access, bar, loginFail2, disable2} is a refinement of P3 and, by transitivity, a refinement of P2 and
P1 also. As before, P4 →a S implies P1 →a S for all systems S.
Compositional Refinement of Policies in UML
313
These examples show how more detailed aspects of system architecture and
behavior may be taken into account at more refined levels. Another feature of
refinement is that the behavior defined at abstract levels can be constrained
at more concrete levels by ruling out alternatives. As an example, consider the
body of the rule disable2 which semantically is captured by the set trace set
[[d2 par l2 par a]]. This defines an interleaving of the traces of the three elements;
there are no constraints on the ordering between them. The ordering can, however, be constrained by using sequential composition instead of parallel composition. If, for example, it is decided that the disabling of the user and the logging
of the incident should be conducted before the user is alerted, this is defined
by (d2 par l2) seq a. Sequential composition is a special case of parallel composition, so semantically we now have that [[(d2 par l2) seq a]] ⊆ [[d2 par l2 par a]].
For the obligation rule, the former set of traces represents a refinement of the
latter set of traces.
Let disable3 be defined as disable2 where d2 par l2 par a of the latter is replaced with (d2 par l2) seq a in the former. Then disable2 disable3. By defining the specification P5 = {access, bar, loginFail2, disable3} we have P4 P5 .
By transitivity, P5 is a refinement of all the previous policy specifications of this
example, and adherence to P5 implies adherence to them all.
6
Related Work
Although a variety of languages and frameworks for policy based management
has been proposed the last decade or so, policy refinement is still in its initial
phase and little work has been done on this issue. After being introduced in [17]
the goal-based approach to policy refinement has emerged as a possible approach
and has also later been further elaborated [13, 14, 18].
In the approach described in [17], system requirements that eventually are
fulfilled by low-level policy enforcement are captured through goal refinement.
Initially, the requirements are defined by high-level, abstract policies, and so
called strategies that describe the mechanisms by which the system can achieve
a set of goals are formally derived from a system description and a description
of the goals. Formal representation and reasoning are supported by the formalization of all specifications in event calculus.
Policy refinement is supported by the refinement of goals, system entities and
strategies, allowing low-level, enforceable policies to be derived from high-level,
abstract ones. Once the eventual strategies are identified, these are specified as
policies the enforcement of which ensures the fulfillment of the abstract goals. As
opposed to our approach, there is no refinement of policy specifications. Instead,
the final polices are specified with Ponder [7], which does not support the specification of abstract policies that can be subject to refinement. The goal-based
approach to policy refinement hence focus on refinement of policy requirements
rather than policy specifications.
The same observations hold for the goal-based approaches described in [13, 14,
18], where the difference between [13, 17] and [14, 18] mainly is on the strategies
314
B. Solhaug and K. Stølen
for how to derive the policies to ensure the achievement of a given goal. The former use event calculus and abduction in order to derive the appropriate strategies,
whereas the latter uses automated state exploration for obtaining the appropriate
system executions. All approaches are, however, based on requirements capturing
through goal refinement, and Ponder is used as the notation for the eventual policy
specification.
In [13] a policy analysis and refinement tool supporting the proposed formal
approach is described. In [17], the authors furthermore show that the formal
specifications and results can be presented with UML diagrams to facilitate usability. The UML is, however, used to specify goals, strategies, etc., and not the
policies per se as in our approach. In our evaluation of the UML as a notation for
specifying policies [9] we found that sequence diagrams to a large extent have
the required expressiveness, but that the lack of a customized syntax and semantics makes them unsuitable for this purpose. The same observation is made
in attempts to formalize policy concepts from the reference model for open distributed processes [8] using the UML [6, 19]. Nevertheless, in this paper we have
shown that with minor extensions, policy specification and refinement can be
supported.
UML sequence diagrams extends message sequence charts (MSCs) [20], and
both MSCs and a family of approaches that have emerged from them, e.g.
[21, 22, 23, 24], could be considered as alternatives to notations for policy specification. These approaches, however, lack the expressiveness to specify policies
and capture a notion of refinement with the properties demonstrated in this
paper.
Live sequence charts (LSCs) [22] and modal sequence diagrams (MSDs) [21]
are two similar approaches based on a distinction between existential and universal diagrams. This distinction can be utilized to specify permissions, obligations
and prohibitions. However, conditionality is not supported for existential diagrams in LSCs which means that diagrams corresponding to our permissions
cannot be specified with triggers. A precise or formal notion of refinement is also
not defined for these approaches. In [23], a variant of MSCs is provided a formal
semantics and is supported by a formal notion of refinement. MSCs are interpreted as existential, universal or negative (illegal) scenarios, which is related
to the specification of permissions, obligations and prohibitions, respectively, in
Deontic STAIRS. There are, however, no explicit constructs in the syntax for
distinguishing between these interpretations. Conditional scenarios with a triggering construct are supported in [23], but as for LSCs the composition of the
triggering scenario and the triggered scenario is that of strong sequencing. This
can be unfortunate in the specification of distributed systems in which entities
behave locally and interact with other entities asynchronously.
Triggered message sequence charts (TMSCs) [24] allow the specification of
conditional scenarios and is supported by compositional refinement. There is,
however, no support for distinguishing between permitted, obligated and prohibited scenarios; a system specification defines a set of valid traces, and all other
traces are invalid.
Compositional Refinement of Policies in UML
7
315
Conclusion and Future Work
In this paper we have shown that the deontic notions of standard deontic logic [4]
can be expressed in the UML by a conservative extension of the sequence diagram notation, thus enabling policy specification. We have defined both a formal
notion of policy adherence and a formal notion of refinement. The refinement relation is transitive and also supports a compositional policy development, which
means that individual parts of the policy specification can be developed separately. The refinement relation also ensures that the enforcement of a low-level
policy specification implies the enforcement of the initial high-level specification.
Stepwise and compositional development of policy specifications is desirable as
it facilitates the development process. Policy analysis is furthermore facilitated
as analysis generally is easier and more efficient at abstract levels, and identified
flaws are cheaper to fix. However, for policy analysis to be meaningful at an
abstract level, the results must be preserved under refinement. In future work we
will analyze the refinement relation with respect to such property preservation,
particularly with respect to security, trust and adherence.
In the future we will also define language extensions to allow the specification
of constraints in the form of Boolean expressions that limit the applicability of
policy rules to specific system states. A refinement relation appropriate for this
extension will also be defined.
Acknowledgments. The research on which this paper reports has been funded
by the Research Council of Norway through the projects ENFORCE (164382/
V30) and DIGIT (180052/S10).
References
1. Sloman, M., Lupu, E.: Security and Management Policy Specification. Network,
IEEE 16(2), 10–19 (2002)
2. Object Management Group: Unified Modeling Language: Superstructure, version
2.1.1 (2007)
3. Sloman, M.: Policy Driven Management for Distributed Systems. Journal of Network and Systems Management 2, 333–360 (1994)
4. McNamara, P.: Deontic Logic. In: Gabbay, D.M., Woods, J. (eds.) Logic and the
Modalities in the Twentieth Century. Handbook of the History of Logic, vol. 7, pp.
197–288. Elsevier, Amsterdam (2006)
5. Kagal, L., Finin, T., Joshi, A.: A Policy Language for a Pervasive Computing
Environment. In: Proc. of 4th International Workshop on Policies for Distributed
Systems and Networks (POLICY), pp. 63–74. IEEE CS Press, Los Alamitos (2003)
6. Aagedal, J.Ø., Milošević, Z.: ODP Enterprise Language: UML Perspective. In:
Proc. of 3rd International Conference on Enterprise Distributed Object Computing
(EDOC), pp. 60–71. IEEE CS Press, Los Alamitos (1999)
7. Damianou, N., Dulay, N., Lupu, E., Sloman, M.: The Ponder Policy Specification
Language. In: Sloman, M., Lobo, J., Lupu, E.C. (eds.) POLICY 2001. LNCS,
vol. 1995, pp. 18–38. Springer, Heidelberg (2001)
316
B. Solhaug and K. Stølen
8. ISO/IEC: ISO/IEC FCD 15414, Information Technology - Open Distributed
Processing - Reference Model - Enterprise Viewpoint (2000)
9. Solhaug, B., Elgesem, D., Stølen, K.: Specifying Policies Using UML Sequence
Diagrams – An Evaluation Based on a Case Study. In: Proc. of 8th International
Workshop on Policies for Distributed Systems and Networks (POLICY), pp. 19–28.
IEEE CS Press, Los Alamitos (2007)
10. Haugen, Ø., Husa, K.E., Runde, R.K., Stølen, K.: STAIRS Towards Formal Design
with Sequence Diagrams. Software & Systems Modeling 4, 355–367 (2005)
11. Runde, R.K., Refsdal, A., Stølen, K.: Relating Computer Systems to Sequence Diagrams with Underspecification, Inherent Nondeterminism and Probabilistic Choice.
Technical Report 346, Department of Informatics, University of Oslo (2007)
12. Refsdal, A., Solhaug, B., Stølen, K.: A UML-based Method for the Development
of Policies to Support Trust Management. In: Trust Management II – Proc. of
2nd Joint iTrust and PST Conference on Privacy, Trust Management and Security
(IFIPTM), pp. 33–49. Springer, Heidelberg (2008)
13. Bandara, A.K., Lupu, E., Russo, A., Dulay, N., Sloman, M., Flegkas, P., Charalambides, M., Pavlou, G.: Policy Refinement for DiffServ Quality of Service Management. In: Proc. of 9th IFIP/IEEE International Symposium on Integrated Network
Management (IM 2005), pp. 469–482 (2005)
14. Rubio-Loyola, J., Serrat, J., Charalambides, M., Flegkas, P., Pavlou, G.: A Functional Solution for Goal-Oriented Policy Refinement. In: Proc. of 7th International
Workshop on Policies for Distributed Systems and Networks (POLICY), pp. 133–
144. IEEE CS Press, Los Alamitos (2006)
15. OASIS: eXstensible Access Control Markup Language (XACML) Version 2.1
(2005)
16. Lupu, E., Sloman, M.: Conflicts in Policy-based Distributed Systems Management.
IEEE Transactions on Software Engineering 25, 852–869 (1999)
17. Bandara, A.K., Lupu, E.C., Moffet, J., Russo, A.: A Goal-based Approach to Policy
Refinement. In: Proc. of 5th International Workshop on Policies for Distributed
Systems and Networks (POLICY), pp. 229–239. IEEE CS Press, Los Alamitos
(2004)
18. Rubio-Loyola, J., Serrat, J., Charalambides, M., Flegkas, P., Pavlou, G., Lafuente,
A.L.: Using Linear Temporal Model Checking for Goal-oriented Policy Refinement
Frameworks. In: Proc. of 6th International Workshop on Policies for Distributed
Systems and Networks (POLICY), pp. 181–190. IEEE CS Press, Los Alamitos
(2005)
19. Linington, P.: Options for Expressing ODP Enterprise Communities and Their
Policies by Using UML. In: Proc. of 3rd International Conference on Enterprise
Distributed Object Computing (EDOC), pp. 72–82. IEEE CS Press, Los Alamitos
(1999)
20. International Telecommunication Union: Recommendation Z.120 – Message Sequence Chart (MSC) (1999)
21. Harel, D., Maoz, S.: Assert and Negate Revisited: Modal Semantics for UML Sequence Diagrams. Software & Systems Modeling 7(2), 237–252 (2008)
22. Harel, D., Marelly, R.: Come, Let’s Play: Scenario-Based Programming Using LSCs
and the Play-Engine. Springer, Heidelberg (2003)
23. Krüger, I.H.: Distributed System Design with Message Sequence Charts. Ph.D
thesis, Institut für Informatik, Ludwig-Maximilians-Universität München (2000)
24. Sengupta, B., Cleaveland, R.: Triggered Message Sequence Charts. IEEE Transactions on Software Engineering 32(8), 587–607 (2006)