A feature-based approach for modeling role-based access ... - CiteSeerX

The Journal of Systems and Software 84 (2011) 2035–2052

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

A feature-based approach for modeling role-based access control systems Sangsig Kim a , Dae-Kyoo Kim a , Lunjin Lu a , Suntae Kim b,∗ , Sooyong Park c a

Department of Computer Science and Engineering, Oakland University, Rochester, MI 48309, USA Department of Computer Engineering, Kangwon National University, Gangwon, South Korea c Department of Computer Science and Engineering, Sogang University, Seoul, South Korea b

a r t i c l e

i n f o

Article history: Received 4 February 2011 Received in revised form 31 March 2011 Accepted 31 March 2011 Available online 7 July 2011 Keywords: Feature modeling Role-based access control UML

a b s t r a c t Role-based access control (RBAC) is a popular access control model for enterprise systems due to its flexibility and scalability. There are many RBAC features available, each providing a different function. Not all features are needed for an RBAC system. Depending on the requirements, one should be able to configure features on a need basis, which reduces development complexity and thus fosters development. However, there have not been suitable methods that enable systematic configuration of RBAC features for system development. This paper presents an approach for configuring RBAC features using a combination of feature modeling and UML modeling. Feature modeling is used for capturing the structure of features and configuration rules, and UML modeling is used for defining the semantics of features. RBAC features are defined based on design principles of partial inheritance and compatibility, which facilitates feature composition and verification. We demonstrate the approach using a banking application and present tool support developed for the approach. © 2011 Elsevier Inc. All rights reserved.

1. Introduction RBAC (Ferraiolo et al., 2001) is a flexible and scalable access control model that governs access based on user roles and permissions. Since the emergence of the generalized RBAC in 1992 (Ferraiolo and Kuhn, 1992), there have been many features proposed, each addressing a different concern. The NIST RBAC standard (Ferraiolo et al., 2001) presents Core RBAC capturing essential RBAC functions, Hierarchical RBAC providing functions to support role hierarchies, Static Separation of Duties (SSDs) RBAC preventing user assignment to conflicting roles, and Dynamic Separation of Duties (DSDs) RBAC limiting simultaneous activation of conflicting roles. More recently, researchers have proposed other features such as Temporal RBAC (T-RBAC) (Bertino et al., 2001) addressing temporal aspect of RBAC, Privacy RBAC (P-RBAC) (He, 2003) concerning privacy in RBAC, and Context-Aware RBAC (CA-RBAC) (Kumar et al., 2002) supporting context-based access control in pervasive computing. Not all these features are needed for an RBAC system. Depending on needs, one should be able to configure features by selecting only the features that are needed. For instance, in the database management system (DBMS) domain, Informix Online Dynamic Server 7.2 does not support static separation of duties, while Sybase

∗ Corresponding author. Department of Computer Engineering, Kangwon National University, Gangwon, South Korea. E-mail addresses: [email protected] (S. Kim), [email protected] (D.-K. Kim), [email protected] (L. Lu), [email protected] (S. Kim), [email protected] (S. Park). 0164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2011.03.084

Adaptive Server release 11.5 does. On the other hand, Informix supports dynamic separation of duties, while Oracle Enterprise Server Version 8.0 does not (Ramaswamy and Sandhu, 1998). In the hospital domain, the combination of T-RBAC and P-RBAC is often desired for time-based access control for hourly staffs and protecting privacy in patient records. There is much work on RBAC focusing on theoretical foundations for defining policies for a specific concern (e.g., role hierarchies, conflict-of-interest) and their enforcement at the kernel level (e.g., Ferraiolo and Kuhn, 1992; Ferraiolo et al., 2001; Bertino et al., 2001; He, 2003; Kumar et al., 2002). There is, however, only a little work on techniques for developing RBAC systems from a development perspective. By the cross-cutting nature of access control, the development of access control systems involves high complexity and likelihood of errors, and development techniques specific to the access control domain that enable systematic development are highly desired. Several researchers use UML profiles (OMG, 2002) to capture the concepts in the access control domain (e.g., Jurjens, 2002; Lodderstedt et al., 2002; Priebe et al., 2004; Shin and Ahn, 2000). While UML profiling helps incorporating access control concepts into design models, it does not capture the structure of concepts and their behaviors. Ray et al. use the UML to describe RBAC structure and behaviors. However, they do not have concept of features, and thus does not support feature configuration. In this paper, we present a feature-based approach for developing RBAC systems. In the approach, RBAC features and configuration rules are captured by feature modeling (Kang et al., 1990). The semantics of features is defined using the Unified Modeling Language (UML) (OMG, 2007) and the Object Constraint Language

2036

S. Kim et al. / The Journal of Systems and Software 84 (2011) 2035–2052

(OCL) (Warmer and Kleppe, 2003) based on partial inheritance and compatibility, which are design principles developed in this work for designing RBAC features. The approach provides a composition method based on partial inheritance for building RBAC configuration, which also serves as a verification point for correctness of composition. We demonstrate the approach using a banking system and describe how the configured RBAC can be used for instantiating a design model for the system. We also present tool support for the approach. This paper is an extension of our preliminary work (Kim et al., 2010). The extension includes the specification for the Static Separation of Duty feature and enriched specifications with additional behaviors for the Core and General features, and the Compatibility principle supporting interference analysis, proofs for semantic composition, a prototype tool, and case studies. The rest of the paper is organized as follows. Section 2 gives an overview of related work. Section 3 briefs the presented approach. Section 4 describes RBAC feature modeling. Section 5 describes the formal basis of design principles for specifying RBAC features. Section 6 presents RBAC feature specifications based on the design principles. Section 7 describes the composition method for building RBAC configurations. Section 8 presents case studies demonstrating the application of the approach to a banking system and a database management system and discusses lessons learned. Section 9 discusses tool support for the approach and Section 10 concludes the paper.

2. Related work Several researchers use the UML to describe access control models. The work can be classified into two categories. One is using the UML notation to describe the structure of an access control model and its constraints. Shin and Ahn (2000) use UML class diagrams to describe RBAC structure and the OCL to define RBAC constraints. Ray et al. use UML templates to capture RBAC structure and behaviors (Ray et al., 2003; Kim et al., 2004) and object diagrams to visualize RBAC constraints (Ray et al., 2004). In their work, RBAC is viewed as a design aspect for reuse in different applications. The work presented in this paper is influenced by their work on UML modeling of RBAC. However, they do not have a concept of features, and thus does not support feature configuration. Priebe et al. (2004) view an access control model as a design pattern and use a pattern template similar to that of the Gang-of-Four (GoF) patterns (Gamma et al., 1995) to describe RBAC. The other approach uses UML profiles, an extension mechanism in the UML, to define access control concepts. Jurjens (2002) proposed a UML profile called UMLsec for modeling and evaluating security aspects for distributed systems based on the multi-level security model (Harrison et al., 1976). Similarly, Lodderstedt et al. (2002) proposed a UML profile called SecureUML for defining security concepts based on RBAC. Doan et al. (2004) extend the UML, not by using profiles, but by directly incorporating security aspects in RBAC and Mandatory Access Control (MAC) (Biba, 1977) into UML model elements. A set of relationship constraints called secure relationship constraints (SRCs) is defined to enforce access control constraints, ensuring no violation of access control constraints when a relationship is added to UML diagrams. Composition of RBAC features in this work is similar to aspect composition in aspect-oriented modeling (AOD) (e.g., Clarke and Walker, 2001; Reddy et al., 2006; Song et al., 2005; Straw et al., 2004). In AOD, cross-cutting concerns are designed as design aspects that are separated from functional aspects (called primary models). Clarke and Walker (2001) proposed composition patterns for composing design aspects described in UML templates with a primary model via parameter binding. Straw et al. (2004) proposed a set of composition directives (e.g., creating, adding) for aspect

composition. Reddy et al. (2006) use UML sequence diagram templates for describing behaviors of design aspects and use tags for behavior composition. In their work, an aspect may include position fragments (e.g., begin, end) designating the location to be added in the sequence diagram. Their composition method, however, is not rigorously defined, and thus it is difficult to verify resulting models. Their position fragments influenced join points in our work. Song et al. (2005) presented a composition method based on the OCL. In their work, composed behaviors are described in OCL and verified by discharging a set of proof obligations. However, their verification is limited to only OCL expressions, and the entire model cannot be verified. Klein et al. (2007) define a behavioral aspect as a pair of a pointcut and an advice using sequence diagrams. While join points being defined in sequence diagram might make composition easier due to the notational homogeneity, the duplicate elements used for detecting join points in primary model makes the resulting sequence diagrams complicated. Join points in our work can be viewed as a folded form of their join points. Several researchers have studied composition of features at the code level (e.g., Apel et al., 2009; Kuhlemann et al., 2009; Whitfield and Soffa, 1997). Kuhlemann et al. (2009) view features as code transformations and present techniques for type checking after composition. Apel et al. (2009) present a type system for verifying product line programs resulting from monotonic composition. Whitfield and Soffa studied identifying program constructs that may cause dependencies among features and affect the ordering of feature composition. Our work focuses on the model level and can benefit from the code-level work in reserve engineering. Evolution of feature models has been studied in feature model refactoring. A number of refactoring and merging rules have been proposed. Some rules (e.g., Acher et al., 2009; Alves et al., 2006; Gheyi et al., 2006) are descriptive, which helps verifying resulting feature models after refactoring or merging, while some other rules are prescriptive (e.g., Czarnecki and Wasowski, 2007; Segura et al., 2008), which helps implementing refactoring and merging process. Feature composition in our work focuses on semantic composition of features and can benefit from the existing work in studying evolution of feature semantics in composition. There is some work (e.g., Czarnecki and Antkiewicz, 2005; Perrouin et al., 2008; Voelter and Groher, 2007) on defining feature semantics. Czarnecki and Antikiewicz use a mapping-based approach to define feature semantics in product line where features are mapped to model elements described in templates of UML activity diagrams and class diagrams. In their work, model elements are annotated with presence conditions which determine the presence of elements and meta-expressions describing the properties (e.g., attributes, name) of elements. Presence conditions and meta-expressions are evaluated during feature configuration. Similar to Czarnecki and Antikiewicz’s work, Voelter and Groher also use mappings of features to model elements for defining feature semantics. When features are configured, only those elements that are mapped to the chosen features are presented in the model. Perrouin et al. define features in terms of fragments of class diagrams, which are composed as features are configured. Their work is similar to our work in terms of designing features. However, it is not clear in their work what is the basis on which feature fragments are designed, which is an important guideline for developers for designing features. Furthermore, the composition is purely syntactic and no behavioral aspect is considered. Feature modeling can be used for describing both problem space and solution space. Several researchers (e.g., Metzger et al., 2007; Sanen et al., 2009) investigate mapping of problem space to solution space in feature modeling to support feature configuration specific to requirements. Metzger et al. (2007) describe two views in software product line engineering, product line variability and software variability, and propose a mapping for each to facilitate reuse of


artifacts in application development. Sanen et al. (2009) view the product line variability and software variability in Metzger’s work as a problem space and a solution space, respectively. They propose a logic-based approach to describe the interactions between problem space and solution space. The interactions are described as configuration strategies leading to the optimal configuration of solution space from problem space. In our work, we focus on the solution space of the RBAC domain and can benefit from the existing work for establishing traceability to RBAC’s problem domain. 3. Overview of approach The presented approach aims at facilitating systematic development of RBAC systems that are specifically configured for given requirements. Fig. 1 illustrates the approach. In the approach, RBAC is viewed as an access control pattern involving a set of features. Feature modeling is used to capture features and their configuration rules. Features are structured into a core feature and non-core features. Non-core features are designed to inherit partial properties from the core feature that are needed to carry out their functions. In this way, feature design becomes simpler and as such feature composition becomes easier. This is called partial inheritance. RBAC features are defined in the UML. Specifically, class diagrams and sequence diagrams are used for describing feature structure and behaviors. For precise behavior semantics, we use the OCL for specifying pre and post conditions of operations and class invariants. Features are selected based on requirements, which results in a series of feature compositions, each resulting in a configuration. The core feature itself becomes the first configuration. The next feature in selection is composed with the first configuration, which results in the second configuration. The process continues until all the selected features are composed. Each configuration is verified to ascertain that it refines both the previous configuration and the composed feature. The final configuration is RBAC that is specifically configured for the requirements. The configured RBAC is instantiated in the context of the system being developed to create an initial design model. 4. RBAC feature modeling RBAC enforces access control based on user roles and permissions. It involves five key concepts – User, Role, Session, Operation and Object (Ferraiolo et al., 2001). User is a person who interacts with the system and may have multiple login IDs which can be activated simultaneously. Role represents a job function with certain authority and responsibility in an organization. A role is represented as a relation between users and permissions, and a user assigned to a role acquires the permissions given to the role. Roles can have overlapping responsibilities and rights. Session represents an instance of a user’s dialogue with the system. A user can create or delete a session, and activate or deactivate a role in a session. Multiple roles can be activated within the same session, and a user may have multiple sessions running simultaneously. A session may be defined as a mapping of a user to the set of the roles that are activated by the user. Object represents any information resource (e.g., files, databases) to be protected in the system. Operation is an access request to an object invoked in a session. Permission represents an authorization to perform an operation on an object and can be represented as a relation between an operation and an object. Roles may be structured in a hierarchy to reflect an organization’s lines of authority and responsibility. A role hierarchy defines an inheritance relation among roles for inheriting permissions and user assignments. Two roles may have a conflict of interest that prevents a user playing one role from being assigned to the other

2037

role. That is, a user whose membership is in one role cannot be a member of the other conflicting role. This is called Static Separation of Duty (SSD). In a role hierarchy of two junior roles in an SSD relation having the same senior role, a user assigned to the senior role may acquire the permissions given to the junior roles through inheritance. This can cause a security breach. To prevent this, hierarchical SSD constraints are defined for the roles in SSD relations not to have the same senior role. Two roles may also have a conflict of interest that prevents them from being activated within the same session. This is called Dynamic Separation of Duty (DSD). Feature modeling is a design method for modeling commonality and variability of an application family (Kang et al., 1990). A feature model consists of mandatory feature capturing commonality and optional features capturing variability. Features are organized in terms of alternative and or groups in a tree-like hierarchy enforcing configuration rules. An alternative group constrains only one feature be selected from the group. An or group allows one or more features to be selected from the group. Features may have dependencies such as implication and mutual exclusion. An implication dependency requires one feature be used with the other feature in the dependency. A mutual exclusion dependency prevents one feature from being used with the other feature in the dependency. Fig. 2 shows a simplified feature model for RBAC. In the figure, filled circles depict mandatory features, while empty circles represent optional features. The empty triangle underneath the Hierarchy feature denotes an alternative group constraining only one of the General and Limited features be selected. The filled triangle beneath the SoD feature denotes an or group allowing either the SSD feature or the DSD feature or both to be selected. The Core feature captures the essential RBAC functions that every RBAC system must possess. The Review feature provides optional review functions for the concepts (e.g., User, Role) involved in the Core feature. The Hierarchy feature enables roles to be structured into a hierarchy in which permissions are inherited bottom-up and users are inherited top-down. A hierarchy can be either General or Limited. A general hierarchy allows a role to have more than one descendant, while a limited hierarchy is limited to only one descendant. The optional Advanced feature provides administrative functions for managing roles in hierarchy. The SoD feature enforces Separation of Duty (SoD) constraints which are divided into Static Separation of Duty (SSD) and Dynamic Separation of Duty (DSD). The Privacy feature supports privacy policies based on data purposes and conditions (Ferraiolo et al., 2007). The Temporal feature provides functions for temporal access control in terms of duration and period (Bertino et al., 2001). The model may be extended as features are refined or more features are considered. For instance, the SSD feature can be further refined into operation SSD, role SSD, and user SSD, or a feature for context-sensitive access control can be added (Kumar et al., 2002). 5. Design principles In this section, we describe design principles of partial inheritance and compatibility for specifying the RBAC features in Fig. 2. 5.1. Partial inheritance In the feature model in Fig. 2, the Core feature forms the basis of all configurations, and other component features add additional properties to Core or redefine its existing properties. This establishes inheritance relationships between Core and component features. However, unlike the traditional inheritance where all properties are inherited, component features inherit only those that are needed for their functions, which is referred to as partial inheritance. We use UML class diagrams and sequence diagrams for

2038


Fig. 1. An overview of the approach.

specifying RBAC features and partial inheritance is defined in terms of these diagrams. We first define operation refinement and cardinality containment of relationship ends as a foundation for the definition of partial inheritance. An operation op with name o, formal parameter types p1 , . . ., pn , and return value type r is denoted o(p1 , . . ., pn ) r. Let Pre(op) and Post(op) be the pre-condition and the postcondition of op. Let Inv(c) be the invariant of a class c and T1 ⊆ T2 denote that T1 is a subtype of T2 . An operation opc = oc (p1 , . . ., pn ) r in class cc is said to redefine an operation opp = op (p1 , . . . , pm ) r in class cp (Brady, 1993) iff O1: oc = op O2: n = m O3:

∀i ∈ 1..n, pi

⊆ pi

O4: r ⊆ r

O5: Pre(opp ) ∧ Inv(cc ) ⇒ Pre(opc ) O6: Pre(opp ) ∧ Post(opc ) ⇒ Post(opp ).

The cardinality of a relationship rel at an end e is an interval of positive integers and it is denoted as bounds(rel(e)). The containment relationship between intervals is defined as usual. That is, one interval i1 is contained in another i2 if the lowerbound of i1 is greater than or equal to that of i2 and the upperbound of i1 is smaller than or equal to that of i2 . More formally, l1 , u1 ⊆ l2 , u2

iff l1 ≥ l2 and u1 ≤ u2 . The intersection of two intervals l1 , u1 and

l2 , u2 is l1 , u1 ∩ l2 , u2 = max(l1 , l2 ), min(u1 , u2 ). The set of traces of a sequence diagram SD is denoted T(SD). A trace s is a sub-sequence of another trace t, denoted s t iff s can be obtained from t by removing zero or more events. We say a class cc in a component feature fc is inherited from fp if cc has the same name as a class cp in fp and we call cp the parent of cc . Definition 5.1. feature fp iff

A component feature fc partially inherits the Core

1. At least one class in fc is inherited from fp . 2. Each group of inherited classes preserves all relationships between their parents. A relationship relp in fp is preserved iff there is a relationship relc in fc that has the same name and the same ends as relp and for all relationship end e, bounds(relc (e)) ⊆ bounds(relp (e)). 3. For each inherited class cc and its parent cp , ∃−Y • Inv(cc ) ⇒ ∃−Y • Inv(cp ) where Y is the set of properties shared by cp and cc and ∃−Y • P is defined as ∃z1 · · · ∃zn • P and {z1 , . . ., zn } contains all those variables in P that are not in Y. 4. For each inherited class cc and its parent cp , each inherited operation opc in cc refines its corresponding operation opp in cp .

RBAC

Core

Review

General

Hierarchy

Limited

Advanced

SoD

SSD

Privacy

DSD

Fig. 2. RBAC feature model.

Temporal


5. If a sequence diagram SDp in fp and a sequence diagram SDc in fc have the same name, then every trace of SDp is a sub-sequence of some trace of SDc : ∀t ∈ T(SDp ) • ∃s ∈ T(SDc ) • (t s). 5.2. Compatibility A pair of features is said to be compatible if they are allowed to be used together by the feature model. Though allowed by feature model, compatible features may have interferences when they are actually used together in practice. Such interferences are usually not explicit and should be analyzed and addressed during design process. Informally, compatibility relation is a set of (1) or relations (e.g., (SSD, DSD)) under the same branch, (2) relations of features across branches that can be combined (e.g., (General, DSD)), and (3) implication dependencies. The following is a formal definition of compatibility. Let F = {f1 , . . . , fn } be a finite set. The set of un-ordered pairs of different features from F is pair(F) = { fi , fj |fi ∈ F ∧ fj ∈ F ∧ (i < j)}. For any feature f in a feature model M, UM (f) be the set of features along the path from f to the root of M including both f and the root. Two features are incompatible if they cannot be used together. Otherwise, they are compatible. The incompatible relation induced by a model M is denoted ICM defined as follows. ICM

=

f, g|f and g are leaf features

∃f ∈ UM (f ) ∧ g ∈ UM (g)• (f

and

g

are in an alternative relationship in M)

The compatibility relation is the complement of ICM with respect to the set of all pairs of leaf features. Let children(f) be the set of child features of f and leaves(f ) the number of leaf features in the sub-feature rooted at f. The number of compatible pairs of different leaf features in the sub-feature tree root at a given feature f can be computed without first calculating ICM or its complement using the following recurrence. NCP(f ) = f1 ,f2 ∈ pair(F) leaves(f1 ) × leaves(f2 ) + g ∈ F NCP(g)

2039

a request based on specified policies. Although the operations in the class diagram are self-descriptive, their semantics should be defined clearly. For instance, the following defines the semantics of addActiveRole(): context Session:: addActiveRole(r:Role) pre: true let auth:OclMessage=UserâuthorizedRoles() post: in Auth: auth.hasReturned() and auth.result() = ars and Cond: if ars → includes(r) then active in = active in@pre → including(r) else active in = active in@pre endif

The postcondition specifies that an invocation of the operation results in invoking the authorizedRoles() operation which returns a set of authorized roles for the user, and the requested role is activated only if it is included in the authorized roles. Auth and Cond are labels to be used later in this section for proving design correctness. The semantics of assignUser() is defined similarly as follows: context Role:: assignUser(u:User) true pre: let auth:OclMessage=UserâuthorizedRoles() post: in Auth: auth.hasReturned() and auth.result() = ars and if ars → excludes(self) Cond: then assigned to = assigned to@pre → including(u) else assigned to = assigned to@pre endif

General hierarchy feature. General hierarchy allows a role to have one or more immediate ascendants and descendants for inheriting user memberships and permissions from multiple sources. Fig. 4 shows the General hierarchy feature. Based on Definition 5.1, it is designed to contain only the properties that are needed for role hierarchy. The General hierarchy feature redefines several operations in the Core feature which are denoted in bold. For example, the operations authorizedRoles() and createSession() in the User class are redefined to include the roles that are inherited by the directly assigned roles. The addActiveRole() operation in the Session class is redefined to activate inherited roles when the requested role is activated in a session. The new semantics of addActiveRole() is defined as follows:

where F = children(f ). If f is a leaf feature then F = ∅ and hence NCP(f) = 0. The formula suggests that there are 20 compatible pairs to be analyzed in Fig. 2 excluding the Privacy and Temporal features which are not considered in our analysis. The formula can be extended to take into account mutual exclusion dependencies by subtracting them from the formula. The notion of compatibility in this work is similar to that of Batory’s work (Batory, 2005) and the resulting pairs can be verified using his approach.

context Session:: addActiveRole(r:Role) pre: true post: let auth:OclMessage = UserâuthorizedRoles(), ˆ desc:OclMessage = Roledescendants()

6. Designing RBAC features

The operations deassignUser() and authorizedUsers() in the Role class are redefined to take into account inherited roles in role deassignment and role activation. In analysis of compatibility, interference in behavior is found between the General hierarchy feature and the DSD feature when DSD relations involve inherited roles. This may cause security breaches if the inherited roles in DSD are activated in the same session as they have a conflict of interest. To address this issue, we use a join point to designate where in interaction DSD constraints should be checked for inherited roles. The filled rectangle in the loop fragment of the AddActiveRole sequence diagram in Fig. 4 denotes a join point. The syntactic definition of join points is defined as follows based on the UML metamodel:

In this section, we define the Core, General, Limited, SSD, and DSD features in Fig. 2 based on partial inheritance, which are used in the case studies in Section 8 and verify the correctness of the designs. Other features can be found in Kim et al. (2009). 6.1. Designing features We model features using UML class diagrams for capturing feature structure, sequence diagrams for describing interaction behaviors, and the OCL for defining operation semantics. These diagrams are put together into a package as a single unit of feature. Core feature. The Core feature captures essential RBAC properties required by any RBAC system. Fig. 3 shows the structure and behaviors of the Core feature. The symbol “|” in the diagram denotes parameters to be used for instantiation after configuration. The concepts in the diagram have been described in Section 4, except the ReferenceMonitor class which determines user accessibility for

in Auth: Desc: Cond:

auth.hasReturned() and auth.result() = ars and desc.hasReturned() and desc.result() = dscnts and if ars → includes(r) then active in = active in@pre → including(r) and dscnts → forAll(d| active in = active in@pre → including(d)) else active in = active in@pre endif

follows < Construct> in < FragmentOperator> join [< Qualification>]::< Joint> precedes < Construct> < Construct>::= Message | InteractionUse | CombinedFragment | “None” < Joint>::= Message | Interaction | InteractionUse | CombinedFragment

2040


RBAC::Core |assigned_to

|User |authorizedRoles(): Set(|Role) |createSession()

|Role

0..*

0..* 0..*

1 |creates

|active_in

0..* |Session |addActiveRole(|r:|Role) |dropActiveRole(|r:|Role) |getActiveRoles(): Set(|Role)

|given_to 0..*

|Permission

0..*

0..*

0..*

1

0..* |monitors_role 1

0..* |monitors_session 0..*

|assignUser(|u:|User) |deassignUser(|u:|User) |grantPermission(|p:|Permission) |revokePermission(|p:|Permission) |authorizedUsers(): Set(|User) |permissions(): Set(|Permission)

1 |executed_on

|Object

0..*

|Operation

0..*

1

|ReferenceMonitor

0..*

0..*

|monitors_object

1 |checkAccess(|o:|Object,|op:|Operation):Boolean

1

|monitors_operation

AssignUser

AuthorizedRoles

|r:|Role

:|User

|assignUser(|u)

|authroizedRoles() |ars=|get()

opt

|u:|User

|ars=|authorizedRoles()

ref

AuthorizedRoles

[|ars −> excludes(|r)]

|ars

|add(|u)

AddActiveRole :|Session |addActiveRole(|r) |ars=|authorizedRoles() opt

:|User ref

AuthorizedRoles

[|ars−>includes(|r)] |add(|r)

Fig. 3. RBAC Core feature. < FragmentOperator>::= InteractionOperator < Qualification>::= Feature | Feature::< Qualification>

According to the syntax, a join point can be defined between messages, fragments, or combinations of both. If the checking should be placed at the beginning of a sequence, the None construct is used in the follows condition. Similarly, None is used if the checking should be placed at the end of a sequence. The Qualification construct represents the ownership of the joining construct. That is, the join point is effective only when the feature specified in the qualification is in use. Join point can be defined only between (1) optional component features and (2) the Core feature and mandatory component features. It cannot be defined between the Core feature and optional component features due to partial inheritance. Based on the syntax, the join point in AddActiveRole() is defined as follows. follows descendants() in loop join DSD::CheckDSD precedes add()

The join point specifies that the CheckDSD fragment in the DSD feature must be added between descendants() and add() when the DSD feature is in use. Another interference is found when the General hierarchy feature is used together with the SSD feature, which leads to redefining the assignUser operation in the Role class. In the presence of role hierarchies, SSD constraints must be checked to prevent security breaches that might be caused by permission inheritance. This is handled by the join point in the AssignUser sequence diagram in Fig. 4.

Limited hierarchy feature. Limited hierarchy limits the number of immediate ascendants and descendants to one. The Limited hierarchy feature has the same structure as the General hierarchy feature except that the addInheritance() operation has the following additional constraint. Let childOrParent(r1, r2) be true iff r1 is either a child or a parent of r2 and singleChildOrParent(r) be true iff r has no more than one child or it has no more than one parent. Then, the following precondition must hold. childOrParent(r1, r2) ⇒ singleChildOrParent(r1) ∧ singleChildOrParent(r2)

SSD feature. The SSD feature enforces SSD relations to proscribe a user from being assigned two conflicting roles. That is, a user who has a membership in one role in an SSD relation is prevented from being a member of the other role. For instance, in a pharmacy application, a user should not be assigned to both the Prescriber role and the Pharmacist role which have a conflict of interest. Fig. 5 shows the SSD feature. In the figure, an SSD relation is captured by the SSDRole class. The cardinality property in the class specifies the number of roles to which a user can be assigned in an SSD relation. In general, it is two. The addSSDRoleMember(), deleteSSDRoleMember(), and setSSDCardinality() operations are administrative operations for adding and deleting a role from an SSD relation and setting a cardinality. The SSDRoles() and SSDCardinality() operations are query operations returning the set of roles in an SSD relation and the cardinality of the relation. The SSDRoleSet class captures the set of SSD relations.


2041

RBAC::Hierarchy::General |User

1 |creates 0..*

|active_in

|Session

:|Session

|addActiveRole(|r)

opt

0..* |assignUser(|u:|User) |deassignUser(|u:|User) 0..* |addAscendant(|ascnt:|Role) |addDescendant(|ascnt:|Role) |authorizedUsers(): Set(|User) |ascendants(): Set(|Role) |descendants(): Set(|Role)

1..*

|senior

ascendant |junior 1..*

1..* |RoleHierarchy 1..*

descendant

:|User

|ars=|authorizedRoles() ref

|ars[i]:|Role

|r:|Role

AuthorizedRoles :|User |authroizedRoles()

AuthorizedRoles

|ars[i]:|Role

|ars=|get()

[|ars−>includes(|r)] loop

|add(|r) |dscnts=|descendants() loop

|addInheritance(|r1:|Role,|r2:|Role) |deleteInheritance(|r1:|Role,|r2:|Role)

0..*

|addActiveRole(|r:|Role)

AddActiveRole

|Role

|assigned_to

|authorizedRoles(): Set(|Role) 0..* |createSession()

loop

[i includes(|r)]

|add(|u)

Fig. 5. SSD feature.

RBAC::SoD::DSD |User

|assigned_to

|authorizedRoles():Set(|Role) |createSession() 1 |creates 0..* |Session |addActiveRole(|r:|Role) |dropActiveRole(|r:|Role) |getActiveRoles():Role(set)

0..*

|Role 0..* |DSDRoles(): Set(|Role)

|constrained_by_DSD n

0..*

0..*

|addDSDRoleMember(|r:|Role) |deleteDSDRoleMember(|r:|Role) |setDSDCardinality(|card:Integer) |DSDRoles(): Set(|Role) |DSDCardinality(): Integer

|active_in |DSDRoleSet |createDSD() |deleteDSD() |DSDRoleSets(): Set(|DSDSet)

0..*

|consists_of 1

|DSDRole |cardinality: Integer

0..*

AddActiveRole :|Session |addActiveRole(|r)

opt

|acrs[i]:|Role

|ars=|authorizedRoles()

:|DSDRole

:|User

CheckDSD :|Session

|acrs[i]:|Role

loop

[|ars−>includes(|r)]

[iincludes(|r)]


to take into account DSD constraints. The new semantics of addActiveRole() is defined below, checking if the requested role has a DSD relation with any active role in the session: context Session:: addActiveRole(r:Role) true pre: let auth:OclMessage=UserâuthorizedRoles(), post: ˆ dsd:OclMessage = RoleDSDRoles()

partial inheritance

Core (config1)

in auth.hasReturned() and auth.result() = ars and Auth: DSD: dsd.hasReturned() and dsd.result() = drs and let violateDSD:Boolean = drs → exists (dr | ars → includes(dr)) in if ars → includes(r) Cond: then active in = active in@pre → including(r) and not violateDSD else active in = active in@pre endif

component feature1

configurations

• The first proof obligation is proved by the presence of the inherited classes User, Role, and Session in the DSD feature and the fact that the relationships assigned to, creates, and active in have the same ends and multiplicities. • There are two classes (User, Session) in the DSD feature that have the same set of properties as the corresponding classes in the Core feature, and the second proof obligation can be proved by Inv(UserDSD ) ⇒ Inv(UserCore ) and Inv(SessionDSD ) ⇒ Inv(SessionCore ), which are both trivially true since there is no invariant defined for the User and Session classes in both Core and DSD. • The third proof obligation must be discharged for every operation redefined in the inherited classes. As an example, addActiveRole() in the DSD feature redefines that of the Core feature, since they both have the same name, the same parameter type, and no return type. This satisfies the constraints O1, O2, O3, and O4. Based on the OCL semantics of the addActiveRole() operations, O5 and O6 can be proved by (1) (true ∧ true) ⇒ true, which is trivially true, and (2) (true ∧ (AuthDSD ∧ DSDDSD ∧ CondDSD )) ⇒ AuthCore ∧ CondCore . The second condition is proved as follows: Let a = (ars → includes(r)), b = (active in = active in@pre → including(r)), d = (active in = active in@pre), and e = violateDSD. Let CondDSD = ((a ⇒ (b ∧ ¬ e)) ∨ d) and CondCore = ((a ⇒ b) ∨ d). It suffices to prove that (AuthDSD ∧ CondDSD ) ⇒ (AuthCore ∧ CondCore ) since (AuthDSD ∧ DSDDSD ∧ CondDSD ) ⇒ (AuthDSD ∧ CondDSD ). (b ∧ ¬ e) ⇒ b, we have (a ⇒ (b ∧ ¬ e)) ⇒ (a ⇒ b) Since which implies CondDSD ⇒ CondCore which in turn implies (AuthDSD ∧ CondDSD ) ⇒ (AuthCore ∧ CondCore ). Other operations can be proved similarly. • The fourth proof obligation is concretized as ∀t ∈ T(AddActiveRoleCore ) • ∃s ∈ T(AddActiveRoleDSD ) • (t s) for the AddActiveRole sequence diagram. There are two traces involved in T(AddActiveRoleCore ),< addActiveRole(), authorizedRoles()> and < addActiveRole(), authorizedRoles(), add()>. The first one exists in T(AddActiveRoleDSD ) and the second one is a sub-sequence of < addActiveRole(), authorizedRoles(), getActiveRoles(), DSDRoles(), DSDRoles(), add()> which also exists in T(AddActiveRoleDSD ). Thus, the proof obligation is discharged. The partial inheritance for other component features can be verified similarly. The analysis of compatible features reveals four

component feature2

config2

6.2. Verifying features The feature specifications in Section 6.1 are developed based on partial inheritance. To ensure their correctness, the specifications should be verified against the definition of partial inheritance in Definition 5.1. The partial inheritance between Core and DSD is verified as follows by discharging the proof obligations in the definition:

2043

config3

Fig. 7. Multiple inheritance of configurations.

interferences between (1) SSD and General, (2) SSD and Limited, (3) DSD and General, and (4) DSD and Limited, which are all handled by join points in the specifications. Note that the number of interferences in the RBAC feature model is relatively low, which indicates that the RBAC features have high modularity in nature. This shows the suitability of the proposed approach for RBAC. 7. Composition method Partial inheritance enables step-wise composition, which allows the verification of the impact of each feature selection. The Core feature is selected by default as the first configuration. The n th configuration is built upon the (n − 1) th configuration by adding the properties of the selected feature or redefining the existing properties. We view this approach as a special kind of multiple inheritance where the elements having the same name get composed rather than renamed as in the traditional multiple inheritance. Fig. 7 illustrates the approach. The following defines feature composition in terms of class diagrams and sequence diagrams. Class diagram composition is further defined in terms of composition of class invariant, operation, and relationship. We define feature composition as refinement in the view of multiple inheritance. Relationship composition. In composition of class diagrams CD1 and CD2 , relationship a1 from CD1 is composed with relationship a2 from CD2 if a1 and a2 have the same name and same relationship ends. The composed relation denoted a1 ⊕ a2 has the same name and relationship ends as a1 and a2 and bounds((a1 ⊕ a2 )(e)) = bounds(a1 (e)) ∩ bounds(a2 (e)) for each relationship end e. This ensures that the resulting end has the maximal bound interval that conforms to the end of both a1 and a2 . Class composition. Class c1 in class diagram CD1 is composed with class c2 in class diagram CD2 if they have the same name. Let OP(c) be the set of operations in class c. Class c = c1 ⊕ c2 is the composition of c1 and c2 iff C1. Inv(c ) ⇒ Inv(c1 ) ∧ Inv(c2 ). C2. ∀op ∈ OP(c1 ) ∪ OP(c2 ) • ∃op ∈ OP(c ) • name(op) = name(op ). C3. op1 ⊕ op2 ∈ OP(c ) iff op1 ∈ OP(c1 ), op2 ∈ OP(c2 ) and op1 matches op2 . C1 ensures that the invariants of the classes that are composed are preserved in the resulting class. C2 requires that the resulting class have the operations of both the classes that are composed. C3 ensures that only matching operations can be composed.

2044


Operation composition. Operation o(p1 , . . ., pn ) r is said to match with operation o (p1 , . . . , pm ) r iff (1) o = o , (2) n = m, (3) ∀i ∈ 1..n, pi ⊆ pi ∨ pi ⊆ pi , (4) r ⊆ r ∨ r ⊆ r. The composition of two matching operations op1 and op2 is denoted op1 ⊕ op2 . Let op1 = o(p11 , . . ., p1n ) r1 and op2 = o(p21 , . . ., p2n ) r2 . We require that op1 ⊕ op2 be an operation (o(p1 , . . . , pn ) r ) that satisfies P1. ∀i ∈ 1..n, pi = lub(p1i , p2i ) where lub is the least upper bound operation. P2. r = glb(r1 , r2 ) where glb is the greatest lower bound operation. P3. Pre(op1 ) ∧ Pre(op2 ) ∧ Inv(c ) ⇒ Pre(op ). P4. Pre(op1 ) ∧ Pre(op2 ) ∧ Post(op ) ⇒ Post(op1 ) ∧ Post(op2 ). P1 ensures that composed operations can take any parameter valid for component operations. P2 postulates that the return value of composed operations be of the type that conforms to the return type of component operations. Consistent with P1 and P2, P3 enforces that the precondition of composed operations must not be stronger than that of component operations. Similarly, P4 constrains that the postcondition of composed operations must not be weaker than that of component operations. We are now ready to define class diagram composition. Let E(CD) be the set of classes and relationships of class diagram CD. Definition 7.1. An operation ⊕ on class diagrams is a composition operation iff • ∀e1 ∈ E(CD1 ) • [∀e2 ∈ E(CD2 ) • (name(e1 ) = / name(e2 ) ⇒ e1 ∈ E(CD1 ⊕CD2 ) ] and ∀e2 ∈ E(CD2 ) • [∀e1 ∈ E(CD1 ) • (name(e1 ) = / name(e2 )) ⇒ e2 ∈ E(CD1 ⊕ CD2 )]; • ∀e1 ∈ E(CD1 ) • ∀e2 ∈ E(CD2 ) • (name(e1 ) = name(e2 ) ⇒ ∃e ∈ E(CD1 ⊕ CD2 ) • e = e1 ⊕ e2 ). We define sequence diagram composition as follows. An operation on sequence diagrams ⊕ is a composition operation if each trace of SD1 ⊕ SD2 can be obtained by interleaving a trace of SD1 and a trace of SD2 and all traces of SD1 and SD2 are used. The interleave of two traces of events is the set of traces obtained by interleaving the two traces in all possible ways. Let x, y be events and , traces. The following definition of the interleave operator || | is adapted from Störrle (2003).

||| ||| x|||x x|||y

= = = =

{x} × ((|||x) ∪ (x|||) ∪ (|||)) {x} × (|||y) ∪ {y} × (x|||v) for x = / y

Note that the above definition allows us to replace two consecutive occurrences of the same event by a single occurrence if they arise from different traces that are interleaved. Definition 7.2. An operation ⊕ on sequence diagrams is a composition operation iff 1. ∀t ∈ T(SDi ) • ∃t ∈ T(SD1 ⊕ SD2 ) • (t t ) for i = 1, 2; 2. ∀t ∈ T(SD1 ⊕ SD2 ) • ∃t1 ∈ T(SD1 ) • ∃t2 ∈ T(SD2 ) • t ∈ (t1 |||t2 ) where t1 | | | t2 is the set of traces obtained from interleaving t1 and t2 in all possible ways. It should be noted that the composition method is built upon partial inheritance as so are the specifications of RBAC features, and thus it is consistent with the definition of partial inheritance. 8. Case studies: configuring RBAC In this section, we present two case studies, one using a banking system taken from Chandramouli (2000) and another on a database

management system. We use the banking system to demonstrate the approach and the database management system for a realworld example. 8.1. Case study 1: banking system The banking system has the following access control policies: R1. A teller can modify customer deposit accounts. R2. A customer service representative can create or delete customer deposit accounts. R3. An accountant can create general ledger reports. R4. An accounting manager can modify ledger-posting rules. R5. A loan officer can create and modify loan accounts. R6. The customer service representative role is senior to the teller role. R7. The accounting manager role is senior to the accountant role. R8. A user may be assigned the customer service representative role and the loan officer role, but they cannot be activated simultaneously. R1–5 describe general authorization requirements for roles, which can be addressed by the Core feature. R6–7 describe role hierarchies, which can be satisfied by the General hierarchy feature. R8 describes a dynamic SoD requirement to be addressed by the DSD feature. The selection is assumed to be in the order of Core, General hierarchy, and DSD, but it can be in any order by partial inheritance. The Core feature itself forms the first configuration by the composition method. The following subsections describe the second and third configurations. 8.1.1. Second configuration The second configuration is built by composing the Core and General hierarchy features, which involves (1) adding the RoleHierarchy class and its associated relationships to the Core feature, and (2) composing the common classes of User, Session, and Role. Composing the common classes involves composing matching operations such as addActiveRole() in the Session class. The composition method composes two operations by conjoining their preconditions and postconditions. By partial inheritance, inherited operations in component features refine their corresponding operations in the Core feature. Thus, the composed operations resulting from the second configuration are same as the refining operations in the General feature, which satisfy the constraints P 1–4 of the composition method in Section 7. Proofs that General addActiveRole() refines Core addActiveRole() and General addActiveRole() refines DSD addActiveRole() are shown in Lemmas A.1 and A.2, respectively, in Appendix A. Fig. 8 shows the hierarchical properties added to the Core feature. Sequence diagrams are composed by combining lifelines and interleaving traces. For example, the AddActiveRole sequence diagrams are defined in both the Core and the General hierarchy features. They are composed by adding the ars[i]:Role and r:Role lifelines to the AddActiveRole sequence diagram in Core. The ars[i]:Role lifeline is added to check authorized descendant roles, which in turn requires the lifeline to be involved in the AuthorizedRole fragment. The r:Role lifeline is added to query the descendants of the requested role r. The loop fragment from the General hierarchy feature is added to check violation of DSD policies in the descendant roles. The fragment is enabled only when the DSD feature is used. The locations of the descendants() message and the loop fragment are determined relative to the location of the add() operation in the Core feature. Fig. 9 shows the resulting sequence diagram.


2045

added by the General feature

|Role |assignUser(|u:|User) |deassignUser(|u:|User) |grantPermission(|p:|Permission) |revokePermission(|p:|Permission) |authorizedUsers(): Set(|User) |permissions(): Set(|Permission) |addAscendant(|ascnt:|Role) |addDescendant(|ascnt:|Role) |ascendents(): Set(|Role) |descendents(): Set(|Role)

1..* |senior 1..* ascendent 1..* |junior 1..* descendent

|RoleHierarchy |addInheritance(|r1:|Role,|r2:|Role) |deleteInheritance(|r1:|Role,|r2:|Role)

Fig. 8. Partial composition of Core class diagram with General class diagram.

Note that the composition results in the same sequence diagram as the one in the General hierarchy feature. This is because of the constraint (5) in Definition 5.1 requiring that a component feature include every trace of the Core feature, which is consistent with Definition 7.2. This is true for every sequence diagram in the second configuration, provided that component features conform to Definition 5.1. Thus, the resulting configuration conforms to Definition 7.2. Other sequence diagrams can be composed similarly.

8.1.2. Third configuration The third configuration, which is the final configuration in this demonstration, is built by composing the second configuration Config2 with the DSD feature. The composition is carried out by (1) adding the DSDRole and DSDRoleSet classes and their associated relationships to Config2, and (2) composing the common classes of User, Role, and Session. Fig. 10 shows the DSD properties added to the Config2 class diagram. The composition of the addActiveRole() operations in Config2 and the DSD feature results in an operation that checks DSD policies for the requested role and its inherited roles in activating roles:

context Session:: addActiveRole(r:Role) true pre: let auth:OclMessage=UserâuthorizedRoles(), post: ˆ desc:OclMessage = Roledescendants(), ˆ dsd:OclMessage = RoleDSDRoles() in auth.hasReturned() and auth.result() = ars and Auth: Desc: desc.hasReturned() and desc.result() = dscnts and dsd.hasReturned() and dsd.result() = drs and DSD: let violateDSD:Boolean = drs → exists (dr | ars → includes(dr)) in if ars → includes(r) then Cond: (active in = active in@pre → including(r) and dscnts → forAll(d| active in = active in@pre → including(d))) and not violateDSD else active in = active in@pre endif

The resulting semantics conforms to the definition of operation composition in Section 7 as follows: • P 1 and P 2 are trivially true, since the composed operation has the same name and parameter type (Role) and no return type as that of Config2 and the DSD feature.

added by the General feature AddActiveRole :|Session

:|User

|ars[i]:|Role

|addActiveRole(|r) |ars=|authroizedRoles() ref

opt

AuthorizedRoles

[|ars−>includes(|r)] |add(|r) |dscnts=|descendants() loop

[iincludes(|r)] |acrs=|getActiveRoles() ref

CheckDSD

|add(|r)

added by the DSD feature

|dscnts=|descendants() loop ref

[i, Operation →< Transaction, Create, Modify, Delete >. The instantiation lends itself as a design framework for the application addressing access control concerns. 8.2. Case study 2: SmallSQL We carried out another case study using SmallSQL (http://www.smallsql.de/), an open source DBMS. SmallSQL is a Java-based DBMS implementing JDBC 3.0 (SmallSQL, http://www.smallsql.de/). It is a stand-alone application running on individual computers without network interface. It consists of 157 classes supporting SQL query, table and index management, and file and storage management. However, it does not support

user management and access control. In this study, we applied the proposed approach to incorporate RBAC into SmallSQL. For the application, we configured RBAC with the Core, General hierarchy, and SSD features. The Core feature is chosen as it is a mandatory feature in the RBAC feature model. The General hierarchy feature is chosen to support the hierarchy of user roles (e.g., DB Administrator, Data Writer) in the DBMS domain. The SSD feature is selected for handling conflict of interest among user roles in the domain. The DSD feature is not chosen as it is usually not desirable for stand-alone DBMSs like SmallSQL. After composing the configured features, we instantiated the resulting RBAC in the context of SmallSQL. In the instantiation, the Permission class in RBAC is mapped to the SystemPrivilege and UserPrivilege classes, which are introduced in this work. As SmallSQL does not have access control, there is no concept of privilege existing. So, we introduced the two classes based on an analysis of the DBML domain. System privileges, which correspond to administrator privileges, enable accessing any schema object at the system level. On the other hand, user privileges are concerned with accessing specific schema object at the user level. SmallSQL involves only three types of schema objects – Database, Table, and View, which are mapped to the Object class in RBAC. These objects are manipulated through operations of CreateDatabase, CreateView, Delete, Drop, Insert, Select, and Update, which are mapped to the Operation class in the configured RBAC. We also introduced a user class for managing users, which is not supported in SmallSQL. After instantiation, we reverse engineered the source code of SmallSQL to derive a design model. The model is then integrated with the RBAC instantiation. This study shows that the presented approach enables systematic incorporation of RBAC into an existing system. The approach helps reducing development complexity by configuring features on a need basis, which results in optimized RBAC for the system. Such a configuration is enabled through feature

2048


Fig. 13. RBAC feature model and configuration.

modularization, which is not supported in the traditional development of RBAC systems. 9. Tool support We developed tool support for the approach as a plug-in to IBM Rational Software Architect (RSA) which is a widely used UML modeling tool. We chose RSA as the base tool because (1) it is based on Eclipse, a flexible open source platform which allows us to take benefits from the existing Eclipse plug-ins for feature modeling and (2) it provides strong UML modeling features which aid drawing UML diagrams of features and a feature for checking consistency of diagrams. The tool supports the following tasks in the approach: (i) configuring features, (ii) composing features, and (iii) instantiating composed features. We use fmp (Antkiewicz and Czarnecki, 2004), an Eclipse-based feature modeling plug-in, for RBAC feature modeling and configuration. Since both fmp and RSA

are Eclipse-based, their integration was carried out without major issues except some minor issues such as version mismatch of their base Eclipse. By using the existing tools for the background techniques, we not only harness the previous efforts, but also we can better focus on the proposed approach in tool development. Fig. 13 shows fmp integrated with RSA. The left compartment in the figure shows RBAC features defined in package. The expansion of the DSD feature shows that a class diagram (denoted as SPS) and a sequence diagram (denoted as IPS) are defined for the feature. The further expansion of the DSD sequence diagram shows its participating lifelines. The right compartment shows the RBAC feature model configured for the banking system in Section 8 by selecting the Core, General, and DSD features, which is carried out manually by the developer. The configuration resulting from fmp is fed into the composition engine which implements the composition method described in Section 7. The tool composes features in a predefined order


Fig. 14. Composed class diagram.

Fig. 15. Composed sequence diagram.

2049

2050


where the Core feature is always set to be the first and other component features are composed in the order in which they are selected. Composition is carried out based on name matching. In class diagram composition, a selected feature is composed with the previous configuration by adding new elements to the previous configuration and composing common elements. Existence of elements is determined by name matching in the order of classes, attributes, operations, and relationships. Operation composition supports both syntactic and semantic composition. We use SAT4J, a Java-based SAT solver (http://www.sat4j.org/) for semantic verification of composed operations and the built-in OCL feature in Rational Rose Architecture (RSA) for building OCL expressions and checking syntax. OCL expressions are composed by interleaving labels and propositions to enforce the composition constraints. The resulting expressions are validated for syntactic correctness using RSA and translated into the conjunctive normal form (CNF) for input to SAT4J for satisfiability evaluation. Sequence diagram composition is also carried out based on name matching where new methods are added at the location determined relative to existing methods and the reference specified in join points is added at the designated location. Every time a method is added or a join point is executed, the validity of the new trace is checked against the set of all possible combinations of traces computed based on the traces of the original sequence diagrams being composed. The tool is also capable of creating multiple instances of RBAC elements by setting the realization multiplicity of elements, which enables further customization of the resulting RBAC specific to the application context. This feature is particularly useful for the Object and Operation classes which often involve multiple instances. Fig. 14 and Fig. 15 show the resulting model after composition where the light shade indicates the elements added by the General feature and the dark shade indicates the elements added by the DSD feature. The left upper window in Fig. 14 highlights the three features that are composed. The current version still needs some improvement in composing sequence diagrams. One improvement to be made is to link messages to reference fragments. A difficulty we encountered during the implementation is maintaining the consistency of diagrams which is hindered by the high complexity of UML2, the UML metamodel used in RSA. The resulting model can be used as a base for implementation with the code generation feature in RSA.

10. Conclusion We have described a feature-based modeling approach for configuring RBAC to support the need-based development of access control systems. This approach enables fine-grained configuration of RBAC at the feature level in a systematic manner, which helps to reduce development complexity and errors by excluding undesired features. The design principles and the composition method together enable rigorous development, verification, and composition of RBAC features. The approach may be also applied to other domains such as availability and performance where features are found eminent. The prototype tool demonstrates a proof of concept and the feasibility of the approach. The case study shows that the approach can be used for not only new development, but also existing systems without access control. In this work, we found feature modeling effective for capturing the variabilities of the RBAC domain as the domain is mature and the features in the domain are distinctive. We assumed that features are configured manually based on access control requirements. However, it is possible to automate feature selection using metrics-based techniques such as Analytical Hierarchical Process (Triantaphyllou and Mann, 1995), which we plan to investigate in

the future work. The UML is found suitable for describing the static and behavioral properties of RBAC features, and the resulting specifications are easy to understand. However, the informal nature of the language makes it difficult to reason about refinement in the composition method. To address this, we used the OCL. Based on first-order predicate logic, the OCL provides sufficient level of formality for reasoning refinement. RBAC is usually modularized in system architecture and an RBAC module can be developed in-house, purchased (e.g., COTS) from the market, or acquired from an open source repository. The presented approach benefits most in-house development as it allows feature configuration in full scale to address the specific needs of the target system and seamless integration of configured RBAC into architecture. In open source development, RBAC is usually implemented to be simple and general as the target system is not known. For instance, in the DBMS domain, open source RBAC implements just access control lists (ACLs) in many cases, assuming that the data needed for ACLs and supporting RBAC entities (e.g., users, roles, and sessions) are readily available and accessible from in the target DBMS, which might not be always true. This may require non-trivial modifications to both the open source RBAC and the target system for integration if the assumption fails. The presented approach helps to make source RBAC self-contained in terms of required RBAC entities. This makes the assumption no longer needed as the RBAC module can provide the required RBAC entities if they do not exist in the target system. This makes open source RBAC more reusable and easier to integrate. In commercial development, RBAC is usually implemented with typical features (e.g., role hierarchy, SSD, DSD) and the features are customized as needed for individual customers. In general, if commercial RBAC is used, it is planned from the beginning of the project and the vendor participates in the development for customization and integration of the module. For commercial RBAC, the domains where it would be used vary greatly, and as the variability of use increases, higher degree of customizability is required. For instance, a set of features needed for one customer might be significantly different from that of another customer. The presented approach supports such high degree customizability through feature configuration. We have also applied a similar approach to the domain of software architecture tactics (Kim et al., 2009). Unlike the RBAC domain where features have strong homogeneity, the tactics (features) in the software architecture domain are highly heterogeneous. So, partial inheritance and the refinement-based composition are not suitable. Instead we used a mapping-based approach for composing heterogeneous concepts. We also think that the cardinality-based feature modeling (Czarnecki and Kim, 2005) might be useful for the domain as tactics are often instantiated multiple times. We have also used the approach for Mandatory Access Control (MAC) (Bell and LaPadula, 1975) and Discretionary Access Control (DAC) (Harrison et al., 1976). However, we found the presented approach less appealing for these models because of their low variability. However, we found the approach useful for building hybrid models of RBAC and MAC which are often used in the government and military domains to support policies at different levels of security per role. A challenge in the work is comprehensive analyses of feature relationships in the two heterogeneous domains to identify and handle possible conflicts.

Acknowledgements This research is supported in part by the MKE (The Ministry of Knowledge Economy), Korea, under the ITRC (Information Technology Research Center) support program supervised by the NIPA (National IT Industry Promotion Agency) (NIPA-2011-C1090-11310008).


Appendix A. Lemma A.1. The operation addActiveRole() in General refines the operation addActiveRole() in Core. Let a abbreviate ars → includes(r), b abbreviProof. ate active in = active in@pre → including(r), c abbreviate dscnts → forAll (d|active in = active in@pre → including(d) and d abbreviate active in = active in@pre. Let CondGeneral = ((a ⇒ (b ∧ c)) ∨ d) and CondCore = ((a ⇒ b) ∨ d). We need to prove that (AuthGeneral ∧ DescGeneral ∧ CondGeneral ) ⇒ (AuthCore ∧ CondCore ). It suffices to prove that since (AuthGeneral ∧ CondGeneral ) ⇒ (AuthCore ∧ CondCore ) (AuthGeneral ∧ DescGeneral ∧ CondGeneral ) ⇒ (AuthGeneral ∧ CondGeneral ). Since (b ∧ c) ⇒ b, we have (a ⇒ (b ∧ c)) ⇒ (a ⇒ b) which implies CondGeneral ⇒ CondCore which in turn implies (AuthGeneral ∧ CondGeneral ) ⇒ (AuthCore ∧ CondCore ). Lemma A.2. The operation addActiveRole() in DSD refines the operation addActiveRole() in Core. Proof. We use a, b, c and d to abbreviate formulas as in Lemma A.1. Let e abbreviate violdateDSD. The following proof can be obtained from the above proof by changing DescGeneral to DSDDSD and c to ¬e. CondDSD = ((a ⇒ (b ∧ ¬ e)) ∨ d) and Let CondCore = ((a ⇒ b) ∨ d). We need to prove that It suf(AuthDSD ∧ DSDDSD ∧ CondDSD ) ⇒ (AuthCore ∧ CondCore ). fices to prove that (AuthDSD ∧ CondDSD ) ⇒ (AuthCore ∧ CondCore ) (AuthDSD ∧ DSDDSD ∧ CondDSD ) ⇒ (AuthDSD ∧ CondDSD ). since Since (b ∧ ¬ e) ⇒ b, we have (a ⇒ (b ∧ ¬ e)) ⇒ (a ⇒ b) which implies CondDSD ⇒ CondCore which in turn implies (AuthDSD ∧ CondDSD ) ⇒ (AuthCore ∧ CondCore ). Lemma A.3. The operation addActiveRole() in Config3 is a composition of the operation addActiveRole() in Config2 with the operation addActiveRole() in DSD. Proof. Let a, b, c, d and e be given in Lemmas A.1 and A.2. Let CondConfig2 = ((a ⇒ (b ∧ c)) ∨ d), CondDSD = ((a ⇒ (b ∧ ¬ e)) ∨ d), and CondConfig3 = ((a ⇒ (b ∧ c ∧ ¬ e)) ∨ d). We need to prove that (AuthConfig3 ∧ DescConfig3 ∧ DSDConfig3 ∧ CondConfig3 ) ⇒ ((AuthConfig2 ∧ DescConfig2 ∧ CondConfig2 ) ∧ (AuthDSD ∧ DSDDSD ∧ CondDSD )). We first prove that (AuthConfig3 ∧ DescConfig3 ∧ DSDConfig3 ∧ CondConfig3 ) ⇒ (AuthConfig2 ∧ DescConfig2 ∧ CondConfig2 ). It suffices to prove that (AuthConfig3 ∧ DescConfig3 ∧ CondConfig3 ) ⇒ (AuthConfig2 ∧ DescConfig2 ∧ CondConfig2 ) since (AuthConfig3 ∧ DescConfig3 ∧ DSDDSD ∧ CondConfig3 ) ⇒ (AuthConfig3 ∧ DescConfig3 ∧ CondConfig3 ). Since (b ∧ c ∧ ¬ e) ⇒ (b ∧ c), we have (a ⇒ (b ∧ c ∧ ¬ e)) ⇒ (a ⇒ (b ∧ c)) which implies CondConfig3 ⇒ CondConfig2 which in turn implies (AuthConfig3 ∧ DescConfig3 ∧ CondConfig3 ) ⇒ (AuthConfig2 ∧ DescConfig2 ∧ CondConfig2 ). The proof that (AuthConfig3 ∧ DescConfig3 ∧ DSDConfig3 ∧ CondConfig3 ) ⇒ (AuthDSD ∧ DSDDSD ∧ CondDSD ) ) is similar. Thus, (AuthConfig3 ∧ DescConfig3 ∧ DSDConfig3 ∧ CondConfig3 ) ⇒ ((AuthConfig2 ∧ DescConfig2 ∧ CondConfig2 ) ∧ (AuthDSD ∧ DSDDSD ∧ CondDSD )). References Acher, M., Collet, P., Lahire, P., France, R., 2009. Composing feature models. In: Proceedings of the 2nd International Conference on Software Language Engineering (SLE’09), Denver, Colorado, pp. 62–81. Alves, V., Gheyi, R., Massoni, T., Kulesza, U., Borba, P., Lucena, C., 2006. Refactoring product lines. In: Proceedings of the 5th international conference on Generative Programming and Component Engineering, pp. 201–210. Antkiewicz, M., Czarnecki, K., 2004. FeaturePlugin: feature modeling plug-in for eclipse. In: Proceedings of the Workshop on Eclipse Technology Exchange, Vancouver, Canada, pp. 67–72. Apel, S., Grös¨linger, A., Kästner, C., Lengauer, C., 2009. Type-safe Feature-oriented Product Lines. Technical Report MIP-0909, Department of Informatics and Mathematics, University of Passau. Batory, D., 2005. Feature models, grammars, and propositional formulas. In: Proceedings of the International Software Product Line Conference (SPLC), pp. 7–20.

2051

Bell, D.E., LaPadula, L.J., July 1975. Secure Computer System: Unified Exposition and MULTICS Interpretation. Technical Report MTR-2997, MITRE Corporation, Bedford, MA. Bertino, E., Bonatti, P., Ferrari, E., 2001. TRBAC: a temporal role-based access control model. ACM Transactions on Information and Systems Security 4 (3), 191–223. Biba, K.J., 1977. Integrity Considerations for Secure Computer Systems. Technical Report ESD-TR-76-372, Bedford, MA. Air Force Electronic Systems Division. Brady, A.F., 1993. A taxonomy of inheritance semantics. In: Proceedings of the 7th International Workshop on Software Specification and Design, Redondo Beach, California, pp. 194–203. Chandramouli, R., 2000. Application of XML tools for enterprise-wide RBAC implementation tasks. In: Proceedings of the 5th ACM Workshop on Role-based Access Control, Berlin, Germany. Clarke, S., Walker, R., 2001. Composition patterns: an approach to designing reusable aspects. In: Proceedings of the 23rd International Conference on Software Engineering, Toronto, Canada, pp. 5–14. Czarnecki, K., Antkiewicz, M., 2005. Mapping features to models: a template approach based on superimposed variants. In: Proceedings of the 4th International Conference on Generative Programming and Component Engineering, pp. 422–437. Czarnecki, K., Kim, C.H.P., 2005. Cardinality-based feature modeling and constraints: a progress report. In: Proceedings of International Workshop on Software Factories, San Diego, California. http://www.ece.uwaterloo.ca/kczarnec/sf05.pdf. Czarnecki, K., Wasowski, A., 2007. Feature diagrams and logics: there and back again. In: Proceedings of the 11th International Software Product Line Conference, pp. 23–34. Doan, T., Demurjian, S., Ting, T., Phillips, C., 2004. RBAC/MAC security For UML. In: Proceedings of IFIP TC11/WG 11.3 Annual Conference on Data and Applications Security, Catalonia, Spain, pp. 189–202. Ferraiolo, D., Kuhn, D.R., 1992. Role-based access control. In: Proceedings of the NIST-NSA National (USA) Computer Security Conference, pp. 554–563. Ferraiolo, D., Kuhn, D.R., Chandramouli, R., 2007. Role-Based Access Control, 2nd edn. Artech House. Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., Chandramouli, R., 2001. Proposed NIST standard for role-based access control. ACM Transactions on Information and Systems Security 4 (3), 224–274. Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Gheyi, R., Massoni, T., Borba, P., 2006. A theory for feature models in alloy. In: Proceedings of the 1st Alloy Workshop, pp. 71–80. Harrison, M.H., Ruzzo, W.L., Ullman, J.D., 1976. Protection in operating systems. Communications of the ACM 19 (8), 461–471. He, Q., 2003. Privacy Enforcement with an Extended Role-Based Access Control Model. Technical Report TR-2003-09, Computer Science Department, North Carolina State University, Raleigh, NC. Jurjens, J., 2002. UMLsec: extending UML for secure systems development. In: Proceedings of the 5th International Conference on the Unified Modeling Language, Dresden, Germany, pp. 412–425. Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S., 1990. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania. Kim, D., Lu, L., Kim, S., June 2009. A Modeling Approach to Configurable Role-Based Access Control. Technical Report CSE-09-TR-0601, CSE Department, Oakland University, Rochester, MI. Kim, D., Lu, L., Kim, S., 2010. A verifiable modeling approach to configurable rolebased access control. In: Proceedings of the 13th Fundamental Approaches to Software Engineering (FASE/ETAPS), Paphos, Cyprus, pp. 188–202. Kim, D., Ray, I., France, R., Li, N., 2004. Modeling role-based access control using parameterized UML models. In: Proceedings of the 7th Fundamental Approaches to Software Engineering (FASE/ETAPS), Barcelona, Spain, pp. 180–193. Kim, S., Kim, D., Lu, L., Park, S., 2009. Quality-driven architecture development using architectural tactics. Journal of Systems and Software 82 (8), 1211–1231. Klein, J., Fleurey, F., Jezequel, J., 2007. Weaving multiple aspects in sequence diagrams. Transactions on Aspect-Oriented Software Development 3, 167–199. Kuhlemann, M., Batory, D., Kästner, C., 2009. Safe composition of non-monotonic features. In: Proceedings of the 8th International Conference on Generative Programming and Component Engineering, Denver, Colorado, pp. 177–186. Kumar, A., Karnik, N.M., Chafle, G., 2002. Context sensitivity in role-based access control. ACM SIGPOS Operating Systems Review 36 (3), 53–66. Lodderstedt, T., Basin, D.A., Doser, J., 2002. SecureUML: a UML-based modeling language for model-driven security. In: Proceedings of the 5th International Conference on the Unified Modeling Language, Dresden, Germany, pp. 426–441. Metzger, A., Heymans, P., Pohl, K., Schobbens, P.-Y., Saval, G., 2007. Disambiguating the documentation of variability in software product lines: a separation of concerns, formalization and automated analysis. In: Proceedings of the International Conference on Requirements Engineering, pp. 243–253. Perrouin, G., Klein, J., Guelfi, N., Jezequel, J.M., 2008. Reconciling automation and flexibility in product derivation. In: Proceedings of the 12th International Software Product Line Conference, pp. 339–348. Priebe, T., Fernandez, E.B., Mehlau, J.I., Pernul, G., 2004. A pattern system for access control. In: Proceedings of 18th Annual IFIP WG 11.3 Working Conference on Data and Application Security, Sitges, Spain, pp. 25–28.

2052


Ramaswamy, C., Sandhu, R.S., 1998. Role-based access control features in commercial database management systems. In: Proceedings of the 21st NIST-NCSC National Information Systems Security Conference, Arlington, Virginia. Ray, I., Li, N., France, R., Kim, D., 2004. Using UML to visualize role-based access control constraints. In: Proceedings of the 9th ACM Symposium on Access Control Models and Technologies (SACMAT), Yorktown Heights, USA. Ray, I., Li, N., Kim, D., France, R., 2003. Using parameterized UML to specify and compose access control models. In: Proceedings of the 6th IFI TC-11 WG 11.5 Working Conference on Integrity and Internal Control in Information Systems (IICIS), Lausanne, Switzerland. Reddy, R., Solberg, A., France, R., Ghosh, S., 2006. Composing sequence models using tags. In: Proceedings of Models Workshop on Aspect Oriented Modeling, Genova, Italy. Sanen, F., Truyen, E., Joosen, W., 2009. Mapping problem-space to solution-space features: a feature interaction approach. In: Proceedings of the 8th International Conference on Generative Programming and Component Engineering, Denver, Colorado, pp. 167–176. Segura, S., Benavides, D., Ruiz-Cortes, A., Trinidad, P., 2008. Automated merging of feature models using graph transformations. In: Lammel, R., Visser, J., Saraiva, J. (Eds.), Generative and Transformational Techniques in Software Engineering II, LNCS, vol. 5235. Springer, Heidelberg, pp. 489–505. Shin, M., Ahn, G., 2000. UML-based representation of role-based access control. In: Proc. of the 9th IEEE International Workshops on Enabling Technologies, Gaithersburg, Maryland, pp. 195–200. Song, E., Reddy, R., France, R., Ray, I., Georg, G., Alexander, R., 2005. Verifiable composition of access control and application features. In: Proceedings of the 10th ACM Symposium on Access Control Models and Technologies, Stockholm, Sweden, pp. 120–129. Störrle, H., 2003. Semantics of interactions in UML 2.0. In: Proceedings of IEEE Symposium on Human Centric Computing Languages and Environments, Auckland, New Zealand, pp. 129–136. Straw, G., Georg, G., Song, E., Ghosh, S., France, R., Bieman, J., 2004. Model composition directives. In: Proceedings of the 7th International Conference on the UML, Lisbon, Portugal, pp. 84–97. The Object Management Group (OMG), January 2002. XML Metadata Interchange. Version 1.2 Formal/2002-01-01, OMG. http://www.omg.org. The Object Management Group (OMG), November 2007. Unified Modeling Language: Superstructure. Version 2.1.2 formal/07-11-02, OMG. http://www.omg.org. Triantaphyllou, E., Mann, S., 1995. Using the analytic hierarchy process for decision making in engineering applications: some challenges. International Journal of Industrial Engineering: Applications and Practice 2 (1), 35–44. Voelter, M., Groher, I., 2007. Product line implementation using aspect-oriented and model-driven software development. In: Proceedings of the 11th International Software Product Line Conference, pp. 233–242. Warmer, J., Kleppe, A., 2003. The Object Constraint Language Second Edition: Getting Your Models Ready for MDA. Addison Wesley. Whitfield, D.L., Soffa, M.L., 1997. An approach for exploring code improving transformations. ACM Transactions on Programming Languages and Systems 19 (6), 1053–1084.

Sangsig Kim is a Ph.D. candidate in Computer Science and Informatics at Oakland University. He received the MS and BEE in Computer Software from Myongji University, Korea in 2008 and 2006, respectively. During the undergraduate and master programs, he participated in the Substation Automation System (IEC 61850) project funded by Korea Electric Power Corporation (KEPCO). His research interests include design patterns, access control modeling and formal methods. Dae-Kyoo Kim is an associate professor of the Department of Computer Science and Engineering at Oakland University. He received the Ph.D. in computer science from Colorado State University in 2004. He worked as a technical specialist at NASA\Ames Research Center in 2003 and as a senior software engineer at McHugh Software International from 1997 till 2000. His research interests include UML modeling, design pattern formalization, model refactoring, aspect-oriented modeling, software architecture modeling, access control modeling, and formal methods. He is a senior member of the IEEE Computer Society. Dr. Lunjin Lu graduated from the University of Birmingham (England) with a Ph.D. in Computer Science in 1995. From 1995 to 1999, he worked as a postdoctoral fellow at the Ecole Polytechnique in Paris, the Ben-Gurion University of the Negev, and the Univesity of Waikato. He was a lecturer at the East China Normal University from 1985 to 1990 and from 1995 to 1996 and a visiting assistant professor at the Texas State University in 1999. Dr. Lu joined the Oakland University in 2000 and is now an associate professor of engineering. Dr. Lu is interested in semantics and analysis of programs, constraint and logic programming, program debugging, programming environments, software verification. Suntae Kim is an assistant professor of the Department of Computer Science and Engineering at Kangwon National University. He received his B.S. degree in computer science and engineering from Chung-Ang University in 2003, and the M.S. Degree and PH.D. Degree in computer science and engineering from Sogang University in 2007. He worked in SoftwareCraft Co. Ltd., as a senior consultant and engineer for financial enterprise systems during 2002–2004. Also, he is involving in developing Android based Smart TV middleware since 2009 at Anypoint Media Group. His research focuses on software architecture, design patterns and requirements engineering. Sooyong Park received the Bachelor of Engineering degree in computer science from Sogang University, Seoul, in 1986, the Master of Science degree in computer science from Florida State University in 1988, and the PhD degree in information technology with a major in software engineering from George Mason University in 1995. He is a professor in the Computer Science Department at Sogang University and the director of the Requirements and Validation Engineering Center that is supported by the Korean Ministry of Knowledge and Economy. During 1996–1998, he served as a senior software engineer at TRW ISC. He is actively involved in academic activities, including as president of the Korean Software Engineering Society, a steering committee member of the Asian-Pacific Software Engineering Conference, and a guest editor of the Communications of the ACM December 2006 issue on software product lines. His research interests include requirements engineering, self-managed software architecture, and software product-line engineering. He is a member of the IEEE and the IEEE Computer Society.

A feature-based approach for modeling role-based access ... - CiteSeerX

A feature-based approach for modeling role-based access ... - CiteSeerX

Suggest Documents

A MODELING APPROACH FOR VERIFICATION OF ... - CiteSeerX

Optical Approach for Efficient Access ... - CiteSeerX

A PDF APPROACH TO MODELING TURBULENCE ... - CiteSeerX

A probabilistic approach to modeling microstructural ... - CiteSeerX

A CONCEPT-MAP MODELING APPROACH TO ... - CiteSeerX

InfoMetrics: a Structural Equation Modeling approach - CiteSeerX

Object-Role Modeling as a Domain Modeling Approach - CiteSeerX

A dual-domain mass transfer approach for modeling ... - CiteSeerX

A Queuing Modeling Approach for Load-Aware Route ... - CiteSeerX

A Beam Tracing Approach to Acoustic Modeling for ... - CiteSeerX

A New Modeling Approach for Planar Beams: Finite ... - CiteSeerX

A Queuing Modeling Approach for Load-Aware Route ... - CiteSeerX

A Semantic Approach for Access Control in Web Services - CiteSeerX

Object-Role Modeling as a Domain Modeling Approach - CiteSeerX

A Modeling Approach to Federated Identity and Access Management

A Graphical Approach for Modeling Time-Dependent ... - CiteSeerX

A Moving Average Modeling Approach for Computing ... - CiteSeerX

A Perceptual Subspace Approach for Modeling of Speech ... - CiteSeerX

A Scalable Approach for Steady State Traffic Modeling in ... - CiteSeerX

A modeling approach for prediction of erosion behavior of ... - CiteSeerX

A Quasi-species Approach for Modeling the Dynamics of ... - CiteSeerX

A Bayesian Approach for Modeling Sensor Influence on ... - CiteSeerX

A Generic Approach for Modeling Test Case Priorities with ... - CiteSeerX

A Modeling and Optimization Approach for Multiple ... - CiteSeerX