0.1 Introduction
The ability to efficiently protect resources from unauthorised access and to preserve the integrity and confidentiality of critical data has never been more crucial, leading to an increasing interest in models to effectively control access to information and resources. However, despite the variety of models, there is still a pressing need for effective methods and tools to facilitate the tasks of policy specification and analysis. Formal specifications of access control models and policies have used theorem provers, purposebuilt logics, functional approaches, etc, and although textual languages and logicbased models are convenient for theoreticians or computer experts, graphical models are more appealing to less technical users, therefore urging the development of models that establish a bridge between theoretical tools and the practitioners’ (mainly security administrators) needs. The motivation for developing a graphbased framework is clear: graphs are a natural model for distributed systems, with graphical languages being widely used for describing complex structures in a visual and intuitive way in a variety of domains (software modelling, representation of proofs, microprocessor design, XML documents, communication networks, social networks, biological systems, etc), while graph transformations, or graph rewriting, is used to define the dynamic behaviour of the system modelled.
In this paper we develop a graphbased framework for the visualisation and analysis of obligations in access control policies. Our basis will be CBACO [2], an axiomatic metamodel for access control that deals with obligations in a comprehensive way and which extends the CBAC metamodel [10] that subsumes the most wellknown access control models. The notion of obligation helps to bridge a gap between requirements and policy enforcement. For example, consider a hospital scenario in which any doctor may be authorised to read the medical record of a patient in an emergency situation, but in that case there is a requirement to inform the patient afterwards. Although access control models deal mainly with authorisations, incorporating the notion of an obligation facilitates the tasks of ensuring that obligations are enforced and ensuring that obligations are compatible with authorisations. CBAC(O) focuses on the notion of a category, which is a class of entities that share some property, and permissions are assigned to categories of users, rather than to individual users. Categories can be defined on the basis of user attributes, geographical constraints, resource attributes, etc. In this way, permissions can change in an autonomous way unlike, e.g., rolebased models, which require the intervention of a security administrator. A graphical representation of CBAC policies, including composed policies involving several local policies in a multisite system, was developed in [4], where static properties were checked using basic graph properties on paths. However, to deal with realistic scenarios one needs to be able to answer more complex and relevant questions, based on static and/or dynamic information. In particular, there is a need for tools to analyse the interactions between different policies which may deal with different features of the system.
Taking the graphical model of CBAC as a basis, we develop a new graphical model for CBACO and implement it using PORGY [5], a strategy driven graphrewriting tool based on the theory of portgraphs that provides a visual modelling environment with specific simulation and verification tools, which we believe to be well suited for the analysis of policies. PORGY is based on the theory of portgraphs [7] and implements a strategy driven language for port graph rewriting. In a portgraph, edges attach to nodes at specific connection points called ports. Rules and rewriting strategies are also viewed as portgraphs that can be rewritten into new rules, enabling the modelling of adaptive systems. Portgraphs have been used to model complex systems in the areas of biochemistry and interaction nets, as well as algorithm animation and games. The main contributions of this work are:

We extend CBACO to deal with dynamic aspects of obligations;

We present a new graphical model for CBACO;

We implement our model using the PORGY framework, taking advantage of its strategy driven graphrewriting language to implement the dynamic aspects of our graphical model.
Overview: In Section 0.2, we recall the CBACO metamodel, extend it to deal with the state of duties and briefly describe PORGY. Section 0.3 discusses a graphical model for obligations, while Section 0.4 shows how our graphical model is implemented in PORGY. In Section 0.5 we describe how the strategy language of PORGY can be used to implement the dynamics of the modeled systems. In Section 0.6, we discuss related work, and in Section 0.7, conclusions are drawn and further work is suggested.
0.2 Preliminaries
We briefly describe below the key concepts underlying the metamodel for categorybased access control with obligations and the formalism of portgraphs.
0.2.1 CBACO: Obligations in the categorybased metamodel
The CBACO metamodel [2] is based on the notion of category. Informally, a category is any of several distinct classes or groups to which entities may be assigned. Entities are denoted by constants in a many sorted domain of discourse, including: a countable set of categories, denoted , , , a countable set of principals, denoted , , , a countable set of named actions, denoted , , , a countable set of resource identifiers, denoted , , , a finite set of possible answers to access requests (e.g., {grant, deny, undetermined}), a finite set of events (denoted ), a finite set of event schemes (denoted ) and a finite set of event histories (denoted ). More generally, entities can be represented by a data structure (e.g., a principal could be represented by a term ), but constants will be sufficient for most examples in this paper. We start by defining some notions related to events, permissions, prohibitions, authorisations and obligations. The definitions in this subsection follow the notions defined in [2].
A (specific) event is a ground event specification , which represents an actual action/happening that occurred in a system.
A generic event represents a family of events and is given by an event specification ^{1}^{1}1The definition of what an event specification is, depends on the particular system., to which is associated a context where are the term variables in . Replacing with ground values will result in a ground event specification .
An event history is a possible sequence of events of the system represented as a list of events of the form where every is associated to a specific time and such that if then , according to some notion of ordering on time. A subsequence of is an event interval, denoted , where is the first event of the interval and is the last one. We say that opens the interval and closes it. For every event in such that we say that .
A permission is a pair of an action and a resource, and an authorisation is a triple that associates a permission with a principal.
A generic obligation is an action on a resource that must be performed between two event schemes , represented as a tuple . If there is no starting (resp. closing) event scheme, meaning the obligation can be performed at any time before (resp. after ), then (resp. ) is . A specific/concrete obligation is an obligation where the event schemes are ground terms, therefore corresponding to specific events. Like authorizations, obligations will be assigned to categories, but these might not be the same as authorization categories.
A duty , is a tuple , where is a principal, is a concrete obligation such that there exists a generic obligation assigned to and are instantiations of event schemes , respectively. If there is no starting (resp. closing) event then (resp. ) is .
The metamodel includes the following relations:

, such that iff a principal is assigned to the category .

, such that iff action on resource can be performed by the principals assigned to the category .

, such that iff a principal can perform the action on the resource .

is the prohibitioncategory assignment: iff members of category cannot perform action on resource ;

is the prohibitionprincipal assignment: iff principal cannot perform action on resource ;

is the undetermined permission principal assignment: iff principal is neither authorized nor banned from performing action on resource ;

is the obligationcategory assignment: iff there exists an obligation such that principals of category are obliged to perform action on resource between events that are instantiations of event schemes and ;

is the obligationprincipal assignment: iff there exists an obligation such that principal is obliged to perform action on resource between events that are instantiations of event schemes and ;

is the duty assignment: iff there is a concrete obligation such that principal is obliged to perform action on resource between events and ;

is the event instantiation relation: iff event is an instance of event scheme , denoted , according to an instantiation relation between events and event schemes;

is the event interval relation: iff event closes the interval initiated by event in event history .
The relations defined above satisfy the following axioms, where we assume that there exists a partial ordering between authorisation categories and a partial ordering between obligation categories:
(1) 
(2) 
(3) 
(4) 
(5) 
(6) 
0.2.2 State of Duties
Issued obligations, can be in one of four states: invalid, fulfilled, pending or violated. This is unlike permissions, which are either issued or not. To deal with that, we defined the following new relations to deal with the state of duties:

Fulfilled: , such that if the duty was fulfilled by the event in history .

Pending: , such that if the duty is pending in history .

Violated: , such that if the duty is violated in history .
We do not consider a relation on invalid duties, since our model does not allow them to be issued. Furthermore, we introduce the following axioms regarding the state of duties, where we assume that every history of events starts with an event .
0.2.3 Porgy
PORGY [5] is an interactive tool that has been developed to visualise and analyse port graph reduction systems. Visually, a port graph is a graph where edges are attached to nodes at points called ports. Below we give a brief introduction to port graphs (see [7, 6] for more details and examples). We assume a signature where is a set of attributes; is a set of attribute variables; is a set of values; and is a set of value variables.
We can represent elements of the graph as records (sets of pairs ) over the signature . We assume the attributes Name, Interface, Arity, Attach and Connect. Attribute Name identifies records in the sense that if two records have the same value for attribute Name then they have the same set of defined attributes, although their values can differ.
A port graph over a signature is defined as a tuple where: is a finite set of nodes (denoted ); is a finite set of ports (denoted ); is a finite set of undirected edges (denoted ); is a labeling function. For every element of the sets described above, returns the record associated with it such that: for every node the record contains attribute Interface and returns the set of ports of ; for every port the record contains attributes Attach and Arity, such that gives the number of edges connected to that port and returns the node to which belongs; for every edge the record contains attribute Connect and returns the ports that is connected to.
A port graph rewrite rule is a port graph composed of two subgraphs, and , and a special node (called arrow node) that connects the two. It defines a way of rewriting graphs in the sense that, if there is a instance of , it can be replaced by and the arrow node defines the way to reconnect to the rest of the graph. Ports in the arrow node have attribute Type that can have values bridge, blackhole or wire. These values define the rewriting in the following way:

a port with Type bridge has exactly one edge connecting it to a port of and one or more connecting it to ports of . This type of port defines that edges of the graph being rewritten that are connected to the image of and are not in should be reconnected to every ;

there is at most one port with Type blackhole and it only has edges connected to ports of . It defines that edges connected to such ports should be erased;

a port with Type wire has exactly two edges connecting it to two ports of and it defines that there should be created an edge between every port that is connected to the image of and every port that is connected to the image of .
A rewrite rule matches a graph if there is a morphism such that and the image of every port in not connected to the arrow node is not connected to any port of . This last condition ensures that rewriting does not leave dangling edges.
Given a port graph , a rewrite rule and a morphism such that , a rewriting step from by rule and morphism , denoted , is defined as follows: the build phase: graph is added to ; the rewiring phase: edges connecting to are connected to following the rules set by the arrow node; the deletion phase: is erased obtaining .
Example 1.
In Figure 1 the portgraph on the right is obtained from the portgraph on the left, by applying the portgraph rewrite rule represented by the portgraph in the middle^{2}^{2}2In this rule the top two nodes of L belong to , the top two nodes of R belong to and the bottom one to ..
Given a set of rewrite rules and a graph, it will be possible to apply the rules in different orders and places of the graph. To control that, PORGY uses a strategy language. To define these strategies we start by defining the notions of position and banned subgraphs of a located graph.
A located graph is a graph such that is called the position subgraph and is the banned subgraph. This notion is used in PORGY to select nodes, ports or edges where rewriting should happen and where it cannot happen.
A located rewrite rule can be applied to a located graph by means of a morphism if: ; , if is specified. In this case we write where and .
In lay terms defines the elements of which images should be in the position graph and (resp. ) defines the elements of which images are to be added to the position (resp. banned) subgraph of . In PORGY we can use the strategy language to control both the way rewrite rules are applied and the position and banned subgraphs (see [5] for a complete description of PORGY’s strategy language).
0.3 Graph Representation of Obligations
We now define a graphical model for CBACO that extends the CBAC representation using graphs presented in [4].
Definition 1 (Cbaco policy graph).
A CBACO policy graph is a tuple with:

a finite set of nodes (denoted );

a finite set of undirected edges (denoted );

a labeling function for nodes such that for every node , and where:

iff ;

iff ;

iff ;

iff ;

iff ;

iff ;

iff ;

iff ;

iff ;


a labeling function for edges such that for every edge , gives the two nodes connected by the edge. We also define the function such that . Furthermore if:

then and
; 
then ;

then ;

then ;

then ;

then ;

Nodes of type E have an attribute set to either or . Only one node of type E can have set to , which specifies what is the current event. Nodes of type O represent obligations and are always connected to a node of type and zero, one or two nodes of type G. Other connections will be to nodes of type . Nodes of type D represent duties and are always connected to a node of type a node of type and zero, one or two nodes of type .
Because we represent both and there is the need to distinguish edges of type . Edges that represent the (resp. ) will have the (resp. ) attribute value set to and we write (resp. ).
Edges of type CP_{r} serve the same purpose of the edges of type CA in the graph representation of CBAC in [4] and for that reason have attribute defined as either or and we will write and , respectively, to distinguish edges corresponding to authorizations/prohibitions.
Edges of type OG (resp. DE) have the (resp. ) attribute value set to either or to distinguish between the initial and final event scheme (resp. event). Edges of type GG are used to represent the notion that some event schemes are instantiations of other event schemes and have attribute target set to the node that represents the event scheme that is more general (the one which the other is an instantiation of). Furthermore, the type of this edges when in terms of types of paths will have an arrow on top in the same way edges of type have. Edges of type EE connect events of the same history and have attribute target set to the node that represents the one event that comes after the other. As edges of type and GG the type of this edges in paths will have an arrow on top.
Definition 2 (Path).
Given a policy graph a path of length is a sequence of pairwise distinct nodes such that for every , for some .
Definition 3 (Constrained path and constrained reverse path).
A constrained path of length is a sequence , with pairwise distinct nodes and edges such that for every , and when exists.
A constrained inverse path of length is a sequence with pairwise distinct nodes and edges such that for every , and when exists.
Definition 4 (Types of paths).
Consider a path of length such that for every . The type of this path is given by the types of its edges .
The notation is used to denote that there is a path and its edges are of type .
If an edge of the path is connecting two nodes and both of type then its type will be if and if .
Note that an edge might be both of type and .
Definition 5 (Redundant edges in the Cbaco policy graph).
Consider a CBACO policy graph . An edge is redundant if:

, i.e. it connects nodes such that and with , , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with and , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with and , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with , and , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with , and , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with , , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with , , and there is a path of type and length greater or equal to 2 connecting and ;

, i.e. it connects nodes such that and with and , and there is a path of type and length greater or equal to 2 connecting and .
Definition 6 (Wellformed Cbaco policy graph).
A CBACO policy graph is wellformed iff for every if and then , and for every if then either or have type CP_{r} and , for every with one of the following is true:

;

;

;

;

;

;

;

;

;

;

;

;

;

;

;

;

;
and there are no redundant edges. Moreover if a constrained path and an inverse constrained path begin in the same node with type and end in nodes of type such that the last edges of the paths are of type and , respectively, then the end node must be different. This means that a principal cannot be both able and unable to perform an action on a resource.
A graph defines a particular CBACO policy.
Definition 7 ().
Given a wellformed policy graph the CBACO policy defined by is defined by the following entities and relations:

;

;

;

;

;

;

;

;

;

;

Comments
There are no comments yet.