COSE Preprint

*Manuscript Click here to view linked References 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 domRBAC: An Access Control Model for Modern Collaborative Systems Antonios Gouglidis∗, Ioannis Mavridis Department of Applied Informatics, University of Macedonia, 156 Egnatia Str., 54006, Thessaloniki, Greece. Abstract Modern collaborative systems such as the Grid computing paradigm are capable of providing resource sharing between users and platforms. These collaborations need to be done in a transparent way among the participants of a virtual organization (VO). A VO may consist of hundreds of users and heterogeneous resources. In order to have a successful collaboration, a list of vital importance requirements should be fulfilled, viz. collaboration among domains, to ensure a secure environment during a collaboration, the ability to enforce usage constraints upon resources, and to manage the security policies in an easy and efficient way. In this article, we propose an enhanced role based access control model entitled domRBAC for collaborative applications, which is based on the ANSI INCITS 359-2004 access control model. The domRBAC is capable of differentiating the security policies that need to be enforced in each domain and to support collaboration under secure inter-operation. Cardinality constraints along with context information are incorporated to provide the ability of applying simple usage management of resources for the first time in a role-based access control model. Furthermore, secure inter-operation is assured among collaborating domains during role assignment automatically and in real-time. Yet, domRBAC, as an RBAC approach, intrinsically inherits all of its virtues such as ease of management, and separation of duty relationships with the latter also being supported in multiple domains. As a proof of concept, we implement a simulator based on Corresponding author. University of Macedonia, Thessaloniki, Greece. Email addresses: agougl@uom.gr (Antonios Gouglidis), mavridis@uom.gr (Ioannis Mavridis) URL: http://users.uom.gr/~agougl/ (Antonios Gouglidis) ∗ Preprint submitted to Computers and Security January 13, 2012 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 the definitions of our proposed access control model and conduct experimental studies to demonstrate the feasibility and performance of our approach. Keywords: Access control, Cross-domain authorization, Grid computing, RBAC, Resource usage management, Secure inter-operation 1. Introduction Modern collaborative systems are becoming the de facto platform for the implementation of applications. These applications may vary in nature and are capable of solving different types of problem sets posed from either the scientific community or the business sector. Nevertheless, in most cases, the need for excessive processing power and large storage space is required. In collaborative systems, as the Grid, the notion of users, resources, and of virtual organizations (VOs) play an important role. To this effect, we explicitly set the following definitions, mainly based on (Benantar, 2005; Chakrabarti, 2007; Ferraiolo et al., 2003; Foster & Tuecke, 2005; Sandhu & Samarati, 1994). A user in a Grid environment can be a set of user identifiers or a set of invoked services that can perform on request one or more operations on a set of resources. A resource in a Grid environment can be any sharable hardware or software asset in a domain and upon which an operation can be performed. Lastly, a domain can be defined as a protected computing environment, consisted of users and resources under an access control policy. The collaboration that can be established among domains leads to the formation of a virtual organization. Yet, as in all types of computing systems, the role of access control in the Grid is to control and limit the actions or operations that are performed by a user on a set of resources. In brief, it enforces the access control policy of the system, and at the same time it prevents the access policy from subversion. Access control in the literature is also referred to as access authorization or simply authorization. A Grid access control policy can be defined as a Grid security requirement that specifies how a user may access a specific resource and when. Such a policy can be enforced in a Grid system through an access control mechanism. The latter is responsible for granting or denying a user access upon a resource. Therefore, an access control model can be defined as an abstract container of a collection of access control mechanism implementations, which is capable of preserving support for the reasoning of the system policies through a conceptual framework. In this article we propose the domRBAC model, which is an access control 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 model designed to enforce access control under secure inter-operation in collaborative systems, as the Grid computing paradigm. The proposed model is based on the domRBAC model defined in (Gouglidis & Mavridis, 2011). Specifically, the domRBAC access control model is redefined in this paper regarding the hierarchical domRBAC and role inheritance management. The updated version of domRBAC is making use of more efficient algorithms and data structures in the process of identifying a violation. Yet, it defines a new function for preventing privilege escalation, which can be caused by a new inter-domain role assignment. Moreover, since the definition of domRBAC is based on the ANSI INCITS 359-2004 standard (ANSI, 2004), it also supports all the components of the RBAC model, namely the core RBAC, hierarchical RBAC, static separation of duty relations, and dynamic separation of duty relations. The domRBAC access control model is defined in such way to be both secure and efficient in order to cope with the requirements posed by modern collaborative computing systems. Such functionality includes along with the foregoing, support for multiple domains and the capability of applying simple usage management policies upon resources for the first time in a role based approach. By the term of usage management we refer to the management of the usage of resources across and within domains (Jamkhedkar et al., 2010). The remainder of this paper is organized as follows: Section 2 provides information about related research and presents our motivation. Section 3 provides sufficient details regarding the formal definition of domRBAC, and section 4 provides implementation aspects concerning the former definitions. Section 5 presents a prototype simulator that we have implemented according to our access control model definitions and details some experimental results. In section 6 we compare the proposed access control model with existing solutions, where applicable. Finally, section 7 summarizes this article. 2. Related Work and Motivation In collaborative systems like the Grid computing paradigm, various access control models are implemented into mechanisms in order to preserve support for the reasoning of the system’s policies. The most mainstream access control models are based on two models; viz. role-based access control (RBAC) and attribute-based access control (ABAC), which is mainly introduced to overcome a number of RBACs shortcomings (Yuan & Tong, 2005). However, the latter type of access control models lack in most cases of a proper formal 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 definition, apart from the usage control model (UCONABC ) (Sandhu & Park, 2003), which encompasses traditional access control, trust management and digital rights management for the protection of digital resources. The RBAC access control model has received considerable attention from researchers, mainly due to its abstraction and generalization. It is abstract because it includes only properties that are relevant to security, and it is general since it supports various designs that can all be interpreted as valid ones. More of RBACs virtues are the support of a significant number of principles, namely the least privilege, separation of administrative functions and separation of duties (Sandhu et al., 1996). Furthermore, RBAC is capable of supporting constraints, as the static and dynamic separation of duty relationships, and last but not least it can enforce role based administration. However, RBAC lacks decentralized management of policies and it cannot support any type of usage management. In order for RBAC to overcome some of its limitations regarding collaboration, a number of solutions were proposed that had to do with secure inter-operation, which is capable of tackling this issue. Research in (Shafiq et al., 2005) proposed an integer programming (IP)-based approach for optimal resolution of the examined conflicts. A policy integration framework is used for the merging of the individual RBAC policies into a global policy. However, this approach is not dynamic since the global policy is not a result of an incremental composition of the inter-domain policies. In (Chen & Crampton, 2007) an inter-domain role-mapping approach based on the least privilege principle is suggested. Yet, the applied greedy algorithm may not compute optimal solutions, and from a security perspective may fail to find a safe solution. Research in (Shehab et al., 2005) presents a protocol for secure inter-operation, which is based on the idea of access paths and access path’s constraints. Nonetheless, the protocol does not check for violations during an inter-domain role assignment. Rather, it assumes that inter-domain role mappings already exist. In (Zhang & Parashar, 2004) the DRBAC is presented as a dynamic context-aware access control model for Grid applications. However, the management of inter-domain policies is not tackled. Nevertheless, resource usage management, to the best of our knowledge, is completely absent from existing RBAC-based models. Attribute based access control (ABAC) has lately gained a lot of attention due to the development of Internet based distributed systems. However, in contrast to RBAC, attribute based access control, as already stated, has not been standardized yet. The only exception is the UCONABC model. In such 4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 access control approaches, access decisions are provided on resources based on the requesters owned attributes. The advantage of these approaches is that it is possible to provide access to users in a collaborative environment without the need for them to be known by the resource a priori. Thus, they natively support distributed access control and collaboration among domains. UCONABC is the only one that is capable of enforcing usage control. Nonetheless, functionalities such as administration and delegation are still absent. Another ABAC approach that gained considerable attention is the eXtensible Access Control Markup Language (XACML) that is an OASIS standard (OASIS, 2011). In XACML, the access control policies are specified in an XML-based language and exchanged among systems over the Web. A basic characteristic of XACML is its ability to support access control in a interoperable and flexible way. However, there are open world scenarios that XACML is unable to support. A number of XACML’s shortcomings along with a number of enhancements to be made to the standard are presented in (Ardagna et al., 2011). In Grid systems, the existence of various access control models, inevitably led to the implementation of different Grid authorization mechanisms. Additionally, each mechanism tried to further implement features not intrinsically supported by the implemented model (e.g. support of inter-domain collaborations, quality of service and so on). Representative authorization mechanisms in Grid systems are the Community Authorization Service (CAS) (Pearlman et al., 2002), the Virtual Organization Membership Service (VOMS) (Alfieri et al., 2004), Akenti (Thompson et al., 2003), PERMIS (Chadwick et al., 2003; Chadwick, 2005), and Usage Based Authorization (Zhang et al., 2006). Regarding mobile Grid systems, there are various architectures that have been proposed to provide solutions, as the virtual cluster approach in (Phan et al., 2002), the mobile OGSI.NET (Chu & Humphrey, 2004) and the Akogrimo project (Racz et al., 2007). Yet, the proposed authorization mechanisms are complementary to existing Grid authorization services, as the A4C infrastructure in Akogrimo. In collaborative systems as the Grid, we identify a list of non-functional access control requirements that must be fulfilled. These are, as identified in (Gouglidis & Mavridis, 2012), the support of interoperability among participating domains, the existence of a secure collaborative environment, the support of resource usage management and ease of policy management. After an analysis of existing access control approaches, namely the RBAC and ABAC, it is concluded that the aforementioned cannot fully support all the 5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 requirements that are posed by modern collaborative systems. More specifically, it is realized that neither of them can tackle the difficulties risen by the defined Grid access control requirements flawlessly. Yet, the implementation of the access control approaches into a Grid authorization mechanism has the same level of applicability in Grid applications. This means that also the mechanisms cannot handle well the defined requirements of modern collaborative systems. This is mainly a result of applying general purpose access control models that are not specifically designed to tackle the requirements of such systems. Hence, motivated by the absence of an access control model able to fulfill the requirements of modern collaborative systems, as the Grid, we further proceed with the definition of a new access control model. 3. The domRBAC Access Control Model We define our proposed access control model as an enhancement of the ANSI INCITS 359-2004 (ANSI, 2004). Although the ANSI standard cannot originally support the extra functionality required by modern collaborative systems, it provides a solid background for a new role based access control model. This section discusses the domRBAC model in a systematic manner, by providing all the required modifications and additions in the formal definitions of its base model. 3.1. Elements The domRBAC model consists of the following six basic elements: users, roles, sessions, operations, objects, and containers. A basic difference between the ANSI INCITS 359-2004 and domRBAC is that the latter can support access control among participating domains. A domain can be defined as a protected computing environment, consisted of users and resources/objects under an access control policy. Such a functionality is of vital importance since it governs inter-operations among domains. Figure 1 illustrates the proposed access control model. Henceforth, we use the terms object and resource interchangeably. Sessions, objects and operations are three concepts that are commonly used in access control. The latter two form a new element of permissions. A permission or a privilege is an approval to perform an operation on one or more RBAC protected objects. In domRBAC, the aforementioned elements provide the same functionality in their familiar sense. As in all role-based 6 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 models, sessions are dynamic elements. They are used as intermediary entities between the users and roles elements. The user element usually depicts a physical person who interfaces with a computer system. User elements, in role-based models, are assigned to role elements and vice-versa. Sessions, in role-based models, are used to enforce dynamic security policies to computing systems. Each user can be associated with many sessions, and each session may have a combination of many active roles. In regard to objects, they are used to represent an entity in a computing system. Control of access to objects can be coarse-grained or fine-grained, depending on the computing system. For instance, the sharing of files and exhaustible system resources can be considered an example of coarse-grained access control. On the contrary, the granting of access in a database on the level of record or field is an example of fine-grained access control. Yet, in domRBAC, an object can be associated with many container elements. The container element is explained in detail later in this section. Lastly, the element of operations provides a set of allowed operations on objects. Both operations and objects are system dependent. This means that different types of operations applies to different objects. Roles in domRBAC are enriched with the notion of domains, and are expressed in pairs of domains and roles. For the naming of the roles, we use the DomainRole notation. Thus, the Domain prefix indicates the role’s domain name, and the Role suffix indicates the name of the role. A formal definition is given later in definition 1.ii. The naming notation is used only for the element of roles. Nonetheless, when assigning users or permissions to roles, it is understood that the former two are also bounded by the role’s domain name. Through the role’s naming convention, the domRBAC model can distinguish the security policies enforced among the autonomous domains. The container is an abstract element that incorporates additional decision factors employed by the access decision function. The container can handle both the environment and usage level information. The environment attributes are used to set time constraints, spatial information and so on and so forth. Yet, the usage level attributes can limit the usage of shared resources. The information specified in the container element is based on (Neumann & Strembeck, 2003). Thus, a container attribute can represent a certain property of the environment or usage levels. A container function provides a mechanism to obtain the current value of a specific container attribute. Lastly, a container condition is a predicate that compares the current value of a container attribute either with a predefined constant, or 7 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 another container attribute of the same domain. A significant enhancement of domRBAC, when compared to the ANSI INCITS 359-2004, is that the element of container can support resource usage policies. Moreover, domRBAC can support additional constraints, namely static and dynamic role cardinality constraints, which can be applied to the process of role assignment and role activation, respectively. This means that the number of roles that can be assigned to and/or activated by the users of a system can be managed. The constraint of role cardinality is introduced to fulfill both requirements posed by the system administrators as well as resource owners. Administrators can use static role cardinality to limit the assignment of critical roles with users. Furthermore, dynamic role cardinality can be used for setting quality of service rules. Resource owners can manage the usage of their resources by limiting the number of users that utilizes them. Thus, it is feasible to create license agreements between users and resource owners. This leads users to receive high quality services in a computing system. Furthermore, the domRBAC model supports the identification of interdomain violations, in an automated way. The inter-domain violations are caused due to new immediate inter-domain role inheritance relations. The supported violations are: cyclic inheritance, privilege escalation, violation of static separation of duty relations in a domain, and violation of dynamic separation of duty relations in a domain. The domRBAC model is designed to preserve the security principle among collaborators. Nevertheless, the autonomy of a domain may be willing to be compromised (Shafiq et al., 2005). In the rest of this section, all formal definitions are given in the Z formal description language (ISO/IEC-13568, 2002), as it also happens in the ANSI INCITS 359-2004 standard. 3.2. Definitions 3.2.1. Definition 1. Core domRBAC. The formal definition of core domRBAC model, based on (ANSI, 2004), is extended as follows: i. USERS, ROLES, OPS, OBS, CNTRS, stands for users, roles, operations, objects and containers, respectively. ii. ddomain rrole ∈ ROLES is a role expressed in a DomainRole format, where Domain denotes a domain name and Role denotes a role name. For example, if a role rm belongs to a domain di , we write di rm . 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 iii. UA ⊆ USERS × ROLES, a many-to-many mapping user-to-role assignment relation. iv. assigned users(di rm :ROLES) → 2U SERS , the mapping of role di rm onto a set of users. Formal definition: assigned users(di rm ) = {u ∈ USERS | (u,di rm ) ∈ UA}. v. PRMS = 2(OP S×OBS), the set of permissions. vi. PA ⊆ PRMS × ROLES, a many-to-many mapping permission-to-role assignment relation. vii. assigned permissions(di rm :ROLES) → 2P RM S , the mapping of role di rm onto a set of permissions. Formal definition: assigned permissions(di rm )={p ∈ PRMS | (p,di rm ) ∈ PA}. viii. CA ⊆ CNTRS × OBS, a many-to-many mapping container-to-object assignment relation. ix. assigned containers(o: OBS) → 2CN T RS , the mapping of object o onto a set of containers. Formal definition: assigned containers(o)={c ∈ CNTRS | (c,o) ∈ CA}. x. Op(p: PRMS) → {op ⊆ OP S}, the permission to operation mapping, which gives the set of operations associated with permission p. xi. Ob(p: PRMS) → {ob ⊆ OBS}, the permission to object mapping, which gives the set of objects associated with permission p. xii. SESSIONS = the set of sessions. xiii. session user(s: SESSIONS) → USERS, the mapping of session s onto a corresponding user. xiv. session roles(s: SESSIONS) → 2ROLES , the mapping of session s onto a set of roles. Formal definition: session roles(s) ⊆ {di rm ∈ ROLES | (session user(s),di rm ) ∈ UA}. xv. avail session perms(s: SESSIONS) → 2P RM S , the permissions available S to a user in a session = di rm ∈session roles(s) assigned permissions(di rm ). 3.2.2. Definition 2. Hierarchical domRBAC. The hierarchical domRBAC is defined to cope with inter-domain role inheritance relations. Henceforth, we use i and j to refer to domains, where + i = j if we refer to an intra-domain relation, and i = j if we refer to interdomain relations (intra − domain ⊆ inter − domain). 9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 i. RH ⊆ ROLES × ROLES is a partial order on ROLES called the inheritance relation, written as ≥, where di rm ≥ dj rn only if all permissions of dj rn are also permissions of di rm , and all users of di rm are also users of dj rn . Formal definition: di rm ≥ dj rn ⇒ authorized permissions(dj rn ) ⊆ authorized permissions(di rm )∧ authorized users(i,j) (di rm ) ⊆ authorized users(i,j)(dj rn ). ii. authorized users(i,j) (di rm : ROLES) → 2U SERS , the mapping of role di rm onto a set of users in the presence of a role hierarchy. Formal definition: authorized users(i,j)(di rm ) = {u ∈ USERS|dj rn ≥ di rm ∧ (u, dj rn ) ∈ UA}. iii. authorized permissions(i,j) (di rm : ROLES) → 2P RM S , the mapping of role di rm onto a set of permissions in the presence of a role hierarchy. Formal definition: authorized permissions(i,j) (di rm ) = {p ∈ P RMS|di rm ≥ dj rn ∧ (p, dj rn ) ∈ P A}. Definition 2.iii, in domRBAC, is based on the corrected formal definition of authorized permissions, as this is identified in (Li et al., 2007). 3.2.3. Definition 3. Constrained domRBAC. Separation of duty (SoD) is a fundamental security principle that is supported in domRBAC. SoD serves as a requirement for critical operations, which are divided among two or more people, so that no single individual can compromise security. SoD methods are categorized into two broad categories, namely that of static and dynamic. Static SoD (SSD) are constraints that are placed on roles at the time roles are assigned to users. SSD are further defined in the presence of a hierarchy, where it works in the same way as in the latter case except that when enforcing the constraints both inherited roles and directly assigned roles are considered. Dynamic SoD (DSD) are constraints that are invoked when users are using the system to activate already assigned roles (Ferraiolo et al., 2003). Apart from the support of static and dynamic separation of duty constraints in each domain, domRBAC supports static and dynamic role cardinality constraints. Static role cardinality constraints can restrict the number of users assigned to a role, to a maximum number. Moreover, dynamic role cardinality constraints can restrict the number of users that activate a role, to a maximum number in all concurrent sessions. In the following, we redefine SSD and DSD in the presence of domains, and we define static and dynamic role cardinality. 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 i. Static Separation of duty (SSD): SSD ⊆ (2ROLES × N) is a collection of pairs (di rs,n) in SSD, where each di rs is a role set in a domain di , t a subset of roles in di rs, and n is a natural number ≥2, with the property that no user of domain di is assigned to n or more roles from the set di rs in each (di rs,n) ∈ SSD. Formal definition: ∀(dT i rs, n) ∈ SSD, ∀t ⊆ di rs : |t| ≥ n ⇒ di rm ∈t assigned users(di rm ) = ∅. ii. SSD in the presence of a hierarchy: In the presence of a role hierarchy SSD is redefined based on authorized users rather than assigned users as follows: Formal definition: ∀(dT i rs, n) ∈ SSD, i = j, ∀t ⊆ di rs : |t| ≥ n ⇒ di rm ∈t authorized users(i,j)(di rm ) = ∅. iii. Dynamic Separation of Duty (DSD): DSD ⊆ (2ROLES × N) is a collection of pairs (di rs,n) in DSD, where each di rs is a role set and n a natural number ≥2, with the property that no subject may activate n or more roles from the set di rs in each dsd ∈ DSD. Formal definition: ∀di rs ∈ 2ROLES , n ∈ N, (di rs, n) ∈ DSD ⇒ n ≥ 2.|di rs| ≥ n, and ∀s ∈ SESSIONS, ∀di rs ∈ 2ROLES , ∀role subset ∈ 2ROLES , ∀n ∈ N, (di rs, n) ∈ DSD, role subset ⊆ di rs, role subset ⊆ session roles(s) ⇒ |role subset| < n. iv. Static role cardinality (SRC): If static role cardinality constraint is required for any role di rm , then di rm cannot be assigned to more than a maximum number of users. SRC ⊆ (ROLES × N) is a collection of pairs (di rm , n) in static role cardinality, where di rm is a role rm in a domain di and n is a natural number ≥ 0, with the property that the number of users assigned with role di rm cannot exceed the number n in each (di rm , n) ∈ SRC. Formal definition: di rm ∈ ROLES, n ∈ N, n ≥ 0, ∀(di rm , n) ∈ SRC ⇒ |assigned users(di rm )| ≤ n. v. SRC in the presence of a hierarchy: In the presence of a role hierarchy static role cardinality constraint is redefined based on authorized users rather than assigned users as follows: 11 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 + di rm ∈ ROLES, i = j, n ∈ N, n ≥ 0, ∀(di rm , n) ∈ SRC ⇒ |authorized users(i,j) (di rm )| ≤ n. vi. Dynamic role cardinality constraint (DRC): If dynamic role cardinality is required for any role di rm , then di rm cannot be activated for more than a maximum number of authorized users in all concurrent sessions of a system. DRC ⊆ (ROLES × N) is a collection of pairs (di rm , n) in dynamic role cardinality, where di rm is a role rm and n is a natural number ≥ 0, with the property that the number of concurrent role activations by users authorized for role di rm cannot exceed the number n. Formal definition: di rm ∈ ROLES, n ∈ N, n ≥ 0, P ∀s ∈ SESSIONS, (di rm ,n) ∈ DRC ⇒ |di rm ∩ session roles(s)| ≤ n. After defining both the container element and the DRC constraint, we elaborate on the supported types of resource usage policies. The first type is via the container element, by declaring the required attribute value, function and condition of the container. However, this type of resource usage policy is unable to provide quality of service to consumers since each container element restricts the usage of a resource on per role activation. A second type of resource usage policy with quality of service capabilities is provided via the combination of the container element and DRC constraint. This type of resource usage policy enforcement restricts the usage of a resource on all concurrent role activations. 3.2.4. Definition 4. Role Inheritance Management. The domRBAC model aims at providing a comprehensive solution to secure inter-operation based on the principles of security, autonomy and containment (Ravi Sandhu, 2008). In order to establish a secure inter-operation among the participating domains, domRBAC provides two new administrative commands for managing inter-domain role inheritance relations. The administrative commands can be used by the administrator of each domain, according to the interoperability requirements of each system. Their objective is to check for a number of violations before committing an inter-domain role inheritance relation. Thus, based on the definitions 4.i, 4.ii, 4.iii and 4.iv, we introduce the InterdomainPolicyViolation function for the checking of inter-domain violations due to the inter-domain role inheritance relations, and two new inter-domain administrative commands AddInterdomainInheri12 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 tance and DeleteInterdomainInheritance for establishing and discarding immediate inter-domain inheritance relationships, respectively. Intra-domain management not listed below is handled the same as in the ANSI INCITS 359-2004 standard. i. Intra-domain violation of role assignment: As stated in (Shafiq et al., 2005) an inter-domain policy causes a violation of role assignment constraint of domain di if it is allowed to a user u of domain di to access a local role di rm even though u is not directly assigned to di rm or any of the roles that are senior to di rm in the role hierarchy of domain di . We identify role assignment violations by checking for cyclic inheritance in the inter-domain role hierarchy graph. Role assignment violations can occur due to the addition of a new immediate inter-domain inheritance relationship di rmasc ≫ dj rndesc between existing roles di rmasc , dj rndesc , where di rmasc is a role ascendant of dj rndesc . ii. Privilege escalation: Apart from cycle inheritance, we identify another case that may lead to privilege escalation due to a new interdomain role assignment. The applied methodology ensures that the principle of security is preserved during the collaboration at the cost of reducing inter-operation. The security principle ensures that if an access is not permitted within an individual domain, it must not be permitted under secure inter-operation. iii. Intra-domain violation of SSD relationships: An inter-domain policy causes an intra-domain violation of SSD relationships of domain di if it is allowed to a user u of domain di to be assigned to any two conflicting roles di rm and di rn of domain di . We identify violations of SSD relationships, using the following properties (Ferraiolo et al., 2003): Property 1: If there are two roles di rm and dj rn that are mutually exclusive, then neither one should inherit the other, either directly or indirectly. Property 2: If there are two roles di rm and dj rn that are mutually exclusive, then there can be no third role that inherits both of them. iv. Intra-domain violation of DSD relationships: An inter-domain policy causes an intra-domain violation of DSD relationships of domain di if it is allowed to a user u of domain di to activate any two conflicting roles di rm and di rn of domain di . We identify violations of DSD relationships similarly to definition 4.iii due to the following property (Ferraiolo et al., 2003): 13 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Property 3: If SSD holds, then DSD is maintained. Thus, properties 1 and 2 must be guaranteed. v. InterdomainPolicyViolation: This function checks if any of the aforementioned violations occur during the creation of a new interdomain role assignment. Hence, it returns true if a violation occurs and false otherwise. vi. AddInterdomainInheritance: This command establishes a new immediate inter-domain inheritance relationship di rmasc ≫ dj rndesc between existing roles di rmasc , dj rndesc . The command is valid if and only if di rmasc and dj rndesc are members of the ROLES dataset, di rmasc is not an immediate ascendant of dj rndesc , and violations of role assignment and of SSD and DSD relationships do not occur. Formal definition: AddInterdomainInheritance(di rmasc , dj rndesc : NAME)⊳ di rmasc , dj rndesc ∈ ROLES; InterdomainP olicyV iolation(dj rndesc ) = f alse; ¬(di rmasc ≫ dj rndesc ); ¬(dj rndesc ≥ di rmasc ) ≥′ =≥ ∪{dr, dq : ROLES|dr ≥ di rmasc ∧ dj rndesc ≥ dq • dr 7→ dq}⊲ vii. DeleteInterdomainInheritance: This command deletes an existing immediate inter-domain inheritance relationship di rmasc ≫ dj rndesc . The command is valid if and only if the roles di rmasc and dj rndesc are members of the ROLES dataset, and di rmasc is an immediate ascendant of dj rndesc . The new inter-domain inheritance relation is computed as the reflexive-transitive closure of the immediate inheritance relation resulted after deleting the relationship di rmasc ≫ dj rndesc . Formal definition: DeleteInterdomainInheritance(di rmasc , dj rndesc : NAME)⊳ di rmasc , dj rndesc ∈ ROLES; (di rmasc ≫ dj rndesc ) ≥′ = (≫ {di rmasc 7→ dj rndesc })∗ ⊲ 4. Implementation Aspects In this section a series of implementation aspects of the model are discussed. Our approach utilizes algorithms derived from the theory of graphs. This is done since firstly graphs help in the visualization of inter-domain role inheritance relations, secondly adjacency lists make it easy to find subgraphs and finally adjacency queries are fast. Knowing that role hierarchies 14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 are represented as sparse graphs, we choose to use linked lists for their representation instead of matrices since the former is more efficient. A list of implementation aspects follow in the rest of this section. i. G = (V, E) is the inter-domain role hierarchy directed graph, which consists of a finite, nonempty set of role vertices V ⊆ ROLES and a + set of edges E. Each edge is an ordered pair (di rm , dj rn ), i = j of role vertices that indicates the following relation: di rm ≥ dj rn . ii. A path in a G graph is a sequence of edges (di r1 , di r2 ), (di r2 , di r3 ), . . ., (di rn−1 , di rn ). This path is from role vertex di r1 to role vertex di rn and has length n-1. The path represents not immediate inheritance relation between role vertex di r1 and di rn . iii. An adjacency list representation for graph G = (V, E) is an array L of |V | lists, one for each role vertex in V . For each role vertex di rm , there is a pointer Ldi rm to a linked list containing all the role vertices that are adjacent to di rm . A linked list is terminated by a nil pointer. Henceforth, we refer to the adjacency list as AG . We also set AG [di rm , dj rn ] = 1 if there is an edge from role vertex di rm to role vertex dj rn , and AG [di rm , dj rn ] = 0 otherwise. Despite the fact that the latter notation is mostly used in matrices, we choose to use it also in linked lists for simplicity and readability reasons. iv. The transitive closure of a graph G = (V, E) is a graph G∗ = (V, E ∗ ) such that E ∗ contains an edge (u, v) if and only if G contains a path (of at least one edge) from u to v. The algorithm used to implement the transitive closure is based on the detection of strong components (Nuutila, 1995; Purdom, 1970), having a worst case time complexity of O(|V ||E|). Henceforth, we refer to the transitive closure list of a directed graph G = (V, E) with adjacency list AG as TG . Furthermore, we set TG [di rm , dj rn ] = 1 if there is a path from di rm to dj rn of length 1 or more, and 0 otherwise. In turn, we provide the algorithms that implement definitions 4.i to 4.v. v. Intra-domain violation of role assignment: The algorithm for detecting cycles is given in Figure 2. In short, we iterate onto every vertex di r of the transitive closure list, and for each adjacent vertex dj r to vertex di r we check if vertex di r = dj r. In such case, TG [di r, dj r] = 1 since there is a path from di r to dj r of length one or more. 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 vi. Privilege escalation: We describe the algorithm that implements the current function using an example. Assume that we have two domains d1 and d2 , as shown in Figure 3. In domain d1 we have role d1 ra that inherits role d1 rb . Likewise, in domain d2 we have role d2 rc that inherits roles d2 rd and d2 re . Let users u1 and u2 be assigned to roles d2 rd and d2 re , respectively. At first, we commit an inter-domain role assignment between roles d2 rd and d1 ra (d2 rd inherits d1 ra ). The latter role assignment does not raise any problem to the security nor the autonomy principles. Now, if we try to make a new inter-domain role assignment between d1 rb and d2 re (d1 rb inherits d2 re ), user u1 of domain d2 can then activate role d2 re , even though it was not assigned with him/her at the beginning. Through this process, a user can get more privileges in his/her parent domain. Thus, in domRBAC, we identify such cases and we reject the inter-domain role assignments. In order to identify this kind of privilege escalation cases we work as follows. Assume that we want to make the aforementioned inter-domain role assignment between roles d1 rb and d2 re (d1 rb inherits d2 re ). We gradually check for each role in the target domain d2 if there is a role d2 rx that may lead its assigned users to gain more privileges in their parent domain. To identify such cases we assume that the initial inter-domain role assignment can be applied and we check for each role d2 rx , which is in equal or lower depth when compared with role d2 re , if TG [d2 re , d2 rx ] 6= TGd2 [d2 re , d2 rx ] or TG [d2 rx , d2 re ] 6= TGd2 [d2 rx , d2 re ], where TGd2 is the transitive closure list of domain d2 with all inter-domain role assignments excluded. If yes, then we raise an error and we discard the inter-domain role assignment. Otherwise, we commit the inter-domain role assignment. The algorithm for preserving the security principle is given in Figure 4. For simplicity reasons, we describe the algorithm using the TG , TGi notation that was previously defined, instead of describing analytically the iterations onto the list data structures. vii. Intra-domain violation of SSD relationships: The algorithm for detecting intra-domain violations of SSD relationships is given in Figure 5. In more detail, we check for each pair of SSD relationship, if the new role assignment raises an error. In order to do so, we iterate onto the transitive closure list and we firstly check for each SSD pair if Property 1 is being violated. If yes, a violation has been occurred and the function returns true. Otherwise, we continue to check for each SSD pair if Property 2 is being violated. If yes, a violation has been occurred and 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 the function returns true. Otherwise, no violation has been occurred and the function returns false. Specifically, Property 1 is maintained in lines 2-11, and Property 2 in lines 12-19. viii. Intra-domain violation of DSD relationships: The algorithm for detecting intra-domain violations of DSD relationships is given in Figure 6. ix. InterdomainPolicyViolation: Figure 7 presents the implementation of the function with function parameter di rndesc with the latter being a role that can be inherited by any role di rnasc . It is worthy to mention that the function parameter is only required by the sp violation function. All the other functions check for violations in all domains. The following example illustrated in Figure 8 shows how the aforementioned functions are used to identify any of the supported violations. Let’s assume a multi-domain access control policy that allows collaboration between domain d1 and domain d2 . Domain d1 has the following roles: d1 ra , d1 rb , d1 rc , d1 rd and d1 re . Role d1 ra inherits all permissions of d1 rb which further inherits d1 re . Role d1 rc inherits all permissions of d1 rd which further inherits d1 re . An SSD relation is specified for d1 rb and d1 rc meaning that these roles cannot be assigned to the same user simultaneously. Domain d2 has the following roles: d2 rf and d2 rg . Role d2 rf inherits all permissions of d2 rg . The multi-domain access control policy defines the following inter-domain inheritance relationships between domains d1 and d2 , which are applied in the following chronological order. (a) Role d1 rb inherits role d2 rg . (b) Role d2 rg inherits role d1 rc . The inter-domain role relationship described in (a) does not raise any of the discussed violations. Regarding the inter-domain role relationship in (b) we work as follows: Step 1. Assuming that the inter-domain role relationship in (b) can be applied, the required adjacency and transitive closure list representations are constructed, as follows: 17 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65  V ertex     d 1 ra :     d 1 rb :    d 1 rc : AG = d  1 rd :    d 1 re :     d r :    2 f d 2 rg : Linked list  V ertex d1 rb → nil     d 1 ra : d1 re → d2 rg → nil    d 1 rb : d1 rd → nil AGd1 = d d1 re → nil  1 rc :    dr : nil    1 d d 1 re : d2 rg → nil d1 rc → nil  V ertex     d 1 ra :     d 1 rb :    d 1 rc : TG = d 1 rd :     d 1 re :     d r :    2 f d 2 rg : TGd1 Linked list d1 rb → nil d1 re → nil d1 rd → nil d1 re → nil nil Linked list d1 rb → d1 rc → d1 rd → d1 re → d2 rg → nil d1 rc → d1 rd → d1 re → d2 rg → nil d1 rd → d1 re → nil d1 re → nil nil d2 rg → d1 rc → d1 rd → d1 re → nil d1 rc → d1 rd → d1 re → nil  V ertex     d 1 ra :    d 1 rb : = d 1 rc :     d r :    1 d d 1 re : Linked list d1 rb → d1 re → nil d1 re → nil d1 rd → d1 re → nil d1 re → nil nil Step 2. The InterdomainP olicyV iolation function is executed using the d1 rc as function parameter. In turn, the rest functions are executed, namely the ci violation(), sp violation(d1 rc ), ssd violation(), and dsd violation(). The only existing SSD relationship pair is that of (d1 rb , d1 rc ). The computations are performed based on the predefined algorithms. As resulted, two different types of violations are identified. The first is identified by the sp violation(d1 rc ) function call. This happens because during the collaboration, role d1 ra inherits role d1 rc . However, the latter inheritance relationship did not exist in the initial domain d1 , thus, it may lead to privilege escalation. A second violation is determined by the ssd violation() function, since 18 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 it identifies that the inter-domain relationship allows to role d1 rb to access the permissions of role d1 rc through d2 rg . This is not permissible, since the former two roles are mutually exclusive. The identification of the two violations will discard the inter-domain inheritance relationship, assumed in the hypothesis of step 1. Concerning the implementation of the domRBAC model, a number of performance issues had to be solved. Such issues were related to the need for continually re-creating new adjacency and transitive closure lists. Hence, when the re-creation of the adjacency list is required, we update (insert or delete) only the parts of the structure that needs to change, and not the whole adjacency list. In a similar way to the update operation of the adjacency list, there is a need to update the transitive closure, when we add a new edge to a graph, or remove an existing one. To improve the construction time of the transitive closure list, we do not re-create it from scratch. Instead the only new paths we add are the ones which use the new edge (u, v). These paths will be of the form a u→v b, where is used as a logical connective and interpreted as leads to. We can find all these new paths by looking in the old transitive closure for the vertices a ∈ A which had paths to u and for vertices b ∈ B which v had paths to. S The new edges S in the transitive closure will then be (a, b), where a ∈ A u and b ∈ B v. If we represent the transitive closure graph G with an adjacency matrix, we can very easily find the sets A and B. A will include all the vertices which have a one (1) in the column u and B will be all the vertices which have a one (1) in the row v. Since the number of vertices in each set A or B is bounded by V , the total number of edges needed to be added is O(V 2 ) (Carlstrom, 2004). However, since information is stored in lists, the equivalent total number of edges needed to be added becomes significantly lower. 5. Simulation and Experimental Study This section introduces the overall architecture of the simulator, which implements the part that is responsible for the management of policies since the majority of domRBAC’s enhancements are heavily depended on the management of inter-domain policies in real-time. The goal of the simulator is to produce a series of experimental results, so as to check the applicability and efficiency of the domRBAC during collaboration. 19 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 5.1. The domRBAC Simulator The domRBAC simulator is capable of checking security policies and to decide either to commit or reject a policy. Hence, it serves as an Access Control Decision Function (ADF), which together with the Access Control Enforcement Function (AEF) implements the concept of reference monitor (Ferraiolo et al., 2003). An ADF is responsible for the making of access control decisions. The decisions are made based on information applied by the access control policy rules, the context in which the access request is made, and the Access Control Decision Information (ADI) (ITU, 1995). The ADI is a portion in the Access Control Information (ACI) function, which includes any information used for access control purposes, including contextual information. Lastly, the AEF is responsible for the enforcement of the decision taken from the ADF. The concept of reference monitor in open systems has been standardized with the X.812 access control framework (ITU, 1995). The core simulator is implemented in the Debian Linux 2.6.32-5-686 platform using the C++ 4.4.5 programming language and making use of the BOOST 1.42.0 C++ library (Boost, 2011). The graphical user interface is built using the Qt 4.6.3 (Nokia, 2011). Figure 9 illustrates the overall architecture of the domRBAC simulator. The simulator is capable of reading access control policies from two different types of input files. The first file type is in the XML (W3C, 2011) and the second in the DOT language (Graphviz, 2011). DOT is a plain text graph description language, which can describe in a simple way graphs that both humans and computer programs can use. The XML file is currently using a custom syntax opposed to that of XACML RBAC (OASIS, 2011), for simplicity reasons. Due to the modular design of the simulator, this can be changed in the future. The XML file can be validated along with an XSD file (W3C, 2011) to an external validation engine, in order to check the correctness of the XML file. The content of the XSD file is presented in Appendix A. The XML policies are loaded in the core of the simulator using the SAX streaming API (XML-DEV, 2011), since policies can get too big for the available memory. There is also support for the DOM tree-based API (W3C, 2005), only for the part of the simulator that handles the viewing of the available policies. Both parsers are implemented using the equivalent libraries provided by the Qt. However, since the writing of policies can be cumbersome, the domRBAC simulator is capable of loading files that are described in the DOT language. In order to produce random and of different size input data, we used the NetworkX python package (NetworkX, 2011) for 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 the creation of DOT files. Furthermore, the visualization of security policies is possible through the Graphviz library (Graphviz, 2010). Using a configuration file, where a list of parameters can be defined, the core simulator can start the simulation by creating random role assignments. The latter is performed by the random policy generator, which is responsible for the creation of additional policies on top of the imported access control policies. During the simulation a number of role assignments, SSD and DSD relationships are randomly requested, based on the information described in the configuration file. However, after each request the simulator automatically checks if any type of violation is being raised. If not, it commits the requested role assignment, and otherwise, it rejects the role assignment. The main interface of the simulator is depicted in Figure 10. On the left side of the screen, the loaded access control policies are available in tree-view, and on the right side the access control policies, the adjacency and transitive closure lists are being visualized, each one on a different tab. On the top of the screen there is a menu with all the available options (e.g. check for violations, run simulation and so on), and on the bottom a console logs all the actions of the domRBAC simulator. Since domRBAC depends heavily on both adjacency and transitive closure lists, we use state-of-the-art functions provided by the BOOST C++ library, in order to construct and compute them. In more detail, we use the adjacency list class that implements a generalized adjacency list graph structure. This is a two-dimensional structure, where each element of the first dimension represents a vertex, and each of the vertices contains a onedimensional structure that is its edge list. Regarding the computation of the transitive closure we make use of the transitive closure() function, which transforms the input graph g into the transitive closure graph tc. Concerning the update operations in both lists, we update only the required information, as described in section 4. 5.2. Performance Evaluation As an access control management decision is dynamically determined by checking if any violation occurs during a cross-domain role assignment, the performance of the system should be considered. Using the domRBAC simulator, a list of performance metrics are captured during various stress tests. The metrics are mostly considered with time values and memory consumption. The technical characteristics of the test platform were: 1.6GHz Intel Mobile Pentium processor, 786MB of RAM, and using the Debian Linux 21 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 2.6.32-5-686 platform. The simulator was compiled using the -O3 optimization parameter, in order to increase performance (Free Software Foundation, 2008). The test cases were created using the gnc graph function that returns a growing network with copying (GNC) directed graph, which is built by adding nodes one at a time with a link to one previously added node, chosen uniformly at random, and to all of that nodes successors (NetworkX, 2011). In turn, the simulator loads the role hierarchies of each domain and randomly performs role assignment operations, as well as static and dynamic separation of duty relationships. After each new request of role assignment, the simulator checks if the role assignment will be committed or discarded based on the inter-domain policy violation function and logs the transaction. The latter can be repeated continuously and in real-time, in order to collect performance data. For the performance evaluation of the proposed access control model, we performed a series of simulations on different data sets. More specifically, we used test cases of 50, 100, 150 and 200 domains containing 100 roles each, called as group ’A’ of data, and of 5, 10, 15 and 20 domains containing 1000 roles each, called as group ’B’ data. Thus, we created collaborative domains that contained 5000, 10000, 15000 and 20000 roles, respectively. This was done in order to analyze the behavior of the model. For instance, a collaborative system that consists of 5000 roles, in the above-mentioned data sets, can be the result of a combination of 50 domains containing each 100 roles or of 5 domains containing each 1000 roles. Table 1 summarizes the performance of the ADF’s memory consumption along with decision time values and a number of violations. This information is the result of a simulation of 5000 random role assignment, SSD and DSD requests. It can be seen in group’s ’A’ data set that the simulation leads to higher numbers of inter-domain role assignments and to lower numbers of SSD and DSD relationships, in contrast to group’s ’B’ data set. This behavior is logical and expected to be seen since the low number of roles in a domain have a negative effect regarding the creation of new SSD and DSD relationships. Furthermore, the low number of roles combined with a high number of domains act in favor of creating more inter-domain role assignments. Yet, such a behavior results to a slightly higher memory consumption of approximately 3% on average in the adjacency lists, which is increased to the level of 17% on average in the transitive closure lists. Moreover, the high number of violations depicted in Table 1 is the result of domRBAC’s design decisions since domRBAC tries to preserve the security privilege instead of gaining inter-operation. In general, it is not 22 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 a feasible task to create a global multi-domain policy where inter-operation is allowed among domains without violating the security or the autonomy of a participating domain (Shafiq et al., 2005). However, the violation of a domain’s security in not permissible. Nevertheless, the autonomy of a domain may be willing to be compromised. For the overall autonomy loss (OAL) and overall interoperability level (OIL) of the collaborative system we use similar equations, as in (Shafiq et al., 2005). Hence, for calculating the autonomy loss and interoperability level we use the equations 1 and 2, respectively. In 1 the OAL is calculated by subtracting the total number of committed intrarole assignments from the total number of requested intra-role assignments during the simulation period, and dividing the difference by the latter to get the value of OAL. Similarly to OAL, in 2 the OIL is calculated by subtracting the total number of violations occurred due to inter-role assignments from the total number of requested inter-role assignments during the simulation period, and dividing the difference by the latter to get the value of OIL. Using the aforementioned expressions the autonomy loss and inter-operation level reached at 6% and 7.5% in group’s ’A’ data set and 2% and 8% in group’s ’B’ data set, respectively. OAL = (Intra role assignments) − (Committed intra role assignments) (Intra role assignments) (1) OIL = (Inter role assignments) − (Inter violations) (Inter role assignments) (2) Additionally, we present a performance evaluation concerning the time required to compute the data structures used in domRBAC and the time that is required for the ADF to check and identify potential violations. Appendix B.1 and Appendix B.2 include the descriptive statistical measures in detail, viz. mean, median, mode, maximum and standard deviation values, of groups ’A’ and ’B’, respectively. Figures 11 and 12 illustrate the mean and maximum time values of calculations, respectively. Maximum decision time, in both cases, is calculated as the sum of the adjacency list creation, transitive closure list creation and of a maximum value of cycle inheritance, privilege escalation, SSD and DSD violation. The creation of the transitive closure list presupposes the creation of the adjacency list. Hence, it is required to add both time values. We further add the maximum time value 23 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 among violations since violation algorithms can be executed concurrently. In case a violation is determined by a thread that implements a function that identifies a violation, the former sends a signal to the other threads to terminate calculations, and it further returns a true value to indicate the determination of a violation. The maximum decision time regarding mean values ranges approximately from 2 to 50 milliseconds, and from 120 to 1142 milliseconds in worst cases (maximum values). As shown, the ADF performs better when the collaboration is the result of group’s ’A’ data set opposed to that of group’s ’B’ data set. Furthermore, based on the results, it is concluded that the ADF performs with higher values during the identification of SSD and DSD violations in group ’A’ data, instead of that in ’B’. In addition, standard deviation shows that dispersion of time values is higher in group ’B’ data set. This means that data points are spread out over a large range of values. It is noteworthy that the mode statistical measure in all cases is between 0 to 2 milliseconds and the mean value equal to 0 milliseconds. This is mostly due to the identification of a large number of violations. Regarding the median and maximum time values we can once again observe that are lower in group’s ’A’ data set. Figure 13 shows in a logarithmic scale a comparison of the mean and maximum decision time values, where both lines show a similar behavior, with the maximum values being 1.6% and 18.5% higher in average opposed to the equivalent mean values, in group ’A’ and ’B’ data set, respectively. Based on the analysis of the collected data, the results show that the performance is acceptable for the Grid computing paradigm, as well as for general collaboration requirements. 6. Discussion Despite the existence of a large number of proposed and implemented access control models, there are only a few, to the best of our knowledge that provide information relevant to their performance. Moreover, performance comparison among access control models seems to be a difficult task since different performance metrics are provided, if any, in each one of them. Hence, only a partial comparison of the results can be made. In (Zhang et al., 2008) a performance analysis of a usage-based security framework for collaborative systems, is presented. The test case included an analysis of a file sharing prototype system. The performance analysis have shown that ADF’s performance for updating the code of a software module 24 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 varied between 2304 to 15958 milliseconds, depending on the experiment’s input data set. Knowing that there cannot be a direct comparison between the framework in (Zhang et al., 2008) and domRBAC simulator, we examine the processing time in order to check if existing time delays of our ADF are within acceptable time limits. Hence, in regard to domRBAC’s ADF we identified a latency of 1142 milliseconds in worst cases and thus it can be concluded that such delays are within acceptable limits since the latency is significantly lower. In regard to secure inter-operation, in (Shafiq et al., 2005) there is an analysis that shows the trade-off between interoperability and autonomy for two collaborating domains. The domains consist of a maximum number of 20 roles each. Autonomy loss can be set at different levels, based on the requirements of the collaboration. Hence, autonomy loss varied from 39% to 52%, and interoperability level from 30% to 36%. However, this approach is not dynamic as in the proposed model. Instead, the merging of the individual RBAC policies into a global policy needs to be done from scratch, in order to gain the optimality criterion of maximizing inter-domain role accesses without exceeding the autonomy losses beyond an acceptable limit. Regarding the simulation results in domRBAC, the autonomy loss and inter-operation reached the level of 4% and 7.75% on average, respectively. It is noteworthy that in the simulation the data sets had significantly higher number of roles, compared to that in (Shafiq et al., 2005), and moreover that in the proposed access control model the global policy is a result of a continually changing environment. Autonomy or inter-operation thresholds are not supported in domRBAC. Therefore, based on the comparative data, we verified the efficiency of the proposed access control model in regard to its performance and provided level of autonomy loss and inter-operation. In regard to security, this is preserved and assured due to the existence of the inter-domain policy violation function. 7. Conclusions An access control model is proposed in this article for collaborative systems, as the Grid. To meet scalability, security and basic usage management requirements in access control, the proposed domRBAC model is used to support various security policies for collaborative environments. Our proposed access control model is capable of enforcing security policies among multiple domains, having each different security policies. Furthermore, domRBAC as25 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 sures a secure collaborative environment by gradually and in real-time checking for violations, which can be caused by new inter-domain role assignments. Moreover, it provides basic resource usage management for the first time in a role based approach. An implemented simulator capable of enforcing multidomain security policies demonstrated the feasibility of our access control model. A performance study shows that domRBAC can perform well even when implemented in low-end systems. Additionally, through a comparative review it is shown that the proposed access control model is able to perform better in many cases compared with existing implementations. Yet, due to design decisions that requires the maintenance of the security principle, the proposed access control model, results in relatively lower interoperability levels, yet acceptable, compared with existing solutions. In overall, compared to other similar approaches, the domRBAC model provides access control with adequate dynamics for computing systems, as the Grid, and also manages to fulfill critical requirements of modern collaborative environments. Appendix A. The XSD file <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="DomainRole_Graph"> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Organization"/> <xs:element name="DomainRole" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Organization"> <xs:complexType> <xs:sequence> <xs:element name="Org_Name" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Org_Name"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="DomainRole"> <xs:complexType> <xs:sequence> <xs:element name="Name" type="xs:string"/> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Inter_Parent_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> 26 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Inter_Child_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Intra_Parent_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Intra_Child_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="SSD_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="DSD_Role" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:element name="SR_Cardinality" type="xs:unsignedLong" minOccurs="0" maxOccurs="1"/> <xs:element name="DR_Cardinality" type="xs:unsignedLong" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Name"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Inter_Parent_Role"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Inter_Child_Role"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Intra_Parent_Role"> <xs:complexType mixed="true"/> </xs:element> 27 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 <xs:element name="Intra_Child_Role"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="SSD_Role"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="DSD_Role"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="SR_Cardinality"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="DR_Cardinality"> <xs:complexType mixed="true"/> </xs:element> </xs:schema> Appendix B. Statistical measures Appendix B.1. Group A data set Appendix B.2. Group B data set References Alfieri, R., Cecchini, R., Ciaschini, V., Dell’ Agnello, L., Frohner, A., Gianoli, A., Lorentey, K., & Spataro, F. (2004). Voms, an authorization system for virtual organizations. In Grid Computing (pp. 33–40). Springer. ANSI (2004). Ansi incits 359-2004, role based access control. Ardagna, C., De Capitani di Vimercati, S., Paraboschi, S., Pedrini, E., Samarati, P., & Verdicchio, M. (2011). Expressive and deployable access control in open web service applications. Services Computing, IEEE Transactions on, 4 , 96 –109. Benantar, M. (2005). Access Control Systems: Security, Identity Management and Trust Models. Springer-Verlag New York, Inc. Boost (2011). Boost c++ libraries. 28 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Carlstrom, B. (2004). Design and analysis of algorithms, problem set no.6 solutions. Chadwick, D. (2005). Authorisation in grid computing. Information Security Technical Report, 10 , 33–40. Chadwick, D., Otenko, A., & Ball, E. (2003). Role-based access control with x. 509 attribute certificates. Internet Computing, IEEE , 7 , 62–69. Chakrabarti, A. (2007). Grid computing security. Spinger-Verlag. Chen, L., & Crampton, J. (2007). Inter-domain role mapping and least privilege. In SACMAT ’07: Proceedings of the 12th ACM symposium on Access control models and technologies (pp. 157–162). New York, NY, USA: ACM. Chu, D. C., & Humphrey, M. (2004). Mobile ogsi.net: Grid computing on mobile devices. Grid Computing, IEEE/ACM International Workshop on, 0 , 182–191. Ferraiolo, D. F., Kuhn, D. R., & Chandramouli, R. (2003). Role-Based Access Control . Artech House, Inc. Foster, I., & Tuecke, S. (2005). Describing the elephant: The different faces of it as service. Queue, 3 , 26–29. Free Software Foundation, I. (2008). Using the gnu compiler collection. Gouglidis, A., & Mavridis, I. (2011). Role-based secure inter-operation and resource usage management in mobile grid systems. In C. Ardagna, & J. Zhou (Eds.), Information Security Theory and Practice. Security and Privacy of Mobile Devices in Wireless Communication (pp. 38–53). Springer Berlin / Heidelberg volume 6633 of Lecture Notes in Computer Science. Gouglidis, A., & Mavridis, I. (2012). Computational and data grids: Principles, applications and design. chapter Grid Access Control Models and Architectures. (pp. 217–234). IGI Global. Graphviz (2010). Graphviz - graph visualization software. Graphviz (2011). The dot language. 29 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 ISO/IEC-13568 (2002). Information technology z - formal specification notation - syntax, type system and semantics. International Standard. ITU (1995). Information technology - open systems interconnection - security frameworks for open systems: Access control framework. Jamkhedkar, P. A., Heileman, G. L., & Lamb, C. C. (2010). An interoperable usage management framework. In Proceedings of the tenth annual ACM workshop on Digital rights management DRM ’10 (pp. 73–88). New York, NY, USA: ACM. Li, N., Byun, J., & Bertino, E. (2007). A critique of the ansi standard on role-based access control. Security Privacy, IEEE , 5 , 41 –49. NetworkX (2011). Networkx. Neumann, G., & Strembeck, M. (2003). An approach to engineer and enforce context constraints in an rbac environment. In SACMAT ’03: Proceedings of the eighth ACM symposium on Access control models and technologies (pp. 65–79). New York, NY, USA: ACM. Nokia (2011). Qt - cross-platform application and ui framework. Nuutila, E. (1995). Efficient transitive closure computation in large digraphs. Ph.D. thesis Acta Polytechnica Scandinavica, Helsinki University of Technology. OASIS (2011). Oasis extensible access control markup language (xacml) tc. Pearlman, L., Welch, V., Foster, I., Kesselman, C., & Tuecke, S. (2002). A community authorization service for group collaboration. In Policies for Distributed Systems and Networks. Proceedings. Third International Workshop on (pp. 50–59). IEEE. Phan, T., Huang, L., & Dulan, C. (2002). Challenge: integrating mobile wireless devices into the computational grid. In Proceedings of the 8th annual international conference on Mobile computing and networking (p. 278). ACM. Purdom, P. (1970). A transitive closure algorithm. BIT Numerical Mathematics, 10 , 76–94. 10.1007/BF01940892. 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Racz, P., Burgos, J., Inacio, N., Morariu, C., Olmedo, V., Villagra, V., Aguiar, R., & Stiller, B. (2007). Mobility and qos support for a commercial mobile grid in akogrimo. In Mobile and Wireless Communications Summit, 2007. 16th IST (pp. 1 –5). Ravi Sandhu, V. B. (2008). The ascaa principles for next-generation rolebased access control. In Proc. 3rd International Conference on Availability, Reliability and Security (ARES) (pp. xxvii–xxxii). Barcelona, Spain volume 6. Sandhu, R., & Park, J. (2003). Usage control: A vision for next generation access control. In Computer Network Security (pp. 17–31). Springer Berlin / Heidelberg volume 2776. Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-based access control models. IEEE Computer , 29 , 38–47. Sandhu, R. S., & Samarati, P. (1994). Access control: Principles and practice. IEEE Communications Magazine, 32 , 40–48. Shafiq, B., Joshi, J. B. D., Bertino, E., & Ghafoor, A. (2005). Secure interoperation in a multidomain environment employing rbac policies. IEEE Trans. on Knowl. and Data Eng., 17 , 1557–1577. Shehab, M., Bertino, E., & Ghafoor, A. (2005). Serat: Secure role mapping technique for decentralized secure interoperability. In SACMAT ’05: Proceedings of the tenth ACM symposium on Access control models and technologies (pp. 159–167). New York, NY, USA: ACM. Thompson, M., Essiari, A., & Mudumbai, S. (2003). Certificate-based authorization policy in a pki environment. ACM Transactions on Information and System Security (TISSEC), 6 , 566–588. W3C (2005). Document object model (dom). W3C (2011). Xml technology. XML-DEV (2011). Simple api for xml. Yuan, E., & Tong, J. (2005). Attributed based access control (abac) for web services. Web Services, IEEE International Conference on, 0 , 561–569. 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Zhang, G., & Parashar, M. (2004). Dynamic context-aware access control for grid applications. In Grid Computing, 2003. Proceedings. Fourth International Workshop on (pp. 101–108). IEEE. Zhang, X., Nakae, M., Covington, M., & Sandhu, R. (2006). A usage-based authorization framework for collaborative computing systems. In Proceedings of the 11th ACM symposium on Access control models and technologies (pp. 180–189). ACM. Zhang, X., Nakae, M., Covington, M. J., & Sandhu, R. (2008). Toward a usage-based security framework for collaborative computing systems. ACM Trans. Inf. Syst. Secur., 11 , 1–36. 32 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Figure 1: The domRBAC access control model. 1. 2. 3. 4. 5. 6. ci violation() : boolean for each vertex di r ∈ TG for each adjacent vertex dj r to di r if (di r = dj r) return true return false Figure 2: Identification of cycles in role assignment Figure 3: Privilege escalation example. 33 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 1. sp violation(di rj ) : boolean 2. for each vertex di r ∈ domain i where di r ≥ di rj 3. if (TG [di rj , di r] 6= TGi [di rj , di r]) or 4. (TG [di r, di rj ] 6= TGi [di r, di rj ]) 5. return true 6. return false Figure 4: Assurance of the security principle 1. ssd violation() : boolean 2. for each SSD pair (di rm , di rn ) 3. for each vertex dr ∈ TG 4. if (dr = di rm ) 5. for each adjacent vertex d′ r to dr 6. if (d′ r = di rn )then 7. return true 8. if (dr = di rn ) 9. for each adjacent vertex d′ r to dr 10. if (d′ r = di rm )then 11. return true 12. for each SSD pair (di rm , di rn ) 13. for each vertex dr ∈ TG 14. f oundSSDRole = 0 15. for each adjacent vertex d′ r to dr 16. if (d′ r = di rm ) or (d′ r = di rn ) 17. f oundSSDRole + + 18. if f oundSSDRole = 2 then 19. return true 20. return false Figure 5: Intra-domain violation of SSD relationships 34 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 1. dsd violation() : boolean 2. for each DSD pair (di rm , di rn ) 3. for each vertex dr ∈ TG 4. if (dr = di rm ) 5. for each adjacent vertex d′ r to dr 6. if (d′ r = di rn )then 7. return true 8. if (dr = di rn ) 9. for each adjacent vertex d′ r to dr 10. if (d′ r = di rm )then 11. return true 12. for each DSD pair (di rm , di rn ) 13. for each vertex dr ∈ TG 14. f oundDSDRole = 0 15. for each adjacent vertex d′ r to dr 16. if (d′ r = di rm ) or (d′ r = di rn ) 17. f oundDSDRole + + 18. if f oundDSDRole = 2 then 19. return true 20. return false Figure 6: Intra-domain violation of DSD relationships 1. InterdomainPolicyViolation(di rndesc ) : boolean 2. return ci violation() or 3. sp violation(di rndesc ) or 4. ssd violation() or 5. dsd violation() Figure 7: Inter-domain policy violation function 35 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Figure 8: A multidomain access control policy defining interoperation between d1 and d2 . Figure 9: Overall architecture of the domRBAC simulator. 36 Figure 10: The main interface of the domRBAC simulator. 20*1000 Domains * Roles per domain 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 15*1000 10*1000 5*1000 200*100 150*100 100*100 50*100 0,00 10,00 20,00 30,00 40,00 50,00 60,00 msec Adjacency list SSD violation Transitive closure list DSD violation Cycle inheritance Maximum Decision Time Privilege escalation Figure 11: Time of computations - mean values. 37 Domains * Roles per domain 20*1000 15*1000 10*1000 5*1000 200*100 150*100 100*100 50*100 0,00 200,00 400,00 600,00 800,00 1000,00 1200,00 1400,00 msec Adjacency list SSD violation Transitive closure list DSD violation Cycle inheritance Maximum Decision Time Privilege escalation Figure 12: Time of computations - max values. 10000,00 1000,00 msec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 100,00 10,00 1,00 50*100 100*100 150*100 200*100 5*1000 10*1000 15*1000 Domains * Roles per domain Mean values Max values Figure 13: Comparison of mean and max values. 38 20*1000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Figure 14: Statistics of experiment with 50 domains of 100 roles each. Figure 15: Statistics of experiment with 100 domains of 100 roles each. Figure 16: Statistics of experiment with 150 domains of 100 roles each. Figure 17: Statistics of experiment with 200 domains of 100 roles each. 39 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Figure 18: Statistics of experiment with 5 domains of 1000 roles each. 40 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Figure 19: Statistics of experiment with 10 domains of 1000 roles each. Figure 20: Statistics of experiment with 15 domains of 1000 roles each. Figure 21: Statistics of experiment with 20 domains of 1000 roles each. 41 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Table 1: Performance evaluation of ADF’s memory usage and identified violations (5000 requests) 42 DomainsRoles per domain Role assignments SSD DSD Interdomain Adj. list (KB) 50 100 150 200 5 10 15 20 5362 10029 14979 19925 5970 10553 15456 20379 88 44 39 38 251 108 147 129 111 34 45 35 244 110 117 152 266 52 52 64 77 53 22 20 10362 20029 29979 39925 10970 20553 30456 40379 100 100 100 100 1000 1000 1000 1000 Trans. closure list (KB) 39788 62120 90448 114294 48662 65166 100485 164882 Role viol. SSD viol. DSD viol. 4565 4865 4870 4875 3947 4413 4503 4591 8 2 1 0 50 12 15 3 12 1 0 0 25 12 8 6