A formal role-based access control model for security policies in multi-domain mobile networks

Computer Networks 57 (2013) 330–350

Contents lists available at SciVerse ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/locate /comnet

A formal role-based access control model for security policiesin multi-domain mobile networks

D. Unal a,⇑, M.U. Caglayan b,1

a TUBITAK BILGEM (Center of Research for Advanced Technologies of Informatics and Information Security), TUBITAK Gebze Yerleskesi, P.O Box 74, 41470 Gebze,Kocaeli, Turkeyb Bogazici University, TAM Research Center, Kandilli, Istanbul, Turkey

a r t i c l e i n f o

Article history:Received 25 February 2011Received in revised form 16 November 2011Accepted 24 September 2012Available online 5 October 2012

Keywords:Mobile networkMulti-domainSecurity policyAccess controlModel checking

1389-1286/$ - see front matter � 2012 Elsevier B.Vhttp://dx.doi.org/10.1016/j.comnet.2012.09.018

⇑ Corresponding author. Tel.: +90 2626481352; faE-mail addresses: [email protected]

@boun.edu.tr (M.U. Caglayan).1 Principal corresponding author.

a b s t r a c t

Mobile users present challenges for security in multi-domain mobile networks. The actionsof mobile users moving across security domains need to be specified and checked againstdomain and inter-domain policies. We propose a new formal security policy model formulti-domain mobile networks, called FPM-RBAC, Formal Policy Model for Mobility withRole Based Access Control. FPM-RBAC supports the specification of mobility and locationconstraints, role hierarchy mapping, inter-domain services, inter-domain access rightsand separation of duty. Associated with FPM-RBAC, we also present a formal security policyconstraint specification language for domain and inter-domain security policies. Formalpolicy constraint specifications are based on ambient logic and predicate logic. We alsouse ambient calculus to specify the current state of a mobile network and actions withinsecurity policies for evaluation of access requests according to security policies. A novelaspect of the proposed policy model is the support for formal and automated analysis ofsecurity policies related to mobility within multiple security domains.

� 2012 Elsevier B.V. All rights reserved.

1. Introduction

The provision of services in networks with multipleadministrative domains requires support for cross-domainsecurity policy enforcement, management and verification.The multi-domain mobile network environment consistsof multiple interconnected domains and mobile users,hosts and objects as sketched in Fig. 1. Inter-domain poli-cies in such an environment need to support concepts suchas mobility, inter-domain access rights, role mapping andseparation of duty between domains.

An inter-domain security policy is based on a set ofsecurity agreements by participating organizations. Theprovision of inter-domain information sharing with mobileusers call for an inter-domain policy model for mobile net-

. All rights reserved.

x: +90 2626481100.(D. Unal), caglayan

works, which supports the concepts of inter-domain accessrights, role mapping, locations and mobility, as explainedbelow:

1. Inter-domain access rights are access rights for roles of aforeign domain in a local domain and access rights forlocal roles when accessing from a foreign domain. Theserights relate to inter-domain operations.

2. Role mapping maps user roles in one domain to another.e.g. a lecturer in one university may become aresearcher in another.

3. Locations and mobility in multiple domains relate toobject, host and user mobility across domains. A mobileuser needs to be given access due to location and mobil-ity constraints.

Current state-of-the-art in the area of multi-domainsecurity policy management are mostly related to feder-ated systems. The federated system approach [1,2] re-quires a centralized knowledge of all system resources

http://dx.doi.org/10.1016/j.comnet.2012.09.018

mailto:[email protected]

mailto:caglayan @boun.edu.tr

mailto:caglayan @boun.edu.tr


http://www.sciencedirect.com/science/journal/13891286

http://www.elsevier.com/locate/comnet

D. Unal, M.U. Caglayan / Computer Networks 57 (2013) 330–350 331

and multi-domain users, which are assumed to be static inthe network. This approach is not suitable for multi-do-main mobile networks where administration is distributedand also users and resources are mobile. Other studies suchas [3–9] in the area of role based access control policieswith location information is mostly based on location ofusers, not providing a general model for security policiesin a multi-domain mobile network.

In this paper, we propose a new formal security policymodel for multi-domain mobile networks, called FPM-RBAC, Formal Policy Model for Mobility with Role BasedAccess Control, for specification of domain and inter-do-main security policies. The FPM-RBAC model is based onthe well-known RBAC [10,11] model. We use the RBACmodel since roles provide flexibility in assignment andadministration of permissions. In the context of multi-do-main networks, roles are means of mapping permissionsof a user in one domain to another domain. In the contextof mobile networks, roles provide a user with the capabil-ity to carry all permissions associated with a role from onelocation to another. We augment the RBAC model by intro-ducing services, inter-domain access rights, role hierarchymapping, mobility and location constraints and separationof duty based on role mapping, locations and mobility.

Within the FPM-RBAC policy model, ambient logic[12,13] is used to specify dynamic mobility and locationconstraints in security policy rules. Logical constructsbased on predicate logic are used for specification of staticconstraints such as separation of duty. We use the ambientcalculus [14] to specify the current state of a mobile net-work and actions within security policies for evaluationof access requests according to security policies. Thematching of mobility and location constraints in policyrules is accomplished by checking the validity of ambientlogic formulas against ambient calculus specifications

Fig. 1. Example multi-domain mo

based on the model checking algorithms presented in ourprevious work [15].

Our first contribution is the introduction of a formal in-ter-domain policy model for mobile networks. Second con-tribution is a process calculus based formal mobility modelwithin security policies, capable of representing mobilenetwork state as well as complex location and mobilityconstraints. The administration model is distributed,where policy rules for inter-domain access are defined byrole hierarchy mapping between home, inter-domain andforeign roles. Therefore our model does not require the glo-bal knowledge of users and objects and does not introduceconflicts caused by inter-domain hierarchy mapping.

In this study, we present an example scenario where wedemonstrate the concepts introduced above. In this sce-nario, we consider a university involved in a joint researchproject in the e-health area, with a hospital and an indus-trial partner. The project members have a need to accessand share information both locally and remotely from dif-ferent locations, possibly using mobile communication andcomputing devices. Roles in each individual domain maybe mapped to another one through role mapping relationsduring the project. Policy rules for inter-domain accessrights should be in place for accessing joint project infor-mation. Location and mobility of users and informationalso need to be restricted. An inter-domain security policyrule may state that database records from the hospital do-main related to patients may not be accessible from theuniversity or industrial partner domain and may not bewritten to the university domain.

Section 2 summarizes the related work. In Section 3, wepresent the formal role-based security policy model calledFPM-RBAC. In Section 4, we present the verification ofFPM-RBAC security policies by model checking. In Sec-tion 5, we present an algorithm for giving the permission

bile network environment.

332 D. Unal, M.U. Caglayan / Computer Networks 57 (2013) 330–350

or denial decisions for requested actions with respect toFPM-RBAC security policy specifications. Section 6 summa-rizes our current and future research work.

2. Related work

Ambient calculus, proposed by [14], is a process calcu-lus which is able to theorize about concurrent systems thatinclude mobility and locations. Modal logics are used forexpressing properties of models which cannot be ex-pressed by the constructs of calculi. Ambient logic[12,13] is a modal logic for expressing spatial and temporalproperties of ambient calculus. All spatial and temporalconstructs of ambient calculus are reflected in ambient lo-gic. The main differences of ambient logic from latter logicsare introduction of more expressive space modalities andsimpler temporal connectives [16].

Reasoning about spatial configurations for applicationlevel security policies in ubiquitous environments is inves-tigated by [17]. BACIR [18] is a boxed ambient calculuswith RBAC mechanisms used to define access control poli-cies for ambients. ACPEG proposed by [19] is a tool forevaluating and generating access control policies basedon first-order logic. In [20] a generic security policy speci-fication language is used to express rules and manipulatelocations of mobile code. There are various model checkingalgorithms [21,22] for ambient calculus. In our previousworks [15,31], we presented a model checking algorithmfor ambient calculus.

There are various access control models that includetemporal, location and other context-based spatial andtemporal constraints based on the RBAC model. TRBAC by[23] and GTRBAC by [24], an extension of TRBAC, are tem-poral RBAC models. Some of the examples of access controlmodels which include location and context-based con-straints are, SRBAC by [3], LOT-RBAC by [4], Spatio-Tempo-ral RBAC by [5], STRBAC by [6], GEO-RBAC by [7], ContextAware RBAC by [8] and ESTARBAC by [9,25].

Former studies in the area of location based RBAC aremore suitable for environments in which the location ofusers and objects are static in nature. The former modelsaddress locations, however they do not address mobility,which is a fundamental concept for application to mobilenetworks. Locations are defined with first-order relationsover a set of logical locations. Some formalism is providedto specify complex spatial configurations; but no syntax orsemantics are available for mobility of users or objects. Theimpact of role assumption, enabling, activation and per-mission assignment due to mobility are not considered.Additionally the prior location based RBAC models do notconsider inter-domain aspects, such as role-mapping andinter-domain access. For the reasons discussed above, for-mer models are not well-suited for multi-domain mobilenetworks.

Separation of duty (SOD) constraints based on time andlocation have been discussed in the Spatio-Temporal RBACmodel [5]. This study presents a concept for SOD similar toour framework. However, due to the shortcomings in thelocation model, the expressiveness of SOD constraints arelimited. First of all, location based SOD constraints in this

study does not support location expressions or formulasand they are limited to a single location. In contrast, theFPM-RBAC model supports location formulas, which reflectthe dynamic mobility aspects by representing the entiremobile network state. Second, sessions are statically boundto locations. When the location of a user is changed afterlogging into a session, the evaluation result of a SOD con-straint may become invalid. In the FPM-RBAC model, thiskind of SOD constraint is provided through Service Loca-tion based SOD. Third, location constraints are definedthrough predicates that need to be re-evaluated with eachchange in locations, which is not efficient in a mobile envi-ronment. In the FPM-RBAC model, location based SOD con-straints are evaluated by spatio-temporal model checking,which generates all the possible location configurationsbased on actions that result in mobility. Finally, the modelof Ray et al. does not support multiple domains, whereas inFPM-RBAC, SOD constraints based on inter-domain map-pings are supported.

3. FPM-RBAC: Formal Policy Model for Mobility withRole Based Access Control

FPM-RBAC is a multi-domain access control modelbased on the concepts of domain and inter-domain policiesand represents both static and dynamic aspects of securitypolicies in multi-domain mobile networks. The presentedsecurity policy model supports the specification of Role-Based Access Control (RBAC) policies with role hierarchy,object type hierarchy and role mapping in a multi-domainsetting. We define a formal model for network state relatedto locations and provide the mapping of actions to the for-mal model. Specification of location and mobility con-straints as well as Separation-of-Duty (SOD) constraintsis supported.

3.1. Overall structure of FPM-RBAC

FPM-RBAC components are, a location and mobilitymodel, a domain security policy model, an inter-domainsecurity policy model, and a separation of duty model.The representation of location and mobility aspects forobjects, users, hosts and domains is necessary in a multi-domain mobile network. Location and mobility model ofFPM-RBAC is related with representation of location andmobility constraints in the security policy rules as well asthe representation of actions in the security policy rulesand the state of the network with respect to locations.The location and mobility model of FPM-RBAC is presentedin Section 3.2.

The domain policy model of FPM-RBAC introduces theconcepts of domain, service and object type hierarchy tothe RBAC model. The domain security policy model is pre-sented in Section 3.3. An inter-domain security policy in-cludes security requirements for mobility, role mappingand inter-domain access rights among multiple domains.The inter-domain security policy model is presented inSection 3.4.

Separation of Duty (SOD) constraints are related toassignment and activation of roles. In FPM-RBAC, we intro-


duce additional classes of SOD constraints: (i) servicebased SOD, (ii) inter-domain SOD and (iii) location andmobility based SOD. SOD constraints in FPM-RBAC are pre-sented in Section 3.5. The introduced SOD relation types inFPM-RBAC support specification of SOD relations for ser-vice-based multi-domain mobile networks.

3.2. Location and mobility model

Location and mobility model of FPM-RBAC is relatedwith the representation of location and mobility con-straints in the security policy rules as well as the represen-tation of actions in the security policy rules and thelocation configuration of the system. Due to the dynamicnature of mobility, in mobile networks the location (spa-tial) configuration of the system changes with actions.Ambient calculus is used for representation of actions inthe security policy rules and the location configuration ofthe system. The location and mobility constraints in thesecurity policy rules are specified using ambient logic.We provide a very brief overview of ambient calculusand ambient logic in the following section.

3.2.1. Ambient calculus and ambient logicFor specifying dynamic properties of a mobile network

and modeling the spatial and temporal effects of actions,we need to use an executable process calculus. We usethe ambient calculus because it provides natural meansto model location hierarchies and mobility. The fragmentof ambient calculus used in this study is presented in Ta-ble 1. The semantics of ambient calculus is based on thestructural congruence relation.

Properties of ambient calculus processes can be ana-lyzed in two ways, spatial properties and temporal proper-ties. The notion of ambient is the basic element of thespatial properties of processes. Ambients are boundedplaces identified by a name where processes reside insideor outside. Ambients can be nested in other ambients. Thisprovides an hierarchical organization of locations.

Temporal constructs of process algebras represent thechange of processes over time. The ambient calculus pro-vides temporal constructs related to mobility in additionto communication primitives. The main temporal con-structs for modeling entrance, exit and dissolution are ex-pressed as in n, out n, open n respectively. Sequentialexecution is represented by a path, parallel execution isrepresented by the parallel operator (j). A specification inthe form of a[in n.out z.0] represents an ambient a whichwill enter ambient n, exit ambient z and stop. Communica-

Table 1Fragment of ambient calculus used in the study.

P, Q processes M capabilities

0 inactivity x variablePjQ composition n nameM[P] ambient in M can enter MM.P capability out M can exit M(x).P input open M can open MhMi output � null

M.M path

tion primitives enable processes within the same ambientto exchange messages.

Ambient logic has temporal and spatial modalities inaddition to propositional logic elements. Semantics of theconnectives of the ambient logic are defined through satis-faction relations. The satisfaction relation is denoted by �symbol. P � A denotes that process P satisfies formula A.

The ambient logic provides two main spatial and tem-poral constructs. The somewhere connective, �, is used forspecifying nesting properties of processes. The formula�A is satisfied by processes which satisfies A in some innerlocation. The sometime connective, }, is used for specify-ing temporal behavior of the processes on the basis ofreduction relations (?). Fragment of ambient logic usedin this paper is shown in Table 2.

3.2.2. Representation of location and mobility in FPM-RBACThe mobility model for a multiple domain mobile net-

work consists of four basic elements: administrative do-mains, hosts, users and objects. We assume that all theelements reside in a system element called the World. Inthis model the locations and mobility of hosts, users andobjects are formalized as ambient calculus processes andthey have the following mobility capabilities:

� Hosts: Moving into a domain represents connecting ahost to a domain. Moving out represents disconnecting.� Users: If a user moves into a host, the user is logged into

that host. If a user moves out of a host, the user islogged out. If the user moves into/out of a domain, thisrepresents enrollment, logging into a domain or move-ment between domains depending on the context.� Objects: Every object must reside in a host when not on

the move. The movement of objects from one host toanother represents communication.

In the formal specification, domains, hosts, users andobjects are modeled as ambients. We present some exam-ples of object, host and user mobility specification as ambi-ent calculus processes. Some known notation conventionsare utilized, for example n[] means n[0]. The symbol ?represents the reduction relation and ?⁄ represents a ser-ies of reductions.

Object mobility: File f1 is moved from directory dir1 inhost h1 to directory dir2 in host h2.

TabFra

gA

T:A

0

d1½h1½dir1½out dir1:out h1:in h2:in dir2:f1½��jh2½dir2½��!�d1½h1½dir1½��jh2½dir2½f1½��

Host mobility: Portable host h1 moves from Domain d1 toDomain d2.

le 2gment of ambient logic used in the study.

a name n;B;C::¼

true AjB compositionA negation n½A� location_B disjunction }A sometime

void �A somewhere

Fig. 2. Example for change of location configuration with actions.


d1½h1½out d1:in d2:0��jd2½�!�d1½�jd2½h1½��

User mobility: User u1 logs into Host h1, which containsFile f1.

u1½in h1:0�jh1½f1½�� ! h1½u1½�jf1½��

An example mobile network specification in ambient cal-culus is presented in (1). In this example there are two do-mains, d1 and d2. Mobile user u2 has the right to move intoeither of the two domains, login to h1 and h2 and read filesf1 and f2. The formal representations of multiple actionsare combined with the parallel (j) operator since any of theseactions may be exercised independent from each other.

LCONF ¼ d1½u1½�jh1½f1½data1½in u2:0jout u2:0��jd2½h2½u2½out h2:0jout d2:0jin d1:in h1:0jout h1:out d1:0jin d2:in h2:0jin f 1:0jin f 2:0jout f 1:0jout f 2:0�jf2½data2½�� ð1Þ

3.2.3. Location configuration of the systemThe location configuration of the system LCONF holds

the ambient calculus process specification for the currentsystem. The initial state for a user is before a user logs intoa service. In the initial state, LCONF0 is derived from the ini-

Fig. 3. FPM-RBAC domain s

tial state of the mobile network and the security policyspecification. The domains, users, hosts and objects in thesystem and their locations are derived from defined datasets. The set of possible actions are derived from the secu-rity policy. When an action is requested by a user, the ac-tion is matched to its formal representation, and ifallowed by the security policy, it is executed and the loca-tion configuration is updated accordingly. The state changebetween different location configurations takes place witha sequence of actions. Here is an example for modifying thelocation configuration with actions. The location configura-tion of the system at time T0 and T1 are depicted in Fig. 2.

At the initial state the ambient calculus specification isas follows:

LCONF0 ¼ D1½u1½�jh1½f1½dt1½in u2:0jout u2:0��jD2½h2½u2½out

h2:0jout D2:0jin D1:in h1:0jout h1:out D1:0jinD2:in h2:0jin f 1:0jin f 2:0jout f 1:0jout f 2:0�jf2½dt2½��

In Step (1), User u2 logs out of Host h2 with ambient cal-culus capability u2[out h2 . . . ]:

LCONF1 ¼ D1½u1½�jh1½f1½dt1½in u2:0jout u2:0��jD2½u2½out

D2:0jin D1:in h1:0jout h1:out D1:0jin D2:in

h2:0jin f 1:0jin f 2:0jout f 1:0jout f 2:0�jh2½f2½dt2½��

3.3. Domain security policy model

A security administrative domain, or a domain in short, isa logical boundary for an information and communicationsystem governed by a single administrative authority. Adomain is defined by the data sets and relations associatedwith an administrative boundary. A security policy is de-fined by a set of authorization terms. Authorization termsinclude authorization subjects, authorization objects, actionsand constraints. Services provided by the domain to itsinternal and external users are also included in the autho-rization model. Services are associated with a subset of

ecurity policy model.


authorization objects and actions. The set of enabled rolesfor a service is defined by the service access relation. Foreach service, a permission assignment relation is specifiedfor association of enabled roles for the service with permis-sions. Constraints are specified by formal languages. Pred-icate calculus is used for the specification of genericconstraints named as conditions and ambient logic is usedfor the specification of location and mobility constraintsnamed as location formula, or formula in short. The singledomain security policy model of FPM-RBAC is depicted inFig. 3. In the following sections we present data sets, do-mains, services, actions, constraints, relations, hierarchiesof the domain security policy model.

3.3.1. Data setsThe data sets in the FPM-RBAC access control model is

specified using first order set theory. An AuthorizationSubject is an active entity that may conduct an action onan authorization object. Since the RBAC model is adopted,roles are authorization subjects, however specification ofusers in this context are also supported. An authorizationobject is an entity upon which an action is conducted. Anauthorization object may be a domain, host, object or ob-ject type.

Where the constants g, t, q, b, m, r respectively denotethe number of hosts, users, roles, objects, object types andservices, the following data sets are defined:

H ¼ fh1;h2; . . . hgg HostsU ¼ fu1;u2; . . . utg UsersR ¼ fr1; r2; . . . rqg RolesO ¼ fo1; o2; . . . ; osg ObjectsT ¼ ft1; t2; . . . tmg Object typesAS ¼ U [ R Authorization Subjects:AO ¼ O [ T [ H [ D Authorization Objects:

In the joint project scenario, three organizations areworking on a joint e-health research project. Regardingthis scenario, example definitions for data sets of Univer-sity A (UniA), Commercial Company B (CorpB), and Hospi-tal C (HosC) related to the joint project case are givenbelow.

D ¼ fUniA;CorpB;HosCg;HUniA ¼ fh11; h12;h13g;HCorpB ¼ fh21;h22g;HHosC ¼ fh31;h32g;H ¼ HUniA [ HCorpB [ HHosC ;

UUniA ¼ fnmullis; jfrantz; cmieleg;UCorpB ¼ fdmendiola;mrundellg;UHosC ¼ ffmcbride; aweathersg;U ¼ UUniA [ UCorpB [ UHosC ;

O ¼ fjrapp;unif ; jrep;prdgT ¼ fObj;App; File;Db;Message; PortablegRUniA ¼ fMember; Teaching;Research;Admin;

Lecturer; Faculty;RAssist; SysAdming;RCorpB ¼ fMember; Engineer;Research;Mgr;

RnDEng; SwEng; PrjMgrg;RHosC ¼ fMember;Medical;Doctor; SocialSecg:

The elements of the set of hosts represent the followingin our scenario: h11: Research lab client of jfrantz, h12:Application server used for joint research project of Uni-versity A, h13: The portable PC of nmullis, h21: The portablePC of mrundell, h22: The file server of CorpB, which holdsjoint project reports, h31: File server of Hospital C contain-ing patient records, h32: The portable PC of fmcbride. Theelements of the set of objects represent the following inour scenario: jrapp: Joint research project web application,unif: Joint research project work file, jrep: Joint researchproject project report file, prd: Patient health recordsdatabase.

3.3.2. DomainsA domain is defined by a set of hosts, users, objects,

roles and object types associated with that particular do-main. Each domain is associated with a domain adminis-trator. A Domain D is defined as D ¼ fH;U;O;R; Tg.

When there are multiple domains in the network, d rep-resents the number of domains and D defines the set of alldomains in the network. In this case, the set of hosts, users,roles, objects, object types, authorization subjects andauthorization objects associated with domain Di are repre-sented respectively with Hi, Ui, Ri, Oi, Ti, ASi, AOi. The set ofall domains is defined as D ¼ fD1;D2; . . .Ddg.

3.3.3. ServicesThe FPM-RBAC model includes a specific construct for

services, which binds the dynamic user-role associationto a subset of resources and actions. The decision to intro-duce services arises from the service-oriented nature ofmulti-domain networks with heterogeneous and intercon-nected services such as web services and network services.In FPM-RBAC, the concept of services is built on the W3CWeb Services Architecture [26]. The W3C Web ServiceGlossary defines services as follows [27]: ‘‘A service is anabstract resource that represents a capability of perform-ing tasks that form a coherent functionality from the pointof view of providers entities and requesters entities’’. Morespecifically, a service is a resource that represents a personor organization in some collection of related tasks. A task isa set of actions associated with a service. The difference ofa service from other kind of resources is that it is associ-ated with a set of actions.

In the RBAC model, resources are regarded as a set ofobjects, which are passive entities. However, for supportingaccess control for services, there is a need for a constructthat defines the functionality provided by resources. Forexample, a joint project service may be associated withactions on the set of resources which are utilized towardsproviding a functionality, such as shared access to jointproject documents.

A policy is scoped by a domain, applies to a resourceand constrains actions which target resources. For a do-main service, the scope of the policy for the service is a sin-gle domain. For inter-domain services, the scope of thepolicy may be multiple domains. For example, the accesscontrol policy for a joint project service for the universityapplies to the resources within the university which pro-vides the joint project service, such as a web applicationfor editing shared documents. The policy constrains ac-

Table 3Relations in the FPM-RBAC model.

Relationname

Relation Specification Meaning

HD H � D HDðhk;DiÞ hk is enrolled toDomain Di

UD U � D UDðuj;DiÞ ur is enrolled toDomain Di

OD O � D ODðon;DiÞ on is within DomainDi

UA U � R UA(uj,rl) Role rl assigned to theuser uj

PA R � ACT � AO PA(rl,act,ao) rl has permission(act,ao)

SA R � V SA(rl,Sm) rl is enabled forservice Sm


tions upon the resource, such as writing to a specificdocument.

A service in the FPM-RBAC model is associated with aset of resources. The set of resources associated with a spe-cific service Sj is denoted as Pj. Pj is a subset of authoriza-tion objects and it includes hosts, objects and objecttypes. The relation called Service Resources (SR), includesthe set of accessible resources by a service for provisionof a capability. SR associates services with resources. Theset of hosts associated with a service represents logicallocations that a role may be enabled. The subset of objectsand object types associated with a service are included inthe Permission Assignment Matrix related with the service.A service is also associated with a set of actions. This set iscalled tasks. The Service Tasks (ST) relation maps services totasks.

The set of Services V defines the services within a singledomain. If there are multiple domains, the services withina domain Di is represented as V i. The set of services S andthe set of domain services V i within a domain Di are de-fined as follows.

Definition 1. The set of services is S ¼ fS1; S2; . . . Srg. Theset of domain services is V � S;V ¼ V1 [ . . . [ Vd. The set ofresources for a specific service Sj is Pj � AO. Pj ¼ Hj

i [ Oji [ Tj

iwhere Hj

i ¼ fhk; . . . ;hlg are hosts associated with serviceSj; Hj

i � Hi; Oji ¼ fom; . . . ; ong are objects associated with

service Sj; Oji � Oi; Tj

i ¼ ftx; . . . ; tyg are object types asso-ciated with service Sj; Tj

i � Ti. The set of tasks for a specificservice is Kj � ACT. The service resources relation for aspecific service Sj is SR � S � Pj. The service tasks relationfor a specific service Sj is ST � S � Kj.

The activation of roles in FPM-RBAC access controlmodel is achieved through the use of service sessions. Theconcept of session in the original RBAC model representsa dynamic binding of users to a set of roles. Sessions arenot sufficient to express the use of services. We introducethe concept of a service session, which is a ternary rela-tionship which binds users to roles and services. The Ser-vice Sessions (SS) relation is defined as SS � U � R� S.The service sessions in the FPM-RBAC model are definedwhen a user is registered to a service, and activated whenthe user requests to use the service.

3.3.4. ActionsThe set of actions defines the operations by subjects on

objects. For this study we assume a fixed set of actionsA = {Enroll, Login, Logout, Execute, Read, Write, Send, Receive,Delete, Create, Manage}. The action Manage is an adminis-trative action relating to the policy system. The set of per-missions P = ACT � AO defines all possible actions onauthorization objects for a given system.

The actions may also be signed. Positive authorizationsare considered default and positive sign may be omittedwithin specifications. The following constructs are usedto specify signed actions:

� Signs: N = {+, �} represents permission or denial.� Signed actions: ACT = N � A represents permission or

denial of an action. (+, read) denotes that read actionis permitted.

The actions are modeled as ambient calculus capabili-ties as shown in Definition 2. The translation of actionsin the security policy rules to ambient calculus is basedon a formal mapping. The translations are encoded as atemplate and are based on inference of specific subjectand object names from the high-level specifications ofsecurity policy. Here we present template encodings fortranslation of actions to ambient calculus. The encodingis for a single domain. This list is not exhaustive since alter-native encodings for the same actions in different contextsare possible.

Definition 2. Ambient calculus encoding for actions insecurity policy rules are specified as follows. In thisencoding, aas,ao represents an action with authorizationsubject as and authorization object ao. Where z, new-z 2 U [ H, u, u1, u2 2 U, d 2D, h, h1, h2 2 H, l 2 H [ D, m,prog, file, f, data 2 O, and M, P are process specifications,

Enrolz;d , newz½in d:z½�� j d½open newz�:0Loginu;l , u½in l� j l½�Logoutu;l , l½u½out l��Sendu1 ;m , d½h1½u1½m½Mjout u1:out h1:in h2:

in u2:0��j½h2½u2½��Receiveu;m , u½open m:ðmÞjm½M��Executeu;prog , d½h½u½open prog� j prog ½in u:P��Readu;file , h½file½data½in u:0�� j u½in file:0��Writeu;file , h½file½T� j u½in file:data½out u:0��Deleteu;file , h½file½in u� j u½open file:0��Createu;file , h½u½open f :f ½file½out f :0��

3.3.5. ConstraintsA constraint determines the applicability of a security

policy rule. The set of constraints is of the form C = {(co, fo):co 2 PL, fo 2 AL} where PL denotes the language of predicatelogic and AL denotes the language of ambient logic. Thereare two types of constraints. Conditions (co) define thegeneric constraints for a rule to be applicable. Location for-mula (fo) defines the location and mobility constraints of


the mobile network that must be satisfied by a securitypolicy rule.

Generic constraints are logical pre-requisites for a ruleto be applicable and are defined using predicate logic. Theyare specified by a predicate logic formula that defines theconstraints and relationships between subjects and objectsspecified in the policy rules. In cases where roles are men-tioned in a rule, generic constraints may apply to user-roleassignment.

We define the following pre-defined predicates for def-inition of generic constraints. Additional predicates may bedefined by the domain administrator.

1. EnrolledDomainUser ðDi;ujÞ, where Di 2 D; uj 2 U,specifies whether a user uj has been enrolled (regis-tered) to domain Di. Abbreviated as EDRðDi; ujÞ.

2. EnrolledDomainHost ðDi;hkÞ, where Di 2 D; hk 2 H,specifies whether a host hk has been enrolled (regis-tered) to domain Di. Abbreviated as EDHðDi;hkÞ.

3. ActiveDomainUser ðDi;ujÞ, where Di 2 D; uj 2 U, speci-fies whether user uj has been logged into domain Di.Abbreviated as ADUðDi;ujÞ.

4. RoleAssigned (uj,rl), where uj 2 U, rl 2 R, specifieswhether user uj has rights to assume role rl. Abbreviatedas RSG(uj,rl).

5. RoleAssumed (uj,rl), where uj 2 U, rl 2 R, specifieswhether user uj has actively assumed role rl. Abbrevi-ated as RAS(uj,rl).

6. RoleEnabled (rl,Sm), where Sm 2 V, rl 2 R, specifieswhether role rl is enabled for service Sm. Abbreviatedas REN(rl,Sm).

7. DescendantRole (rl,rk), where rl, rk 2 R specifies whethera given role is rl descendant (or specialization) ofanother given role rk. Abbreviated as DR (rl,rk)

8. ObjectIsType (on, tm), specifies whether an object on 2 Oidentified by its object name is of a given object typetm 2 T. Abbreviated as OIT(on, tm)

9. Administrator ðuj;DiÞ, where uj 2 U; Di 2 D specifieswhether user uj has administrative rights over domainDi. Abbreviated as ADM (j, i).

The location constraints in the security policy rules arespecified using the ambient logic. The location formula fo,which represents a location and mobility constraint, is amodal logic formula with spatial and temporal constructs.It is a formula in spatial logic that includes names of do-mains, authorization subjects and authorization objects.The ambient logic is used since it is possible to representboth time and location. We note here that the location inour model is a logical concept that shows the relative loca-tion of objects and users to hosts and domains rather thantheir physical location.

If the location formula contains the somewhere (�), par-allel (j) and ambient ([]) formalizations of ambient logic, itis referred as a location constraint. Additionally, if it con-tains temporal constructs which are sometime (}) andeverytime (h) modalities in ambient logic, it is referredas a mobility constraint. Location constraints are evaluatedby spatial model checking, whereas mobility constraintsare evaluated by a further step of temporal modelchecking.

As an example to location and mobility constraints, wepresent the location formula in (2) associated with theambient calculus specification LCONF presented in (1). Thisis an ambient logic specification stating that Domain d2

should never contain data1 and data2 at the same time.Combined with specification LCONF which specifies thatdata1 resides in d1 and data2 resides in h2 inside d2, theinterpretation of this mobility constraint is that domaind2 data should not be copied to domain d1.

fo ¼ �f:}f�d2½�fdata1½>�jdata2½>�g�j>gg ð2Þ

The possibility of conflicts arising from conflicting ac-tions may be resolved using the theorem proving ap-proach, as presented in our previous work [28]. Using theformalization methodology described above, some exam-ple security policy definitions with location constraintsare presented below. The authorization term structure,which is the basis of the security policy rules, will be intro-duced in Section 3.3.8.

� All users can read files in folder Project_Folder, if theyare in a location that contains this folder: (as = user,ao = Project_Folder, sa = + read, fo = �(as[] j ao[]), co = u-ser 2 U ^ OIT(ao, Project_Folder))� All users can send E-mail between the UniA and CorpB

domains: (as = user, ao = E-mail, sa = +send, fo = UniA[�as[]] j CorpB [�ao[]] _ CorpB [�as[]] j UniA[�ao[]],co = user 2 U ^ OIT(ao, E �mail))

3.3.6. Relations and system functionsRelations in the FPM-RBAC model are specified in Ta-

ble 3. The HD relation maps hosts to domains, whereasUD relation maps users to their home domains. The UArelation specifies the assignment of users to roles. The Per-mission Assignment (PA) relation specifies the assignmentof roles to permissions. Finally, the Service Assignment (SA)relation specifies the set of enabled roles for services.

The PA and SA relations are specified in terms of matri-ces. The dynamic binding of users to roles and permissionsis achieved through services. Permissions are assigned toroles based on PAMs defined for each service and authori-zation object type.

The Service Access Matrix (SAM) binds roles to services.When a user logs into a service, the roles associated withthat service are enabled. Then the role may act only onthe subset of authorization objects referred by the service.The SAM matrix denotes whether role rl is allowed to useservice Sj.

Definition 3. The Service Access Matrix is SAM : R� Vwhere SAM[i, j] = TruejFalse, 1 6 i 6 q, 1 6 j 6 r.SAM[i, j] = True ? SA(ri,Sj).

A Permission Assignment Matrix (PAM) is defined foreach service, which also includes Location and Mobilityconstraints. This design decision simplifies the specifica-tion of permissions for a network with multiple domainsand different types of services. PAM binds roles to permis-sions. Permissions are tuples of the form (act,ao) whereact 2 ACT, ao 2 AO. For each service there is a PAM that in-


cludes permissions for that service. PAM[i, j,k] determineswhether Role ri is allowed to conduct Action actj on Autho-rization Object aok.

Definition 4. The Permission Assignment Matrix isPAM:R � ACT � AO where PAM[i, j,k] = TruejFalse,1 6 i 6 q,1 6 j 6 jACTj, 1 6 k 6 jAOj. PAM[i, j,k] = True ? PA(ri,actj,aok).

The system functions in the FPM-RBAC model are de-fined in line with the standard RBAC model [10,11]. Addi-tional functions are provided due to the introduction ofservices and object type hierarchies. The functions inFPM-RBAC are presented in Table 4.

3.3.7. Role and object hierarchies in FPM-RBACHierarchies in the FPM-RBAC model consist of Role

Hierarchy (RH) and Object Type Hierarchy (OTH). The pre-cedence relationship of roles are defined in the Role Hier-archy (RH) relation. The role hierarchy is compatiblewith the role-based access control [10,11] model. The rolehierarchy for a domain Di is represented as RHi.

The mapping of objects to object types are defined inthe Object Type Hierarchy (OTH) relation. Object-typehierarchies were introduced by Jajodia et al. in the FlexibleAuthorization Framework (FAF) [29]. In a multi-domainsetting, the knowledge of objects across domains is notdesirable because of distributed administration. Throughthe use of object types the permissions may be mappedacross multiple domains without the need of global knowl-edge of individual objects. The object hierarchy for a do-main Di is represented as OTHi.

Definition 5. Hierarchy. A hierarchy is a triple (A, B, )where

1. A and B are disjoint sets;2. is a partial order on A [ B s.t. every element a 2 A is

said to be minimal in A [ B. Minimal elements haveno elements below themselves in the hierarchy, i.e.a 2 A and "b 2 A [ B, b a) b = a.

For the OTH relation, a b means that object a is of ob-ject type b. For the RH, a b means that role a is a special-ization of role b.

Definition 6. Object Type Hierarchy. A = O, B = Ta b ? (a,b) 2 OTH where a 2 O, b 2 T.

Table 4System functions in the FPM-RBAC model.

Function name Specification Mean

services U ? 2V Givesservice_users V ? 2U Mapsenabled_roles V ? 2R: {r 2 Rj(v,r) 2 SA} Mapsenabled_roles⁄ V ? 2R: {r 2 Rjr0 � r, (v,r0) 2 SA} Mapsassigned_users R ? 2U: {u 2 Uj(u,r) 2 UA} Mapsauthorized_users R ? 2U: {u 2 Ujr0 � r, (u,r0) 2 UA} Mapsobject_type O ? T Givesroles U [ P [ V ? 2R Mapsroles⁄ U [ P [ V ? 2R Mapspermissions R ? 2P Mapspermissions⁄ R ? 2P Maps

Definition 7. Role Hierarchy. A = R, B = Ra b ? (a,b) 2 RH where a 2 R, b 2 R.

For the joint project scenario, example role hierarchiesfor University A (RHUniA), Commercial company B (RHCorpB),Hospital C (RHHosC) are presented below.

RHUniA ¼ fMember Teaching;Member

Research;Member Admin; Teaching

Lecturer;Research Faculty;Research

ResAssist;Admin SysAdmingRHCorpB ¼ fMember Engineer;Member

Research;Member Mgr; Engineer

SwEng;Research RnDEng;Mgr PrjMgrgRHHosC ¼ fMember Medical;Medical

Doctor;Member SocialSecg

The types for services may be defined as sub-types forapplication object type in the object type hierarchy. Theuse of services together with object-type hierarchies en-able the use of FPM-RBAC model in specification of securitypolicies for software, network and security services. Anexample object type hierarchy for the joint project scenariois OTH = {(jrapp,App), (unif,File), (jrep,File), (prd,Db)}.

3.3.8. Authorization termsAn authorization term at is the basic formal construct

used to specify security policy rules. AT is the set of allauthorization terms and ATi is the set of authorizationterms for Domain Di. The permission assignment relationstogether with generic constraints and location and mobil-ity constraints are formalized by authorization terms. Setof authorization terms AT is defined as: AT � PA � C whereat 2 AT, AT = {(as,ao,act,co, fo): as 2 AS, ao 2 AO, act 2 ACT,(co, fo) 2 C}.

The formal specification of security policy rules is basedon predicate logic and ambient modal logic within theauthorization term structure. Here, we present the formal-ization process through realistic security policy examples.The policy statement in verbal form is followed by the cor-responding formally specified authorization term. Thereare two types of policy specification. The first one is gener-ic policy statements valid for all network models. The sec-ond one is network specific policy statements defined by asystem or security administrator specific to a network.First, we list examples of generic policy statements that

ing

the services accessible by a usereach service to its userseach service to the set of enabled roleseach service to the set of enabled roles in presence of a role hierarchya role to set of usersa role to set of users in presence of role hierarchythe type of an objectusers, permissions and services to rolesusers, permissions and services to roles in presence of role hierarchyroles to permissionsroles to permissions in presence of role hierarchy


can be defined by following our method. In these genericstatements, host 2 H, object 2 O, user 2 U, domain 2 D.

� Users must be enrolled to a domain before they canlogin: (as = user, ao = domain, sa = login, fo = �(domain-[T]juser[T]jT), co = "user 2 U, $domain 2 D, EDR(domain,user))� Users must be logged into a host before any other action

can be conducted by a user in a domain: (as = user,ao = domain, sa = An{login}, fo = �(domain[host[user[T]]-jT]jT), co = "user 2 U, $domain 2D, $host 2 H)� Enrolling any entity to a domain can be done by a user

with administrative rights.: (as = user, ao = domain,sa = enrol, fo = T, co = "domain 2 D, $user 2 U,ADM(user,domain))

Below are some examples for formal specification ofnetwork specific policy statements with location andmobility constraints for the joint project scenario.

� Files in the patient records server (h11) cannot be readby any user from portable hosts: (as = user, ao = File,sa = (�)) read, fo = �(host[user[T]jT]jh11 [file[]]),co = "user 2 U, (OIT(file,File) ^ OIT(host,Portable))� The user nmullis may send messages to the user jfrantz:

(as = nmullis, ao = Message, sa = send, fo = �(nmul-lis[m[]jT]) ^ �(jfrantz[m[]]j T)), co = OIT(m,Message)� The portable host h13 can be connected to the CorpB

domain by users of CorpB: (as = user, ao = h13, sa = con-nect, fo = �(h13[T]jCorpB[T]), co = $user 2 U, $h13 2 H,$CorpB 2 D, EDR(user,CorpB) ^ OIT(h13,Portable))� User cmiele can login to the joint project applica-

tion server (h12): (as = cmiele, ao = h12, sa = login,fo = �(h12[T]jcmiele[T]), co = T)

3.3.9. Domain security policyThe security policy Pi for a domain Di includes the set of

defined services, authorization terms and hierarchies. Thedata sets that are referred by the domain security policyare included in the specification of Di. The domain securitypolicy is defined as Pi ¼ fV i;ATi;RHi;OTHig; 1 6 i 6 d.

Since the FPM-RBAC model is multi-domain, there maybe multiple domain security policy definitions. Each do-main security policy defines its access rules for local usersto access local resources within the domain. The accessrules for users to access inter-domain resources are speci-fied by an inter-domain security policy. As a result of thisadministration method, the knowledge of local users andresources remains within the administrative boundary of

Fig. 4. Access control policies in m

a domain. The set of domain security policies in a multi-domain environment is defined by the set X. The set of do-main security policies is defined as X ¼ fP1; . . . ;Pdg.

3.4. Inter-domain security policy model

An inter-domain security policy is the set of access con-trol rules, attributes and mapping for entities and informa-tion in multiple domains to be able to securely access orexchange information. It facilitates the provision of ser-vices between domains by providing a common set ofsecurity policies for cross-domain services. Use of inter-do-main policies adds a layer of abstraction to security man-agement by enabling the security management of cross-domain services independently from domain services.

The constructs specified in the domain security policymodel presented in Section 3.3 are also valid in the inter-domain security policy model (hereafter referred as inter-domain model). The inter-domain model adds constructsfor inter-domain services, inter-domain roles, inter-domainrole hierarchy, role maps, inter-domain service access and in-ter-domain permission assignment. Inter-domain securitypolicy is defined over inter-domain authorization termswhich are specified on the basis of these constructs.

The inter-domain model introduces the concepts ofhome domain, foreign domain and inter-domain. Home do-main is the boundary of security administration for a do-main which provides services to other domains. Foreigndomains are domains whose users access inter-domainservices through inter-domain roles. Inter-domain policyincludes rules for foreign users to access home domain ob-jects through inter-domain roles, as well as the mapping ofhome and foreign domain roles to inter-domain roles.

As far as domain security administration is concerned,home domain administrator is only informed about the in-ter-domain role hierarchy. It is not necessary for the for-eign domain role hierarchy to be communicated to thehome domain. The home domain administrator definesrules for the foreign users to access home domain objectsusing inter-domain roles. In this manner, the principle ofautonomous administration is preserved without the needof global distribution of knowledge of objects and users.

The overall view for access control policies in a multi-domain environment is depicted in Fig. 4. The inter-do-main access control model of FPM-RBAC is detailed inFig. 5. Here, we introduce the concept of inter-domainroles and inter-domain role hierarchies. Roles are mappedto inter-domain roles with a role mapping function. An in-ter-domain service is accessible by home or foreign users

ulti-domain environment.

Fig. 5. FPM-RBAC inter-domain security policy model.


through inter-domain roles. It is associated with actionsand authorization objects from the home domain. The ac-cess rules for inter-domain services by foreign roles is achievedthrough the inter-domain permission assignment relation.

3.4.1. Inter-domain servicesInter-domain services are services which are associated

with authorization objects and actions within a set of do-mains C. One of the elements of C is named as home do-main and the others are named as foreign domains. Inter-domain services are accessed by inter-domain roles. Theset of inter-domain services IC is defined as follows.

Definition 8. The set of inter-domain services IC among aset of domains C, where Da is the home domain and Db,Dc. . . are foreign domains, is specified as IC ¼ fbSj : 1 6j 6 cg where c is the number of inter-domain services.

The subset of authorization objects associated with aninter-domain service is called inter-domain resources. Thesubset of actions associated with an inter-domain serviceis called inter-domain tasks. The associations are definedthrough the Service Resources (SRC) and Service Tasks(STC) relations. The mentioned sets and relations are de-fined as follows.

Definition 9. Inter-domain service resources for a specific

inter-domain service bSj is bPj ¼ C;Hj;Oja; T

ja

n o; bPj � AO. Hj =

{hk, . . . ,hl} are hosts associated withbSj;H

j � Ha [ Hb [ Hc . . . ;Oja ¼ fom; . . . ; ong are objects asso-

ciated with bSj;Oja � Oa; T

ja ¼ ftx; . . . ; tyg are object types

associated with bSj; Tja � Ta. The set of all inter-domain

service resources is bP ¼ Sci¼1bPi. The set of inter-domain

service tasks is bK � ACT. bK j is the inter-domain service

tasks for a specific service bSj. The inter-domain service

resources relation is SRC � IC � bP . The inter-domain ser-vice tasks relation is STC � IC � KC.

Regarding the joint project scenario, we consider twointer-domain services: The Joint Research Project serviceand the Patient Health Records service. The resources asso-ciated with the Joint Research Project service include theapplication server, joint research web application, projectwork files and project report files. The tasks associatedwith this service include actions to login and execute theapplication as well as to read and write project files. Theresources associated with the Patient Health Records ser-vice include the patient records database and the file ser-ver of Hospital C containing patient records. The tasksassociated with this service include actions to login to thefile server as well as to read and write database records.

The definitions for inter-domain services are as follows.Here,cS1 represents the Joint Research Project inter-domainservice and cS2 represents the Patient Health Records inter-domain service.

IC ¼ fcS1 ;cS2gbP1 ¼ fUniA;CorpB;HosC; jrapp;unif ; jrep;

App; File;h11;h12;h13; h21;h22;h31;h32g;bP2 ¼ fUniA;HosC; prd;App;Db; File;h12;h31gbP ¼ bP1 [ bP2

bK 1 ¼ fLogin; Logout; Execute;Read;WritegbK 2 ¼ fLogin; Logout;Read;WritegbK ¼ bK 1 [ bK 2

SRC ¼cS1 � bP1 [cS2 � bP2

STC ¼cS1 � bK 1 [cS2 � bK 2


3.4.2. Inter-domain rolesAn inter-domain role is a role which does not apply to a

particular domain and is used for mapping of roles be-tween domains. A direct map between roles of multipledomains is avoided to provide more flexibility of adminis-tration and enforcement. Inter-domain services can be di-rectly specified according to the needs of informationsharing between organizations and enforced with respectto inter-domain roles. The set of Inter-Domain Roles RC isdefined as RC ¼ r1

C; . . . ; r.C

� �where . is the number of in-

ter-domain roles. The definition of inter-domain role hier-archy RHC in Definition 10 is similar to RH relation.

Definition 10. Inter-Domain Role Hierarchy RHC , a b ? (a,b) 2 RHC, a, b 2 RC.

3.4.3. Role mapA role map RM is a many-to-one relation from a set of

roles R to inter-domain roles RC. The choice of many-to-one relations for defining role maps eliminates conflictsin role mapping. A home or foreign role may not map tomultiple inter-domain roles associated with a possiblyconflicting set of permissions. Furthermore a direct mapbetween roles of multiple domains is avoided by introduc-tion of home and foreign role maps. This decision facili-tates independent administration of inter-domain rolesand inter-domain role hierarchies. The role map fromhome roles to inter-domain roles is represented as RMh

and the role map from foreign roles to inter-domain rolesis represented as RMf.

Definition 11. Role Maps are specified as

RMh ¼ fðri; rjCÞ : ri 2 Ra; r

jC 2 RCg:9ðrx; ryÞ 2

RMh ^ 9ðrx; rzÞ 2 RMh ! y ¼ z

RMf ¼ fðrk; rjCÞ : rk 2 Rb; r

jC 2 RCg:9ðrx; ryÞ 2

RMf ^ 9ðrx; rzÞ 2 RMf ! y ¼ z;

where Da is the home domain and Db is a foreign domain.Consider the example presented in Fig. 6. In this exam-

ple the role hierarchies are assumed to be tree structuresfor the sake of simplicity. Here,

Fig. 6. Example for home and foreign

R1 ¼ fr11; r12; r13; r14; r15; r16g;R2 ¼ fr21; r22; r23; r24; r25; r26g;RC ¼ fr121; r122; r123; r124; r125g;RMh ¼ fðr12; r125Þ; ðr13; r124Þ; ðr15; r124Þg;RMf ¼ fðr24; r124Þ; ðr26; r125Þg:

3.4.4. Inter-domain relations and authorization termsThe relation PAC is the inter-domain permission assign-

ment relation, used for the assignment of inter-domainroles to permissions. SAC is the inter-domain serviceassignment relation used for assignment of inter-domainroles to inter-domain services. ATC is the set of inter-do-main authorization terms specified as inter-domain per-mission assignments associated with constraints. CC isthe set of inter-domain constraints. Inter-domain permis-sion assignment, inter-domain service access relation andinter-domain authorization terms are respectively speci-fied as follows: PAC �RC�ACT�AO; SAC�RC�IC; ATC�PAC�CC; ATC ¼fðas;ao;sa;co; foÞ : as2 RC; ao2AO; sa2ACT;ðco; foÞ 2 CCg.

Regarding the joint research project case, assume thatthe ‘‘project manager’’ (ResPrjMgr) may use the Joint Pro-ject service, but may not access patient health records. Incontrast ‘‘Supervisor’’(Supervisor) may access health re-cords but not Joint Project resources. ‘‘System administra-tor’’ (SysAdmin) may perform administrative duties onJoint Project service, for example to manage and upgradethe joint project web application. A service access matrixfor the joint project inter-domain access is given inTable 5.

Detailed access permissions may be granted to rolesbased on the services. An excerpt of a permission assign-ment relation related to the object jrapp is given in Table 6.

3.4.5. Inter-domain security policyAn inter-domain security policyWC is defined among a

set of domains C, where Da is the home domain and Db, Dc,. . . are foreign domains.WC includes inter-domain servicesIC, inter-domain role hierarchy RHC, home domain to in-ter-domain role-mapping RMh, foreign domain to inter-do-main role mapping RMf and inter-domain authorizationterms ATC. The formal representation of Inter-DomainSecurity Policy is WC ¼ fIC;RHC;ATC;RMh;RMf g.

role maps among two domains.

Table 5Service access matrix for joint research project inter-domain access.

Inter-domain role Inter-domain service

Joint project Health records

ResPrjMgr Yes NoResGrpMgr Yes YesSysAdmin Yes NoResearcher Yes YesSupervisor No Yes

Table 6A part of permission assignment relation for joint project service relating toobject jrapp.

Inter-domain role Permission

Object Action

ResPrjMgr jrapp +executeResGrpMgr jrapp +executeSysAdmin jrapp +manage, +writeResearcher jrapp +executeSupervisor jrapp �execute


Below we present examples for inter-domain securitypolicy rules. The formal specification includes the mobilityand access control aspects of the inter-domain policy.Example policy statements for mobility and inter-domainaccess as a verbal form of policy rule are given followedby formal specification of authorization terms and aninterpretation of the location and mobility constraints.

1. ‘‘Users with Research Project Manager role from Corpo-ration B are allowed to login with portables to Univer-sity A’’:

ðas ¼ ResPrjMgr; ao ¼ Portable; sa ¼ login; fo

¼World½CorpB½T�jp½user½T�jT�jUniA½T�jT�; co

¼ 9user

2 U; EDRðuser;UniBÞ ^ RASðuser;ResPrjMgrÞ^ OITðp; PortableÞÞ

Interpretation of the constraints: There is a user, who has as-sumed the role of a Research Project Manager, which islogged into a host of object type Portable and is not yetconnected to either UniA or CorpB, in a location that canbe connected to either of the domains UniA and CorpB.2. ‘‘Software Engineers of Corporation B can read data

from files on the project server in University A domainfrom within University A’’:

ðas¼SwEng;ao¼h12;sa¼ read;fo

¼World½UniA½h12½file½data�jT�j�user½�jT�jCorpB½T�jT�;co

¼EDRðuser;CorpBÞ^ADUðuser;UniAÞ^RASðuser;SwEngÞÞ

Interpretation of the constraints: UniA contains a projectserver including a file with data and the user who has as-sumed the role Software Engineer, is an active domain userof UniA and an enrolled domain user of CorpB, is locatedsomewhere inside UniA.

3. ‘‘Researchers of University A with a Portable hostwithin Hospital C cannot write files to the patientrecords database in servers of Hospital C’’:

ðas ¼ Researcher; ao ¼ Server; sa ¼ ð�Þwrite; fo

¼World½HosC½p½user½f ½��jh31½prd½�jT�jT�jT�; co

¼ EDRðuser;UniAÞ ^ ADUðuser;HosCÞ^ RASðuser;ResearcherÞ ^ OITðp; PortableÞ^ OITðprd;DbÞ ^ OITðf ; FileÞ ^ OITðh31; ServerÞÞ

Interpretation of the constraints: The user who has assumedthe role Researcher, is an enrolled domain user of UniA,and an active domain user of HosC, who is logged onto aPortable host with a file, is within UniA domain which con-tains a Server h31 with a Database prd.

3.5. Separation of Duty (SOD) constraints in FPM-RBAC

Static SOD enforces constraints on the assignment ofUsers to Roles. If a user is authorized as a member of onerole, the user may be prohibited to become a member ofanother (conflicting) role. Dynamic SOD enforces con-straints on the activation of Roles by Users. A user maybe assigned to two or more conflicting roles but may acti-vate only one of them at any specific session.

In FPM-RBAC, novel classes of SOD constraints are iden-tified: (i) service based SOD, (ii) inter-domain SOD and (iii)location and mobility based SOD. Service-based SOD is de-fined on the basis of a set of conflicting services CS. CS is aset of services, where two or more of its members may notbe assigned to a single role. For example, a role may not beassigned to services ‘‘Secret’’ and ‘‘Unclassified’’. Inter-do-main SOD may be based on inter-domain role assignment,home role mapping or foreign role mapping. Locationbased SOD may be based on service location, role locationor permission location. The classification of SOD in FPM-RBAC is presented in Fig. 7. Static or dynamic aspects arerepresented by time of evaluation. Static SOD is evaluatedstatically against initial system state, while dynamic SOD isevaluated at runtime against current system state.

In [30], the SOD constraints are specified within therole-based constraints language using the sets of conflict-ing roles, permissions and user sets in addition to the stan-dard RBAC model. Mutually disjoint roles are defined asconflicting roles set CR. The concept of conflicting permis-sions defines conflict in terms of permissions rather thanroles. Two permissions may be considered in conflict inde-pendent from role assignment relation. For example, per-missions to write grades to student files and to approvegrades of students may be declared as conflicting permis-sions. Role and permission based SOD are included as sin-gle-domain constraints (SCR and SCP) in this classification.An interplay of the three classes of SOD constraints are alsopossible however a detailed analysis is out of scope of thisstudy.

3.5.1. Single domain SODThe Single Domain SOD is defined based on the static

separation of duty definition in the standard RBAC model.We differentiate between role-based, permission-based

Fig. 7. Classification of static separation of duty in FPM-RBAC.


and service-based SOD in FPM-RBAC model. Service BasedSOD is a novel concept defined in the FPM-RBAC model.The sets of roles, permissions and services which are thebasis for mutual exclusion are defined as CR (conflictingroles), CP (conflicting permissions) and CS (conflicting ser-vices) respectively. The static separation of duty based onroles follows the standard RBAC model definitions [11].Additionally in FPM-RBAC, SCS (SOD based on conflictingservices) and SCP (SOD based on conflicting permissions)are defined as follows:

Static separation of duty based on roles: SCR # (2R � N) isa collection of pairs where CR = {rx, . . ., ry: rx, . . ., ry 2 R} is aset of conflicting roles, t a subset of roles in CR, and n a nat-ural number n P 2, s.t. no user is assigned to n or moreroles from the set CR in each (t,n) 2 SCR. SCR is defined in(3). In presence of a hierarchy, the function assigned_users(r) in (3) is replaced with the function authorized_users (r).

8ðt;nÞ 2 SCR;8t #CR : jtjP n!\r2t

assigned usersðrÞ¼ ; ð3Þ

Static separation of duty based on services: SCS # (2V � N) isa collection of pairs where CS ¼ fvx; . . . ;vy : vx; . . . ;vy 2 Vgis a set of conflicting services, s a subset of services in CS,and n a natural number n P 2, s.t. no role is assigned to nor more services from the set CS in each (s,n) 2 SCS. SCSis defined in (4). In presence of a hierarchy, the function en-abled_roles (v) in (4) is replaced with the functionenabled_roles⁄(v).

8ðs;nÞ 2 SCS;8s#CS : jsjP n!\v2s

enabled rolesðvÞ¼ ; ð4Þ

Static separation of duty based on permissions: WhereCP = {cpi: cpi 2 ACT � AO} is a set of conflicting permissions,the set of conflicting inter-domain roles is interpreted asCR = {rx: permissions⁄(rx) \ cpi – ;}. Specification (3) isapplicable with the derived CR set.

Fig. 8. Conflicting role sets for i

3.5.2. Inter-domain SODThe introduction of role maps arise additional concerns

about separation of duty. Due to multiple sets of conflictingroles for home, foreign and inter-domain roles, new typesof SOD need to be defined. First we define the set of con-flicting inter-domain roles,CRC ¼ rx

C; . . . ; ryC : rx

C; . . . ; ryC 2 RC

� �. We identify the follow-

ing types of static SOD related with inter-domain rolemapping:

1. SICR: No user can be assigned to a set of roles whichmap to n or more conflicting inter-domain roles.

2. SRMh: No user can be assigned by mapping to n or moreinter-domain roles which are mapped by a set of con-flicting home domain roles.

3. SRMf: No user can be assigned by mapping to n or moreinter-domain roles which are mapped by a set of con-flicting foreign domain roles.

We introduce a function rmap(r): R � RC which givesthe set of mapped inter-domain roles for a set of home orforeign domain roles. The formal definitions for the newlyintroduced static SOD constraints SICR, SRMh, SRMf arerespectively defined in (5)–(7).

8ða;nÞ 2 SICR; 8a � R; jrmapðaÞjP n;\r2a

assigned usersðrÞ– ; ! rmapðaÞ� CRC ð5Þ

8ða;nÞ 2 SRMh; 8a � R; jrmapðaÞjP n;\r2a

assigned usersðrmapðrÞÞ – ; ! a � CRh ð6Þ

8ða;nÞ 2 SRMf ; 8a � R; jrmapðaÞjP n;\r2a

assigned usersðrmapðrÞÞ – ; ! a � CRf ð7Þ

nter-domain hierarchies.


As an example of static SOD relations for inter-domainrole mapping, consider the example depicted in Fig. 8.Let CRh = {r12,r13,r15},CRC = {r124,r125}, CRf = {r23,r24,r26}.The home domain mapping is RMh = {(r13,r124), (r15,r122)}.The foreign domain mapping is RMf = {(r25,r124),(r26,r125)}. The role assignment {(u,r122), (u,r124)} is con-flicting according to SRMh and {(u,r25), (u,r26)} is conflictingaccording to SICR.

SOD relations may be defined in an alternative way. Onemay define sets of conflicting permissions instead of con-flicting roles. In this case, the conflicting roles can be inter-preted as the roles that have conflicting permissionsassigned to them. In this case, the set of conflicting inter-domain permissions can be defined by the administratoras CPC = {cpi: cpi 2 ACT � AO} and the set of conflicting in-ter-domain roles is interpreted by the system asCRC ¼ frx

C : permissions�ðrxCÞ \ cpi – ;g. The inter-domain

SOD constraints presented in this section are then applica-ble with the derived CRC set.

3.5.3. SOD for location and mobility constraintsWe identify new aspects about the specification of SOD

constraints together with location and mobility con-straints. Two or more roles or permissions may be consid-ered in conflict if one of these permissions relates to anaction which involves mobility. For example, the Guest Lec-turer role may be in conflict with the Lecturer role if theperson is visiting another university. As an example to per-mission conflicts arising from mobility, consider a requeststo send a student record file to another institution and atthe same time to change the records. In this case, the re-cords which have been sent would be in conflict with theones changed.

In the FPM-RBAC model, static and dynamic SOD con-straints may be used in accordance with Location andMobility Constraints. The generic form of location andmobility based SOD constraints based on setC 2 fCR;CP;CSg is ðC;n; sfoÞ where n is a natural numberand sfo is a (set of) location constraint (s) for separationof duty. Set C is specified depending on whether the con-straint is role-based, permission-based or service-based.We associate the SOD constraints with the Location andMobility constraints for conflicting roles and conflictingservices as follows:

1. Conflicting Roles with Location Constraints (SLCR): n ormore roles may not be assigned to a user if these rolesare within the conflicting roles set CR and if the Loca-tion constraint sfo is valid in the initial location config-uration of the system.

2. Conflicting Services with Location Constraints (SLCS): nor more services from the set of conflicting services CSmay not be assigned to a role if the location constraintsfo is valid in the initial location configuration of thesystem.

Static location constraints are evaluated against the ini-tial location configuration (LCONF0), which depicts thestate of the network before any action has been executed.The formal definitions of SLCR, location and mobility SOD

based on conflicting roles, and SLCS, location and mobilitySOD based on conflicting services, are in (8) and (9).

8ðt;nÞ 2 SLCR; 8t # CR : jtjP n

!\r2t

assigned usersðrÞ ¼ ; ^ LCONF0 � sfo ð8Þ

8ðs;nÞ 2 SLCS; 8s # CS : jsjP n

!\v2s

enabled rolesðvÞ ¼ ; ^ LCONF0 � sfo ð9Þ

In the presence of hierarchies, SLCR is obtained byreplacing the function assigned_users in (8) with the func-tion authorized_users. Similarly, SLCS in the presence ofhierarchies is obtained by replacing enabled_roles (r) in(9) with enabled_roles⁄(r).

A number n or more authorization terms are in conflictif among all authorization terms assigned to the sameauthorization subject, n or more permissions are withinthe conflicting permissions set CP = {cpi: cpi 2 ACT � AO}and if the Location constraints associated with the permis-sions are all valid in the initial location configuration of thesystem. In this case the location formula for separation ofduty is defined by the set {fo1, . . ., fon} associated withauthorization terms {at1, . . ., atn}. The formal definitionfor SLCP, SOD based on Conflicting Permissions with Loca-tion Constraints, is given in (10).

8ðp;nÞ2SLCP; 8a#AT; 8p#CP : jpjPn; a¼fðas;p1;fo1;co1Þ;. . .ðas;pn;fon;conÞg;

permissionsðasÞ#p!LCONF0�ffo1; . ..fong ð10Þ

In presence of an hierarchy, the assignment of permis-sions to authorization subjects are evaluated according tothe role hierarchy. In this case, the function permissions(as)in (10) is replaced by the function permissions⁄(as).

3.5.4. Dynamic SODHere we define the dynamic SOD constraints in the

FPM-RBAC model. Similar to static SOD constraints, dy-namic SOD constraints also have three different types,namely, role based, service based and location/mobilitybased dynamic SOD. The main differentiation between Sta-tic and Dynamic SOD constraints are: (i) dynamic con-straints are based on activation of roles, which occurswhen a user logs into a service, rather than assignmentor roles and (ii) dynamic constraints are evaluated atrun-time against the current state of the system, in whicha set of actions has already been executed. The spatial andtemporal location and mobility constraints enable thespecification of complex temporal and spatial restrictionson separation of duty. The concept of services, which bindsa dynamic login session to a set of authorization objects,replaces the concept of sessions in standard RBAC. Sincethe user may login to one service at a time, the DSOD def-inition based on services is related to the set of enabledroles within a service.

Dynamic separation of duty based on roles: DCR # (2R � N)is a collection of pairs where CR = {rx, . . ., ry: rx, . . ., ry 2 R}is a set of conflicting roles, t a subset of roles in CR, andn a natural number n P 2, s.t. no user has actively assumedn or more roles from the set CR in each (t,n) 2 DCR.


8ðt;nÞ 2 DCR;8u 2 U;8t # CR : jtjP n!^r2t

RASðu; rÞ ¼?

ð11Þ

Dynamic separation of duty based on services: DCS #

(2R � N) is a collection of pairs where CR = {rx, . . . ,ry: rx,. . ., ry 2 R} is a set of conflicting roles, t a subset of rolesin CR, and n a natural number n P 2, s.t. no user, whenlogged into a service v 2 V, may activate n or more rolesfrom the set CR in each (t,n) 2 DCS.

8ðt;nÞ 2 DCS;CR � 2R; 8t # CR; 8v 2 V;t � enabled rolesðvÞ ^ jtjP n!

^r2t

RENðv ; rÞ ¼

? ð12Þ

Dynamic Separation of Duty based on Locations and Mobility:Location and mobility based dynamic SOD constraints areevaluated against the location configuration of the systemat time s (LCONFs), after a set of actions has already beenexecuted by users. The dynamic constraints take hierar-chies into account since the predicates RAS and REN takeinto account the effect of descendant roles. Where CR = {rx,. . ., ry: rx, . . ., ry 2 R} is a set of conflicting roles, the formaldefinitions of dynamic location and mobility SOD con-straints based on conflicting roles DLCR and conflicting ser-vices DLCS are given in (13) and (14).

8ðt;n; s; sfoÞ 2 DLCR; 8u 2 U; 8t # CR : jtjP n

!^r2t

RASðu; rÞ ¼? ^LCONFs � sfo ð13Þ

8ðt;n; s; sfoÞ 2 DLCS; CR � 2R; 8t # CR; 8v2 V; t � enabled rolesðvÞ ^ jtjP n

!^r2t

RENðv; rÞ ¼? ^LCONFs � sfo ð14Þ

Table 7Part of output generated by the spatial model checker for an examplepolicy.

State Spatial state of World AP Action

0 d1[u1[]jh1[f1[data1[]]]]jd2[h2[u2[]jf2

[data2[]]]]\ u2[out

h2]52 d1[u1[h1[f1[]]]jd2[h2[f2

[u2[]jdata2[]jdata1[]]]\ u2[out f2]

53 d1[u1[h1[f1[]]]jd2[h2[f2

[data2[]jdata1[]]ju2[]]> –

4. Verification of FPM-RBAC security policies

Use of the FPM-RBAC policy model enables formal andautomated verification of inter-domain security policies.A novel aspect of FPM-RBAC is that location and mobilityof users, objects and hosts may be included in verificationand mobility within multiple domains may be addressed.In this section, we present the summary of the spatio-tem-poral model checking algorithm for checking satisfaction oflocation and mobility constraints. The ambient calculusmodel checker is a realization of the spatio-temporal mod-el checking algorithm. The details of this algorithm and themodel checker may be found in our previous work [15,31].We also present two examples, first concerning two do-mains and the second concerning multiple domains.

4.1. Spatial and temporal model checking for security policies

We divide our problem into two sub problems; namelytemporal model checking and spatial model checking. Thetemporal model checker is used for carrying out satisfac-tion process for the sometime and everytime connectivesof ambient logic. The proposed model checking method

generates all possible future states and build a state transi-tion system based on the ambient calculus process specifi-cation. After evaluation of ambient logic formula in eachstate, this state transition system is processed into a KripkeStructure which is then given to temporal model checker.NuSMV [32] is used as a temporal model checker.

Outline of the algorithm for the model checking is pre-sented below.

1. Define atomic propositions with respect to spatial prop-erties of ambient logic formula and register the (atomicproposition-spatial modality) couples.

2. Reduce ambient logic formula to temporal logic formula(CTL) by replacing spatial modalities with atomicpropositions.

3. Generate state transition system of the ambient calcu-lus specification with respect to reduction relations.This involves generation of initial state from givenambient calculus specification, generation of new statesby applying available capabilities with respect to ambi-ent calculus reduction relations and addition of newstates to state transition system with transitionrelation.

4. Generate Kripke Structure from state transition system.This step involves the assignment of the values of theatomic propositions for each state of state transitionsystem (labeling) by applying model checking for spa-tial modalities on ambient topology of the related stateand the addition of a new state with its label (values ofatomic propositions) to the Kripke Structure.

5. Generate NuSMV code from Kripke Structure and CTLFormula.

As an example, let’s consider the scenario and policyexample presented in Sections 3.2.2 and 3.3.5. Whenthe ambient calculus specification is input to the modelchecker, a total of 53 states are generated. One AtomicProposition (AP) is generated, where AP = �{�h2[�{data1-[>]jdata2[>]}]j>}. A part of the execution of the algorithmis presented in Table 7. Only the initial and the last twostates are shown. For each state an action is executed toproduce a new spatial state. For state 53 the spatial modelchecking algorithm matches the spatial formula AP to thecurrent state of World.

A detailed analysis for the complexity and performanceof the model checking algorithm may be found in [31].According to this analysis, the time complexity of statetransition system generation is dependent on the numberof capabilities. Where n is the number of capabilities inthe ambient calculus specification, the time complexity of


generating the state transition system in the worst case isO(n!). The time complexity of the spatial match process isexponential with the number of ambients. The space com-plexity of the model checking algorithm is linear with thenumber of capabilities and the number of connectives inthe location formulas. The time complexity and perfor-mance of temporal model checking depends on the num-ber of states generated with respect to an ambientcalculus specification. Research on partial order reductiontechniques to reduce the number of states generated byambient calculus model checking, is in progress.

4.2. Example for verification of inter-domain security policybetween two domains

In the first example there are two domains, UniA andHosC. Users may roam between domains, but may belogged onto one domain. Assume that a security policy rulestates that data related to other research projects of Uni-versity A should not be in the same location with patienthealth records. This is formalized with the mobility con-straint (ILFormula). Joint researchers are allowed to loginto servers and read files and databases within UniA andHosC.

In Fig. 9, an information leakage breach in this setting isshown. The set of possible actions allowed by the securitypolicy is modeled as an ambient calculus specification (IL-Spec1) and the location and mobility constraint is modeledas an ambient logic formula (ILFormula) in (15). In order tofind security breaches, the specification includes all possi-ble actions of the user and possible movements of the pa-tient health record, encoded as pdata within the databaseprec. Here the users fmcbride and jfrantz with mobile de-vices have been encoded respectively as u1 and u2.

ILSpec1 ::¼ HosC½u1½�jh31½prec½pdata½in u2:0jout u2:0��jUniA½h11½u2½out h11:0jout UniA:0jin HosC:in h31:0jout h31:out

HosC:0jin UniA:in h11:0jin unif :0jin prec:0jout prec:0jout unif :0�junif ½udata½��

ILFormula ::¼ �f:}f�fpdata½T�judata½T�jTgg ð15Þ

The model checker finds the sequence of actions thatviolate the security policy rule ILFormula. The followingaction sequence formalized by ambient calculus capabili-ties leads to a violation of inter-domain security policy:

Fig. 9. An example mobile user inter-domain access lea

LCONF0 u2½out h11:out UniA:in HosC:in h31��!

pdata½in u2��!

u2½out h31:in UniA:in h11��!

pdata½out u2��!

LCONF1

The interpretation of these actions is, the university re-searcher u2 (jfrantz) moves from UniA domain to HosC do-main with a mobile device, reads patient health recordsfrom HosC file server to his mobile device, moves it tothe university domain and instead of writing it to the jointresearch application server, writes it to the research lab cli-ent where it can be read by other UniA users. Although allof the actions in the specification are allowed individuallyby the security policy, a particular sequence of actions maylead to a security breach as shown in this example.

4.3. Example for verification of inter-domain security policyamong multiple domains

Let’s assume that the there are security policy rulesstating that patient records database prd may be read di-rectly by users of UniA and HosC but not by CorpB users.The joint project users in UniA may also write records tojoint project web application jrapp of UniA. Assume thatthe security policy allows jrapp in Host h12, to be accessibleand readable by Software Engineers in CorpB (dmendiola isencoded as u4). Also assume that patient records serverHost h31 in Domain HosC is accessible by Domain UniAuser nmullis (encoded as u2). These policy rules result inthe formalization of security policy LCONF and the map-ping of permissions to the formal specification as detailedin Table 8.

Now we specify an inter-domain security policy rulethat patient records in HosC domain should not ever occurwithin CorpB file server h22. This results in a security policyrule with spatial and temporal formula specified asfo ¼ �f:}f�fh22½�fprec½T�jTg�ggg. The specifications aregiven to the model checker to find a counter-examplewhich satisfies LCONF�fo.

The model checker generates a total of 81,782 states forthis scenario. The flow of states leading to a state in whichfo is invalidated denotes the sequence of actions leading tothe unintended violation of the inter-domain security pol-icy. The sequence of actions, corresponding to the statesleading to a counterexample discovered by the modelchecker is outlined below.

ding to an inter-domain security policy violation.

Table 8Formal specification of policy in ambient calculus for multi-domainscenario.

Subject Permission Formal specification LCONF in ambientcalculus

u2 (read,prd) World[HosC[h31[prd[out h31.out HosC.inUniA.in h11.in u2.0j

u2 (write,prec) prec[in jrapp.0]]]]ju4 (login, jrapp) UniA[h12[jrapp[out h12.out UniA.in CorpB.in

h22.in u4.0u2 (login, jrapp) jout h12.in h11.in u2.0u2 (write, jrapp) jout u2.out h11.in h12.0]]u2 (read,prd) jh11[u2[open prd.0]]]ju4 (read, jrapp) DomainC[h22[u4[open jrapp.0]]]]


LCONF0 u2ðread;prdÞ��!

LCONF1

u2ðlogin; jrappÞ��!

u2ðwrite; precÞ��!

LCONF2

u4ðlogin; jrappÞ��!

LCONF3

u4ðread; jrappÞ��!

LCONF4

According to this sequence of actions, User nmullis (u2),who is logged into h11 in UniA, reads patient records precfrom patient records database prd in h31 (LCONF0 ?

⁄LCONF1).u2 logs into application jrapp and writes prec to applica-tion jrapp in h12 (LCONF1 ?

⁄LCONF2). Then softwareengineer dmendiola (u4) of CorpB logs into jrapp(LCONF2 ? ⁄LCONF3). Then u4 reads and discloses thedatabase records from within file server h22 in CorpB(LCONF3 ? ⁄LCONF4). The state LCONF4 violates the inter-domain security policy rule.

5. Authorization of access requests according to FPM-RBAC security policies

The algorithm presented in this section is utilized formaking the permission or denial decisions for requestedactions against security policy specifications. Determina-tion of whether the actions in the multi-domain mobilenetwork are permitted requires a formal linkage of accessrequests to the security policy model. Checking the satis-faction of current state of the system to constraints inthe security policy is essential to match rules to policies.The location configuration of the system LCONF holds theambient calculus process specification for the current sys-tem. With each action this configuration is updated. Thelocation constraints which are enabled in the current loca-tion configuration of the system is determined by spatialmodel checking. This computation is decidable when usingthe fragments of ambient calculus and logic presented inthis paper. The set of functions and predicates in domainpolicies and the inter-domain policies are defined respec-tively by the set of security policies X and W. The stateof the logical functions and predicates are tracked by thesystem. The Generic constraints as well as SOD constraintsare evaluated according to the current state of the logicalfunctions and predicates.

Matching actions to policy rules requires the followingsteps:

1. Determine the applicable authorization terms based onthe service activated by the user.

2. Map the authorization subjects in the policy rule to rolesin the access request through role hierarchy definitions.

3. Map the authorization objects in the policy rule to theobject on which an access is requested, through objecthierarchy definitions.

4. Determine whether the location and mobility con-straints are satisfied by the location configuration.

5. Determine whether the generic constraints and SODconstraints are satisfied.

6. Determine whether the action is permitted or deniedthrough the access control function.

The steps for checking the satisfaction of location con-straints and generic constraints may be computed off-lineduring state changes. The evaluation of the access controlfunction needs to be computed at the time of the request.In the following paragraphs, we investigate the functionsand algorithms necessary for the execution of the stepsmentioned above.

5.1. Evaluation of access requests according to services

An access request ar is specified as ar = hu,serv,ru, lr,act,objiwhere serv 2 V [ IC; ru 2 R; lr 2 H [ D; act 2 A; obj 2 O.Here, serv denotes the active service that the user hasactivated including inter-domain services, ru is the roleassumed by the user, lr is the location of the user (a hostor domain), act is the requested action and obj is the objectupon which an action is requested.

The subset of domain security policy for domain i per-taining to the service activated by the user,P0i, is specifiedas P0i � Pi : f8v 2 V i; serv ¼ vg.

Given an authorization term in of the form at = (as,ao, -sa,co, fo), the set of available authorization terms to a rolewithin a service AT 0i � ATi is specified in (16).

AT 0i ¼[

at2AT

RASðas; ruÞ ^ RENðru; servÞ ð16Þ

The calculation is straightforward since the PAM alreadydefines permissions for each service. The authorizationterms are the rules in the permission access matrix forthe service which relate to the enabled roles.

5.2. Evaluation of hierarchies

First, the system checks whether the requested role inthe access request may be assumed by the user. This isequivalent to RAS (u,ru) = >.

Second, the set of authorization terms which apply tothe role and object hierarchies defined in the security pol-icy needs to be calculated. This takes four steps, to find theset of authorization terms at ¼ ðas; ao; sa; co; foÞ; at 2 AT 0i,where:

1. The user specified in the authorization term (if any) isequal to the user requesting the service,ATu

i ¼ fatj at 2 AT 0i; as ¼ ug.2. The role specified in the authorization term is equal or a

descendant role of the role specified in the accessrequest, ATr

i ¼ fatj at 2 AT 0i; as ¼ ru _ as rug.


3. The object specified in the authorization term is equalto the object upon which the access is requested,ATo

i ¼ fatj at 2 AT 0i; ao ¼ objg.4. The object specified in the access request is of object

type specified in the authorization term, or the objecttype of the object is a descendant of the object typespecified in the authorization term, ATot

i ¼ fatj at 2AT 0i; OITðobj; aoÞ _ object typeðobjÞ aog.

The set of derived authorization terms in presence ofrole and object type hierarchies AT00 is AT 00 ¼ ATu

i [ ATri[

AToi [ ATot

i .

5.3. Checking satisfaction of location and mobility constraints

To check location constraints in security policy, we ap-ply model checking of ambient calculus specificationsagainst ambient logic formulas, as presented in Section 4.The calculation of satisfaction relation for location configu-ration against location and mobility constraints is formal-ized as follows: for each authorization term(as,ao,sa,co, fo) 2 AT00, where LCONF is an ambient processspecification for the current location configuration and fois an ambient logic formula within the authorization term,determine whether LCONF�fo.

The set of authorization terms applicable for the cur-rent access request is further reduced according to thesatisfaction of location constraints by the current locationconfiguration of the system. The set of derived authoriza-tion terms which satisfy location constraints is ATloc ={(as,ao,sa,co, fo) 2 AT00jLCONF�fo}.

5.4. Checking generic and SOD constraints specified byconditions

The method for checking conditions in the security pol-icy rules is as follows: Where PRED is the set of satisfiedpredicates in the current state of the system and co is acondition, for each authorization term (as,ao,sa,co, fo) 2 AT00, determine whether PRED�co.

Since predicate calculus is utilized for specification ofpredicates and conditions in the security policy rule, thesatisfaction relation is a logical entailment problem. Weutilize an automated theorem prover for specificationand verification of conditions. A detailed description oftheorem prover support is out of scope of this paper. Thecalculation of SOD relations are presented in detail inSection 3.5.

The set of authorization terms applicable for the currentaccess request, which satisfy conditions is specified asATco = {(as,ao,sa,co, fo) 2 AT00jPRED�co}.

5.5. Evaluation of the access control function

The access control function (ACF) matches a requestedpermission against the set of permissions assigned to rolesin a certain location. The set permissions⁄(ru), denoting per-missions for a role, derived from the set of authorizationterms at = (as,ao,sa,co, fo), at 2 AT00 evaluated against hier-archies, can be calculated as:

permissions�ðruÞ ¼ ðobj; actÞ 2[

ðao;saÞ2P

at 2 AT 00

When an access request ar by a user u with role ru in aspecific location lr to conduct action act on object obj isreceived, ACF (ar) may return two values, allowed or de-nied. The definitions of the access control function is asfollows.

Definition 12. Access Control Function ACF is:

ACFðarÞ ¼ allowed if : ðlr 2 servÞ ^ ðAT 00 – ;Þ^ðATco [ ATloc – ;Þ ! 9ðþ; actÞ 2 permissions�ðruÞ

ACFðarÞ ¼ denied if : ðlr R servÞ _ ðAT 00 ¼ ;Þ_9ð�; actÞ 2 permissions�ðruÞ

The interpretation of the access control function is, ifthe location of the user is within locations associated withthe service, if there is any derived authorization termsaccording to evaluation of user name, role, role hierarchy,object or object hierarchy, if the location and separation-of-duty constraints are applicable to the set of derivedauthorization terms, then there is at least one rule with apermission that has the same object and action as thosewithin the access request. The denial takes place if the re-quest is placed from a location outside the scope of the ser-vice, there is no derived rule for the request, or there is atleast one derived rule with a specific denial (negative sign).The order of evaluation of denials versus allowed accessesmay depend on precedence of signs (denials take prece-dence, allowances take precedence).

6. Conclusions and future work

In this study, we presented a new formal security policymodel for multi-domain mobile networks, called FPM-RBAC (Formal Policy Model for Mobility with Role BasedAccess Control). FPM-RBAC supports the specification ofmobility and location constraints, role hierarchy mapping,inter-domain services, inter-domain access rights and sep-aration of duty. Role hierarchy mapping, inter-domain ser-vices, inter-domain access rights are defined by a formalinter-domain security policy model. Within this modelwe have introduced the concept of inter-domain rolesand inter-domain role hierarchies. Roles are mapped to in-ter-domain roles with a role mapping function. An inter-domain service is accessible by home or foreign usersthrough inter-domain roles and includes objects fromhome domain. The access rules for inter-domain servicesby foreign roles is achieved through the inter-domain per-mission assignment relation. This approach provides moreflexible administration where a domain administrator doesnot need to know the roles and identities of foreign usersor entities who are accessing resources in a domain andare enrolled in other domains. Also, need-to-know princi-ple of security is preserved while information is shared be-tween multiple domains.

Associated with FPM-RBAC, we also present a formalsecurity policy constraints specification language for do-main and inter-domain security policies. Formal policyconstraint specifications are based on ambient logic and


predicate logic. ambient calculus is used to specify the cur-rent state of a mobile network and actions within securitypolicies for evaluation of access requests according to secu-rity policies. We take a formal process calculus approachbecause it is inefficient to represent mobility with rela-tional models which is an approach in recent literature inthe area of location based access control models. The for-mal location and mobility model within FPM-RBAC is capa-ble of modeling actions in security policy rules as well asproviding a dynamic spatial and temporal mobile networkmodel. It provides a formal link between security policiesand the mobile network.

As a result of this link, the use of the proposed formalpolicy model enables specification and analysis of inter-domain security policies. Formal analysis of securitybreaches arising from mobility within multiple securitydomains is possible. This analysis uses the model checkingalgorithm we have presented in our previous work. Wehave presented two examples of formal analysis in mobilenetworks, for two domains and multiple domains. By useof formal analysis, it is possible to construct a set of secu-rity policies towards prevention of security breaches aris-ing from mobility.

In our ongoing research work, we are constructing auto-mated tools for extracting formal specifications from XML-based security policies and automated verification of secu-rity policies for multiple-domain mobile networks. We aimin providing a complete policy framework for FPM-RBACwith an integrated specification, enforcement and verifica-tion environment.

Acknowledgements

This work is partially supported by the State PlanningOrganization of Turkey, TAM Project (2007K120610). Wealso acknowledge the comments by Dr. Tuna Tugcu.

Appendix A. Supplementary material

Supplementary data associated with this article can befound, in the online version, at http://dx.doi.org/10.1016/j.comnet.2012.09.018.

References

[1] S. De Capitani di Vimercati, P. Samarati, Access control in federatedsystems, in: Proceedings of the 1996 Workshop on New SecurityParadigms, 1996, pp. 87–99.

[2] R. Bhatti, E. Bertino, A. Ghafoor, X-FEDERATE: a policy engineeringframework for federated access management, IEEE Transactions onSoftware Engineering 32 (2006) 330–346.

[3] F. Hansen, V. Oleshchuk, Spatial role-based access control model forwireless networks, Proceedings of IEEE Vehicular TechnologyConference 3 (2003) 2093–2097.

[4] S. Chandran, J. Joshi, LoT-RBAC: a location and time-based RBACmodel, in: A. Ngu, M. Kitsuregawa, E. Neuhold, J.-Y. Chung, Q. Sheng(Eds.), Web Information Systems Engineering, Lecture Notes inComputer Science, vol. 3806, Springer, Berlin/Heidelberg, 2005, pp.361–375.

[5] I. Ray, M. Toahchoodee, A spatio-temporal role-based access controlmodel, in: S. Barker, G.-J. Ahn (Eds.), Data and Applications SecurityXXI, Lecture Notes in Computer Science, vol. 4602, Springer, Berlin/Heidelberg, 2007, pp. 211–226.

[6] M. Kumar, R.E. Newman, STRBAC – an approach towards spatio-temporal role-based access control, in: Proceedings of the 3rd

IASTED Int. Conf. on Communication, Network, and InformationSecurity, 2006, pp. 150–155.

[7] M.L. Damiani, E. Bertino, B. Catania, P. Perlasca, GEO-RBAC: aspatially aware RBAC, ACM Transactions on Information andSystem Security 10 (2) (2007).

[8] D. Kulkarni, A. Tripathi, Context-aware role-based access control inpervasive computing systems, in: Proceedings of the 13th ACMSymposium on Access Control Models and Technologies, 2008, pp.113–122.

[9] S. Aich, S. Mondal, S. Sural, A.K. Majumdar, Role based access controlwith spatiotemporal context for mobile applications, in: M.L.Gavrilova, C.J. Tan, E.D. Moreno (Eds.), Transactions onComputational Science IV, Springer-Verlag, Berlin, Heidelberg,2009, pp. 177–199.

[10] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role-basedaccess control models, IEEE Computer 29 (1996) 38–47.

[11] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli,Proposed NIST standard for role-based access control, ACMTransactions on Information and System Security 4 (2001) 224–274.

[12] L. Cardelli, A.D. Gordon, Ambient logic, Mathematical Structures inComputer Science (2006) In Press.

[13] L. Cardelli, A.D. Gordon, Anytime, anywhere: modal logics for mobileambients, in: Proceedings of the 27th ACM SIGPLAN-SIGACTSymposium on Principles of Programming Languages – POPL ’00,2000, pp. 365–377.

[14] L. Cardelli, A.D. Gordon, Mobile ambients, Theoretical ComputerScience 240 (2000) 177–213.

[15] D. Unal, O. Akar, M. Ufuk Caglayan, Model checking of location andmobility related security policy specifications in ambient calculus,in: I. Kotenko, V. Skormin (Eds.), Computer Network Security,Lecture Notes in Computer Science, vol. 6258, Springer, Berlin/Heidelberg, 2010, pp. 155–168.

[16] D. Hirschkoff, E. Lozes, D. Sangiorgi, On the expressiveness of theambient logic, Logical Methods in Computer Science 2 (2) (2006).No: 3.

[17] D. Scott, Abstracting application-level security policy for ubiquitouscomputing, Ph.D. thesis, University of Cambridge, 2005.

[18] A. Compagnoni, P. Bidinger, Role-based access control for boxedambients, Theoretical Computer Science 398 (2008) 203–216.

[19] N. Zhang, M. Ryan, D.P. Guelev, Synthesising verified access controlsystems through model checking, Journal of Computer Security 16(2008) 1–61.

[20] C. Braghin, N. Sharygina, K. Barone-Adesi, A model checking-basedapproach for security policy verification of mobile systems, FormalAspects of Computing (2010) 1–22.

[21] R. Mardare, C. Priami, P. Quaglia, A. Vagin, Model checking biologicalsystems described using ambient calculus, Computational Methodsin Systems Biology 3082 (2005) 85–103.

[22] W. Charatonik, S.D. Zilio, A.D. Gordon, S. Mukhopadhyay, J. Talbot,Model checking mobile ambients, Theoretical Computer Science 308(2003) 277–331.

[23] E. Bertino, P. Bonatti, E. Ferrari, Trbac: a temporal role-based accesscontrol model, ACM Transactions on Information and SystemSecurity (TISSEC) 4 (2001) 191–223.

[24] J.B.D. Joshi, E. Bertino, U. Latif, A. Ghafoor, A generalized temporalrole-based access control model, IEEE Transactions on Knowledgeand Data Engineering 17 (2005) 4–23.

[25] S. Mondal, S. Sural, XML-based policy specification framework forspatiotemporal access control, in: Proceedings of the 2ndInternational Conference on Security of Information and Networks,2009, pp. 98–103.

[26] W3C Web Services Architecture, 2004. <http://www.w3.org/TR/ws-arch/> (accessed October 2011).

[27] W3C Web Services Glossary, 2004. <http://www.w3.org/TR/ws-gloss/> (accessed February 2011).

[28] D. Unal, M. Caglayan, Theorem proving for modeling and conflictchecking of authorization policies, in: Proceedings of theInternational Symposium on Computer Networks, 2006, pp. 146–151.

[29] S. Jajodia, P. Samarati, M.L. Sapino, V.S. Subrahmanian, Flexiblesupport for multiple access control policies, ACM Transactions onDatabase Systems 26 (2001) 214–260.

[30] G.-J. Ahn, R. Sandhu, Role-based authorization constraintsspecification, ACM Transactions on Information and SystemSecurity 3 (2000) 207–226.

[31] D. Unal, M.U. Caglayan, Spatio-temporal model checking of locationand mobility related security policy specifications, Turkish Journal ofElectrical Engineering & Computer Sciences, (2012), in press. http://dx.doi.org/10.3906/elk-1105-54.



http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/ws-gloss/

http://www.w3.org/TR/ws-gloss/

http://dx.doi.org/10.3906/elk-1105-54

http://dx.doi.org/10.3906/elk-1105-54


[32] C.C. Giunchiglia, A. Cimatti, E. Clarke, F. Giunchiglia, M. Roveri,Nusmv: a new symbolic model checker, International Journal onSoftware Tools for Technology Transfer 4 (2000) 410–425.

Devrim Unal is a senior researcher in theCenter of Research for Advanced Technologiesof Informatics and Information Security(TUBITAK BILGEM), Kocaeli, Turkey. Hereceived Bachelor of Engineering degree inComputer and Control Engineering fromIstanbul Technical University, Turkey in 1997,Master of Science degree in Telematics fromUniversity of Sheffield, UK in 1998 and Doctorof Philosophy in Computer Engineeringdegree from Bogazici University in 2011. Hisresearch interests are in the area of informa-

tion security, access control, mobile networks and formal methods.

Mehmet Ufuk Caglayan (S’77-M’82) receivedhis BSEE and MSCS degrees from Middle EastTechnical University, Ankara, in 1973 and1975 respectively, and his PhD degree fromNorthwestern University, Evanston, Illinois, in1981. He was a faculty member in DePaulUniversity, Northwestern University andUniversity of Petroleum and Minerals, Dhah-ran, Saudi Arabia. He served as a computerscientist in BASF AG, Ludwigshafen, Germany.He is currently serving as a full professor inthe Department of Computer Engineering,

Bogazici University, Istanbul. His interests are in computer and networksecurity, computer networks, wireless and mobile networks, parallel anddistributed systems, operating systems, performance modeling and soft-
ware design. He is a member of Turkish Informatics Society, TurkishAssociation of Electrical Engineers and Turkish Internet TechnologiesSociety.

Documents

A formal role-based access control model for security policies in multi-domain mobile networks