Interoperability of Context Based System Policies Using O2O Contract

Celine Coma Nora Cuppens-Boulahia Frederic CuppensIT/TELECOM Bretagne, 2 rue de la Chataigneraie, 35512 Cesson Sevigne, France

Ana Rosa CavalliIT/TELECOM Sud Paris, 9, rue Charles Fourier, F-91011 Evry, France

Abstract

The evolution of today’s markets and the high volatilityof business requirements put an increasing emphasis on theability for systems to accommodate the changes required bynew organizational needs while maintaining security objec-tives satisfiability. This is even more true in case of col-laboration and interoperability between different organiza-tions and thus between their information systems. Usualsolutions do not anticipate interoperability security require-ments or do it in a non satisfactory way. In this paper, wepropose contract and compatibility principles to achieve asecure interoperation. Contracts are used to explicitly rep-resent the rules that determine the way interaction betweenorganizations must be controlled to satisfy secure accessesto resources. Compatibility relations make it possible to de-rive interoperability security policies.

1 Introduction

In the traditional approaches of data processing and re-source access controlling, the model of an enterprise israther static. This is sufficient for managing securely thebehavior of an enterprise within settled ranges of actions;it is unsatisfactory when the environment of the enterprisechanges following the occurrence of different events likethose generated by interoperability sessions.

Environment changes became an established fact of cur-rent enterprises. They need to be agile, flexible and se-curely interoperable since they act in an increasingly dy-namic environment which tends to be collaborative but un-fortunately possibly hostile. To meet these requirements,synthetic knowledge is needed to let enterprises continu-ously manage accesses, ensure the integrity of exchangesand the continuity of services.

Most of the recent works argue for the use of ontolo-gies as a mean for providing this synthetic knowledge ofcommon domains. Moreover, as this cooperation must be

secure for each of the party involved within it, it is nec-essary to provide a context-aware tailored mapping pro-cess that takes into account this security aspect and derivesthe security policies. We claim that this derivation processneeds to use: (1) ontological mapping, this means mappingstructure-oriented entities of the two organizations havingto interoperate. Accordingly, a correct meaning can be as-signed to these structuring entities which could seem a pri-ori different. Examples of these entities are roles or activi-ties of subjects pertaining to these organizations, especiallythe environmental conditions under which they evolve, and(2) compatibility relations between the grantor organizationoffering the service and the grantee organization request-ing an access to the service, this means mapping deontic-oriented entities of the organizations having to interoperate.These relations will be used to specify interoperability poli-cies. In this case, deontic entities are primarily permissionsand prohibitions rules.

Moreover, these interoperability security policies mustnot be derived on the fly. This can lead to a lack of fair-ness, inconsistencies and breaches of security. Also, thesepolicies are usually established after a phase of policy ne-gotiation, which can be time consuming. This time, may insome cases be longer than the interoperability session andresult in a loss of efficiency.

In this paper, we propose an approach to anticipate inter-operation security policies and thus shorten the policy ne-gotiation steps. Our work is based on the O2O approach(Organization to Organization) [6] as a framework for a se-cure interoperability where the authority sphere defining se-curity policy and the management sphere administering thissecurity policy are well identified. We define interoperationcontracts to control the aforementioned derivation processof interoperability security policies. This process is charac-terized by a duality between the maximization of the secu-rity and the insurance of the cooperation.

The rest of this paper is organized as follows. In §2 wecarry out a survey of existing research works related to se-cure interoperability and emphasize on their weaknesses.In §3 we recall the two basic bricks we use to express,

2008 IEEE International Conference on Signal Image Technology and Internet Based Systems

978-0-7695-3493-0/08 $25.00 © 2008 IEEE

DOI

137

2008 IEEE International Conference on Signal Image Technology and Internet Based Systems

978-0-7695-3493-0/08 $25.00 © 2008 IEEE

DOI

137

2008 IEEE International Conference on Signal Image Technology and Internet Based Systems

978-0-7695-3493-0/08 $25.00 © 2008 IEEE

DOI 10.1109/SITIS.2008.68

137

2008 IEEE International Conference on Signal Image Technology and Internet Based Systems

978-0-7695-3493-0/08 $25.00 © 2008 IEEE

DOI 10.1109/SITIS.2008.68

137

derive and enforce context-aware interoperability policies:the contextual security model OrBAC[11] and the interop-erability framework O2O. In §4 we explain the steps forinteroperability establishment. After limiting the scope ofinteroperation in §5, we state formally the different types ofcompatibility relations between the grantor and the granteeorganizations to establish an interoperability security pol-icy rules using the ontological mapping and the definitionof compatibility constraints. The process guarantees thatthe interoperability security policy is consitent with the lo-cal policy of the grantor organization and the security policyof the grantee organization. We present a peer-to-peer ex-ample to illustrate our approach in section §7. §8 concludesthis paper.

2 Usual Approaches for Interoperability

There exist three ways to deal with interoperability. Afirst approach is the Federation of Identity Management(FIM). There are several kinds of FIM technologies. Themost famous are Liberty Alliance [4] and Microsoft Pass-port [15]. FIM generally covers at the same time user man-agement and access management. Several identity serviceslike Single Sign-On, access control and federation of iden-tities, bring together the necessary components to providea specific pertaining service to a given identity. However,FIM bases the trust relation on reliability of identities ofeach participant. This identity is a set of information knownabout the participants which could be stored across multiplemanagement systems. Certification of identities relies on arelevant trusted authority. So, FIM could have problems toset up their trust relationship. Furthermore, in most of FIMsystems, negotiation exchanges are centralized and partic-ipants have to be identified by FIM. This choice limits theuse cases of interoperability as FIM relies only on the useridentities when dealing with security. Consequently, one ofthe major problems of FIM is the lack of granularity whenassigning privileges. For example, if two organizations Band C belong to a same alliance A, all users of B have thesame privileges when they access to C. Our approach pro-vides finer grained access control than one can do with FIM.

The second kind of interoperability related works is se-curity policy oriented. In this case, the decision to grant anaccess is primarily based on exchanges of credentials andaccesses to the information they convey. Automated TrustNegotiation [12], TrustBuilder [1] and Trust-X [3] are ex-amples of these approaches. In this case, specific languageshave to be defined. They are largely inspired by the RBACmodel (Role based Access control model) [17]. But, in theirlanguages, there is no clear separation between the securitypolicy specification and credentials that are used to imple-ment this policy. Moreover, the RBAC model does not takeinto account the organization dimension, which is essen-

tial in the case of interoperability, and the concept of roleis prevalent in this model which is not sufficient to expressfine grained access control. Our proposal is context-awareand goes beyond the role based approaches.

During interoperability exchanges, each organizationshould inform others about its knowledge. But, the problemis that knowledge must be understandable by participants ofinteroperation sessions. An ontology provides an explicitconceptualization that describes the semantics of the dataand provides a common sharing knowledge which can beeasily communicated. Thus, the third way to manage secureinteroperability makes use of such ontologies. REI [13] andKAoS [18] are examples of models belonging to this cate-gory. KAoS is designed to specify and reason on securitypolicies of interoperable environments, such as Grid or Webservices and uses the ontological language OWL [14]. But,KAoS is restricted to the specification of security policiesthat do not require the use of variable parameters. REI ex-tends the KAoS language by adding logical variables to in-crease its expressivity. REI also includes specification ofmeta-policy to solve conflicts. However, REI ontology onlydeals with constraints and description of local entities whichis far from being enough in case of interoperability. Thus,we should go further in this direction to take into accountlocal, external and contextual information and derive a dy-namic security policy on which we can reason. That is ourproposal in this paper.

3 Generic Interoperation Policies

3.1 Contextual Security Policy

The goal of our approach is to anticipate on interoper-ability. To do so, we require an approach which allows bothfine-grained access control and interoperation. The OrBACmodel [11] is an access control model in which the policydesigner can express the security policy of an informationsystem at the organizational level, that means independentlyof the future implementation of this policy. So, the op-erational system security requirements could be expressedand then deployed over various security components, con-sidered in OrBAC as sub-organizations of the informationsystem organization. This deployment rests also on admin-istrative responsibilities which could be granted to subjectsassigned to different roles.

In OrBAC, the traditional triple (subject, action, ob-ject) is abstracted at the organizational level into the triple(role, activity, view). A role (respectively an activity anda view) is a set of subjects (respectively actions and ob-jects) to which the same security rules apply. This re-duces the number of security rules to define. Further-more, we need to have dynamic security policies to reactin time and to satisfy interoperability requirements. Or-

138138138138

BAC is context sensitive, so that the policy could be ex-pressed dynamically by taking into account environmentalevents and states. For instance, the following OrBAC se-curity rule: securityRule( network, permission( peer,access, resource, memberOfnetwork)) means that inorganization network, a peer has the permission to accessto a resource in a context where this peer is member ofnetwork.

Moreover, using the OrBAC model we can specify adecentralized security policy administration that complieswith four principles: organizations, concrete entities, ab-stract entities and hierarchies. An ontological specifica-tion of OrBAC using OWL-DL [14] which rests on the fouraforementioned administration principles, has been definedto meet interoperability objectives [5].

With OrBAC, concrete security policy rules are derivedautomatically from abstract ones. This derivation is com-putable in polynomial time [8], and using OWL-DL is ex-pressed as the following:

is permitted(?s, ?a, ?o) ←securityRule(?org, permission(?r, ?act, ?v, ?ctx)) ∧hasProperty(?org, empower(?s, ?r)) ∧hasProperty(?org, consider(?a, ?act)) ∧hasProperty(?org, use(?o, ?v)) ∧hold(?org, context(?s, ?a, ?o, ?ctx)).

3.2 O2O Interoperability Framework

O2O (Organization to Organization) [6] is both a modeland a framework to manage interoperability between com-ponents having their own policies defined by different or-ganizations. To explain the basic principals of O2O, let usconsider that a given organization Alice.org that wants to in-teroperate with another organization Bob.org. In this case,each organization has to define a Virtual Private Organiza-tion (VPO) respectively called Alice2Bob (A2B for short)and Bob2Alice (B2A for short). The VPO A2B is associ-ated with a security policy that manages how subjects fromthe grantee organization Alice.org, O grantee, may havean access to the grantor organization Bob.org, O grantor.We say that the VPO A2B manages the interoperability se-curity policy from Alice.org to Bob.org. The VPO B2Ais similarly defined to control accesses of subjects fromBob.org to Alice.org. Hence, a VPO is a dynamic orga-nization created to achieve a given interoperability purposeand canceled once this purpose in no more needed. Themanagement of VPO can be centralized, decentralized orhybrid [6]. O2O is formally defined as an extension of theOrBAC model.

4 Interoperability contract

The interoperability process we propose composed ofthree steps. (1) The contract definition step, (2) the inter-operability security policy definition step and (3) the inter-operability security policy management step. The figure 1shows the sequencing of interoperability security policy es-tablishment. First of all, before the interoperation sessions,the O grantor organization defines contracts for each or-ganization type it has to interoperate with (cf. §4). Forthat purpose, the O grantor defines the scope of each con-tract. It specifies entities and information that can be pro-vided during interoperability. In the second step (cf. §5), theO grantor organization defines some patterns of interoper-ability security rules on the basis of its local security policyand according to the type of interoperability. Thirdly, us-ing ontologies, we establish compatibility relations (cf. §6).Next, using these compatibility relations and contracts, wederive the interoperability security rules. At this stage, theVPO is created. Finally, the O grantor decides how thisVPO will be managed: centralized, decentralized or hybridadministration (Cf. [6]).

Figure 1. Creation of interoperability policy

The contract: Interoperability security policies defined andmanaged in VPOs must be compliant with local securitypolicies. They have not to be defined either on the fly orfrom scratch. Thus, the VPO security policies are derivedfrom the local policies. The O grantor, based jointly onits objectives (security), its environment and also its cog-nitive capacities (its own knowledge and knowledge it hasabout the grantee organizations) proposes interoperabilitycontracts. According to the grantee organization type, acontract specifies the way the local policy may be tunedand fixes the scope of this adaptation.The scope: In the interoperability contract, entities that canbe shared are specified. This specification is done usingthe classes (or sub-classes) to whom these entities belong.The benefit of using classes is threefold: (1) we avoid tooverload all the entities, (2) it does not matter if the entityis a subject, an object or an action as the class overrides thisdifference and (3) a class is not organization dependent.

Each class is associated with some attributes. In

139139139139

the logical formalism of the OrBAC model, an attributeis specified by a binary predicate. For example, thefact peername(p1, p1name) means that p1 has an at-tribute peername whose value is p1name. The pred-icate classAssign is used to express that some objectbelongs to some class. For example, classAssign(p1,peerDesc) means that p1 belongs to the class peerDesc.Then, the grantor organization specifies the possible inter-operation entities in some given contract using the predi-cate can be mapped. The fact can be mapped(?grantee,?o grantor, ?className) means that all entities belong-ing to the class ?className can be used, so mapped, dur-ing the interoperation between ?o grantor and ?grantee.Notice that, in that case, ?o grantor is some organizationA and ?grantee can be an organization B or also an orga-nization type, for instance every organization that belongsto some peer to peer network.The effective mapping: Among attributes of a class, thereare key attributes. These key attributes indicate whichattributes must be used in the ontological mapping pro-cess between the grantee and the grantor organizations;other attributes are not taken into account. So, for eachclass appearing in the interoperability contract, its key at-tributes are specified. This is achieved using the predicateclass(?className, ?attribute, Key att). For instance,if the interoperability contract requires that to authenticatea user in some peer to peer network, only one of its identities(IP address, Id client, etc.) have to be mapped, the attributesrelated to the peer identity are key attributes. Moreover, inthis example a threshold is specified (only one attribute isneeded) and required to conclude that the mapping is ac-cepted.

We can go further. The key attribute requirement canbe strengthened. The interoperability contract could spec-ify that, for a mapping to be effective, a particular key at-tribute (key key attribute) have to be mapped between enti-ties within key key attributes. For instance, in a peer to peernetwork, only the hash is used to establish a compatibilitybetween the shared files’ contents. So, the hash attribute issuch a key key attribute. The figure 2 gives examples ofsuch attributes. In figure 2, the key key attributes are un-derlined. To establish compatibility between two elements,either all the key key attributes should match, or more thanAmatchThreshold ratio key attributes should match.

5 Nature of Interoperability Contract

5.1 Underivability and Exception

In the O2O approach, each organization defines andmanages its VPO policies. The administration of VPO mustbe both compliant with the local security and allows thegrantor organization to carry out a flexible interoperability.

Figure 2. Key and Key Key Attributes

In the following, we set forth some VPO policy derivationrequirements.

Obviously, some privileges are strictly local to thegrantor organization. So, to bound the propagation ofthe security rules related to these kinds of privileges,the predicate underivable is used. Thus, the followingfact: underivable(?grantee, securityRule(?o grantor,permission(?r, ?activity, ?view, ?cxt))) specifies thatthe securityRule defined in the local policy of ?o grantorcannot be derivable in the VPO policy of the ?grantee or-ganization or organization type.

Moreover, a collaborative organization can have specificsecurity rules related to its security policy externalization.These rules are not used in the local policy. The pred-icate exception is used to express such exception rules.The fact exception(?grantee, securityRule(?o grantor,prohibition(?r, ?activity, ?view, ?cxt))) means that aprohibition is added to the VPO policy when a ?granteeorganization requires an interoperability session with?o grantor. An exception security rule is either a prohi-bition or an obligation.

Usually, a conflict can appear between a permission anda prohibition. Thus, exceptions can also create new con-flicts. To ease the policy designer’s work, we anticipate theresolution of conflicts generated by such exception rules.Thus, exception rules are always associated with higherpriority than other privileges (including the non derivablerules). This conflict resolution strategy is chosen to managethe shadowing anomaly1.

5.2 Compatibility Relation Patterns

A compatibility relation can be defined if and onlyif ontological mapping between O grantee entities andO grantor entities has been established elsewhere a newpackage of security rules is defined and added to the VPOpolicy. Security rules of the VPO are derived according to

1A rule is shadowed by a higher priority rule if it can never be activated.

140140140140

Figure 3. VPO derived from contract

this mapping, the contract, underivability and exception re-quirements and, the restrictions to be applied to the localroles specified by the O grantor organization for a givenO grantee organization (see figure 5.2). We model theserestrictions as compatibility relations.

Let ro grantor be a role defined in the O grantor or-ganization and ro grantee the corresponding grantee roledefined in the O grantee organization. And let Ovpo be theVPO associated to O grantee. There are four main com-patibility patterns:

• Total compatibility relation (T compatibility).If O grantor and O grantee are T compatible then,in Ovpo, the grantee role ro grantee inherits all thesecurity rules assigned to ro grantor along with ex-ception rules. Notice that underivable security rulesare not inherited.

• Partial compatibility relation (P compatibility).If O grantor and O grantee are P compatible then,in Ovpo, the grantee role ro grantee inherits the secu-rity rules associated with ro grantor along with someconstraints and exceptions. These constraints are re-strictions on activities, views, contexts. Underivablesecurity rules are not inherited.

• Symmetric compatibility relation (S compatibility).If O grantor and O grantee are S compatible then,in Ovpo, the grantee role ro grantee inherits the secu-rity rules of a common derivable sub set of the two lo-cal policies of O grantee and O grantor, with someconstraints, along with some exceptions.

• No compatibility relation (No compatibility).If O grantor and O grantee are No compatiblethen, in Ovpo, there is no security rule related toro grantee. In this case, the interoperation cannottake place through the role ro grantee.

In the case of partial compatibility relation, restrictionson view, activity and context are specified. To do so, wedefine a restriction predicate for each of these OrBAC en-tities. For instance, restrictionActivity(O grantor, A,RA) means that during partial compatibility interoperation

the activity A is replaced by the restriction activity RA. Forinstance, creating activity during interoperability, can be re-stricted to updating activity. Notice that restriction entityshould be included in previous entities.

In our approach, the type of compatibility between orga-nizations having to undertake interoperability sessions mustbe known. We define the predicate type compatibility forthis purpose. The fact, type compatibility(O grantor,O grantee, Type), where Type is a compatibility pattern,means that O grantor and O grantee have a Type com-patibility relation. No compatibility is the default com-patible type. When this default type is used this means theend of the collaboration. In this case, all privileges relatedto this collaboration, if any, are revoked.

6 Interoperation Policy Establishment

6.1 Ontological Mapping

During interoperability, access control cannot be set upwithout semantic compatibility establishment between se-curity policies of parties that have to interoperate. Entitiesinvolved in a collaboration need common knowledge whichshould be understandable by all parties. We stress on thefact that to get good interoperation, organizations need toshare understandable information. To facilitate this sharing,our approach is based on ontology. An ontology providesan explicit conceptualization that describes the semantics ofthe data and provides a common sharing knowledge whichcan be easily exchanged. Usefulness of ontology appearswhen the two ontologies are mapped. With both vocabular-ies and meaning, with help of ontologies, we can establishan automatic translation between two organizations. Thismapping allows ontologies to provide a shared and com-mon understanding of an application domain that can beexchanged between organizations and application systemsundertaking collaboration.

Our ontological mapping is based on TBOX mapping re-lated to the mappings of classes, properties and hierarchies,ABOX mapping related to the mappings of instances andRBOX mapping related to the mappings of rules. Thesemappings apply only to entities that are authorized to bemapped during interoperability by the corresponding con-tract and the nature of this contract. To illustrate the on-tological mapping process, we further describe the ABOX

mapping. Detailed description of other parts of the ontolog-ical mapping process can be found in [5].

ABOX mapping rests on correspondences between at-tributes and their associated values. Thus, we first have tomap attributes before concepts. This kind of mapping hasalready been studied in several works, such as those done inCOMA++ [9] and GLUE [10], but without considering se-curity issues. Notice that ABOX mapping is easy to estab-

141141141141

lish or to revoke when the key attributes are set up. Thus, toestablish ABOX mapping, we compare the number of cor-respondences of key attributes with a threshold, beginningfirst with key key attributes. Let us consider two entitiesc1 ∈ O grantor organization, c2 ∈ O grantee organiza-tion and Sim(c1,c2) the measure of similarity between c1

and c2. First case: c1 and c2 own key key attributes. Inthat case, if all the key key attributes of c1 and c2 match,Sim(c1,c2) = 1, else Sim(c1,c2) = 0. Second case: c1

and c2 have not key key attributes but key attributes. Weuse a normalized value. So, let |Ac1 | be the number of keyattributes associated to c1 and |Ac1 ∩ Ac2 | the number ofkey attributes c1 and c2 have in common. Then, the similar-ity Sim between c1 and c2 is evaluated using the formulaSim(c1,c2) = |Ac1∩Ac2 |

min(|Ac1 |,|Ac2 |)∈[0..1]. Then, ABOX map-

pings are established if the similarity value belongs to theinterval [AmatchThreshold, 1]. AmatchThreshold is athreshold set by the O grantor organization and specifiedin the contract.

6.2 Establishment of Compatibility Rela-tions

The establishment of compatibility relations is a pre-requisite condition to the derivation process of interoper-ability security rules. It rests on the three aforementionedontological mappings, TBOX , ABOX and RBOX and thefour compatibility relation patterns, no compatibility, totalcompatibility, partial compatibility and symmetric compat-ibility. So, for each entity used to express a security rulein the access control model (namely role, activity, viewand context), we define a compatibility predicate. Theview compatibility predicate is defined as the following:

view compatibility(?oa2ob, ?resV a, ?vb) ←viewTmatch(?oa2ob, ?va, ?vb) ∧grantor(?oa2ob, ?orga) ∧ grantee(?oa2ob, ?orgb) ∧restrictionV iew(?orga, ?va, ?resV a) ∧type compatibility(?orga, ?orgb, P compatibility).

Which means that two views resV a and vb in the VPOorga2orgb are compatible if there exists an ontologicalmapping between a view va belonging to the grantor or-ganization orga and a view vb belonging to the granteeorganization orgb and, resV a is a restricted view of vaand, there is a P compatibility relation between orgaand orgb. The two predicates activity compatibilityand context compatibility are similarly defined androle compatibility are defined without restriction.

6.3 Derivation of the Interoperability Se-curity Policy

Once some agreements exist on the compatibility of en-tities of those organizations having to undertake some in-teroperability sessions, security rules are derived from thelocal policies. In the case of total compatibility, a securityrule is derived as the following:

securityRule(?oa2ob, permission(?rb, ?a, ?v, ?c)) ←type compatibility(?orga, ?orgb, T compatibility) ∧grantor(?oa2ob, ?orga) ∧ grantee(?oa2ob, ?orgb) ∧securityRule(?orga, permission(?ra, ?a, ?v, ?c)) ∧role compatibility(?oa2ob, ?ra, ?rb) ∧not(underivable(?orgb, securityRule(?orga,permission(?rb, ?a, ?v, ?c))).

Similar rules with some restrictions are defined in thecase of partial compatibility type and symmetric compati-bility . Notice that if an entity has no restriction, the restric-tion of this entity is itself. Let us take an example.

securityRule(net, permission(node, access,sharingMovies, lawfull)) ←type compatibility(netp1, netp2, P compatibility) ∧grantor(net, netp1) ∧ grantee(net, netp2) ∧securityRule(netp1, permission(peer, access, files,lawfull)) ∧ role compatibility(net, peer, node) ∧restrictionV iew(netp1, files, sharingMovies) ∧restrictionActivity(netp1, access, access) ∧restrictionContext(netp1, default, lawfull) ∧not(underivable(netp2, securityRule(netp1,permission(peer, access, files, lawfull))).

In this example of security rule derivation, organizationnetp2 has established a partial compatibility type contractwith organization netp2. So, the permission of a peer in thegrantee organization netp1 to get an access to a file belong-ing to the grantor organization netp2 must be tuned in theVPO net during the interoperability sessions. The defaultcontext is restricted to a context related to lawfull. Therole peer must be compatible with the role node. Further-more, organization netp1 restricts its file to an interoperableview SharingMovies. So, in the interoperability securitypolicy we derive the permission for a node in the VPO orga-nization net to access to interoperation files in the lawfullcontext, that is to say movies which respect the legal ageaccording to the grantee country.

7 Illustration

7.1 P2P and interoperability

As seen in the related works (cf. §2), most of the usualapproaches rest on a centralized administration of policies

142142142142

to create collaborations, like in CAS server [16], or are notsufficient to express fine grained access control. The in-creasing use of spontaneous networks like peer to peer tendsto require a decentralized administration of the collabora-tion resources. In that case, the security of this kind of in-teroperability environments remains a hard problem. As amatter of fact, peer-to-peer systems can be very dynamicand the peers’ volatility is a barrier to a negotiation pro-cess setting during access control checking. Furthermore,P2P networks have many specific problems. For instance,in P2P systems, a peer is anonymous, so it is difficult toestablish trust relationships. File sharing mitigates free-riding problem, but it is a spread vector of corrupted andmalicious files. As suggested in this paper, the O2O frame-work, and the concept of contract the interoperability policysub-organization has to be comply with, significantly con-tributes to secure this kind of collaboration. In the follow-ing, we illustrate the interoperability policy derivation usinga P2P scenario.

7.2 P2P and O2O contract

A new peer Robert joins the P2P networkpeerNetwork. Robert wants to get an access to theResident Evil movie. So, First, Robert emits a searchrequest to find this movie. The Distributed Hash Tableindicates that two peers own the Resident Evil movie:P1 and P3. Then, Robert sends a resource request to P3

to access to Resident Evil. A resource access request iscomposed of an interrogative license and can also containthe authorization proofs (credentials). A license (cf. [7]) isan administrative access control object which is modular,exportable and contains all the relevant security informa-tion. The existence of a valid licence will be interpretedas the assignment of some permission. A licence hasfive attributes: (1) authority: organization in which thelicence applies, (2) grantee: subject to which the licenceis granted, (3) privilege: action permitted by the licence,(4) target: object to which the licence grants an accessand (5) context: specific conditions that must be satisfiedto use the licence. The corresponding access request lookslike the following:

accessRequest(?number,@Robert, resourceAccess,license[authority(L,@Dest), grantee(L,Robert),privilege(L, download), target(L,ResidentEvil),context(L, default)]), @polRobert).

where ?number is the identifier of the request, grantee,privilege, target and context are license information.@polRobert is the URI of Robert’s security policy.@Robert is Robert’s address. @Dest is the grantor’s ad-dress, in this case P3 address. P3 contract specifies thatthere is No compatibility type with a peer which has never

exchanged resources in peerNetwork. Thus, Robert can-not download Resident Evil from P3. This denial of accessleads Robert to send a request to another peer P1 whichhas the same resource, the Resident Evil movie. P1 contractspecifies that there is T compatibility type with a peer per-taining to peerNetwork. So, to establish a VPO securityrules between P1 and Robert, we only have to establishrole compatibility. To do so, Robert provides a RDF fileof his security policy, which is easily exchangeable becauseit rests on XML. Robert can hide information which arenot related to roles. Then, P1 derives from its local securitypolicy and this RDF file the VPO Robert2P1. The secu-rity policy of VPO Robert2P1 is created in a new RDF fileand identified by the URI @Robert2P1. Thus, P1 can sendthe VPO file to a server; and Robert can consult the VPOat the address @Robert2P1. In our example P1 decides torestrict the access to Resident Evil according to legal con-dition related to the grantee country. So, the lawfull con-text is then defined this restriction. In France, 12 years oldsand youngers are prohibited from watching Resident Evilmovie. Thus, the management sphere, who is in charge ofmanaging the VPO Robert2P1, requires Robert to provehis age (for instance, via a credential). If this phase suc-ceeds, then Robert can download Resident Evil from P1.Henceforth, as the VPO Robert2P1 between Robert andP1 is already established, the interoperabiliy policy deriva-tion is no longer necessary when Robert requires an accessto another movie.

8 Conclusion

To facilitate collaboration between organizations, con-flict between security policy scopes should be detected andsolved. Furthermore, interoperability requires reactivity,flexibility and continuity of service. In this paper, we sug-gest a new approach to facilitate secure interoperation be-tween organizations. This approach is defined as an exten-sion of the O2O approach. In O2O, each organization ad-ministrates its resources so that it is always possible to knowwhich security policy is applied to the resource. The objec-tive of the suggested extension is to automatically deriveinteroperability security rules. This derivation depends onthe following taxonomy of interoperability relations: totalcompatibility relation, partial compatibility relation, sym-metric compatibility relation and no compatibility relation.These compatibilities can be refined with exception rules.

The main innovation of our approach is to provide a solu-tion to anticipate over security requirements before the in-teroperability establishment. This anticipation is possibledue to the abstraction of the whole security policy and itsindependency of the implementation. To interoperate se-curely and anticipate on this interoperation, we use the no-tion of contract. A contract which is defined by the grantor

143143143143

organization, specifies for each grantee organization, whichgrantor’s resources or part of these resources are accessi-ble. Moreover, as the interoperability security policies arederived from the grantor security policy, according to thenature of the contract, adaptation constraints of this securitypolicy may be also specified. In this way, the grantor organi-zation controls the accesses to its resources during interop-erability sessions without weakening the security policies ofthe grantee organizations. An automatic derivation processof the interoperability policies based on these contracts hasbeen defined. Since our approach to manage interoperabil-ity is defined as an extension of the OrBAC model, deriva-tion of interoperability policies has actually similar com-plexity as derivation in the OrBAC model, namely polyno-mial. We are currently implementing this derivation processas an extension of MotOrBAC [2], a toolkit that supports thespecification of security policies using the OrBAC model.

Acknowledgment: Celine Coma’s PhD thesis was sup-ported by the Institute TELECOM.

References

[1] Trustbuilder: http://isrl.cs.byu.edu/software.htm.

[2] Fabien Autrel, Frederic Cuppens, Nora Cuppens-Boulahia, and Celine Coma. MotOrBAC 2: a secu-rity policy tool. In Third joint conference on securityin network architectures and security of informationsystems (SAR-SSI’08), Loctudy, France, october 13-172008.

[3] Elisa Bertino, Elena Ferrari, and Anna Cinzia Squic-ciarini. Trust-X: A Peer-to-Peer Framework forTrust Establishment. IEEE Trans. Knowl. Data Eng.,16(7):827–842, 2004.

[4] S. Cantor, J. Hodges, J. Kemp, and P. Thompson.Liberty ID-FF Architecture Overview. Thomas Wa-son edition, https://www.projectliberty.org/resources/specifications.php#box1.

[5] Celine Coma, Nora Cuppens-Boulahia, Frederic Cup-pens, and Ana Rosa Cavalli. Context Ontology for Se-cure Interoperability. In 3rd International Conferenceon Availability, Reliability and Security (ARES’08),March 4-7 2008.

[6] Frederic Cuppens, Nora Cuppens-Boulahia, andCeline Coma. O2O: Virtual Private Organizations toManage Security Policy Interoperability. In SecondInternational Conference on Information Systems Se-curity (ICISS’06), December 2006.

[7] Frederic Cuppens, Nora Cuppens-Boulahia, andCeline Coma. Multi-granular licences to decentralize

security administration. In SSS/WRAS 2007: First in-ternational Workshop on Reliability, Availability andSecurity, November 14-16 2007.

[8] Frederic Cuppens, Nora Cuppens-Boulahia, andMeriam Ben Ghorbel. High level conflict manage-ment strategies in advanced access control models.Electronic Notes in Theoretical Computer Science(ENTCS), 186(1571-0661):3–26, Jully 2007.

[9] Hong-Hai Do and Erhard Rahm. COMA - A Sys-tem for Flexible Combination of Schema MatchingApproaches. In 28th Conference on Very LargeDatabases (VLDB’02), August 2002.

[10] AnHai Doan, Jayant Madhavan, Robin Dhamankar,Pedro Domingos, and Alon Halevy. Learning to matchontologies on the Semantic Web. The VLDB Journal,12(4):303–319, 2003.

[11] OrBAC et al. The OrBAC Model Web Site.http://www.orbac.org, 2006.

[12] Jiangtao Li, Ninghui Li, and William H. Winsbor-ough. Automated trust negotiation using crypto-graphic credentials. In 12th ACM Conference on Com-puter and Communications Security, CCS 2005, pages46–57, Alexandria, VA, USA, November 7-11 2005.

[13] Ryusuke Masuoka, Mohinder Chopra, Zhexuan Song,Yannis K Labrou, Lalana Kagal, and Tim Finin.Policy-based Access Control for Task Computing Us-ing Rei . In Policy Management for the Web Workshop,WWW 2005, pages 37–43, May 2005.

[14] Deborah L. Mcguinness and Frank van Harme-len. Owl web ontology language overview. Inhttp://www.w3.org/TR/2004/REC-owl-features-20040210/, February 2004.

[15] Rolf Oppliger. Microsoft .net passport: A securityanalysis. Computer, 36(7):29–35, 2003.

[16] Laura Pearlman, Von Welch, Ian Foster, Carl Kessel-man, and Steven Tuecke. A community Authoriza-tion Service for Group Collaboration. In 3rd inter-national workshop on Policies for Distributed Sys-tems and Networks (POLICY’02), Monterey, Califor-nia, U.S.A, June 5-7 2002.

[17] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein,and Charles E. Youman. Role-Based Access ControlModels. Computer, 29(2):38–47, 1996.

[18] Andrzej Uszok, Jeffrey M. Bradshaw, Matthew John-son, Renia Jeffers, Austin Tate, Jeff Dalton, and StuartAitken. Kaos policy management for semantic webservices. IEEE Intelligent Systems, 19(4), 2004.

144144144144