Navid Pustchi

Ravi Sandhu
email: ravi.sandhu@utsa.edu

Role-Centric Circle-of-Trust in Multi-Tenant Cloud IaaS

Keywords: Circle-of-Trust, Federation, Attribute-Based Access Control, Collaboration, Multi-Tenant, Authorization, Security

Currently, collaboration is a major challenge in adopting cloud Infrastructure-as-a-Service (IaaS). Enterprise work-flow intrinsically mandates collaboration across its tenant boundaries as well as with associated organizations' tenants in the cloud. In this paper, we investigate a Circle-of-Trust approach where tenants establish trust within a circle of tenants for the purpose of collaboration. We present a novel extension of role-centric access control models to provide collaboration in the context of homogeneous and heterogeneous circles. In a homogeneous circle, our approach allows tenants to equally assert cross-tenant user assignments to enable access to shared resources. In a circle with nonuniform tenants, attributes are added to distinguish user-assignments where tenants are differentiated by type in the heterogeneous circle. Particularly, tenant-trust relation is established within a group of tenants authorizing user-role assignments across tenants.

Introduction

Cloud IaaS is firmly accepted by enterprises for its cost benefits, reliability, and dynamicity at scale [START_REF] Mell | The NIST definition of cloud computing[END_REF]. Its benefits are well documented and well practiced in the industry, but still organizations resist to fully migrate to cloud IaaS which arises from security, performance, and vendor lock-in concerns. Enabling collaboration mitigates such concerns regarding vendor lock-in and different security levels required, and improves performance by utilizing distinct cloud providers.

In multi-tenant platforms which utilize shared physical infrastructure, users' data are isolated into tenants to protect privacy and integrity. A tenant could be an organization, a department of an organization, or an individual cloud consumer, which is represented by an account in AWS [1] or a domain in Open-Stack [START_REF]OpenStack[END_REF]. Furthermore, current cloud service providers offer federation APIs to enable collaboration between tenants such as AWS and OpenStack platforms. Besides federation between two tenants, collaboration can also be established between a set of organizations where tenants adhere to a common set of policies, trust relations and collaboration interfaces within a circle. We denote this collaboration model as a Circle-of-Trust. Scenarios such as a large enterprise with multiple tenants collaborating in a public cloud, an organization with tenants across public and private clouds, or tenants from multiple organizations performing collaborative tasks are motivating use cases for Circle-of-Trust.

In this paper we present novel role-based and role-centric attribute-based access control models to enable federation in a multi-tenant cloud IaaS Circle-of-Trust. Our scope of contribution is homogeneous and heterogeneous multi-tenant circles in cloud IaaS. To better clarify the concept, consider the example in Figure 1 where ACME, a multinational technology corporation, aims to implement its enterprise requirements with cloud services. ACME migrates its IT infrastructure to a public cloud service provider where each tenant represents a department. ACME utilizes multiple tenants to satisfy distinct security levels required for each department. For example, Finance Dept. resources should not co-locate in the same tenant with Research & Development Dept., as Finance Dept. retains sensitive data. Furthermore, ACME organizational structure demands collaboration between its departments which is thereby required in its cloud adoption. To this end, ACME establishes a Circle-of-Trust among its tenants in the cloud and starts adding its tenants to the circle. For instance a new tenant created as Sales tenant in ACME, requests to join the circle. Adding additional tenants requires all ACME circle members to agree on trusting the new Sales tenant. When Sales tenant joins the circle, it trusts members assertions and its assertions are likewise trusted by other ACME circle members. In particular, Circle-of-Trust offers an association of ACME principals to collaborate in the circle.

Role-based access control (RBAC) [START_REF] Ferraiolo | Proposed NIST standard for role-based access control[END_REF][START_REF] Sandhu | Role-based access control models[END_REF] and its variations has been successfully applied to cloud IaaS providing collaboration within single-cloud [START_REF] Tang | Cross-tenant trust models in cloud computing[END_REF][START_REF] Tang | Multi-tenancy authorization models for collaborative cloud services[END_REF] and multi-cloud systems [START_REF] Pustchi | Authorization federation in IaaS multi cloud[END_REF]. In RBAC access permissions are assigned to roles and roles are assigned to users. Roles are central to RBAC for formulating policy and its commercial success, where it abstracts permissions into roles and role relations. With its dominance for the past two decades, RBAC limitations have been recognized leading to a push towards using attributes [START_REF] Hu | Guide to attribute based access control (ABAC) definition and considerations[END_REF][START_REF] Hu | Attribute-based access control[END_REF][START_REF] Sandhu | The authorization leap from rights to attributes: maturation or chaos?[END_REF] with roles [START_REF] Kuhn | Adding attributes to role-based access control[END_REF]. One method, is to add attributes to roles as role-centric attributes which takes advantage of roles' simplicity and attributes flexibility [START_REF] Jin | RABAC: role-centric attribute-based access control[END_REF]. Attributes are defined as name:value pairs representing entities' properties. We anticipate cloud service providers will incorporate ABAC features to their current RBAC models such as role-centric to adopt convenience of RBAC with flexibility of ABAC models.

Our contribution in this paper is to design multi-tenant role-centric models with cross-tenant user-assignments. To our knowledge this is the first work considering role-centric models in Circle-of-Trust context.

The remainder of this paper is organized as follows. Section 2 overviews trust properties applicable in Circle-of-Trust and corresponding trust relations between tenants. In section 3, our multi-tenant role-based access control in circle denoted MT-RBAC c is proposed and specified. Section 4 introduces our multitenant role-centric attribute-based model in circle denoted MT-RABAC c . Related work and conclusion is presented in sections 5 and 6 respectively.

Concept of Trust in Circle

In a Circle-of-Trust, trust relationships are defined between all circle entities. We use terms entities and principals interchangeably. Principals make assertions in the circle, assigning users to roles.

Trust Properties in Circle

Trust in the circle has the following properties, entity coupling, initiation, direction, and transitivity. Figure 2 gives a logical hierarchy of these trust properties discussed below. Vertical placement of characteristics is selected to better illustrate trust relations in our scope of contribution.

Entity Coupling (Homogeneous vs. Heterogeneous).

In a circle-of trust, type of entities engaging in interactions determines homogeneity or heterogeneity of the circle, shaping its authorized interactions between tenants. Moreover, with each circle type a set of trust properties are applicable. By homogeneous circle we denote the case where entities are uniform. For instance a circle of universities forms a homogeneous circle. In a homogeneous circle, collaborating principals are equally authorized to make cross-tenant authorization assertions. A heterogeneous circle, is an association of non-uniform entities where each type of entity is authorized specifically to make certain assertions. For instance, a circle consisting of universities, insurance companies, and banks establishes a heterogeneous circle. In this scenario, universities can assign users to discounted insurance plans in insurance companies while insurance companies cannot assign their users to resources in the universities. In this paper, we use type and domain interchangeably denoting the type of entities in a heterogeneous circle. Initiation (Multilateral vs. Unilateral). If trust initiation to join a circle is required to be confirmed by all circle members, trust is considered multilateral. In special situations when joining members are not authorized to make assertions (in heterogeneous circles) trust initiation is not required to be confirmed by all circle members denoted as unilateral trust. For instance a domain of insurance companies joins a heterogeneous, unilateral circle of institutions. Insurance entities in the circle are not authorized to make assertions whilst institution entities are authorized to assert their users to discounted plans available to universities. Direction (Bidirectional vs. Unidirectional). In a circle, direction of trust determines whether both participating circle members have equal authorizations or only one side is authorized to make assertions. If partners are authorized equally to make assertions, trust relation is bidirectional, otherwise it is unidirectional trust. Homogeneous circles' relations are bidirectional while heterogeneous circles support both trust directions. Unilateral heterogeneous circles such as given example above are only unidirectional in trust relations. Circle of universities is an example of bidirectional trust in a homogeneous circle. Sharing files in Dropbox is an example of a unidirectional trust where a user can share files with a group of users unidirectionally. Transitivity (Transitive vs. Non-transitive). In a trust relation when principal "A trusts B" and "B trusts C" result in implication that "A trusts C", trust relation is denoted as transitive. In a homogeneous circle, bidirectional trusts are essentially transitive where all members trust and likewise trusted by other circle members. In heterogeneous unidirectional circles, trust relations cannot be transitive. For example, in the heterogeneous unidirectional circle of institutions, banks, and insurance companies, an institution can assign students to bank specific account types in banks whilst banks can assign employees to health insurances in insurance companies. Considering heterogeneous domains in the circle, a university trusting a bank and a bank trusting an insurance entity does not necessarily imply that the university can assign students to insurance resources.

In this paper, we consider multilateral, bidirectional, and transitive trust relationships for homogeneous circles. Trust relations between tenants in heterogeneous circles are considered multilateral, unidirectional, and non-transitive. In the following we identify how trust relations authorize cross-tenant assignments in a Circle-of-Trust federation model.

Tenant-Trust in Circle

In a circle, trust is defined between tenants as tenant-trust relationship. In a unidirectional trust relationship, common in peer-to-peer, trust is initiated and established between two tenants denoted as trustor and trustee. In a trust relation, trustor tenant is willing to trust another tenant denoted as trustee tenant. In our scope, trust is initiated multilaterally between principals in a circle. In the context of circle, trustor and trustee are not distinguished in trust relations between tenants. We identify tenants involve in a cross-tenant assignment as user-owner and resource-owner tenants. User-owner tenant owns the users in the cross-tenant assignment and resource-owner tenant owns the roles to which users are assigned. Central to tenant-trust defined in this paper, is authorizing userowner or resource-owner tenants to assert cross-tenant user-role assignments.

We use "▹" to represent tenant-trust where T A ▹ T B signifies that tenant A trusts tenant B. In this relation, T A is user-owner tenant and T B is resourceowner tenant. Regardless of circle entity coupling, we define two types of tenant trust relations denoted as type-ϵ and type-ζ. Each tenant-trust relation type is applied to all tenants in the circle. In type-ϵ circle, user-owner tenants are authorized to assign users to roles in the circle. The following defines type-ϵ tenant-trust illustrated in Figure 3a.

Definition 1. If T A ▹ ϵ T B , then tenant T A is authorized to assign its users to T B 's roles. Tenant T A controls user assignments.

In type-ζ circle, resource-owner tenants are authorized to assign users in the circle to their roles. Type-ζ is defined as follows and is depicted in Figure 3b.

Definition 2. If T A ▹ ζ T B , then tenant T B is authorized to assign T A 's users to its roles. Tenant T B controls user assignments.

In homogeneous circles, all peers trust each other and trust is transitive, therefore T A ▹ T B if and only if T B ▹ T A . However, in heterogeneous circles trust relations are unidirectional and non-transitive as a result T A ▹ T B may not imply T B ▹T A or vise versa. Each tenant-trust type caters to a different security concern and objective in the Circle-of-Trust collaboration. Type-ϵ enable tenants in the circle to assign their users to roles of other tenants in the circle. The advantage is its simplicity to administer and implement as long as tenants' resources shared are not sensitive within the circle and tenants are willing to delegate user-role assignments to trusted tenants in the circle. For instance, an academic Circleof-Trust is a motivation of this type of circle where academic tenants establish a Circle-of-Trust to share computing resources. Any academic tenant can assign its users to resources across tenants in the circle.

Type-ζ on the other hand, follows a different purpose to protect shared resources where user-role assignments are administered by resource-owner tenants. Tenants do not want to delegate trusted tenants permission to make assertions to their shared resources. A circle of financial institutions is a motivating example of type-ζ tenant-trust. Financial institutes do not want to expose their resources for collaboration in the circle since their resources are highly sensitive even with respect to trusted tenants in the circle. In this scenario, a resource-owner tenant administrator assigns users in the circle to its roles, authorizing access to its shared resources.

Homogeneous Role-Based Circle-of-Trust

This section introduces a multi-tenant role-based access control model to enable federation in a homogeneous Circle-of-Trust which we refer to as MT-RBAC c . In a homogeneous circle, tenants are equally authorized to make assertions. Collaboration in MT-RBAC c is issued through cross-tenant user-role assignments with respect to circle types ϵ and ζ. MT-RBAC c model component sets and relations are depicted in Figure 4. We use a circle of institutions called Cyber Security Research (CSR) shown in Figure 5 as a running example to exemplify the concepts throughout this section. The formal definition of MT-RBAC c is given in Table 1. We discuss MT-RBAC c in parts through the following subsections, in context of these figures and table.

MT-RBAC c Basic Sets and Functions

The basic sets of MT-RBAC c are as follows: tenants (T ), users (U ), private roles (R prv ), public roles (R pub ), roles (R), operations (OP S), objects (OBS), and permissions (P RM S). Many of these are familiar from the traditional RBAC models [START_REF] Ferraiolo | Proposed NIST standard for role-based access control[END_REF][START_REF] Sandhu | Role-based access control models[END_REF] and will not be further discussed here. The new sets in MT-RBAC c are tenants (T ) and private and public roles (R prv and R pub respectively). A tenant is considered as a virtual container with tenant-specific environment for cloud services leased to cloud consumers. Practically, a tenant hosts a project, a department, or an organization. Each tenant is represented as t ∈ T where T is the global set of tenants in the cloud. In Figure 5, each tenant represents an institution, UTSA, UTA, and UTD respectively. Each user, role, and object is identified with a single owner tenant, shown within the dashed tenant boundary in Figure 5. UTSA and UTD have similar Researcher roles, however in the cloud they are distinguished as Researcher#UTSA and Researcher#UTA. Similarly for objects and users.

Within each tenant the roles are partitioned into disjoint sets of public roles and private roles, R pub and R prv respectively, as depicted in Figure 4 and expressed in Table 1 by the owner functions. In Figure 5 private roles are shown as blue circles named in italics while public roles are shown as red circles named in regular script, e.g., the UTSA tenant has private roles Professor, Researcher and Research Staff and a public role Scholar.

A central principle of MT-RBAC c is that permission to role assignment can only occur within a tenant boundary, and only to private roles. This is formalized in the definition of the permission assignment (P A) relation in Table 1. It is our first departure from traditional RBAC which in general allows any permission to be assigned to any role.

MT-RBAC c Tenant-Trust and User-Role Assignment

A Circle-of-Trust (CoT ) is a subset of tenants T who mutually trust each other within the scope of MT-RBAC c . In Figure 5, UTSA, UTA, and UTD form a homogeneous CoT of institutes. In general, multiple and possibly overlapping CoT s can be established among different subsets of tenants. For our purpose in this paper it suffices to focus on a single CoT . Tenant-trust between two members of a circle is indicated by the ▹ symbol, which is a reflexive, transitive and symmetric relation.

MT-RBAC c distinguishes two kinds of trust, named type-ϵ and type-ζ and distinguished by a subscript applied to the symbols CoT and ▹. In type-ϵ trust each tenant in the CoT ϵ can assign users from another tenant in the circle to its own public roles. In type-ζ trust each tenant in the CoT ζ can assign it own users to public roles belonging to another tenant in the circle. In Figure 5, if CSR is a type-ϵ circle then the tenant administrator of UTA can assign its users, e.g., David and May, to roles in UTSA and UTD. If CSR is a type-ζ circle then the tenant administrator of UTA can assign users from UTSA, e.g., Alice and John, as well as users from UTD to roles in UTA. In both types of circles such cross-tenant user-role assignments is limited to public roles. These concepts are formalized in Table 1. These restrictions on user-role assignment constitute a second major departure from traditional RBAC.

Limited Role Hierarchy

A third significant departure from traditional RBAC is to limit the role hierarchy with respect to public and private roles. We use the symbol ≽ to represent the role hierarchy where r 1 ≽ r 2 means that the permissions assigned to role r 2 are also available to users assigned to role r 1 . MT-RBAC c imposes the following requirements on the role hierarchy.

-Private roles can inherit private roles only if both are owned by the same tenant, e.g., Senior Researcher ≽ Researcher in the UTD tenant in Figure 5. -Private roles cannot inherit public roles. The Researcher role in UTD tenant cannot be senior to the Scholar role in UTSA. -Public roles can inherit private roles only if both owned by the same tenant.

In the UTD tenant, Security Scientist role inherits the Researcher role.

Table 1: MT-RBAC c Component Sets and Functions.

Basic Sets and Functions • T, U, R, OP S, and OBS (tenants, users, roles, operations, and objects, respectively). t ∈ T , u ∈ U , r ∈ R, op ∈ OP S, and ob ∈ OBS.

• R pub is a set of public roles and Rprv is a set of private roles where R pub ⊆ R, Rprv ⊆ R, R pub ∩ Rprv = ∅, and R pub ∪ Rprv = R.

• P RM S = OP S × OBS, the set of permissions.

• U O ⊆ U × T , a many-to-one user-to-tenant owner relation. Also written as owner user : (u : U ) → T , the mapping of user u into its owner tenant. Formally: owner user(u) = t where (u, t) ∈ U O.

• RO ⊆ R × T , a many-to-one role-to-tenant owner relation. Also written as owner role : (r : R) → T , the mapping of role r into its owner tenant. Formally: owner role(r) = t where (r, t) ∈ RO.

• OO ⊆ OBS × T , a many-to-one object-to-tenant owner relation. Also written as owner object : (ob : OBS) → T , the mapping of object ob into its owner tenant. Formally: owner object(ob) = t where (ob, t) ∈ OO.

• P A ⊆ P RM S × R, a many-to-many mapping permission-to-role assignment relation requiring that ((op, ob), r) ∈ P A ⇒ (owner object(ob) = owner role(r) ∧ r ∈ Rprv). Also written as assigned permissions : (r : R) → 2 P RM S , the mapping of role r into a set of permissions. Formally: assigned permissions(r) = {p ∈ P RM S | (p, r) ∈ P A}.

Tenant-Trust

• CoT ⊆ T , is a subset of T called Circle-of-Trust. For every two tenants that are member of CoT (t1, t2 ∈ CoT ) trust relationship is written as t1 ▹ t2, which is symmetric so t1 ▹ t2 iff t2 ▹ t1, reflexive so t1 ▹ t1, and transitive.

• HomogeneousCoTϵ, for all tenants t1 where t1 ▹ϵ t2, tenant t1 is authorized to assign its users to public roles in t2. Tenant t1 controls t1's users to t2's roles assignments.

• HomogeneousCoT ζ , for all tenants t1 where t1 ▹ ζ t2, tenant t2 is authorized to assign users from t1 to its public roles. Tenant t2 controls t1's users to t2's roles assignments.

User Role Assignment

• U A ⊆ U × R, a many-to-many mapping user-to-role assignment relation requiring that (u, r) ∈ U A ⇒ (owner user(u) = owner role(r) ∧ r ∈ Rprv) ∨ ((owner user(u) ▹ϵ owner role(r) ∨ owner role(r) ▹ ζ owner user(u)) ∧ r ∈ R pub ). Also written as assigned user roles : (u : U ) → 2 R , the mapping of user u into a set of roles. Formally: assigned user roles(u) = {r ∈ R | (u, r) ∈ U A}.

Limited Role Hierarchy

• RH ⊆ R × R, is a partial order on R called hierarchy relation, written as ≽, requiring that (r1, r2) ∈ RH ⇒ ((owner role(r1) = owner role(r2)) ∧ ¬(r1 ∈ Rprv ∧ r2 ∈ R pub )) ∨ ((owner role(r1) ▹ϵ owner role(r2) ∨ owner role(r2) ▹ ζ owner role(r1)) ∧ (r1, r2 ∈ R pub )).

Authorized User Permissions Derived Function

• authorized user permissions : (u : U ) → 2 P RM S , the mapping of user u into a set of permissions. Formally: authorized user permissions(u) = ∪ r∈assigned user roles(u) ∪ r ′ ≼r assigned permissions(r ′ ).

-Public roles can inherit public roles from trusted tenants in the circle. In UTD tenant, Senior Scientist ≽ Security Scientist where both are UTD's public roles. It is also possible for a public role of one tenant to be senior to a public role in another tenant. We include this possibility for generality, although role to role assignment is outside the scope of MT-RBAC c .

MT-RBAC c Trust Properties

In terms of the circle trust properties of Section 2.1 MT-RBAC c is homogeneous in entity coupling since all tenants in the circle are treated equivalently. In term of initiation in joining or leaving a circle of trust, MT-RBAC c does not explicitly formalize this aspect. As such MT-RBAC c is neutral on this issue. Different models of initiation such a multilateral or unilateral are compatible with MT-RBAC c . Regarding direction and transitivity, a circle in MT-RBAC c is explicitly defined to be bidirectional and transitive.

Heterogeneous Role-and-Attribute Based Circle-of-Trust

This section, introduces a multi-tenant role-centric attribute-based access control model (MT-RABAC c ) enabling federation in a heterogeneous Circle-of-Trust. Our model is motivated by a previously defined role-centric model [START_REF] Jin | RABAC: role-centric attribute-based access control[END_REF] for combining roles and attributes. In a heterogeneous circle, entities are from non-uniform types. In MT-RABAC c , tenants are not equally authorized and cross-tenant user-role assignments are limited with respect to tenant's domain type attribute. MT-RABAC c adds attributes to enforce cross-tenant user-role assignment separation. Attributes are used to denote tenant types where tenants are only authorized to assert cross-tenant user assignments on certains type of tenants. Figure 6 depicts elements in MT-RABAC c , where tenant attributes (T AT T ), user attributes (U AT T ), and object attributes (OAT T ) are added to the tenant, user, and object components of Figure 4 respectively. We use a heterogeneous circle of institutions (UTA and UTSA) and a bank (BoA) in Figure 7 as a running example to exemplify the concepts throughout this section. The extensions and modifications to the MT-RBAC c model to obtain MT-RABAC c are formally given in Table 2. Similar to the description of MT-RBAC c in the previous section, we will describe MT-RABAC c systematically in the following subsections, in context of the afore-mentioned figures and table.

MT-RABAC c User and Object Attributes and Meta-Attributes

An attribute is considered as a function which takes a tenant, user or object as input and return a value from the attribute's range. For example, an atomicvalued user attribute function such as employeeT ype returns employee status of a user john where employeeT ype ∈ U AT T , john ∈ U and employeeT ype(john) = f ull time. Range or scope of an attribute is a finite set of atomic values specifying the valid range of attribute functions. Attribute functions either return a single value or set of values, which are respectively called atomic-valued and set-valued attribute types. In MT-RABAC c , users and objects are respectively associated with attributes in the sets U AT T and OAT T . Each user attribute uatt ∈ U AT T is a partial function since not every attribute is defined for every user. Similarly, each object attribute oatt ∈ OAT T is a partial function.

Each user and object attribute is owned by a single tenant. This is realized by means of meta-attributes uattOwner and oattOwner. Users and objects can only be assigned attribute values for attributes owned by the same tenant as the user or object. User and object attributes do not impact user-role assignment and are included in the model for generality and uniformity.

MT-RABAC c Tenant Attributes

Tenant attributes are fundamental to MT-RABAC c to enforce constraints on cross-tenant user-role assignments. Each tenant administrator can only assign values to its set of tenant attributes. In a heterogeneous circle, tenants are from different types which needs to be recognized in cross-tenant user-role assignments. To that end, we define a domain as a set of tenants grouped together with respect to their type in the system. Each domain is a subset of T defined in Table 2. For instance in Figure 7, circle includes two types of tenants, Institute and Bank domains. Particularly, a tenant is related to a domain with an atomic-valued required attribute function, tenantDomain. It is defined as an atomic attribute to signify that each tenant only belongs to one domain. In Figure 7, UTSA and UTA have Institute and BoA has Bank tenantDomain attribute values. Moreover, to separate user-role assignments in MT-RABAC c , trustedDomains is defined as a required set-valued tenant attribute. In MT-RABAC c , each tenant administrator specifies the group of domains it trusts with their assertions, including its own domain. For instance in Figure 7, UTSA trusts assertions from Institute and Bank domain while UTA only trusts Bank domain assertions meaning UTA does not trust assertions from its own domain. In the heterogeneous circle in Figure 7, BoA does not allow any assertions from tenants in the circle.

MT-RABAC c Tenant-Trust

In MT-RABAC c , tenant-trust is limited with trustedDomains attributes. In type-ϵ circle, user-owner tenant can assign its users to roles from tenants which it is a member of their trustedDomains attribute set. In type-ζ, user assignment is modified to satisfy the condition where role-owner tenant can assign users from tenants in the circle, if it is a member of their trustedDomains attribute set. Type ϵ and ζ is defined in Table 2. In Figure 7, if circle is a type-ϵ, then the tenant administrator of UTA can assign its users, e.g., David and May, to roles in UTSA since UTSA trusts assertions from its domain. If circle is a type-ζ, then the tenant administrator of BoA can assign users from UTSA, e.g., Alice

Basic Sets and Functions

• T AT T , U AT T , and OAT T represent finite set of tenant, user, and object attribute functions respectively.

• For each att in T AT T ∪ U AT T ∪ OAT T , Scope(att) represents the attribute's scope, a finite set of atomic values.

• attT ype : T AT T ∪ U AT T ∪ OAT T → {set, atomic}, specifies attributes as set or atomic valued.

Meta Attributes of User and Object Attributes

• M AT T = {uattOwner, oattOwner}, required meta-attribute functions. uattOwner : (uatt : U AT T ) → T , required atomic user meta-attribute function, mapping user attribute uatt to attribute owner tenant t. oattOwner : (oatt : OAT T ) → T , required atomic object meta-attribute function, mapping object attribute oatt to attribute owner tenant t.

User Attribute

Tenant Trust

• HeterogeneousCoTϵ, for all tenants t1 where t1 ▹ϵ t2, if tenantDomain(t1) ∈ trustedDomain(t2), then tenant t1 is authorized to assign its users to public roles in t2. Tenant t1 controls t1's users to t2's roles assignments.

• HeterogeneousCoT ζ , for all tenants t1 where t1 ▹ ζ t2, if tenantDomain(t2) ∈ trustedDomain(t1), then tenant t2 is authorized to assign users from t1 to its public roles. Tenant t2 controls t1's users to t2's roles assignments. and John, as well as users from UTA to roles in BoA since both UTSA an UTA trust assertions from Bank domain tenants.

User Role Assignment

• U A ⊆ U × R,
In this context, user-assignment is modified with respect to trustedDomains attributes. A user is assigned to a role only if (owner user(u) = owner role(r) ∧ r ∈ R) ∨ (owner user(u) ▹ ϵ owner role(r) ∧ r ∈ R pub ∧ tenantDomain(owner user(u)) ∈ trustedDomains(owner role(r)))∨ (owner user(u) ▹ ζ owner role(r) ∧ r ∈ R pub ∧ tenantDomain(owner role(r)) ∈ trustedDomains(owner user(u))) In a Circle-of-Trust we allow only one trust type in the circle. We don't allow both type ϵ and ζ at once in a circle due to assignment conflict. Permissionassignment remains unchanged where a permission is assigned to a role only if (owner role(r) = owner object(o) ∧ r ∈ R prv ) Authorized user permisisons denotes the set of permissions available to a user with respect to tenant types in the circle which is not changed from Table 1.

MT-RABAC c Trust Properties

In terms of the circle trust properties of Section 2.1 MT-RABAC c is heterogeneous in entity coupling since tenants in the circle are distinguished by their domain, and thereby not treated equivalently. In term of initiation in joining or leaving a circle of trust, MT-RABAC c does not explicitly formalize this aspect. As such MT-RABAC c is neutral on this issue. Different models of initiation such a multilateral or unilateral are compatible with MT-RBAC c . Regarding direction and transitivity, a circle in MT-RBAC c is explicitly defined to be unidirectional and non-transitive.

Related Work

The Liberty Alliance Project [START_REF] Wason | Liberty id-ff architecture overview[END_REF] identified the conceptual framework and guidelines in a Circle-of-Trust as part of their federated identity vision. Considerable research on Circle-of-Trust has been devoted to identity federation such as [START_REF] Kylau | Trust requirements in identity federation topologies[END_REF] where trust requirements and patterns in a Circle-of-Trust identity federation are identified. In [START_REF] Boursas | Dynamic inter-organizational cooperation setup in circle-of-trust environments[END_REF], Circle-of-Trust collaboration trust considerations in identity federation for assessment of entities' trust outside the circle are considered. Our work is focussed on authorization federation in a collaboration group of entities considered as tenants.

Sharing resources among organizations has been investigated in multiple aspects. ROBAC [START_REF] Zhang | ROBAC: Scalable role and organization based access control models[END_REF] extended RBAC to consider authorization in multiple organizations, but collaboration within organizations is not considered. GB-RBAC [START_REF] Li | Towards secure dynamic collaborations with group-based RBAC model[END_REF] extends RBAC with groups to support collaboration. In GB-RBAC, administrator cannot manage users in the groups. In our model, each tenant administers its collaboration policy by controlling users or roles in user-role assignments across the tenants in the circle. In [START_REF] Warner | A credential-based approach for facilitating automatic resource sharing among ad-hoc dynamic coalitions[END_REF], a dynamic coalition-based access control (DCBAC) model is proposed that allows automatic access to resources of one coalition entity by users from another coalition entity. O2O [START_REF] Cuppens | O2O: Virtual private organizations to manage security policy interoperability[END_REF] defined an approach to deal with access control in interoperability context based on virtual private organizations (VPO) and role single-sign on (RSSO). Our contribution is differentiated based on the collaboration framework to enable collaboration between tenants. In O2O, each organization is responsible to define its security policy for roles whereas in our federation framework, each tenant defines its collaboration policy through public roles for a group of tenants in the circle.

Further in cloud IaaS, models such as CTTM [START_REF] Tang | Cross-tenant trust models in cloud computing[END_REF] extended RBAC to enable collaboration in multi-tenant cloud systems. In [START_REF] Pustchi | Authorization federation in IaaS multi cloud[END_REF], cross-tenant collaboration models discussed enabling federation in multi-cloud environments. In this paper, we focus on Circle-of-Trust federation compared to [START_REF] Tang | Cross-tenant trust models in cloud computing[END_REF] and [START_REF] Pustchi | Authorization federation in IaaS multi cloud[END_REF] where collaboration is enabled in a Peer-to-Peer federation. In ABAC collaboration in cloud, MT-ABAC [START_REF] Pustchi | MT-ABAC: A multi-tenant attribute-based access control model with tenant trust[END_REF] proposed collaboration between tenants by cross-tenant attribute assignment in cloud IaaS. Such attribute-based federation provides Peer-to-Peer collaboration, however our role-centric model provides federation in a circle.

Conclusion

This paper elaborated a fine-grained collaboration model in a Circle-of-Trust. We introduced the MT-RBAC c model in a homogeneous circle, in which collaboration is enabled through user to public role assignments. We identified, private and public roles with limited role hierarchy to control access on tenants' resources. Trust is defined on tenants with circle types ϵ and ζ authorizing user-owner and resource-owner tenants' assertions respectively. Moreover, tenant attributes in MT-RABAC c classifies tenants into domains in heterogeneous circles, where tenant-trust is defined conditionally with trustedDomain attributes. Using roles and attributes to enable cross-tenant user-role assignments is general and dynamic enough to address current issues while it is applicable to current platforms. For future work, we plan to extend this work with attribute-based models into further generalization in multi-cloud environments and implement proposed models in the current cloud platforms such as OpenStack.

Fig. 1 :

 1 Fig. 1: ACME Corporation Multi-Tenant Circle-of-Trust.

Fig. 2 :

 2 Fig. 2: Circle-of-Trust Characterization.

  (a) A trusts B in Circle Type-ϵ. (b) A trusts B in Circle Type-ζ.

Fig. 3 :

 3 Fig. 3: User-Role Assignment in Circle-of-Trust Tenant-Trust.

Fig. 4 :

 4 Fig. 4: Multi-Tenant RBAC Circle-of-Trust.

Fig. 5 :

 5 Fig. 5: Example of a Multi-Tenant RBAC c Homogeneous Circle-of-Trust.

Fig. 6 :

 6 Fig. 6: Multi-Tenant Role-Centric ABAC Circle-of-Trust.

Fig. 7 :

 7 Fig. 7: Example of a Multi-Tenant RABAC c Heterogeneous Circle-of-Trust.

•

  Each user attribute function uatt ∈ U AT T is defined as a partial function mapping elements in U to atomic or set values.∀uatt ∈ U AT T.uatt : U → { Scope(uatt) if attT ype(uatt) = atomic 2 Scope(uatt) if attT ype(uatt) = set uatt(u : U ) is defined only if uattOwner(uatt) = owner user(u).Object Attribute• Each object attribute function oatt ∈ OAT T is defined a partial function mapping elements in O to atomic or set values. ∀oatt ∈ OAT T.oatt : O → { Scope(oatt) if attT ype(oatt) = atomic 2 Scope(oatt) if attT ype(oatt) = set oatt(o : O) is defined only if oattOwner(oatt) = owner object(o). Tenant Attribute • Each tenant attribute function tatt ∈ T AT T maps elements in T to atomic or set values. ∀tatt ∈ T AT T.tatt : T → { Scope(tatt) if attT ype(tatt) = atomic 2 Scope(tatt) if attT ype(tatt) = set • D is a finite set of domains. • tenantDomain : (t : T ) → D, required tenant atomic attribute function mapping tenant t to tenant domain d where tenantDomain ∈ T AT T . • trustedDomains : (t : T ) → 2 D , required tenant set attribute function mapping tenant t to the powerset of trusted domains D where trustedDomains ∈ T AT T .

  a many-to-many mapping user-to-role assignment relation requiring that (u, r) ∈ U A ⇒ (owner user(u) = owner role(r) ∧ r ∈ RP rv ) ∨ (owner user(u) ▹ϵ owner role(r) ∧ r ∈ R pub ∧ tenantDomain(owner user(u)) ∈ trustedDomains(owner role(r))) ∨ (owner user(u) ▹ ζ owner role(r) ∧ r ∈ R pub ∧ tenantDomain(owner role(r)) ∈ trustedDomains(owner user(u))).

Table 2 :

 2 MT-RABAC c Component Sets and Functions.

Acknowledgement

This research is partially supported by NSF Grant CNS-1111925 and CNS-1423481.


Rauf Mahmudlu
email: r.m.o.mahmudlu@student.tue.nl

Jerry Den Hartog
email: j.d.hartog@tue.nl

Nicola Zannone
email: n.zannone@tue.nl

Data Governance & Transparency for Collaborative Systems

As social networks, shared editing platforms and other collaborative systems are becoming increasingly popular, the demands for proper protection of the data created and used within these systems grows. Yet, existing access control mechanisms are not suited for the challenges imposed by collaborative systems. Two main challenges should be addressed: collaborative specification of permissions, while ensuring an appropriate levels of control to the different parties involved, and enabling transparency in decision making in cases where the access requirements of these different parties are in conflict. In this paper we propose a data governance model for collaborative systems, which allows the integration of access requirements specified by different users based on their relation with a data object. We also study the practical feasibility of enabling transparency by comparing different deployment options for transparency in XACML.

Introduction

Collaborative systems such as social networking websites, document sharing/editing platforms and audio/video conferencing tools, are gaining increasing popularity over the years. These systems provide an environment wherein users can collaborate and share information. This information, however, can be sensitive and, thus, needs to be protected from unauthorized access and accidental loss or modification.

Access control is widely used to protect sensitive information. Access control mechanisms rely on policies defining which actions users are allowed to perform on data objects. However, existing authorization mechanisms are not able to deal with the security demands of collaborative environments [START_REF] Tolone | Access control in collaborative systems[END_REF]. In particular, we identify two main drawbacks that limit their application to collaborative systems: the lack of (i) a data governance model for shared data objects and (ii) transparency in decision making.

Most access control mechanisms assume that data objects are under the control of a single entity (e.g., the system or the owner). However, in collaborative systems several users can contribute to the creation, governance and management of data [START_REF] Damen | Privacy implications of privacy settings and tagging in facebook[END_REF][START_REF] Hu | Multiparty Access Control for Online Social Networks: Model and Mechanisms[END_REF]. For instance, data can be provided by one or more users, can be stored by some other user, and refer to yet other users where each of these users retains some level of authority on the data. In particular, each user can define its own authorization requirements for the protection of data. Therefore, we need a way to combine those requirements in order to define the policy ultimately regulating the access to data.

Several approaches for policy combination [START_REF] Jajodia | Flexible Support for Multiple Access Control Policies[END_REF][START_REF] Li | Access control policy combining: Theory meets practice[END_REF][START_REF] Matteucci | Prioritized execution of privacy policies[END_REF][START_REF]OASIS XACML Technical Committee: eXtensible Access Control Markup Language (XACML) Version 2[END_REF] and integration [START_REF] Mazzoleni | XACML Policy Integration Algorithms[END_REF] have been proposed. These approaches provide strategies to combine policies specified by different entities and automatically resolve policy conflicts at evaluation time based on predefined priorities between decisions or based on the policy structure. However, they consider every user 'equally' and they do not account for the relation of users with the data to be protected in order to determine how user policies should be combined.

Although the use of these strategies is necessary to guarantee the proper functioning of the system as a conclusive decision has to be made (either allowing or denying the access to the data), it results in a decision making process that is non-transparent to users. Every user expects its policies to be enforced by the system. This, however, is often not possible, for instance when users specify conflicting authorization requirements for the same resource. To resolve policy conflicts, policy combination strategies sacrifice some policies to reach a conclusive decision. Authorization mechanisms make decisions in a blackbox manner [START_REF] Ghai | Cue: A Framework for Generating Meaningful Feedback in XACML[END_REF] and, thus, users are often unaware whether their policies have actually been enforced. This lack of confidence may reduce the level of trust users have towards the system and thus users' willingness to engage in collaboration.

In a previous work [START_REF] Damen | CollAC: Collaborative access control[END_REF] we have introduced the notions of archetype and policy mismatch to address these issues. Archetypes are used to represent the relation of users with a given data object. Policy mismatches are used to identify the difference between the authorization requirements of single users and the final decision enforced by authorization mechanisms. We have also shown how the notion of policy mismatch can be used as a baseline for the realization of transparent authorization mechanisms which increases user awareness about access decision making.

This paper extends our previous work in two directions. First, we propose a data governance model for collaborative systems, which allows the integration of authorization requirements specified by different users based on their relation with a data object. In particular, the governance model provides a general framework to reason on the level of authority that users have over shared data and allows the use of existing policy combination and integration strategies to resolve policy conflicts. Moreover, we investigate the feasibility of transparency in existing authorization mechanisms. In particular, we have developed a transparency service that has been deployed in SAFAX [START_REF] Kaluvuri | SAFAX -An Extensible Authorization Service for Cloud Environments[END_REF], an XACMLbased framework offering authorization as a service. A main feature of SAFAX is that all the components of the XACML reference architecture are designed as loosely coupled services. We exploit the flexibility provided by this design to evaluate the impact of the transparency service with respect to different deployment models.

The remainder of the paper is organized as follows. The next section introduces preliminaries on XACML. Section 3 presents our approach to shared data control. Section 4 discusses the problem of decision mismatches, and Section 5 describes the design, implementation and deployment of the transparent service. Section 6 presents experimental results. Finally, Section 7 discusses related work, and Section 8 concludes the paper and provides directions for future work.

Preliminaries

This section provides preliminaries on XACML [START_REF]OASIS XACML Technical Committee: eXtensible Access Control Markup Language (XACML) Version 2[END_REF], the de facto standard for the specification and enforcement of access control policies. This work is based on XACML v2. However, it can be easily adapted to comply with XACML v3.

Policy Language

XACML provides an attribute-based language that allows the specification of composite policies by using three policy elements: policy sets, policies and rules. Policy sets comprise a list of policy sets and policies; policies comprise a list of rules. Rules specify an effect, i.e. whether an access request should be allowed (Permit) or denied (Deny). Each policy element has a (possibly empty) target which restricts the applicability of the policy element. The target is specified in terms of attributes characterizing the subject, resource, action and environment and denotes the access requests covered by the policy element. A rule may additionally have a condition, i.e. a predicate that must be satisfied for a rule to be applicable. Policy sets and policies can also be associated with obligations, i.e. mandatory requirements that have to be fulfilled.

The evaluation of an access request against a policy element results in an access decision. If the request matches both the target and condition of a rule, the rule is applicable to the request and yields the decision specified by its effect, either Permit or Deny. If the rule is not applicable, a NotApplicable decision is returned. If an error occurs during evaluation, an Indeterminate decision is returned. Each composite policy element (i.e., a policy set or a policy) specifies a combining algorithm that is used to combine the decisions of its comprising elements. XACML provides a number of combining algorithms: permit-overrides (pov), deny-overrides (dov), first-applicable (fa) and only-one-applicable (ooa). These algorithms evaluate composite policies based on the order of the policy elements and priorities between decisions. Hereafter, we use the following abstract notation to represent the policy evaluation process in XACML: P denotes the set of XACML policies, Q the set of access requests, and function p : Q → {Permit, Deny, NotApplicable, Indeterminate} denotes policy evaluation, i.e. p (q) is the decision according to a policy p ∈ P for a request q ∈ Q.

XACML Architecture

The XACML reference architecture is shown in Figure 1. Access requests are intercepted by the Policy Enforcement Point (PEP). Upon receiving an access request, the PEP forwards the request to the Context Handler (CH) which, after translating the request from the application's native format to XACML, sends it to the Policy Decision Point (PDP) for evaluation. The PDP fetches the policies from the Policy Administration Point (PAP). If additional attributes are required to evaluate the request, the PDP queries the CH for such attributes. The CH retrieves these attributes from the Policy Information Point (PIP) and sends them to the PDP. The PDP evaluates the request against the policies and returns a response specifying the access decision (and possibly a set of obligations to be fulfilled) to the CH. The CH sends the response to the PEP, which is responsible for the enforcement of the decision and the fulfillment of obligations.

Shared Data Control

In collaborative systems like social media and document sharing platforms, data objects can be under the control of multiple stakeholders. The level of authority that each stakeholder has on a shared data object depends on its relation with the object. In this section Fig. 1: XACML Architecture we discuss the problem of shared data control and propose an approach to regulate the access to data by taking into account both the authorization requirements of the stakeholders related to the data and their relationship with the shared data. We start by introducing a scenario in healthcare that is used as a running example throughout the paper.

Example 1. A University Medical Center (UMC) provides medical treatment for a variety of diseases. The UMC also has an advanced research program, and several researchers conduct clinical research studies within the UMC. Patient data are stored in a central database at the UMC. The UMC is responsible for guaranteeing the security of patient data and for determining the purposes and means of its processing. Different departments at the UMC can define policies to regulate the access to patient data. Here, we consider two such departments: the Security Department and the Data Center. The Data Center manages the UMC database and is mainly concerned that medical, research and administrative staff of the UMC have access to the data they need to perform their duties. On the other hand, the Security Department mainly focuses on the protection of patient data and on the compliance with regulations and laws that are in place. Our scenario focuses on Alice and Caroline, two monozygotic twins, who both rely on UMC's services for treatment. Caroline has also engaged in a clinical trial and shared her genetic information with the UMC for research purposes.

Privacy is a highly regulated subject, especially in healthcare. Most countries have regulations and laws in force, which impose stringent requirements on the collection and processing of personal data [START_REF] Guarda | Towards the development of privacy-aware systems[END_REF]. To explicitly model the access requirements defined by privacy regulations, we introduce a Regulatory Body as a stakeholder in our scenario. 1 This entity issues and revises regulations to protect the privacy of citizens. Privacy regulations like the EU Directive on data protection (Directive 1995/46/EC) require the creation of an independent authority to protect the fundamental rights of citizens. This authority, hereafter referred to as National Privacy Authority, has the task of overseeing the compliance of organizations with privacy regulations. Moreover, it can prohibit unlawful or unfair data processing operations. Next to the National Privacy Authority, we also consider an Ethical Medical Committee of the Ministry of Health. This entity defines requirements on the use of medical data, especially for research purposes.

Each aforementioned stakeholder can specify requirements to regulate the access and usage of data. These requirements are summarized in Table 1.

Stakeholder Access Requirements

Alice

Her treating doctors and nurses can access her medical information.

Any other access to her information is denied. Caroline Doctors and nurses can access her medical information.

Researchers can read her genetic information.

Any other access to her information is denied. UMC Data Center Doctors and nurses can access patient information.

Researchers can access patient information. UMC Security Department Medical staff can access patient data to provide medical treatment.

Technicians can access and modify patient data for maintenance purposes.

Regulatory Body

Data subjects can access their medical information. Personal data shall be collected and processed only if the data subject has given his explicit consent to their processing. Access is allowed without data subject's consent to comply with a legal obligation imposed upon the controller.

Access is allowed without data subject's consent to protect the data subject's vital interests. National Privacy Authority Unlawful and unfair data processing operations are forbidden. Ethical Medical Committee Researchers can only access anonymized patient information.

Table 1: Access Requirements

Data Governance Model

In collaborative systems, multiple stakeholders can contribute to the creation and management of data objects. Each stakeholder related to a data object should retain some authority on the object. However, not all these stakeholders might have the same level of authority. The degree of authority a user has depends on its role with respect to the data. Thus, the actual permissions on shared data should be defined by taking into account both stakeholders' access requirements and their relation with the data. In this section, we investigate a general framework to explicitly express the relations between stakeholders and data objects as well as to prioritize such relations.

To characterize the relation between stakeholders and shared data, we use the notion of archetype proposed in [START_REF] Damen | CollAC: Collaborative access control[END_REF]. The archetypes for a shared data object capture the roles that stakeholders can have with respect to the object. The role determines the extent of control over the object. In this work we introduce the notion of archetype hierarchy to reflect the level of authority that users have on shared resources. Definition 1. Let A be the set of archetypes for a shared data object o. An archetype hierarchy H has the form:

H = L | (L, pr, H) L = (σ, [a 1 , . . . , a n ]) pr = t | + | -
A level L consists of a set of archetypes a 1 , . . . , a n ∈ A, whose requirements are combined using an intra-level aggregator σ. An archetype hierarchy H is (recursively) built over levels by concatenating a level with a hierarchy according to a given priority pr that can be total (denoted by t), positive (denoted by +) or negative (denoted by -).

Intuitively, a level groups those archetypes that have the same level of authority on shared data. An intra-level aggregator specifies how the requirements of the stakeholders associated to the archetypes in a level should be evaluated. Our framework does not pose restrictions on the intra-level aggregator that can be used. In the next section we provide some examples of intra-level aggregators and discuss how they can be realized.

Example 2. Consider the genetic information provided by Caroline in the scenario of Example 1. We identify two main archetypes for this information: Data Controller and Data Subject. The Data Controller is the entity responsible for the security of the data and defines who can access a data element and how data can be processed. In our scenario, the UMC plays the role of Data Controller for Caroline's genetic information. In particular, the UMC Data Center and Security Department are two instances of the Data Controller. The Data Subject is the person to whom the information refers. In the scenario, Caroline is the Data Subject for her genetic information. In addition, given the twin relationship between Alice and Caroline, we also consider Alice as the Data Subject for the genetic information provided by Caroline. Next to these archetypes, we define an archetype for each of the other stakeholders in the scenario, namely Regulatory Body, National Privacy Authority and Ethical Medical Committee.

In an archetype hierarchy, levels are ordered according to the degree of authority that the archetypes forming a level have. We distinguish three types of priorities between levels: total, positive and negative. Total priority indicates that the access requirements associated to the higher level always override the ones associated to lower levels. However, in some cases only the positive access requirements (i.e., access requirements defining positive authorizations) associated to the higher level should take precedence; otherwise, the access requirements defined by stakeholders at the lower level should also be evaluated. This is achieved using the positive priority. Negative priority is the dual of positive priority where only negative requirements from the higher level take precedence.

Example 3. The archetypes for our running example, identified in Example 2, can be organized in a hierarchy. Fig. 2a presents a graphical representation of this hierarchy. Regulatory Body has the highest priority. The next level comprises the Data Subject, followed by a level formed by the National Privacy Authority and the Ethical Medical Committee. The lowest level is formed by the Data Controller. In order to comply with data protection regulations and to satisfy the intrinsic characteristics of the roles, the following priorities are defined between levels:

-The Regulatory Body has the right to override the decisions of the Data Subjects to permit access to patients' medical records, e.g. to protect their vital interests or comply with legal obligations [START_REF] Guarda | Towards the development of privacy-aware systems[END_REF]. Therefore, a positive priority is used between the first and second level. -Data Subjects have the right to determine who can (or cannot) access and process their information. However, even if they permit access to their information, the National Privacy Authority and the Ethical Medical Committee hold the right to deny it if the request is not in compliance with their requirements. Such a requirement is achieved through a negative priority between the Data Subject and the lower level. -The National Privacy Authority and Ethical Medical Committee can influence how the Data Controller processes personal data. In particular, they can deny an unlawful or unfair access, or permit the access for research purposes regardless of the Data Controller's requirements. A total priority between the levels can be used to achieve this requirement.

Data Governance Instantiation

Access control policy languages like XACML allow stakeholders to express their access requirements as policies and provide means to combine these policies in a single policy (hereafter referred to as the global policy), which is used to determine the actual permissions on shared data. In this section, we present how the global policy can be created from user policies taking into account the archetype hierarchy. We first introduce a grammar for the specification of the global policy. This grammar is inspired by XACML, thus making the encoding into XACML policies straightforward.

Definition 2. The global policy P H is constructed upon the following grammar: where p 1 , . . . , p n are user policies and ca represents a policy combining algorithm.

P H = P L | (fa
An archetype policy P a combines the policies of those users who are associated to an archetype a. To this end, every archetype is associated with a policy combining algorithm that determines how the policies defined by the stakeholders having such an archetype are combined. A level policy P L combines the policies associated to the archetypes in a level L. The combining algorithms used to construct archetype and level policies should reflect the security and privacy needs for the specific domain. In particular, the combining algorithm for level policies should reflect the constraints on the combination of archetypes in a level as given in the archetype hierarchy (Definition 1). Note that our policy language does not impose any restriction on the policy combining algorithms to be used to combine user policies and archetype policies. 2 For instance, archetype/level policies can make use of the standard XACML combining algorithms (see Section 2) or more advanced combining algorithms such as the consensus and majority combining algorithms defined in [START_REF] Li | Access control policy combining: Theory meets practice[END_REF]. The global policy is recursively built over level policies. This is necessary to account for the use of different priority between levels in the archetype hierarchy. Priorities are encoded in terms of combining algorithms. In particular, the total, positive and negative priorities are encoded using first-applicable (fa), permit-overrides (pov) and deny-overrides (dov), respectively.

Next we define how the global policy is constructed from the archetype hierarchy and user policies. Definition 3. Let A be the set of archetypes for an object o and U the set of users. Let UA ⊆ U × A be the user-archetype assignment, i.e. (u, a) ∈ UA iff user u has archetype a. Let P be the set of user policies and let p u denote the policy of user u. We denote by A2ca(a) the combining algorithm ca specified for archetype a. To combine user policies according to the archetype hierarchy, we first create archetype policies:

A2P(a) = (A2ca(a), [p u1 , . . . , p um ])
where u 1 , . . . , u m are the users such that (u 1 , a), . . . , (u m , a) are in UA. Next, archetype policies are combined to form level policies:

L2P((σ, [a 1 , . . . , a n ])) = (ca, [A2P(a 1 ), . . . , A2P(a n )])
where ca is the combining algorithm realizing the intra-level aggregator σ. The global policy is obtained by recursively combining level policies with respect to the priorities between levels:

H2P(L) = L2P(L) H2P((L, pr, H)) = (pr2CA(pr), [L2P(L), H2P(H)])
where pr2CA(t) = fa pr2CA(+) = pov pr2CA(-) = dov

In the next example we illustrate how to derive a global policy from the archetype hierarchy and user policies based on our running example.

Example 4. Fig. 2b shows the structure of global policy G obtained by instantiating the archetype hierarchy in Fig. 2a based on the scenario given in Example 1. Formally, the global policy can be represented as follows:

G = pov(pol RB , dov(pov(pol A , pol C ), fa(wc(pol N P A , pol EM C ), dov(pol SD , pol DC ))))
Here we assume that the policies specified by the data subjects (i.e., Alice and Caroline) are combined using permit-overrides, i.e. access to the data is granted if at least one of the data subjects permits the access. The policies of the UMC Security Department and Data Center are combined using deny-overrides. Finally, we combine the policies of the National Privacy Authority and the Ethical Medical Committee using the weak-consensus algorithm as defined in [START_REF] Li | Access control policy combining: Theory meets practice[END_REF]. According to this algorithm, user policies should not conflict with each other: Permit a request if some user policies permit a request, and no user policy denies it; Deny a request if some user policies deny a request, and no user policy permits it; otherwise Indeterminate should be yielded.

Policy Mismatches

In the previous section, we have shown how the policies of different stakeholders can be combined by taking into account their relationship with the resource to be protected. Ideally, the authorization system should enforce the access requirements of all stakeholders. However, this is not always possible. In fact, users can have conflicting authorization requirements, which results in conflicting policies.

Many access control mechanisms like XACML use policy combining algorithms to automatically resolve policy conflicts. Although solving conflicts is necessary for an authorization mechanism to make a conclusive decision, it makes the decision making process non-transparent to users. Users expect their policies to be enforced by the authorization system; however, in practice, their policies can be overridden by the policies of other entities. The main problem is that, in most existing authorization systems, policy conflict resolution is embedded in the policy evaluation process and, thus, policy conflicts are not identified and/or recorded. This makes users unaware whether their policies have actually been enforced.

We argue that the lack of transparency can affect the collaboration among users and, in particular, their willingness of sharing sensitive information needed for the success of the collaboration. Below we exemplify this issue using our running example.

Example 5. As shown in Example 1, each stakeholder has certain authorization requirements over the genetic information provided by Caroline. Suppose that David, a researcher at the UMC, requests access to this information. Based on the global policy in Example 4 and access requirements in Table 1, the authorization system allows David to access the information. If we look at the requirements of the single users, we have that: the enforced decision is consistent with Caroline's and the UMC Data Center's policy; however, access should have been denied according to Alice's policies; finally, the Regulatory Body's policy returns a NotApplicable as it delegates the Data Subject the authority to decide whether its data can be used for research purposes and thus does not define a specific policy about researcher accessing genetic information. We can observe that Alice's access requirements are not enforced. This can reduce her trust towards the UMC and, thus, can make her reluctant to share information in the future.

We use the notion of policy mismatch introduced in [START_REF] Damen | CollAC: Collaborative access control[END_REF] to capture policy conflicts. Definition 4. Let p 1 , . . . , p n be the policies of n users and p the global policy obtained by combining such policies. Given an access request q, a user i (with i ∈ {1, . . . , n}) has a mismatch if p (q) = p i (q). A mismatch occurs when the decision enforced by the authorization system differs from the decision obtained evaluating the policy of a user. Likely, only mismatches where a user's policy is applicable (i.e., p i = NotApplicable) are relevant for the user. However, we do not restrict the (type of) mismatches that can be reported to users. In particular, we allows each user to specify mismatches preferences, indicating the types of mismatches the user wants to be notified (see Section 5.1). In the next section, we show how the notion of mismatch can be used to augment the XACML reference architecture with a transparency service while being compliant with the XACML specification.

Transparency Service

The goal of this work is to enable collaborations between stakeholders in a trusted, secure and privacy-preserving way. Sharing resources and managing access to them are essential for such collaborations. However, as shown in the previous section, stakeholders may have conflicting authorization requirements. This section presents a transparency service, which aims to make the stakeholders engaged in a collaboration aware of these conflicts and how they are resolved by the authorization system.

The transparency service has been designed to be fully compliant with the XACML standard. This ensures that the service can be used within existing XACML implementations without these implementations being modified. In the remainder of the section, we discuss the design and implementation of the transparency service as well as possible deployment configurations within the XACML reference architecture.

Service Design

The transparency service aims to detect mismatches between the decision enforced by the authorization system and the access requirements of a certain stakeholder. Any mismatch found is then reported to the stakeholders whose decision was not enforced, provided they are interested in this type of discrepancy.

A naïve approach to identify decision mismatches would be to evaluate an access request against the global policy and against each user policy, and compare the obtained decisions. In particular, user policies could be stored separately in the PAP; then, the PDP can fetch one policy at the time for the evaluation of the access request. This naïve approach, however, has a number of drawbacks. First, the selective fetching of policies is not supported by most existing XACML implementations; they typically fetch all policies available in the PAP and then combine the decisions obtained evaluating the fetched policies using a root combining algorithm [START_REF]OASIS XACML Technical Committee: eXtensible Access Control Markup Language (XACML) Version 2[END_REF]. Therefore, this approach would requires a modification of existing XACML implementations. In addition, it requires instantiating the PDP for each user policy, affecting performance.

To address these drawbacks, we introduce viewpoints to distinguish user policies in the global policy. Every user u submits an XACML policy p u implementing its authorization requirements. To reflect the viewpoint the target of p u is extended with an environment attribute ViewPoint. Two values are assigned to this attribute: the identifier of u, representing the user viewpoint, and "global". The evaluation with respect the global perspective provides the access decision which is actually enforced by the It is worth noting that the target is applicable to a given access request (and thus a user policy is evaluated) only if at least one of these two attribute values for attribute ViewPoint is provided in the request. User policies are combined based on the role of the corresponding stakeholder with respect to the resource to be protected as described in Section 3. The resulting policy is stored in the PAP and is fetched by the PDP for the evaluation of access requests. The architecture of the transparency service is presented in Fig. 3. The service comprises three main components: Global Decision Handler, Mismatch Handler and Notification Handler. The service allows users to specify their preferences about which mismatches they want to be notified (e.g., access is permitted whereas the user wants to deny it) along with their contact information. Upon receiving a request, the Global Decision Handler adds attribute ViewPoint with value "global" to the request and passes on the enriched request for evaluation. The response is passed on for enforcement; it is also sent to the Mismatch Handler. This component checks the mismatch preferences provided by every user to determine the users u 1 , . . . u n who are interested in mismatches corresponding to the decision reached. For each such user u, the Mismatch Handler creates a new access request which consists of the original request but now extended with attribute ViewPoint taking value u, the identifier of the user. As the policies specified by other users will not be applicable (due to a non-matching value for attribute ViewPoint) this request is only evaluated against the policy of the corresponding user. When a response to a viewpoint specific requests does not match the global decision and the user is interested in this spefic type of mismatch, the Mismatch Handler calls the Notification Handler. This component retrieves the contact information of the users from the database and notifies them of the mismatches that occurred.

Service Implementation and Deployment

We have implemented the transparency service within the SAFAX framework [START_REF] Kaluvuri | SAFAX -An Extensible Authorization Service for Cloud Environments[END_REF]. SAFAX is an XACML-based architectural framework that offers authorization as a service. A main characteristic of SAFAX is that all components in the XACML reference architecture are designed as loosely coupled services. These services communicate with each other in JSON or XML via preregistered interfaces (defined in a service registry). SAFAX has been implemented in Java and runs on Apache Tomcat server using Jersey as a service framework. Back-end persistent data are stored in a MySQL server. To manage the authorization service configuration and policies, SAFAX offers a User Interface (referred to as SAFAX GUI) that consumes SAFAX services. The transparency service has been implemented as a SAFAX service and the SAFAX GUI has been extended to manage its configurations. Fig. 4a shows a screenshot of the interface used to manage viewpoints and set stakeholders' mismatch preferences. These preferences are stored in a persistent database on the MySQL server and used by the Notification Handler to determine, for each stakeholder, which mismatches should be notified. For demonstration purposes, the evaluation outcome for every request and the notified mismatches are shown in the SAFAX GUI (Fig. 4b).

Thanks to the service-oriented nature of SAFAX, the transparency service can be deployed at two different locations within the XACML reference architecture. In particular, it can act as either PEP or PDP. Depending on its use, the transparency service and its interfaces have to be registered in the SAFAX service registry accordingly. As shown by the architectures in Fig. 5 and Fig. 6, the transparency service encapsulates rather than replacing the corresponding components. By creating a dependency between the transparency service and one of the existing PEP and PDP services, the expected message flow for the corresponding configuration is achieved.

When the transparency service is used as PEP (Fig. 5), it can be seen as an external service offered to users by a (possibly) different provider. On the other hand, when the transparency service is used as PDP (Fig. 6), it can be seen as additional functionality offered by the authorization service itself. SAFAX is able to support both configurations without the need of modifying existing components due to its service-oriented nature. In contrast, other existing XACML implementations can only support the transparency service as an external service because they implement the XACML reference architecture as a monolithic component. Deployment of the transparency service as the PDP would require a modification of these XACML implementations.

Evaluation

As discussed in the previous section, the transparency service generates multiple requests to identify mismatches between the decision enforced by the system and user policies. Therefore, we need to evaluate the introduced overhead to ensure it does not affect user experience, thus hampering the adoption of the service in existing infrastructures. For the experiments we created a dataset consisting of policies of different size, where the size of a policy is characterized by the number of rules in the policy. Since the number of generated requests depends on the number of viewpoints, we added a varying number of viewpoints to these policies (i.e., 5, 10, 20, 30 and 40 viewpoints). The same policies were evaluated when the transparency service is deployed as PEP and PDP as well as when the transparency service is not used. We computed the average evaluation time over ten runs; a new policy dataset was created for each run.

The results of the experiments are shown in Fig. 7. These graphs show that the transparency service when deployed as PEP (Fig. 7b) introduces a larger overhead than when it is deployed as PDP (Fig. 7a). When the transparency service is deployed as PEP, every generated request has to be handled by the PEP, CH and PDP (see Fig. 5). On the other hand, when the service is deployed as PDP, requests are only handled by PDP (see Fig. 6), thus leading to a lower overhead. In addition to the deployment method, the results show that the evaluation time depends on the number of viewpoints and policy size. In particular, the number of viewpoints has an impact on the number of requests that are generated. The observed results imply that the delay introduced by the communication among the components of the system is more significant than the overhead due to the evaluation of the requests.

Although enabling transparency unavoidably comes at the cost of computation time, it should be noted that the decision enforced by the authorization mechanism is obtained from the evaluation of the request with the 'global' viewpoint. The other requests are only needed to detect policy mismatches and generate notifications. Therefore, they can be generated and evaluated offline to not affect the functioning of the system.

Related Work

With the growing popularity of collaborative systems, the risks of data breaches have increased due to the intrinsic difficulty of establishing a data government model for such systems. Several mechanisms have been proposed to balance the ease of collaboration and the level of security with collaborative systems (see [START_REF] Tolone | Access control in collaborative systems[END_REF] for a survey). For instance, solutions such as Role-Based Access Control [START_REF] Sandhu | Role-based access control models[END_REF], Task-Based Access Control [START_REF] Thomas | Task-based authorization controls (TBAC): A family of models for active and enterprise-oriented authorization management[END_REF] and Team-Based Access Control [START_REF] Thomas | Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments[END_REF] use the roles within an organization, the purpose of the usage or group membership to regulate the access to sensitive data. While these solutions provide some basic features to enable access control in collaborative systems, they usually assume that data objects are under the control of a single entity and, thus, they lack support for policy administration of shared resources.

A few models have been proposed for collaborative authorization management of shared data. For instance, Squicciarini et al. [START_REF] Squicciarini | Collective privacy management in social networks[END_REF] consider resources co-owned by multiple users who can separately specify their policies for the shared data, and use the Clarke-Tax model for the collective enforcement of these policies. Hu et al. [START_REF] Hu | Multiparty Access Control for Online Social Networks: Model and Mechanisms[END_REF] propose a multiparty access control model where, in addition to the owner of data, other controllers (e.g., contributor, dissiminator, stakeholders) can regulate the access to shared data. The owner of the data can choose an appropriate strategy (e.g., owner-overrides, full-consensus-permit, majority-permit) to resolve policy conflicts. To account for the different level of authority, the model uses a voting scheme that allows the specification of different weights for controllers. Similarly to the model proposed in [START_REF] Hu | Multiparty Access Control for Online Social Networks: Model and Mechanisms[END_REF], our governance model uses policy combination strategies for conflict resolution; however, our model allows a more fine-grained governance of shared resources by representing and ordering levels of authority through an archetype hierarchy that can be instantiated using an arbitrary combination of policy combining algorithms.

Policy combination strategies are often used by authorization mechanisms to define how policy conflicts should be resolved. Examples of conflict resolution strategies are: deny takes precedence [START_REF] Jajodia | Flexible Support for Multiple Access Control Policies[END_REF], permit takes precedence [START_REF] Jajodia | Flexible Support for Multiple Access Control Policies[END_REF], most-specific takes precedence [START_REF] Jajodia | Flexible Support for Multiple Access Control Policies[END_REF][START_REF] Matteucci | Prioritized execution of privacy policies[END_REF] and explicit specification of priorities [START_REF] Shen | Access control for collaborative environments[END_REF]. Similarly, Reeder et al. [START_REF] Reeder | Effects of access-control policy conflict-resolution methods on policy-authoring usability[END_REF] propose specificity precedence, deny precedence, order precedence, recency precedence or the combination of these when a single strategy fails. The most prominent authorization mechanism that supports (most of) these strategies is XACML [START_REF]OASIS XACML Technical Committee: eXtensible Access Control Markup Language (XACML) Version 2[END_REF]. In particular, XACML encodes conflict resolution strategies as policy combining algorithms (see Section 2). Our solution, being based on XACML, natively supports these strategies as well. Moreover, given the extensible nature of XACML, accommodating other conflict resolution strategies as the ones proposed in [START_REF] Jajodia | Flexible Support for Multiple Access Control Policies[END_REF][START_REF] Li | Access control policy combining: Theory meets practice[END_REF][START_REF] Matteucci | Prioritized execution of privacy policies[END_REF] is straightforward.

Mazzoleni et al. [START_REF] Mazzoleni | XACML Policy Integration Algorithms[END_REF] argue that policy combination algorithms provided by XACML, and in general conflict resolution strategies, are not enough to integrate policies spec-ified by autonomous parties. To this end, they define a policy similarity process and a number of policy integration algorithms. The policy similarity process is used to analyze the behavior of policies with respect to access requests. The result of this analysis, along with policy integration preferences given by the users, is used to select the policy integration algorithms for building the global policy. Differently from [START_REF] Mazzoleni | XACML Policy Integration Algorithms[END_REF], our framework integrates policies specified by multiple administration entities based on their relation with a data object, thus reflecting the level of authority that these entities have on the object. The policy similarity process and policy integration algorithms proposed in [START_REF] Mazzoleni | XACML Policy Integration Algorithms[END_REF] can be employed in our framework to form archetype and level policies.

Although methods for integrating policies specified by autonomous entities (as well as conflict resolution strategies) are necessary to ensure the proper functioning of the system, their application makes access decision making non-transparent to users. Transparency has become a major demand for modern IT governance, social and medical systems [START_REF] Albrecht | Transparency of health-apps for trust and decision making[END_REF][START_REF] De Fine Licht | Transparency actually: how transparency affects public perceptions of political decision-making[END_REF][START_REF] Joshi | An empirical assessment of it governance transparency: Evidence from commercial banking[END_REF]. However, very little research has been conducted towards its introduction into access control. To the best of our knowledge, CollAC [START_REF] Damen | CollAC: Collaborative access control[END_REF] is the only work that proposes a transparent access control solution which detects conflicts during policy evaluation and notifies the users whose decisions have been overridden. This work extents [START_REF] Damen | CollAC: Collaborative access control[END_REF] along two main directions. First, this work introduces archetype hierarchies to reason about the level of authority that users have over shared objects together with a method for obtaining the global policy from the archetype hierarchy and user policies. Moreover, we demonstrate how the notion of transparency can be accommodated in existing XACML-based access control mechanisms, thus showing its practical applicability.

Conclusion

This paper has introduced a governance model for collaborative systems, which enables the integration of the access requirements of all entities involved in the protection of a data object with respect to their relation with the object. This way, all entities are offered an appropriate level of control over shared resources. We have implemented the model in XACML, allowing each user to provide its requirements as a policy and using appropriate combining algorithms to achieve the right precedence between their policies.

Even if the use of combining algorithms is necessary to automatically resolve policy conflicts and thus guarantee the proper functioning of the system, it can result in a user's policy to be overruled without the user being aware. This may lower the user's trust in the system. To this end, we have introduced transparency in the decision making, allowing users to choose to be notified about conflicts between their access requirements and the decision enforced by the system. Our implementation within SAFAX shows that a transparency service can be deployed both as a PEP and a PDP. Our experiments show that deployment as a PDP has a lower overhead. While the solution is not optimized for performance, it can be applied to many scenarios, especially given the fact that the introduced overhead is not on the critical path for access to resources.

The proposed transparency service only notifies users about policy mismatches. To enhance user awareness, users should be also able to understand why a certain decision was taken [START_REF] Ghai | Cue: A Framework for Generating Meaningful Feedback in XACML[END_REF]. An interesting direction for future work is to augment users' notification with information explaining why their policies were overridden.

Fig. 2 :

 2 Fig. 2: Data Governance Model and Instantiation for the scenario in Example 1

Fig. 3 :

 3 Fig. 3: Transparency Service Architecture

Fig. 6 :

 6 Fig. 4: SAFAX GUI

Fig. 7 :

 7 Fig. 7: Evaluation of the overhead introduced by the transparency service

Note that legal requirements can also define the relation between stakeholders. In the next section we will discuss how these requirements can be accommodated in the framework.

Although any combining algorithm can be used to combine user policies and archetype policies, the use of noncommutative algorithms can have undesired effects. In fact, these algorithms often represent a priority between policies based on their order (e.g., first-applicable in XACML), whereas there is no order within an archetype or a level.

Acknowledgments: This work has been partially funded by the ITEA2 projects FedSS (No. 11009) and M2MGrid (No. 13011), the EDA project IN4STARS2.0, and the Dutch national program COMMIT under the THeCS project.