Towards accuracy of role-based access control configurations in component-based systems

Journal of Systems Architecture 57 (2011) 314–326

Contents lists available at ScienceDirect

Journal of Systems Architecture journal homepage: www.elsevier.com/locate/sysarc

Towards accuracy of role-based access control configurations in component-based systems Lianshan Sun a,⇑, Gang Huang b,c a

School of Electrical and Information Engineering, Shannxi University of Science and Technology, China Key Laboratory of High Confidence Software Technologies, Ministry of Education, China c School of Electronics Engineering and Computer Science, Peking University, China b

a r t i c l e

i n f o

Article history: Received 31 August 2009 Received in revised form 4 September 2010 Accepted 10 November 2010 Available online 21 November 2010 Keywords: Software architecture Access control Accuracy Component-based system

a b s t r a c t Access control is a common concern in most software applications. In component-based systems, although developers can implement access control requirements (ACRs) by simply declaring role-based access control configurations (ACCs) of components, it is still difficult for them to define and evolve ACCs accurately implementing ACRs due to the gap between the complex high-level ACRs and the voluminous ACCs enforced by underlying middleware platforms, and the ad hoc mistakes of human. This paper introduces and clarifies the concept of accuracy of ACCs relative to ACRs, and presents a set of metrics and algorithms which can be used to automatically evaluate and improve accuracy of ACCs by evaluating and reconfiguring the software architecture with ACCs. We apply our achievements in a composed e-shop application. Ó 2010 Elsevier B.V. All rights reserved.

1. Introduction Access control is the process of mediating every request to resources and data maintained by a system and determining whether the request should be granted or denied [21]. It is a common component of most software applications to achieve information security [2]. Recently, a trend is to build software applications by composing pre-fabricated components with the support of middleware platforms. Reusing pre-fabricated components can offer great savings over custom-written software. In particular, popular commercial middleware platforms, for example those compliant to J2EE and.NET, adopted the role-based access control model (RBAC) [7] and provided access control service as a reusable component. Reusing the access control service enables developers to implement access control requirements (ACRs) by simply declaring role-based access control configurations (ACCs) of component methods [24] when the software architecture of component-based systems capturing component methods and interconnections among them is available. The ACCs are enforced by the underlying middleware access control service. In this case, developers need not to write new code for access control concern and the efforts

⇑ Corresponding author. E-mail addresses: [email protected] (L. Sun), [email protected] (G. Huang). 1383-7621/$ - see front matter Ó 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.sysarc.2010.11.001

needed to implement the desired ACRs and to ensure their quality will be extremely saved. However, developers cannot simply define and evolve ACCs to accurately implement ACRs due to the inadvertent mistakes of developers and the gap between complex high-level ACRs and voluminous and cooperative low-level ACCs. Generally, ACRs are specified as a composition of objects in problem space and conform to constraints of various business policies; ACCs are specified as a composition of objects in solution space and conform to constraints of underlying middleware platforms. In problem space, ACRs state the requirements about the rights of users in organizations according to various factors, such as their roles which often model the responsibilities, seniority, and working context of users [26]. For example, an ACR of a hospital may state that all nurses in a section have rights to maintain the records of patients in all wards of that section. You can imagine that ACRs of a large hospital (or other large-scale organizations) with dozens of sections, many regulations enacted by both the hospital and various sections, hundreds and thousands of doctors and nurses who may join multiple sections and work in shifts, and even more patients with various privacy requirements, will be too complex and changeful for developers to efficiently manage and accurately implement. In solution space, component-based technologies constrains how developers implement ACRs in two ways. First, ACRs should be implemented outside the components as ACCs, such as method permissions in J2EE applications [24], due to the black-box nature of most reusable components. Second, prevailing middleware

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

platforms, such as those compliant to J2EE and.NET, can only enforce ACCs that conform to core RBAC [7].1 For example, a method permission in J2EE applications defines a set of roles and tells that users can activate any one of them to access the method. Obviously, it is not easy for developers to accurately implement the ACRs not conforming to core RBAC, for example, an ACR that a user is required to simultaneously activate multiple roles to perform a business task. Furthermore, the inadvertent mistakes of human are often inevitable and will introduce various faults in ACCs. For example, developers may spell wrong name of roles, establish wrong relations between roles and methods, or allow a role to access all methods of a component just for simplicity of configuration. In all cases, potential security risks will be introduced. In short, due to the constraints from component based technologies, the complexity and changefulness of the ACRs, the knowledge limits and the inadvertent mistakes of developers, it is very difficult for developers to develop ACCs accurately implementing ACRs. Inaccurate ACCs may lead to unpredictable security risks of information leakage, denial of service, and other negative effects, for example unnecessary performance overhead of enforcing and evaluating improper ACCs. Developers have to face the difficulties of identifying and eliminating inaccurate ACCs in large-scale component-based systems. Software architecture (SA), capturing components and connections among them, is a high-level abstraction of software system and often serves as the blueprint of composing pre-fabricated components in component-based development [16]. Software architecture is a suitable place to analyze and eliminate inaccurate ACCs because ACRs are actually special quality attribute requirements and existing research achievements have shown that software architecture is a suitable place for implementing and analyzing quality attribute requirements before delving into the detail of implementation [9,25]. Various software architecture analysis methods [6], such as the software architecture analysis method (SAAM) and the architecture trade-off analysis method (ATAM), can be employed to do this job. These methods are humanintensive and are initially designed to support development starting from scratch. However, in component-based systems, ACCs cannot be defined or evaluated until some artifacts including the requirements specification, the software architecture, and even the traceability among them become available because ACCs are actually one kind of add-on properties of components2 that had been (at least conceptually) composed together in software architecture. With these available artifacts as inputs, it is possible to develop more automated methods to analyze and reconfigure software architecture with ACCs to identify and eliminate inaccurate ACCs. This paper introduces and clarifies the concept of accuracy of ACCs relative to ACRs, and formally defines a set of metrics and algorithms, which can be used to automatically evaluate and improve accuracy of ACCs. The automation is enabled by the similar structure of ACRs and ACCs, and by the availability of artifacts produced before defining and evaluating ACCs. By our achievements, developers will be relieved from the difficult and time-consuming tasks of evaluating and reconfiguring voluminous ACCs in largescale component-based systems. We apply our achievements in a composed e-shop application.

1 In core RBAC, roles are not organized in a hierarchy. Each role is defined as a set of rights independent from other roles. The users of a system are assigned one or more roles and rights of a user are the union of sets of rights of all roles that user currently belongs to [7]. 2 The so-called add-on properties of components here refer to the properties that can be defined and changed after components are implemented, composed and even deployed.

315

The rest of paper is organized as follows: Section 2 founds the formal basis for exploring accuracy of ACCs relative to ACRs, and states possible problems in handling ACCs and ad hoc solutions in an illustrative example. Section 3 first clarifies prerequisites for automatically evaluating and improving accuracy of ACCs, then defines qualitatively the concept of accuracy of ACCs and clarifies its nature by defining a set of metrics based on the concept of access path to business tasks, and finally presents algorithms for removing inaccurate ACCs. Section 4 presents a reference process of using our achievements. Section 5 applies our achievements in an composed e-shop application. Section 6 discusses our work against related work. Finally, we conclude the paper and envision the future. 2. Problem statements In this section, we first formalize ACRs in problem space and ACCs in solution space. Both of them are the basis of exploring accuracy of ACCs relative to ACRs. Then we state possible problems in handling ACCs and intuitive solutions within an imagined example. 2.1. Access control requirements An organization has a set of business tasks that should be performed by its employees and it needs to define a set of ACRs about which employees can perform what business tasks respecting some organization-wide regulations. The business task is the minimal unit of access rights which are allocated to various employees. Generally, an organization defines ACRs according to the roles of its employees, that is, the responsibility, seniority, and working context of employees [26]. To put these facts formally, we define the definitions (2.1)–(2.6).

O :¼ ðB; RÞ

ð2:1Þ

jb  is a business task in the org:g B :¼ fb R :¼ fr i ji ¼ 1; . . . ; n; n P 1g

ð2:2Þ ð2:3Þ

2R :¼ fRs jRs # Rg

ð2:4Þ

2R

2

R

:¼ fHjH # 2 g

 b  2 B; H 2 22R ;  ja  ¼ ðH; bÞ; ACR :¼ fa

ð2:5Þ ð2:6Þ

H ¼ fRi ji ¼ 1; . . . ; kg; Ri # R; k P 1; Ri ¼ fr ij jj ¼ 1; . . . ; ni g; ni P 1g From the perspective of access rights allocation, an organization O consists of a set of business tasks denoted as B and a set of roles denoted as R, each of which can be activated by one or more users in the organization; 2R is the power set of R; each element of 2R is a subset of R; ACR denotes the set of ACRs of an organization and  of ACR is actually a tuple of a set of role sets H # 2R each element a  2 B; we call an element Rs of a :H as a singleton role and a task b set if and only if it includes only one role as its element ðjRs j ¼ 1Þ, as a non-singleton role set if and only if it includes more than one  denotes that users can perform roles as its elements ðjRs j > 1Þ; a  if and only if they simultaneously activate all roles in the task b  deone of role set Ri in H. For example, an ACR ðffr 1 g; fr2 ; r3 gg; bÞ  by activating r 1 or by simulnotes that users can perform the task b taneously activating r 2 and r3 . In fact, ACRs formalized in definition (2.6) conform to NIST  are singleton RBAC model [21]. First, if all elements of H of an ACR a role set, the ACR conform to RBAC 0 . Second, if there exists one ele:H is non-singleton role set, that is, it includes two or ment Rs of a more roles, the ACR conform to RBAC 1 because some users can activate a role inheriting all roles in Rs to perform their tasks. Furthermore, ACRs, as a special kind of organization security

316

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

policy, are often required to conform to various organization authorization constraints [4] (for example two users cannot activate one specific role). The issues of checking the conformance of ACRs to authorization constraints have been well-discussed in literature [4,22]. Finally, we assume that all ACRs of an organization are defined in a way respecting global authorization constraints, that is, they conform to RBAC 2 . In addition, we define a function (2.7) to be used in the rest of this paper. R

R

c : 22 ! 22 ; cðHÞ ¼ fRs jRs 2 H; 9= Rj 2 H : Rj  Rs g:

ð2:7Þ R

The function cðÞ (2.7) compresses the set of role sets H 2 22 by removing a role set Rk from H when one proper subset Rj of Rk is also the element of H. For example, if we have H ¼ ffr2 g; fr 2 ; r 3 gg, then we have cðHÞ ¼ ffr2 gg. The function cðÞ is used to remove redundant role sets allowed by ACRs. For example, for an ACR  if users can perform the business task b  by simulta ¼ ðH; bÞ, a neously activating roles in a role set Rj of H, then they must be able  that by simultaneously activating all roles in the role to perform b set Rk .

We assume that business tasks in B of an organization are enabled by a component-based system S, which is composed from a set of components C. Components in C are characterized by their externally visible methods M, and are interconnected with each other via inter-component method invocations L. To put formally, we define the definitions (2.8)–(2.11).

S :¼ ðC; LÞ

ð2:8Þ

C :¼ fCjC ¼ fmi ji ¼ 1; . . . ; ng; n P 1; mi is a externally-visible method of compoment Cg

ð2:9Þ

ð2:15Þ

2.3. An illustrative example  in a component ¼ ðH; bÞ Intuitively, implementing an ACR a Þ to protect all compobased system is to define a set of ACCs T 2 ða  We illustrate why the intuition does nent methods in the set T 1 ðbÞ. not work as we hope by an imagined example as follows. As shown in Fig. 1, suppose we have an imagined componentbased system with seven component methods (denoted by circles in Fig. 1) interconnected via method invocations (denoted by ar0 ; b 1 , rows in Fig. 1). This system enables three business tasks b 2 , which are, respectively, implemented as fm0 ; m4 g; fm1 g, and b 0 by and fm3 g. By fm0 ; m4 g, we means that users can perform b invoking either the component method m0 or m4 . To put formally, we have

ð2:16Þ

Obviously, as shown in Fig. 1, users that need to perform any 0 ; b 1 ; b 2 g must have rights to access one or more business task in fb sets of component methods in the area ðp1  p4 Þ enclosed by the dashed line. For example, users that need to perform the business 1 must have the rights to access component methods m1 and task b 2 the rights to acm0 in p3 because m1 calls m0 , the business task b cess component methods m2 ; m3 ; m5 , and m0 in p4 because they can 0 only indirectly invoke m3 by invoking m2 , and the business task b

ð2:10Þ

the rights to access component method m4 in p1 , or component methods m6 ; m0 in p2 , or component methods in p3 or p4 . Suppose we have three ACRs

ð2:11Þ

0 Þ; 0 ¼ ðffr 4 gg; b a

Each connection l ¼ ðh; tÞ in L denotes an invocation relation between the method h (the caller) of component C1 and the method t (the callee) of component C2 . ACCs in component-based systems are attached to externallyvisible component methods and can be enforced by the underlying middleware access control service [24,28]. In fact, the externally visible component method is the minimal unit of defining ACCs in component-based systems. We formally define the set of all possible ACCs in a component-based system as the definition (2.12). An ACC c ¼ ðRs ; mÞ means that users activating any one of roles in Rs will be allowed to access the component method m while users activating none of roles in Rs will be denied to access m. For example, one ACC c ¼ ðfr1 ; r2 g; mÞ means that users can access the component method m by activating either r1 or r2 while users activating nether r1 nor r2 will be denied to access m. When no ACC is defined for a component method, any access to it will be allowed.

C :¼ fcjc ¼ ðRs ; mÞ; m 2 M; Rs # Rg

ÞÞ: ACC ¼ [a 2 ACR ðT 2 ða

0 Þ ¼ fm0 ; m4 g; T 1 ðb 1 Þ ¼ fm1 g; and T 1 ðb 2 Þ ¼ fm3 g: T 1 ðb

2.2. Access control configurations

M :¼ fmjm 2 C; C 2 Cg L :¼ fljl ¼ ðh; tÞ; h 2 C1 ; t 2 C2 ; C1 ; C2 2 Cg

 by do not depend on each other. That means users can perform b   accessing any method in T 1 ðbÞ. The mapping T 2 ðÞ maps an ACR a Þ implementing a . Accordingly, all ACCs of a to a set of ACCs T 2 ða component-based system (denoted as ACC) is actually the union , that is, of the set of ACCs implementing each ACR a

to be implemented. According to these ACRs, users can access the 0 only by activating the role r 4 , the business task business task b  b1 by activating either the role r0 or the role r1 , and the business 2 by simultaneously activating both the role r 2 and the role r3 . task b Now we start to implement the three ACRs (2.17) in the illustra0 . We can simply detive example. First, we implement the ACR a 0 . In fact, another fine an ACC as c0 ¼ ðfr 4 g; m0 Þ to implement a ACC c1 ¼ ðfr4 g; m4 Þ should also be defined. We neglect it here to simulate an ad hoc mistakes of developers. 1 . Obviously, after defining c0 at m0 , Second, we turn to the ACR a 1 by simply defining an ACC as we cannot implement a c2 ¼ ðfr 0 ; r 1 g; m1 Þ because users activating either r 0 or r 1 will be blocked by the ACC c0 . That is to say, the implementation of one ACR may interfere with the implementation of other ACRs. One feasible solution is to redefine the ACC c0 as c3 ¼ ðfr 4 ; r 0 ; r 1 g; m0 Þ besides defining c2 ¼ ðfr0 ; r1 g; m1 Þ. In this case, users activating

ð2:12Þ

Based on the definitions ((2.1)–(2.6) and the definitions (2.8)– (2.12)), we formalize two mappings T 1 ðÞ (2.13) and T 2 ðÞ (2.14) as follows:

T 1 : B ! 2M

ð2:13Þ

T 2 : ACR ! 2C

ð2:14Þ

 to a set of component The mapping T 1 ðÞ maps a business task b  implementing b.  The component methods in T 1 ðbÞ  methods T 1 ðbÞ

ð2:17Þ

1 Þ; and a 2 Þ: 1 ¼ ðffr 0 g; fr 1 gg; b 2 ¼ ðffr 2 ; r3 gg; b a

Fig. 1. The architecture of a component-based system.

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

0 by invoking the component the role r 4 are denied to perform b 1 , this is reasonmethods m1 and m0 in p3 . From the perspective of a 0 are not allowed to perable because users authorized to perform b 1 according to the ACRs a 0 and a 1 ; meanwhile, from the form b 0 , the redefinition of c0 as c3 could be still acceptperspective of a 0 can still successfully able because users who need to perform b  perform b0 by accessing component methods in p1 , p2 , or p4 . 2 . Obviously, we cannot implement At last, we turn to the ACR a 2 by simply defining an ACC c4 ¼ ðfr 2 ; r 3 g; m3 Þ because it will ala low users activating either r2 or r3 to access the component method m2 . Besides illegitimate users will be allowed to perform the 2 by c4 , legitimate users will be blocked to perform business task b 2 by c3 . In fact, one feasible solution is to define two ACCs b c5 ¼ ðfr2 g; m2 Þ and c6 ¼ ðfr 3 g; m3 Þ while to redefine c3 as c7 ¼ ðfr4 ; r0 ; r1 ; r2 ; r3 g; m0 Þ. The ACCs c5 and c6 will deny all users not simultaneously activating r2 and r 3 to perform the business 2 by preventing them from accessing component methods task b m2 or m3 . To be noticed, users activating the role r4 are blocked 0 by accessing component methods m2 ; m3 ; m0 , and to perform b 0 are not alm5 in p4 . This is reasonable because users performing b 2 according to the ACRs a 0 and a 2 . lowed to perform b Up to now, with mappings in Eq. (2.16), ACRs in Eq. (2.17), and the detailed software architecture of the illustrative example shown in Fig. 1 as inputs, we have manually defined ACCs as Table 1. Worth to note, Table 1 includes improper ACCs fc0 ; c3 ; c4 g, which, as we have discussed, will lead to unwanted results. Only ACCs in fc7 ; c2 ; c5 ; c6 g is the final set of accepted ACCs of the example. Various problems have occurred during defining ACCs for the example, and we, on behalf of developers, have coined some ad hoc solutions for them. Most of these problems come from the following two facts.  is actually implemented as one or more  ¼ ðH; bÞ (I1) An ACR a 1 is implemented as coordinated ACCs. For example, the a c2 and c7 . (I2) The implementation of one ACR could influence the implementation of another ACR because one ACC may be an element of the implementations of multiple ACRs. For 0 ; a 1 , example, c7 is an element in the implementations of a 2 . and a The illustrative example is simple and the task of defining and evolving ACCs according to ACRs is still feasible for human. However, due to the above two insights I1 and I2, and the fact that the volume of ACRs and ACCs in large-scale component-based systems will be much larger than those of the simple example here, it is reasonable to extrapolate that it will be very difficult for developers to avoid, identify, and eliminate the possible problems occurred in defining ACCs implementing ACRs. In addition, the inevitable mistakes of human will make things get even worse than what we imagined. 3. Accuracy of ACCs: definition, evaluation and improvement Qualitatively, we define accuracy of ACCs as the degree to which the set of ACCs in a component-based system implements the desired ACRs. By this definition, accuracy of ACCs is actually an abstract, obscure, and subjective quality attribute of component-based

systems. Developers need to understand its nature and need more automated methods to evaluate and improve accuracy of ACCs than traditional human-intensive software architecture analysis methods due to the complexity of ACRs and software architecture with ACCs in large-scale component-based systems. In that, our goals in this paper are to help developers: (1) to understand the nature of accuracy of ACCs; (2) to automatically evaluate the accuracy of ACCs of component-based systems, and if necessary, (3) to improve accuracy of ACCs by automatically reconfiguring ACCs and even software architecture of component-based systems. In the rest of this section, we first analyze the prerequisites for achieving our goals. Second, we introduce the concept of access path to business task to form the basis of clarifying the nature of accuracy of ACCs. Third, we define a set of metrics to clarify the nature of accuracy of ACCs and categorize accuracy of ACCs into three grades on the basis of these metrics. Finally, we develop algorithms for improving accuracy of ACCs in large-scale component based systems. 3.1. Prerequisites Obviously, to evaluate ACCs against ACRs, both of them, as well as the traceability links (formulated as mapping 2.14) among them, should be available too. Furthermore, in component-based systems, ACCs as add-on properties associated to component methods can only be defined after the component composition, or at least the conceptual software architecture of the component composition, is available. In that, it is reasonable to assume that the functional requirements, the detailed software architecture, and the traceability links (formalized in mappings 2.13) among them (often produced during the first round design activities) are available and can be used as inputs to define, evaluate, and reconfigure ACCs. In fact, the business tasks, as the minimal unit of protected resources at the business level, are actually user-visible functions implemented by the target component-based system, and should have been captured as the functional requirements otherwise they will not be enabled by the target system. In that, the functional requirements must be available before defining or evolving ACCs. In this sense, ACRs can be viewed as the constraints on some functional requirements of the target system. We have formulated the functional requirements as a set of business tasks as the definition (2.2). Software architecture of component-based systems is actually a set of components connected with each other via inter-component method invocations among their external visible methods. These invocations among component methods are often specified in the detailed software architecture, and can be obtained from various ways, including the pre-produced design model or the result of source code analysis [10] of white-box components, or even the result of runtime reflection [12]. Software architecture may be configured with various add-on properties, including ACCs. The software architecture with ACCs is used as an input for defining the metrics and algorithms in the rest of this section, and are denoted as the formula (3.1), where C (formula (2.9)) is the set of components and L (formula (2.11)) is the set of inter-component methods invocations. The ACC # C (formula (2.12)) denotes all ACCs of a component-based system.

SA :¼ ðC; L; ACCÞ: Table 1 ACCs defined in developing the example. c0 c3 c5 c7

¼ ðfr 4 g; m0 Þ  0Þ ¼ ðfr 4 ; r0 ; r1 g; m ¼ ðfr 2 g; m2 Þ ¼ ðfr 4 ; r0 ; r1 ; r 2 ; r3 g; m0 Þ

c2 ¼ ðfr 0 ; r1 g; m1 Þ c4 ¼ ðfr 2 ; r3 g; m3 Þ c6 ¼ ðfr 3 g; m3 Þ

317

ð3:1Þ

The business tasks can be automatically traced to component methods involved in implementing and using them via the traceability links and invocations among component methods. The roles specified in ACCs for component methods can be automatically evaluated and reconfigured according to the role sets prescribed in ACRs for business tasks.

318

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

PreOrderðmÞ :¼ ðM; RÞ;

3.2. Access path Before we start to define metrics and algorithms for evaluating and improving accuracy of ACCs, we first introduce the concept of access path to business task. As shown in the illustrative example, in component-based sys is finally implemented as one or more comtems, a business task b ponent methods in the set T 1 ðbÞ. Users can perform a business task  by sequentially invoking one or more chains of component methb ods which call directly or indirectly one of component methods in T 1 ðbÞ. Each chain of component methods is called an access path to the business task. An access path to a business task is actually a list of component methods that are sequentially invoked in performing the business task. The first component method of an access path to a business task  is its head, which is the entrance of users accessing the software b  All component methods accessed in perapplication to perform b. forming one business task form one or more directed trees, whose nodes and edges are the component methods and inter-component method invocations, respectively. The root of each tree is the head of an access path. In that, an access path to a business task can be computed as the result of traversing one of these directed trees in pre-order. For example, in Fig. 1, component methods m2 ; m3 ; m5 , 2 is and m0 form a directed tree, and the access path to b m2 < m3 < m0 < m5 , where we use the operator < to denote the order in which the methods are invoked.  Furthermore, in some software applications, one business task b can be accessed via multiple access paths. For example, in Fig. 1, b0 can be accessed via either access path m1 < m0 or access path  must include at least one compom6 < m0 . Each access path to b  Each user request to perform a business task nent method in T 1 ðbÞ.  are evaluated by access control service according to all ACCs deb  before it is finally fined at component methods on access paths to b allowed. If it is denied by one of ACCs on the access path, users are denied to perform the corresponding business task. Obviously, to define ACCs accurately implementing ACRs, developers need to compute all access paths to each of business tasks. If the knowledge about component methods and invocations among them is available, all access paths to a business task are computable according to the formula (3.5), which uses the functions Head(), Tree() and PreOrder() defined in formula (3.2), (3.3), and (3.4). The function Head(m) returns a set of methods. Each of them is the head of an access path passing the component method m, which is not called by any other component methods in M and calls directly or indirectly component method m via a series of method invocations li 2 L; 1 6 i 6 n. The function Tree(m) returns a tree, whose root is the method m, and whose nodes are component methods called directly or indirectly by m, and whose edges are method invocations. The function PreOrder(m) returns a list of component methods, which is the result of traversing the tree TreeðmÞ in pre-order. According to the definition (3.4) and the definition (3.5), an access path P ¼ ðfm1 ; . . . ; mn g; fhmi ; miþ1 ij i ¼ 1; . . . ; n  1gÞ is actually a totally ordered set, and we concisely form it as P ¼ m1 < m2 <    < mn , where the operator < denotes the order of component methods are invoked.

HeadðmÞ :¼ fxjm; x 2 M; 9 = l 2 L : l:t ¼ x and

ð3:2Þ

R ¼ fhmi ; miþ1 ij mi 2 M; i ¼ 1; . . . ; jV j  1g; where m1 ¼ m; V ¼ TreeðmÞ:V; hmi ; miþ1 i means that mi is invoked just before miþ1 is invoked:  :¼ fPjP ¼ PreOrderðhÞ; where PðbÞ

li :t ¼ liþ1 :h; i ¼ 1; . . . ; n  1g: V ¼ fxjx ¼ m or 9fl1 ; . . . ; li ; liþ1 ; . . . ; ln g # L : l1 :h ¼ m; ln :t ¼ x; li :t ¼ liþ1 :h; where

ð3:3Þ

For example, in the illustrative example, we can compute the 2 by the function PðÞ (3.5) in the following steps: access paths to b 2 Þ ¼ fm3 g (1) According to the mapping T 1 , we have T 1 ðb (formula 2.16); (2) According to the software architecture shown in Fig. 1, we have Headðm3 Þ ¼ fm2 g; (3) According to the software architecture shown in Fig. 1, we have Treeðm2 Þ ¼ ðV; EÞ, where V ¼ fm2 ; m3 ; m0 ; m5 g and E ¼ fhm2 ; m3 i; hm2 ; m5 i; hm3 ; m0 ig; 2 Þ ¼ PreOrderðTreeðm2 ÞÞ ¼ fm2 < m3 < (4) Finally, we have Pðb m0 < m5 g;  the asymptotic time complexity of  ¼ ðH; bÞ, For an ACR a  depends closely on computing access paths to the business task b several metrics on software architecture, including the average of fan-in and fan-out of a component method, the average numbers of methods in a method call tree, but not directly on the number of components, methods, and invocations. In that, by designing software architecture properly, the asymptotic time complexity of computing access paths will not increase along with the increasing scale of component-based systems and can be denoted as Oð1Þ.  includes the set of compoThe access paths to a business task b nent methods that can be configured with ACCs to implement the  We can define a function to compute the set of con ¼ ðH; bÞ. ACR a  as the formula (3.6). figurable methods of a

K : ACR ! 2M ; [ KðaÞ ¼ P:M

ð3:6Þ

 :bÞ P 2 Pða

Futhermore, if we have ACCs defined on an access path to a business task, we can compute the set of role sets that users are required to simultaneously activate to perform the business task. Þ and Rða Þ, which will To do this, we define two functions RP ða be used in defining the metrics and algorithms for evaluating and improving accuracy of ACCs in the rest of this section. For an  the function RP ða  ¼ ðH; bÞ, Þ defined in formula (3.8) comACR a putes the set of role sets that users can activate to perform the  via the access path P 2 Pða   :b :bÞ. business task a Þ and Rða Þ, we define a function T P2 ða Þ(3.7) Before defining RP ða to compute the set ACCs attached to component methods on an ac ACCs in T P ða :bÞ. Þ collaborate closely with each cess path P 2 Pða 2  via  :b other to allow or deny users to perform the business task a the access path P.

 Þ :¼ fcjc 2 T 2 ða Þ; c:m 2 P:M; P 2 Pða :bÞg; T P2 ða [ P Þ ¼ Þ: T 2 ða and obviously; T 2 ða Y

Þ :¼ c RP ða

! c:Rs :

ð3:7Þ

 :bÞ P 2 Pða

ð3:8Þ

Þ c 2 T P ða 2

Þ :¼ Rða

[

Þ: RP ða

ð3:9Þ

 :bÞ P 2 Pða

m; x 2 M; i ¼ 1; . . . ; n  1g; E ¼ fljl ¼ ðh; tÞ 2 L; l:h; l:t 2 Vg:

ð3:5Þ

  and m  2 T 1 ðbÞg: h 2 HeadðmÞ

9fl1 ; . . . ; li ; liþ1 ; . . . ; ln g # L : l1 :h ¼ x; ln :t ¼ m; and TreeðmÞ :¼ ðV; EÞ; where

ð3:4Þ

M ¼ fmi jmi 2 V; i ¼ 1; . . . ; jV jg; and

Q

Þ; cðÞ is defined as formula 2.7; the operator In the function RP ða is used to compute the cartesian product of multiple role sets

319

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

Þ. Here, each element (a tuple of roles) allowed by each ACC in T P2 ða of the cartesian product set is in turn viewed as a set of roles, which Þ means that takes the item in the tuple as its element. That is, RP ða  by activating a role that allowed  :b users can use the business task a Þ, or by simultaneously activating by each ACC in the set T P2 ða multiple roles, at least one of which will be allowed by any ACC Þ. in T P2 ða Þ defined in formula (3.9) computes the set of The function Rða  via  :b role sets that users can activate to perform the business task a  :bÞ. all access paths in Pða 2 in the example in subsection (2.3), we can For example, for a get Table 2, which lists the intermediary results of computing 2 Þ, according to the available knowledge shown in the Rða Eqs. (2.16), (2.17), and Table 1.  we can define a function  ¼ ðH; bÞ, For a role set Rs and an ACR a Þ to judge whether users simultaneously activating roles in dðRs ; a  via the Þ ¼ 1 holds) to perform a  :b Rs are allowed ( when dðRs ; a  or not (when dðRs ; a :bÞ Þ ¼ 0 holds). access paths in Pða

d : 2R  ACR ! f1; 0g; Þ ¼ dðRs ; a



ð3:10Þ

Þ; 1; Rs 2 Rða  0; Rs R RðaÞ:

3.3. Metrics for evaluation In this subsection, we formulate five metrics for evaluating accuracy of ACCs relative to ACRs in the symbols in set theory and basic arithmetic to ensure their calculability by only inputs that are assumed to be available (see Section 3.1). First, some access paths to business tasks may be not configured with ACCs. As a result, any user can access the protected business tasks via these uncontrolled paths. The set of uncontrolled access  can be computed by the metric UPða Þ paths related to any ACR a (3.11) and all uncontrolled paths related to a set of ACRs A can be computed by the metric UPðAÞ (3.12). For example, in the illus0 is trative example, the access path ðfm4 g; /Þ to the business task b an uncontrolled path.

 Þ :¼ fPjT P2 ða Þ ¼ /; P 2 Pða :bÞg: UPða [ Þ: UPða UPðAÞ :¼

ð3:11Þ ð3:12Þ

2A a

–Second, inaccurate ACCs defined on some access paths may block legitimate users to perform the corresponding business tasks. Legitimate users are blocked mainly because some legitimate role sets are overlooked during defining ACCs. To evaluate this type of inacÞ (3.13) to compute the curate ACCs, we define a metric Ov Rolesða  ða :HÞ while set of overlooked role sets that are allowed by the ACR a ÞÞ implementing are not in the set of role sets allowed by ACCs ðT 2 ða . The metric Ov RolesðAÞ computes the overlooked role sets related a to a set of ACRs A. For example, in the illustrative example, 2 Þ in according to ACRs in definition (2.17) and the value of Rða 2 Þ ¼ a 2 :H n Rða 2 Þ ¼ ffr 2 ; r3 gg n ffr2 ; r 3 gg ¼ /. Table 2, Ov erRolesða 2 . That means that there no overlooked role sets of a

Table 2 2 Þ. Intermediary results of computing Rða  ¼ Pðb  Þ 2 :bÞ Pða 2 2 Þ T P2 ða Q c:Rs Þ   c 2 T P ða 2

Q

cð

c:Rs Þ    c 2 TP 2 ðaÞ

2 Þ 2 Þ ¼ RP ða Rða

¼ fP ¼ m2 < m3 < m0 < m5 g ¼ fc5 ; c6 ;  c7 g ¼ ffr 2 ; r3 g; fr2 ; r3 ; r 4 g; fr2 ; r3 ; r0 g; fr2 ; r 3 ; r 1 gg ¼ ffr 2 ; r3 gg ¼ ffr 2 ; r3 gg

Þ :¼ fRs jRs 2 a :H; dðRs ; a Þ ¼ 0g: Ov Rolesða :H n Rða Þ: :¼ a [ Þ: Ov RolesðAÞ :¼ Ov Rolesða

ð3:13Þ ð3:14Þ

2A a

Third, ACCs defined on some access paths may allow illegitimate users to perform some business tasks. Illegitimate users are allowed mainly because some illegitimate role sets not allowed by ACRs are finally allowed by ACCs. As a result, users can perform the corresponding business tasks which are not their duty by activating these redundant role sets. To evaluate this type of inaccuÞ (3.15) to compute the rate ACCs, we define a metric RdRolesða  while set of redundant role sets that are not allowed by the ACR a ÞÞ implementing a . Obviously, are allowed by the set of ACCs ðT 2 ða 2 in the illustrative example, no redundant role sets are introfor a 2 . The metric RdRolesðAÞ computes duced by ACCs implementing a the set of redundant role sets related to a set of ACRs A.

Þ :¼ fRs jRs R a :H; dðRs ; a Þ ¼ 1g: RdRolesða Þ n a :H: :¼ Rða

ð3:15Þ

Þ: RdRolesðAÞ :¼ [a 2 A RdRolesða

ð3:16Þ

Fourth, in addition to allowing and blocking all users to access corresponding business tasks as prescribed by ACRs, ACCs may allow users activating some role sets to access part of methods on access paths to business tasks. We call these role sets as partly allowed role sets. Users activating partly allowed role sets are actually assigned unnecessary rights for their duty. The more partly allowed role sets are, the higher the potential security risks are. For , the set of partly allowed role sets on an access path an ACR a  can be computed by the metric PaRolesP ða :bÞ Þ (3.17). P 2 Pða  can be computed The set of partly allowed role sets for an ACR a Þ (3.18). by the metric PaRolesða Þ (3.17), C is a proper subset of T P2 ða Þ; for any In PaRolesP ða Þ n C and c 2 C, we have c:m < c:m that means the ACC c 2 T P2 ða c will be evaluated before the ACC c is evaluated when handling  cðQ :b;  user requests to business task a  c 2 C c :Rs Þ computes all role sets allowed by the ACCs in C. In that, the set of role sets allowed Þ form the set of partly by ACCs in C while blocked by ACCs in T P2 ða allowed role sets on P. For example, in the example in Section 2.3, users activating only the role r2 are allowed to access the component method m2 while are blocked to access all component meth2 . In this case, the ods on the access path to the business task b malicious users activating r2 may attack the software systems by various means, for example, injecting malicious SQL statements3 into the software applications.

Þ :¼ [CT P ðaÞ ðcð PaRolesP ða 2

Y

c:Rs Þ n RP ðaÞÞ;

ð3:17Þ

c 2 C

8c 2 T P2 ðaÞ n C; c 2 C : c:m < c:m: Þ :¼ PaRolesða

[

Þ: PaRolesP ða

ð3:18Þ

 :bÞ P 2 Pða

PaRolesðAÞ :¼

[

Þ: PaRolesða

ð3:19Þ

2A a

Fifth, there may be multiple ACCs defined on access paths to business tasks. Some of them may be redundant or allowing redundant roles. We call them as redundant ACCs, which will introduce unnecessary performance overhead and make maintenance more Þ (3.20), an ACC c on an difficult. According to the function WP ðc; a  is removable if and only if all users it al:bÞ access path P 2 Pða lowed can be allowed by an ACC y, that is, c:Rs # y:Rs , and all users it blocked can be blocked by an ACC x, that is,  x:Rs # c:Rs ; An ACC c is condensable if and only if removing some allowed roles in c:Rs will not violate any ACRs. 3

http://en.wikipedia.org/wiki/sql_injection

320

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

8 Þ; x–c; y–c : 1; 9x; y 2 T P2 ða > > > > > < x:Rs # c:Rs # y:Rs : WP ðc; aÞ :¼ 2; 9R1  c:Rs : c0 ¼ ðR1 ; c:mÞ > > > > can safely replace c: > : 0; otherwise:

ð3:20Þ Fig. 2. The accuracy grades of ACCs.

, the set of candidates of removable ACCs on an acFor an ACR a  can be computed by the formula RdACC P ða :bÞ Þ cess path P 2 Pða (3.21). The set of candidates of removable ACCs implementing  can be computed by the formula RdACCða Þ (3.22). the ACR a

Þ :¼ fcjc 2 T P2 ða Þ; WP ðc; a Þ ¼ 1g: RdACC P ða [ Þ :¼ Þ: RdACCða RdACC P ða

ð3:21Þ ð3:22Þ

 :bÞ p 2 Pða

RdACCðAÞ :¼

[

Þ: RdACCða

ð3:23Þ

2A a

, the set of candidates of condensable ACCs on an For an ACR a  can be computed by the formula (3.24). :bÞ access path P 2 Pða The set of candidates of condensable ACCs implementing the ACR  can be computed by the formula CdACCða Þ (3.25). For example,in a the example in Section 2.3, the ACC c7 is condensable because it can be condensed from c7 ¼ ðfr 4 ; r 0 ; r 1 ; r 2 ; r 3 g; m0 Þ to c8 ¼ ðfr 4 ; r 0 ; r1 ; r2 g; m0 Þ or c9 ¼ ðfr 4 ; r 0 ; r 1 ; r 3 g; m0 Þ without violating any ACRs.

Þ :¼ fcjc 2 T P2 ða Þ; WP ðc; a Þ ¼ 2g: CdACC P ða [ Þ: Þ :¼ CdACC P ða CdACCða

ð3:24Þ ð3:25Þ

 :bÞ p 2 Pða

CdACCðAÞ :¼

[

Þ: CdACCða

ð3:26Þ

2A a

In summary, the metrics defined here can be used to identify problems ranging from the conformance of ACCs against ACRs (whether all access paths are controlled as prescribed by ACRs) to the quality of ACCs (whether ACCs will introduce partly allowed role sets, and whether ACCs are redundant). 3.4. Grades of accuracy of ACCs With the metrics defined in Section 3.3, we can categorize the ACC (2.15) implementing the ACR(2.6) of a component-based system into three grades concerning its accuracy. In this way, the qualitative concept of accuracy of ACCs can be quantified. The relations among these grades are depicted in Fig. 2. G0 Inaccurate. The ACC is ranked as G0 if and only if UPðACRÞ–/; Ov RolesðACRÞ–/, or RdRolesðACRÞ–/. G1 Sub-Accurate. Over G0 , the ACC is ranked as G1 if and only if we have PaRolesðACRÞ–/; RdACCðACRÞ–/, or CdACCðACRÞ– /. G2 Accurate. Over G1 , the ACC is ranked as G2 if and only if we have PaRolesðACRÞ ¼ /, RdACCðACRÞ ¼ /, and CdACC ðACRÞ ¼ /. The Inaccurate ACC does not allow or deny users to perform business tasks in B as prescribed by the ACR and is not tolerable. The Sub-Accurate ACC does allow or deny users to perform business tasks in B as prescribed by the ACR. However, it may still introduce partly allowed role sets, redundant ACCs, or condensable ACCs. Specifically, we can categorize ACC in G1 into two sub-categories G11 and G12 as follows. In addition, ACCs in grade G1 that introduce both types of inaccurate ACCs ranked as G11 and G12 at the same time are denoted as the shadow area in Fig. 2. The Sub-Accurate ACC is tolerable and is often tolerated when the cost of making it accurate is too high. G11 Sub-Accurate ACCs with partly allowed roles. The ACC in the grade G1 is ranked as G11 if and only if we have PaRoles ðACRÞ–/.

G12 Sub-Accurate ACCs with redundant ACCs or condensable ACCs. The ACC in the grade G1 is ranked as G12 if and only if we have RdACCðACRÞ–/ or CdACCðACRÞ–/. Generally, it is difficult to develop Accurate ACCs in a largescale component-based system. Developers need to evaluate accuracy of ACCs relative to the desired ACRs and to ensure accuracy of ACCs to be acceptable during the process of developing and evolving the system. 3.5. Algorithms of reconfiguring ACCs for one ACR Both this subsection and the next subsection devote to the rationale and algorithms of improving accuracy of ACCs relative to ACRs. This section presents the algorithms for improving accu  ¼ ðH; bÞ. racy of ACCs implementing only one ACR a 3.5.1. Removing uncontrolled paths Þ is to define ACCs Eliminating an uncontrolled path P 2 UPða :H while to block all role sets not in on P to allow role sets in a :H. We formulate an Algorithm 3.5.1 as follows for this purpose. a We illustrate the algorithm by several examples. First, if we  ¼ ðffr1 g; have an ACR allowing only singleton role sets, such as a  and an uncontrolled path P ¼ m0 < m1 , the Algorithm fr2 gg; bÞ, 3.5.1 will define an ACC as c1 ¼ ðfr 1 ; r 2 g; m0 Þ or c2 ¼ ðfr 1 ; r 2 g; m1 Þ Þ. to remove P from UPða Second, if we have an ACR allowing only one non-singleton role  and an uncontrolled path P ¼ m0 <  ¼ ðffr 1 ; r 2 gg; bÞ, set, such as a m1 , the Algorithm 3.5.1 will defines c3 ¼ ðfr 1 g; m0 Þ and c4 ¼ ðfr2 g; Þ. m1 Þ to remove P from UPða Third, if we have an ACR allowing multiple non-singleton role :H ¼ fg 1 ¼ fr1 ; r2 g; g 2 ¼ fr 3 ; sets g i ; 1 6 i < k; jg i j > 1, such as a r4 gg, and an uncontrolled path P ¼ m0 < m1 < m2 < m3 , the Algorithm 3.5.1 will define c5 ¼ ðfr 1 ; r 3 g; m0 Þ; c6 ¼ ðfr 1 ; r 4 g; m1 Þ, c7 ¼ ðfr 2 ; r 3 g; m2 Þ, and c8 ¼ ðfr2 ; r 4 g; m3 Þ. In this way, g 1 and g 2 can be allowed while other illegitimate role sets, such as fr 1 ; r4 g and fr 2 ; r 3 g, can be blocked. Þ. Algorithm 3.5.1. Removing UPða Input  H ¼ fg ji ¼ 1; . . . ; kg;  ¼ ðH; bÞ; (1) An ACR a i (2) The software architecture, SA (definition 3.1); (3) Mapping T 1 (2.13) and T 2 (2.14); Output Þ: the set of reconfigured ACCs; T 2 ða Q 1: Q ¼ cð ki¼1 g i Þ; Þ do 2: for P ¼ ðM; RÞ 2 UPða 3: Denote Q as fRi ji ¼ 1; . . . ; jQ jg; 4: for i=1 to jQ j 5: Take Ri from Q, which is not taken before; 6: Take mi from M, which is not taken before; 7: Let c ¼ ðRi ; mi Þ; Þ ¼ T P2 ða Þ [ fcg; 8: T P2 ða 9: end for  Þ ¼ T 2 ða Þ [ T P2 ða Þ; 10: T 2 ða 11: end for Þ; 12: return T 2 ða

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

The time complexity of the Algorithm 3.5.1 comes from not only computing the uncontrolled access paths but also composing the set of roles and component methods as ACC. The asymptotic time complexity of computing uncontrolled paths is Oð1Þ, and that of composing ACCs from role sets and component methods depends Q :H, that is, Oð ki¼1 ðjg i jÞÞ. on the multiply of the cardinality of g i 2 a  H ¼ fg ji ¼ 1; . . . ; kg,we have  ¼ ðH; bÞ; Theorem 3.1. For an ACR a i Þ defined by the Algorithm 3.5.1 is the minimal that the set K ¼ T P2 ða set of ACCs allowing all legitimate users while blocking all illegitimate  via the access path P, and jKj ¼  :b users to perform business task a Qn jcð i¼1 g i Þj.

Proof 1 (1) Legitimate users simultaneously activating all roles in any :H; 1 6 i 6 k will be allowed to perform one of role set g i 2 a  by ACCs in K because each ACC c 2 K  :b the business task a :H; i ¼ 1; . . . ; k. allows at least one role in each role set g i 2 a (2) Assume that illegitimate users can perform the business  by simultaneously activating roles in an illegitimate  :b task a :H. Obviously, g i must not be the subset of g, that role set g R a is the relation g i  g; 1 6 i 6 k must hold, otherwise g is actually a legitimate role set. Consequently, we have g i n g – /; 1 6 i 6 k and we can define an ACC c ¼ ðRs ; mÞ 2 K; where Rs 2 Q cð ki¼1 ðg i n gÞÞ to block the illegitimate role set g. In that, the set of ACCs defined as K can block any illegitimate users to  :b. perform the business task a , that (3) If K is not the minimal set of role sets implementing a is, there exists an ACC c ¼ ðg; mÞ of K can be removed from K and K n fcg can still allow all legitimate users while deny all ille Then there must :b. gitimate users to perform business task a Sk 0 exist an illegitimate role set g ¼ i¼1 ðg i n gÞ is allowed by the :H. That is, another set of ACCs ACCs defined in K n fcg and g 0 R a  by allowing illegitwith smaller size than that of K will violate a imate users. From (1) and (2), we proof that ACCs defined as K can allow all legitimate role sets while block all illegitimate role sets. From (3), we proof that K is the minimal set of ACCs blocking all illegitimate role sets.   should The Theorem 3.1 states that ACCs implementing ACR a Q be defined by coupling each element in cð ni¼1 g i Þ with each method on P. When the length of access path P is less than the number Q Q of element of cð ni¼1 g i Þ, that is jP:Mj < jcð ni¼1 g i Þj, it is impossible Qn to define the set of ACCs K with jKj ¼ jcð i¼1 g i Þj. One feasible solution is to restructure the software architecture by adding wrappers to some components on P to lengthen P. We illustrate this point in more detail in the case study in Section 5. 3.5.2. Removing overlooked and redundant role sets In fact, the overlooked and redundant role sets can be fixed by reconfiguring ACCs defined on one or more access paths  in the similar way of fixing uncontrolled paths. The :bÞ P 2 Pða only difference is that when allowing the overlooked role sets and removing the redundant role sets, the existing ACCs should be removed first and new ACCs formalized in K (Theorem 3.1) should be defined on P. 3.5.3. Removing partly allowed role sets ÞÞ partly allowed by ACCs on an acThe set of roles ðPaRolesP ða cess path P can be removed directly if they are not elements of :H. In this case, they may be roles misspelled by any role set in a Þ is an element of a role set developers. If a role r1 in PaRolesP ða

321

:H, for example a role set g 1 ¼ fr1 ; r2 g. It cannot be simply rein a moved because removing it will leave g 1 as an overlooked role  will be unavailable  :b set, and consequently the business task a for some legitimate users who simultaneously play roles in g 1 . In fact, ACCs defined in K (Algorithm 3.5.1) will introduce lots of :H includes multiple non-singleton partly allowed role sets when a role sets. There are two solutions to eliminate partly allowed role sets introduced by allowing a non-singleton role set g. One is to envelop the role set g with multiple roles into a single role by defining a new role r to inherit each role in g. For example, after defining a role r to inherit both r1 and r 2 in g 1 ¼ fr1 ; r2 g, users can activate only the role r rather than r 1 and r2 simultaneously to perform corresponding business task. However, users activating r will not allowed to access the component methods that are accessible only by r 1 or r2 due to the inability of the access control service provided by the underlying commercial middleware access control service. The other solution is to implement a customized access control mechanism rather than reusing current commercial middleware access control service. The newly implemented access control mechanism can accept ACCs allowing role sets with multiple elements. However, it is very difficult for developers to ensure the quality of the newly implemented access control mechanism. In contrast to the uncontrolled access paths, overlooked roles and redundant roles, roles partly allowed can often be tolerable for many software systems. In that, it is the responsibility of developers to balance the security risks of tolerating the partly allowed role sets and the benefits of reusing commercial middleware access control service. 3.5.4. Removing redundant ACCs Þ; It is straightforward to eliminate redundant ACCs in RdACC P ða  For example, for an ACC c 2 RdACC P ða :bÞ. Þ, we can let P 2 Pða Þ. c:Rs ¼ /, that is, to delete the ACC c from the set of ACCs T P2 ða  the Þ, P 2 Pða :bÞ, To condense an ACC c in the set CdACC P ða elimination engine needs to check whether any legitimate users  or illegitimate users will be allowed  :b will be blocked to perform a   to perform a:b when a role r is removed from c:Rs , where c 2 Þ, that is, to check whether 9g 2 a :H : g \ ðc:Rs n frgÞ ¼ /. T P2 ða To be noticed, after an ACC is removed or its set of allowed roles Þ and CdACC P ða Þ may become inis condensed, the set of RdACC P ða valid. In that, the elimination engine often iteratively identifies the Þ and reredundant and condensable ACCs in the set of ACCs T P2 ða move it at once. 3.6. Algorithms of reconfiguring ACCs for ACRs In this subsection, we discuss how to improve accuracy of ACCs involved in the implementation of multiple closely related ACRs A. The so-called closely related ACRs are actually ACRs, whose set of configurable methods (computed by the function KðÞ defined as the formula 3.6) interacts with each other. In fact, it is easy to . First, identify a set of closely related ACRs starting from an ACR a  into A; and then we can iteratively add any ACR we can add a i 2 ACR n A into the set A if and only if we have 9a j 2 A : a i Þ \ Kða j Þ – /. Kða To put concisely, we discuss the algorithms of configuring ACCs 1 and a2 . The algorithms implementing two closely related ACRs a of configuring ACCs implementing three or more closely related ACRs can be designed in a similar way. Suppose we have two closely related ACRs:

1 Þ; a 2 Þ; and H1 \ H2 ¼ /: 1 ¼ ðH1 ; b 2 ¼ ðH2 ; b a 1 Þ \ Kða 2 Þ – /. Obviously, we have Kða

322

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

We discuss how to eliminate inaccurate ACCs on a access 1 , which include at the same time some path P to business task b 2 . Obviously, methods accessed in performing the business task b 1 . On P:M must include a component method m1 implementing b 2 , that the one hand, when P does not include m2 implementing b 1 Þ and P R Pðb 2 Þ. In this case, a feasible is, we have P 2 Pðb solution is not to define ACCs on methods accessed in performing 1 and b 2 . On the other hand, when P does include m2 both b 2 , that is,we have P 2 Pðb 1 Þ andP 2 Pðb 2 Þ, to implementing b accurately configure the access path P respecting both the 1 and a2 , we have to consider different situations as ACRs a follows. (1) m1 directly or indirectly calls m2 . 1 via P must have the rights In this case, users performing b 2 although b 2 is not their to access methods implementing b  primary task. Users performing b2 are not allowed to per1 and can only perform b 2 via access paths in form b 2 Þ n fPg. When there is only one access path P to busiPðb 2 , the inaccurate ACCs cannot not be removed ness task b until the software architecture is restructured to introduce 2 because of the confliction among a new access path to b a1 and a2 . In this case, all methods preceding m2 on P should be config1 ured with ACCs allowing the role sets allowed by only a according to the algorithms introduced in the Section 3.5. All methods on P succeeding m2 and m2 itself should be 1 configured with ACCs allowing role sets allowed by both a 2 . and a To be noticed, we can deal with the situation that m2 directly or indirectly calls m1 in a similar way. (2) m1 and m2 have a common ancestor ma and have not a common offspring ms . In this case, both b1 and b2 can be accessed via P by users with enough rights. In fact, there must exist at least one common ancestor of both m1 and m2 because m1 and m2 belongs to the access path P and the head of P is a common ancestor of both m1 and m2 . Assume that ma is the nearest common ancestor of both m1 and m2 . ma and its ancestors should be configured with ACCs allowing all role sets 1 and a 2 . m1 and m2 and their offsprings allowed by both a should be configured with ACCs allowing role sets allowed 1 or a 2 , respectively. by only a (3) m1 and m2 have a common ancestor ma and a common offspring ms . In this case, both b1 and b2 can be accessed via P by users with enough rights. ms and its offsprings should be config1 ured with ACCs allowing all role sets allowed by both a 2 . m1 and its ancestors not calling m2 should be configand a 1 ; m2 and ured with ACCs allowing role sets allowed by only a its ancestors not calling m1 should be configured with ACCs 2 . allowing role sets allowed by only a Up to here, we have clarified the ACRs in a set of closely related ACRs A, against which the evaluation and reconfiguration of ACCs can be done for different parts of an access path in the similar way in Section 3.5. As discussed above, various inaccurate ACCs except for partly allowed role sets can be automatically eliminated by reconfiguring ACCs and restructuring software architecture (for example, adding wrappers to components, introducing new access paths) when necessary. Developers can evaluate the reconfiguration plan to make customized decisions, for example, about tolerating some inaccurate ACCs, or deliberately incorporating some redundant ACCs to improve the security of component-based systems [27].

Fig. 3. A reference process.

4. A reference process This section presents a reference process guiding developers to evaluate and improve accuracy of ACCs by the metrics and algorithms. As shown in Fig. 3, the process includes three stages, inputs preparation, evaluation, and improvement. In the preparation stage, developers are responsible for preparing several inputs for automatically evaluating and improving accuracy of ACCs in component-based systems. The necessary inputs include functional requirements B (2.2), ACRs (2.8), software architecture with ACCs (3.1), and traceability links among them ((2.13) and (2.14)). These inputs are actually artifacts of activities in common software engineering process. We have argued their availability in Section 3.1. In the evaluation stage, the evaluation engine is responsible for automatically evaluating the degree of accuracy of ACCs implementing the desired ACRs according to the metrics defined in Section 3. In the improvement stage, the improvement engine is responsible for automatically reconfiguring the ACCs or even software architecture using the algorithms defined in Section 3. In this stage, developers may be informed to make decisions on choosing the way of reconfiguring ACCs and software architecture when necessary.

5. A case study In this section, we apply our achievements in an integrated eshop application–gShop of an imagined enterprise. The enterprise currently operating two online stores decides to construct a new online store to integrate the two existing ones. Via the integrated store gShop, customers can compare the price of products from different online stores and can buy products as an individual or as a member of group, joining a group-purchasing. In this example, we compose the gShop from two online stores, including JPS [23]–the Java Pet Store developed by Sun Microsystems™, and RUBiS[1]–the online Rice University Biding System.

5.1. Inputs for evaluation 5.1.1. Functional requirements and ACRs Any customer of gShop can browse products, compare the price of products sold by JPS and RUBiS. Normal customers registered to either gShop or JPS can buy products from JPS at original price, and customers registered to both gShop and RUBiS can auction some products and bid for other products. Furthermore, qualified customers, for example, customers with good transaction records, customers recommended by senior customers, or customers holding a certificate sold by gShop or third parties, can buy products as a member of a group to enjoy the lower discount of group-purchasing.

323

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326 Table 3 The list of ACRs of gShop. a1 a2 a3 a4 a5

¼ ¼ ¼ ¼ ¼

ð/; b1 Þ denotes that all customers can perform the business task b1 (browse and compare) ðffr1 gg; b2 Þ denotes that all customers playing r 1 can perform the business task b2 (manage customer information of gShop) ðffr1 g; fr 2 gg; b3 Þ denotes that customers playing r 1 or r 2 can perform the business task b3 (buy products from JPS as an individual) ðffr1 ; r3 gg; b4 Þ denotes that customers simultaneously playing r 1 and r 3 can perform the business operation b4 (auction or bid products in RUBiS as an individual) ðffr1 ; r4 g; fr1 ; r5 g; fr1 ; r 6 gg; b5 gÞ denotes that customers simultaneously playing r 1 and one or more roles in fr 4 ; r5 ; r 6 g can perform the business task b5 (buy products from JPS or RUBiS as a member of group)

There are six roles in gShop, the role r 1 representing normal customers registered to gShop, the role r 2 representing customers registered to JPS, and the role r3 representing customers registered to RUBiS, the role r4 representing customers with good transaction records, the role r5 representing customers recommended by senior customers, and the role r6 representing customers holding a certificate issued by gShop. In addition, in group-purchasing, customers in a group do not directly interact with JPS or RUBiS. It is the gShop that runs as role r 7 and r 8 to start a group-purchasing process at JPS and RUBiS, respectively. That is, JPS and RUBiS will discount substantial orders issued by the role r7 or r8 according to given business agreements. In all, we have five ACRs listed in Table 3. 5.1.2. Software architecture with ACCs Besides the five ACRs above, Fig. 4 shows the high-level architecture of gShop in UML 2.0[19]. Fig. 4 includes eleven components. Each component has one or more interfaces, via which components interconnect with each other. In fact, each interface may have one or more methods that are actually the unit of configuring ACCs. However, for readability of the figure, we do not visualize details of each interface but assume that each interface has only one method tacitly named as the name of the interface. In Fig. 4, roles listed under each architectural interface are roles allowed by ACC of the corresponding component method. For example, role r1 is allowed to access component method UI.gBuy, and corresponding ACC is ðfr 1 g; gBuyÞ, All ACCs defined in Fig. 4 are summarized in Table 4. 5.1.3. Available traceability links The available traceability links between business tasks and component methods are listed in Table 5.

Table 4 List of ACCs in gShop. c1 c2 c3 c4 c5 c6 c7

¼ ¼ ¼ ¼ ¼ ¼ ¼

ðfr 1 g, manageÞ ðfr 1 g, gBuyÞ ðfr 1 g, cmsManageÞ ðfr 4 ; r 5 ; r6 g, groupBuyÞ ðfr 3 g, bidÞ ðfr 1 ; r 2 g, submitÞ ðfr 1 g, getInfoÞ

Table 5 The list of traceability links in gShop. b1 b2 b3 b4 b5

! fbrowse; compareg ! fcmsManageg ! fsubmitg ! fauction; bidg ! fgroupBuyg

5.2. Automated evaluation and improvement With the given inputs, we can start to evaluate and improve accuracy of ACCs listed in Table 4 relative to ACRs listed in Table 3. We start from computing entangled access paths PðAÞ related to a set of closely related ACRs A, and then computing the metrics on ACCs in the set T 2 ðAÞ to identify inaccuracy of ACCs, and finally to eliminate inaccurate ACCs in T 2 ðAÞ in an holistic manner. We first compute the set of ACRs ðAa2 Þ closely related to the ACR a2 and we have Aa2 ¼ fa2 g. Customers can access the business task b2 via only the access path P ¼ manage < cmsManage. Obviously, UPða2 Þ ¼ / denotes that all access paths in Pðb2 Þ are controlled; Ov Rolesða2 Þ ¼ RdRolesða2 Þ ¼ PaRolesða2 Þ ¼ / denotes that no over-

Fig. 4. The gShop SA in UML 2.0.

324

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326 Table 6 The list of access paths to fa3 ; a4 ; a5 g. b3 b4

P1 P2 P3 P4 P5 P6

b5

¼ ibuy < buy < jpsBuy < submit ¼ ibuy < buy < auction ¼ ibuy < buy < bid ¼ gBuy < groupBuy < jpsBuy < submit ¼ gBuy < groupBuy < auction ¼ gBuy < groupBuy < bid

Fig. 5. Reconfigured software architecture.

looked role sets, redundant role sets, or partly allowed role sets are introduced by ACCs on P; jRdACCða2 Þj ¼ jT 2 ða2 Þj ¼ 2 indicates that all ACCs are candidates of redundant ACCs. One of them ðc1 ; c3 Þ could be removed to eliminate the redundancy. Second, we take the ACR a3 as the seed and get all related ACRs as A ¼ fa3 ; a4 ; a5 g. According to formula 3.5, customers can access the business task b3 via the access path P 1 ; b4 via P 2 and P 3 ; b5 via P 4 ; P 5 and P 6 . In summary, the access paths in PðAÞ ¼ fP 1 ; . . . ; P 6 g are listed in Table 6. Evaluating and reconfiguring the ACCs implementing a3 ; a4 , and a5 , respectively by metrics and algorithms in the Section 3, we have the results in Table 7. In detail, two ACRs a4 and a5 are not accurately implemented. Inaccuracies of ACCs include uncontrolled path related to a4 , overlooked role sets related to a4 and a5 , redundant role sets introduced by ACCs related to a4 and a5 , and partly allowed role sets related to a5 . The set of ACCs implementing a4 and a5 is inaccurate and is categorized into G0 . To remove the uncontrolled path P 2 related to a4 , and to allow users playing the overlooked role sets in Ov Rolesða4 Þ, i.e. fr 1 ; r 3 g, the role r 1 and r 3 should be allowed by different ACCs on access paths P 2 and P 3 , respectively while not offending other ACRs. Intuitively, we can define c8 ¼ ðfr3 g; auctionÞ and either c9 ¼ ðfr 1 g; ibuyÞ or c10 ¼ ðfr 1 g; buyÞ. However, either c9 or c10 will block users activating r2 to perform the business task b3 . That is to say, the overlooked roles in Ov Rolesða4 Þ cannot be eliminated in this example until software architecture is restructured. As shown in Fig. 5, we can add a wrapper wRubis for RUBiS-ShopAgent, which simply delegate all requests from ShopingAssit to RUBiS-ShopAgent, and we can define c11 ¼ ðfr1 g; wRubis:auctionÞ and c12 ¼ ðfr1 g; wRubis: bidÞ to replace c9 or c10 . In that, by defining c8 ; c11 and c12 ; Ov Rolesða4 Þ will be removed while not violating other ACRs. After adding the wrapper wRUBiS, ACCs c11 and c12 , redundant role sets in RdRolesða4 Þ is also removed but partly allowed role sets in PaRolesða4 Þ ¼ ffr1 gg is introduced. Worth to note, Ov RolesP 5 ða5 Þ ¼ Ov RolesP 6 ða5 Þ ¼ a5 :H means that all legitimate users are blocked to perform b5 via the access paths P 5 and P 6 . In fact, all legitimate roles are blocked by the ACCs c5 and c8 . If only considering a5 , removing c5 and c8 is sufficient for allowing all legitimate roles. However, c5 and c8 cannot be removed because they are involved in implementing a4 . In this case, it is necessary to restructure the software architecture to allow legitimate users. As shown in Fig. 5, developers can introduce

two instances of RUBiS-ShopAgent into software architecture to serve the interface buy and groupBuy, respectively. In this way, b5 can be implemented and used independently from b4 , and subsequently a5 and a4 can also be implemented independently. In summary, by reconfiguring ACCs and restructuring software architecture when necessary, various inaccuracies of ACCs including uncontrolled paths, overlooked role sets, redundant role sets, and redundant ACCs can be removed. However, as shown in Table 7, partly allowed role sets cannot be removed until replacing middleware access control service or introducing new role to replace role sets including multiple roles. After applying our method, reconfigured ACCs of gShop can be categorized into G11 , that means, they allow or deny users as prescribed by ACRs and include no redundant ACCs, but still introduce partly allowed role sets. 6. Discussion and related work Access control as a means to achieve information security, is a system wide concern and definitely deserves the treatment at the software architecture level. Developers can employ the traditional software architecture analysis methods, such as SAAM, ATAM etc. [6] to evaluate the degree to which a software architecture implements the desired ACRs. However, these methods are human-intensive, and provide neither quantitative metrics for evaluating accuracy of ACCs relative to the desired ACRs nor facilities for improving it. All these tasks are left to the developers. In large-scale component-based systems with voluminous components to be configured, assuring accuracy of ACCs configured on these methods is, if not impossible, very difficult and time-consuming. In contrast, this paper focuses on clarifying the nature of accuracy of ACCs, and on automatically evaluating and improving accuracy of ACCs. The automation of our approach is enabled by the availability of the detailed software architecture which captured the dependencies among component methods, and the traceability among functional requirements and software architecture. If the traceability is not available, the developers should manually construct them before employing our method to automatically analyze accuracy of ACCs. In this case, our method will degenerate into a semi-automatic one. An open issue introduced by our approach is that reconfiguring software architecture with ACCs may influence the degree to which other quality attributes, such as performance, reliability of

Table 7 Evaluation report of applying metrics on the ACCs in T 2 ðfa3 ; a4 ; a5 gÞ.

UP OvRoles RdRoles PaRoles RdACC

a3

a4

P1

P2

P3

P4

P5

P6

/ / / / /

P2 ffr 1 ; r3 gg / / /

/ ffr 1 ; r 3 gg r3 / /

/ / / ffr1 gg /

/ ffr 1 ; r 4 g; fr 1 ; r 5 g; fr1 ; r6 gg ffr 1 ; r 4 ; r 3 g; fr1 ; r5 ; r 3 g; fr 1 ; r 6 ; r3 gg ffr 1 gg /

/ Same to Ov Rolesp5 ða5 Þ Same to RdRolesp5 ða5 Þ ffr 1 gg /

ffr 1 gg

ffr 1 gg

ffr 1 gg

ffr 1 gg

Inaccuracies remained in reconfigured ACCs PaRoles / ffr 1 gg

a5

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

component-based systems are achieved. Field evaluation should be conducted in the future to evaluate how and to which degree these quality attributes are influenced by different reconfiguration plan. ACCs in component-based systems are actually the role-based access control policies interpreted by the middleware access control service. Access control policies have grown from simple matrices to non-trivial specifications as sophisticated configurations in distributed systems [17]. The increasing complexity of these policies correspondingly demands strong quality assurance techniques. Many research works have been done to verify whether or not the access control policies conforming to some properties. For example, Jajodia et al. checked whether two or more access control policies grant or deny an access simultaneously and whether all access have been granted or denied [13]. Naumovich and Centonze [18,5] evaluated the ‘‘location consistency’’ between functionbased access control policies and data-based access control policies. Hansen et al. [11] demonstrated how to use finite model checking to conformance testing between security policies expressed in form of LTL claims and their implementation in RBAC framework. Fisler et al. [8] developed a tool called Margrave that uses multi-terminal binary decision diagrams to verify userspecified properties and perform change-impact analysis on access control polices. Martin et al. [14] introduced idea of mutation test into verification of access control policies to assess the quality of policy properties used to verify access control policies. In particular for component-based systems, Pistoia et al. [20] assumed methods allowed for roles are correct and then utilize the call graph of methods in a program to verify whether the roles assigned to a user is insufficient or redundant for executing the program. They construct the call graph of a program by source code analysis tool DOMO, which can identify both inter-component call and intracomponent call in J2EE applications. In addition, some organization level authorization constraints [3] need to be enforced when specifying access control policies. For example, two roles should not be allowed to access a resource. Some researchers have provided facilities to validate and test access control policies for their violations to authorization constraints [22]. However, these research works concentrate on verifying the properties of access control policies but not on their conformance to high-level access control requirements. In contrast, our method automatically analyze accuracy of ACCs relative to the desired ACRs and reconfigure them to eliminate inaccuracy of ACCs according to ACRs. Here, the ACRs are supposed to be correct and serve as the base for reasoning and reconfiguring the ACCs. In real settings, ACRs may include some faults. By viewing the ACRs as high-level access control policies, developers can apply existing verification techniques on ACRs, for example work in [13,11,5,22]. Massacci et al. [15] identify and resolve the conflicts of ACRs with functional requirements. Our previous work [29] identified and solved part of the problems discussed in this paper in the context of J2EE applications. This paper goes further on the aspects of formally stating the problems in a more general context, defining more comprehensive metrics for identifying the inaccurate ACCs, and developing algorithms for improving accuracy of ACCs. 7. Conclusion and future work Developing software systems by composing reusable components can save time and cost of development while improving the quality of software systems. However, due to the constraints induced by component-based technologies, the complexity of both changeful ACRs and the architecture of component-based systems, the ad hoc mistakes of human, inaccurate ACCs are often inevitably introduced and the software systems are ill-protected. In this paper, we clarify the meaning of accuracy of role-based access control

325

configurations in component-based systems and present a set of formal metrics and algorithms which can used to automatically evaluate and improve the accuracy of ACCs relative to the desired ACRs in large-scale component-based systems. Our method can significantly reduce the complexity and efforts in evaluating and improving accuracy of ACCs if inputs are enough. We have demonstrated that all metrics can be automatically resolved according to given inputs. We have shown that modifying ACCs implementing only one ACR is often straightforward while modifying ACCs implementing multiple ACRs often leads to conflicts which can only be resolved after properly restructuring software architecture. In the future, we plan to develop tool prototypes and to apply our method into more real projects. For now, our method does not go further in how to get, evaluate and apply the plan of restructuring software architecture but leave it to developers. In the future, an interesting research issue is how to codify patterns of restructuring software architecture, how to automatically apply them to improve accuracy of ACCs. Acknowledgments This work is sponsored by the National Key Basic R&D Program of China under Grant No. 2009CB320703; the National Natural Science Foundation of China under Grant No. 60933003, 60873060; the High-Tech R&D Program of China under Grant No. 2009AA01Z116; the EU FP7 under Grant No. 231167; the Research Foundation of Shannxi University of Science and Technology of China No. BJ09-13; the Research Foundation on Opening Issues of Key Laboratory of High Confidence Software Technologies of Ministry of Education of China, No. HCST201004. References [1] RUBiS. Available from: . [2] BS799-1:Information Security Management-Part 1: Code of Practice for Information Security. British Standards Institution, 1999. [3] G. Ahn. The RCL 2000 Language for Specifying Role-Based Authorization Constraints. Ph.D. Thesis, George Mason University, 1999. [4] G. Ahn, R. Sandhu, Role-based authorization constraints specification, ACM Transactions on Information and System Security (TISSEC) 3 (4) (2000) 207– 226. [5] P. Centonze, G. Naumovich, S.J. Fink, M. Pistoia. Role-based access control consistency validation. In ISSTA06: Proceedings of the 2006 international symposium on Software testing and analysis, ACM. L., NY, USA, 2006, pp. 121– 132. [6] L. Dobrica, E. Niemelä, A survey on software architecture analysis methods, IEEE Transactions on Software Engineering 28 (7) (2002) 638–653. [7] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli, Proposed NIST standard for role-based access control, ACM Transactions on Information and System Security (TISSEC) 4 (3) (2001) 224–274. [8] K. Fisler, S. Krishnamurthi, L. Meyerovich, M. Tschantz. Verification and change-impact analysis of access control policies, in: Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 196–205. [9] D. Garlan, Software architecture: a roadmap, in: Proceedings of the Conference on The Future of Software Engineering, 2000, pp. 91–101. [10] D. Grove, C. Chambers, A framework for call graph construction algorithms, ACM Transactions on Programming Languages and Systems (TOPLAS) 23 (6) (2001) 685–746. [11] F. Hansen, V. Oleshchuk, Conformance checking of RBAC policy and its implementation, First Information Security Practice and Experience Conference (ISPEC 2005), 2005, pp. 144–155. [12] G. Huang, H. Mei, F.Q. Yang, Runtime recovery and manipulation of software architecture of component-based systems, Automated Software Engineering 13 (2) (2006) 257–281. [13] S. Jajodia, P. Samarati, V. Subrahmanian. A logical language for expressing authorizations, in: Proceedings of the 1997 IEEE Symposium on Security and Privacy, 31, 1997. [14] E. Martin, T. Xie, A fault model and mutation testing of access control policies, in: Proceedings of the 16th International Conference on WorldWideWeb, 2007, pp. 667–676. [15] F. Massacci, N. Zannone, Detecting Conflicts between Functional and Security Requirements with Secure Tropos: John Rusnak and the Allied Irish Bank, Technical Report, Technical Report DIT-06-002, University of Trento, 2006. [16] H. Mei, J. Chang, F. Yang, Composing Software Components at Architectural Level, in: Proceedings of International Conference on Software Theory and Practice, IFIP the 16th World Computer Congress, 2000, pp. 224–231.

326

L. Sun, G. Huang / Journal of Systems Architecture 57 (2011) 314–326

[17] T.Moses et al. eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS Standard, 2005. [18] G. Naumovich, P. Centonze, Static analysis of role-based access control in J2EE applications, ACM SIGSOFT Software Engineering Notes 29 (5) (2004) 1–10. [19] OMG. UML 2.0 Superstructure. Final Adopted Specification, 2003. Available from: . [20] M. Pistoia, S. Fink, R. Flynn, E. Yahav, When role models have flaws: static validation of enterprise security policies, in: Proceedings of the 29th International Conference on Software Engineering, 2007, pp. 478–488. [21] P. Samarati, S.C. di Vimercati. Access Control: Policies, Models, and Mechanisms. Foundations of Security Analysis and Design: Tutorial Lectures, 2001. [22] K. Sohr, G.J. Ahn, M. Gogolla, L. Migge, Specification and Validation of Authorisation Constraints Using UML and OCL. Computer Security Esorics 2005: 10th European Symposium on Research in Computer Security, Milan, Italy, September 12–14, Proceedings, 2005. [23] Sun Microsystems. Java Pet Store. Available from: . [25] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, AddisonWesley Professional, 2003. [26] R. Crook, D. Ince, B. Nuseibeh, Modelling access policies using roles in requirements engineering, Information and Software Technology 45 (14) (2003) 979–991. [27] Paul Ilechko, and Mannie Kagan. Authorization concepts and solutions for J2EE applications, 2006. Availble from: . [28] A. Freeman, A. Jones, J. Osborn, Programming.NET Security, O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2003. [29] Sun L, Huang G, Mei H, Validating access control configurations in J2EE applications, in: Proceedings of the 11th International Symposium on Component Based Software Engineering, LNCS 5282, 2008, pp. 64–79.

Lian-Shan Sun is a lecturer in School of Electrical and Information Engineering, Shannxi University of Science and Technologies. He acquired a Ph.D. in software engineering from Peking University in 2009. His research interests are in the area of software architecture and component-based software development, with a focus on quality attributes related issues.

Gang Huang is an associate professor in the School of Electronics Engineering and Computer Science, Peking University. His research interests are in the area of the construction and management of middleware, and software engineering with a focus on component based development and software architecture.