Fine-grained Role-based Delegation in Presence of the Hybrid Role Hierarchy James B. D. Joshi Elisa Bertino LERSAIS & Department of Information Science and Telecommunications, University of Pittsburgh Pittsburgh, PA 15212 CERIAS and Department of Computer Science, Purdue University West Lafayatte, IN 47907 jjoshi@mail.sis.pitt.edu bertino@cs.purdue.edu features make RBAC better suited for handling access control requirements of diverse organizations [Jos01b, San96a, Giu97]. One important organizational process that affects the access control privilege distribution among the users is delegation. Delegation involves a subject passing its authority to other subjects. Zhang et al. [Zha03a] identify three cases in which delegation takes place. The first case, termed as backup of role, corresponds to when someone is not in a position to perform the tasks that he is supposed to do. In such a case, he should be allowed to have someone else perform his job functions by delegating his authority to do the job to someone else. Secondly, delegation may be used to achieve decentralization of authority. Lastly, delegation is useful when individuals collaborate on some work – they may need to delegate their authorities to ease the collaboration. ABSTRACT Delegation of authority is an important process that needs to be captured by any access control model. In role-based access control models, delegation of authority involves delegating roles that a user can assume or the set of permissions that he can acquire, to other users. Several role-based delegation models have been proposed in the literature. However, these models consider delegation in presence of the general hierarchy type. Multiple hierarchy types have been proposed in the context of Generalized Temporal Role-based Access Control (GTRBAC) model, where it has been shown that multiple hierarchy semantics is desirable to express fine-grained access control policies. In this paper, we address role-based delegation schemes in the of hybrid hierarchies and elaborate on fine-grained delegation schemes. In particular, we show that upward delegation, which has been considered as having no practical use, is a desirable feature. Furthermore, we show that accountability must be considered as an important factor during the delegation process. The delegation framework proposed subsumes delegations schemes proposed in earlier rolebased delegation models and provide much more fine-grained control of delegation semantics. Existing role-based delegation models address delegation in presence of the traditional single hierarchy type. Recently, Joshi et al [Jos05] have identified three different types of hierarchical relations within the Generalized Temporal RBAC (GTRBAC) framework [Jos05] that can be applied between roles, namely inheritance-only hierarchy (I-hierarchy), activation-only hierarchy (A-hierarchy) and inheritance-and-activation hierarchy (IA-hierarchy). A hybrid hierarchy in which these different hierarchy types coexist can capture fine-grained inheritance semantics [Jos05 Jos02a, Jos03, San98]. In particular, when various separation of duty (SoD) as well as user-centric and permission centric cardinality constraints need to be applied on roles in a hierarchy, A-hierarchy can be used [San98, Jos02a]. The use of these hierarchy types also facilitate efficient integration of multiple RBAC policies employing hierarchical as well as SoD constraints [Sha03]. Categories and Subject Descriptors D.4.6 [Security and Protection]: Access controls; H2.7 [Database Administration]: Security, integrity, and protection. General Terms Security, Management, Theory. Keywords Role based, access control, delegation, hybrid hierarchy In presence of the multiple hierarchy types, more fine-grained delegation semantics with practical applications is possible. In this paper, we address delegation in presence of the hybrid hierarchy within the GTRBAC framework. Because of space limitation, we do not discuss cross-sectional delegation that does not involve hierarchies. The novelty of the paper is as follows: 1. INTRODUCTION Role based access control (RBAC) has emerged as a promising alternative to traditional discretionary and mandatory access control (DAC and MAC) models [Jos01b, Osb00, San96a, Giu97], which have some inherent limitations. Several beneficial • Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACMAT’06, June 7-9, 2006, Lake Tahoe, CA, USA. Copyright 2006 ACM 1-59593-354-9/06/0006...$5.00. 81 We provide a more complete delegation framework that subsumes all role-based delegation schemes proposed earlier in the literature. In addition, the proposed delegation framework also allows delegating or preventing delegation of dynamically assigned permissions during the delegation period. We introduce a novel concept of filter roles to support this feature, which, to the best of our knowledge, has not been addressed earlier. • The proposed delegation framework introduces upward delegation that allows a user assigned to a junior role to delegate his authority to a user assigned to a senior role. Contrary to earlier belief, we show that upward delegation is practically relevant, particularly when hybrid hierarchy is used. Further, we argue that upward delegation is also important to enhance support for accountability. 3. HYBRID HIERARCHY IN GTRBAC The GTRBAC model introduces the separate notion of role enabling and role activation, and provides constraints and event expressions associated with both [Jos05]. An enabled role indicates that a valid user can activate it, whereas an activated role indicates that at the least one user has activated the role. The basic GTRBAC model proposed in [Jos05], allows specification of the following set of constraints: (i) temporal constraints on role enabling/disabling that allow specification of intervals and durations in which a role is enabled; (ii) temporal constraints on user-role and role-permission assignments that allow specifying intervals and durations in which a user or permission is assigned to a role; (iii) activation constraints that allow specification of restrictions on the activation of a role, such as, specifying the total duration for which a user may activate a role, or the number of concurrent activations of the role at a particular time; (iv) runtime events allow an administrator and users to dynamically initiate the various role events, or enable the duration or activation constraints; (v) constraint enabling events that enable or disable duration and role activation constraints mentioned earlier; and (vi) triggers that allow expressing dependencies among events and conditions While different combinations of delegation and revocation schemes are possible, because of the space limitation, we focus on single step delegation and revocation only. For such simple cases, the revocation details are straightforward and hence, for the sake of space, are presented in the tables and only briefly discussed. The paper is organized as follows. We overview related work in Section 2 and the GTRBAC model in Section 3. We present the proposed delegation framework in Section 4 and conclusions in Section 5. 2. RELATED WORK Considerable work on different aspects of delegation has been reported in the literature. Gasser et al. address user-to-machine delegation [Gas90], while Stein explores delegation and inheritance in the object-oriented environment [Ste87]. Process to process delegation in distributed object environment has been introduced by Nagaratnam et al. [Nag98]. Sandhu et al. address delegation related to role administrators in ARBAC97 model [San99]. Goh et al. treat delegation as an attribute of role [Goh98]. RBDM0 allows user-to-user delegation based on roles [Bar00a, Bar00b]. That is, a user (delegator) assigned to a role (delegator role) delegates his role membership to another user (delegatee) assigned to another role (delegatee role). In RBDM0, a role is delegated entirely, i.e., all the permissions associated with the delegated roles are available to the user to whom the role has been delegated. RDM2000 extends RBDM0 and supports delegation in presence of a role hierarchy and multi-step delegation. RDM2000 provides a rule based declarative language to specify and enforce delegation and revocation policies. It introduces the can_delegate condition with prerequisite roles to restrict the scope of delegation. In both RBDM0 and RDM2000, the unit of delegation is a role. PBDM is a family of models that extend RDM2000 with newer features. PBDM0, the first model of PBDM, supports permission level user-to-user delegation, i.e., a subset of permissions is allowed to be delegated. In particular, a new “delegation” role is created with the set of permissions to be delegated explicitly assigned to it. PBDM1 extends PBDM0 by allowing the security administrator to control the delegated permissions. Here, the delegated role, which is a replica of an original role is created by the security administrator in order to control the flow of the delegated permissions. PBDM2 extends PBDM0 by allowing role-to-role delegation. Delegation based on conditions on time, workload and other task attributes have been considered in [Atl05]. Wainer et al. focus on user to user delegation in [Wai05]. Some work, e.g., [Tho97], have dealt with adding permissions to a session dynamically to facilitate collaborative work. Semantically, a role hierarchy expands the scope of the permission-acquisition and role-activation semantics beyond the explicit assignments through the hierarchical relations defined among roles. Within the GTRBAC framework, the following three hierarchy types have been identified: permissioninheritance-only hierarchy (I-hierarchy), role-activation-only hierarchy (A-hierarchy) and the combined inheritance-activation hierarchy (IA-hierarchy) [Jos05]. Table 3.1 captures the predicate notations used in defining the semantics of these hierarchies [Jos05]. Predicates enabled(r, t), assigned(u, r, t) and assigned(p, r, t) refer to the status of roles, user-role and role-permission assignments at time t. Predicate can_activate(u, r, t) indicates that user u can activate role r at time t implying that user u is implicitly or explicitly assigned to role r. active(u, r, s, t) indicates that role r is active in user u’s session s at time t whereas, acquires(u, p, s, t) implies that u acquires permission p at time t in session s. The axioms in Table 3.1 capture the key relationships among these predicates and identify precisely the permission-acquisition and role-activation semantics in GTRBAC [Jos05]. Axiom (1) states that if a permission is assigned to a role, then it can be acquired through that role. Axiom (2) states that all users assigned to a role can activate that role. Axiom (3) states that if a user u can activate a role r, then all the permissions that can be acquired through r can be acquired by u. Similarly, axiom (4) states that if there is a user session in which a user u has activated a role r then u acquires all the permissions that can be acquired through role r. We note that axioms (1) and (2) indicate that permission-acquisition and role-activation semantics are governed by explicit user-role and role-permission assignments. In Table 3.2, the semantics of each hierarchy type is defined by its corresponding implication rule in the shaded box. The rule for the I-hierarchy, (x≥ty), implies that if (x≥ty) holds, then the permissions that can be acquired through role x include all the permissions that can be acquired through role y. In other words, permissions of the junior roles are inherited by the senior role. Similarly, the rule for the A-hierarchy implies that if user u can activate role x, and x≿ty is defined, then user u can also activate The framework we propose in this paper is closely related to the RBDM0 [Bar00a, Bar00b], RDM2000 [Zha03b] and PBDM [Zha03a] models and extends the features they provide with more fine grained delegation semantics aligned with the fine-grained semantics of hybrid hierarchies [Jos02a]. 82 Table 3.1 Status predicates Predicate Meaning Axioms enabled(r, t) Role r is enabled at time t u_assigned(u, r, t) User u is assigned to role r at time t p_assigned(p, r, t) Permission p is assigned to role r at time t For all r ∈ Roles, u ∈ Users, p ∈ Permissions, s ∈ Sessions, and time instant t ≥ 0, the following implications hold: 1. assigned(p, r, t)→ can_be_acquired(p, r, t) can_activate (u, r, t) User u can activate role r at time t 2. assigned(u, r, t) → can_activate (u, r, t) can_acquire (u, p, t) User u can acquire permission p at time t can_be_acquired(p, r, t) Permission p can be acquired through role r at time t 3. can_activate (u, r, t) ∧ can_be_acquired(p, r, t) → can_acquire (u, p,t) active(u, r, s, t) Role r is active in user u’s session s at time t acquires(u, p, s, t) User u’ acquires permission p in session s at time t Table 3.2. Role hierarchies in GTRBAC Short form Notation Formal Semantics (x≥ty) ∀p, (x≥ty) ∧ can_be_acquired(p, y, t) → can_be_acquired(p, x, t) A-hierarchy (x≽ty) ∀u, (x≽ty) ∧ can_activate (u, x, t) → can_activate (u, y, t) IA-hierarchy (x≿ty) I-hierarchy (x≿ty) ↔ (x≥ty) ∧ (x≽ty) Consistency Property: Let <f1><f2> ∈{≥t, ≽t, ≿t}, and x and y be distinct roles such that (x<f1>y) then ¬(y <f2> x) must hold Table 4.1 Notational Conventions and New GTRBAC Terms/notation Description delegator delegatee delegator role delegatee role delegation role delegation sub-role x<f>y,<f>∈{≥,≽,≿} x<f>gy, <f>∈{≥,≽,≿} Project Leader assigned to u1 (PL) h = I-hierarchy taskR assigned to In this section, we extend the GTRBAC model to capture various delegation schemes in presence of different hierarchies. Table 4.1 introduces some terminologies that we use in this paper. In particular, delegator, delegatee, delegator role, delegatee role and delegation role/sub-role have specific meanings. If x is the delegator role then we use x’ to represent the delegation role. u2 u3 u4 u5 A-hierarchy No.of activations ≤ 4 (permission-centric) y is direct or derived junior of x 4. GTRBAC DELEGATION FRAMEWORK (Fridays, enable h) I-hierarchy A user who delegates his authority A user who receives the delegated authority Role that the delegatee is assigned to Role that the delegatee is assigned to A copy of delegator role that the delegatee is assigned to achieve delegation A copy of role to which there is a hierarchical path from the delegator role. x is direct senior of y with hierarchy type <f> more than four users using it at any given time. The project leader mainly supervises the programming tasks. Only the programmers do the coding. The project leader can only look at the tasks the programmers have carried out in a weekly basis, say on Fridays. Figure 3.1 depicts the hierarchy that can be generated for achieving the goal1. Role TaskR contains the read-only permissions whereas role TaskW contains all the write/modify permissions related to the programming task. The Project Leader role becomes the senior of Programmer role only on Fridays. Note that the users assigned to the Project Leader only inherit TaskR permissions and cannot acquire any permissions of TaskW. role y even if he is not explicitly assigned to y. Note that it does not imply that user u can acquire y’s permissions by merely activating x. In other words, permission-inheritance is not implied in an A-hierarchy. The IA-hierarchy is the most general form and includes both permission-inheritance and role-activation semantics. In the remaining sections we do not use the time parameter t in any expression. Programmer (P) 4. active(u, r, s, t) ∧ can_be_acquired(p, r, t) → acquires(u, p, s, t) 4.1 Role-based Delegation Schemes taskW Figure 4.1 shows the delegation schemes allowed in the proposed GTRBAC framework. Figure 3.1 Hierarchy example Example 3.1: Assume that a programming tool is used for a programming project and has a licensing restriction preventing 1 83 I, A and IA-hierarchies are represented by a simple line, a dotted line and a line with arrows on both ends, respectively. who are assigned to higher roles. One such situation in hybrid hierarchies is when there is an I-relation followed by an A-relation from the senior delegatee role (say x) to the junior delegator role (say z), i.e., when x ≥g y and y≽z. In such a case, a user assigned to x cannot acquire any permission that can be acquired through role z. The user cannot activate y either, because of the I-relation. Hence, some form of delegation needs to be utilized if the junior delegator role is to be delegated to the delegatee assigned to the senior delegatee role. Example 4.2 illustrates such a case. 4.1.1 U2U, R2R , U2R, and R2U Delegation Broadly speaking, in an RBAC model, delegation can be user-touser (U2U), user-to-role (U2R), role-to-role (R2R) or role-touser (R2U). In U2U delegation, a delegator delegates a delegator role or a part of it to the delegatee based on the relationship between the delegator role and the delegatee role. In R2R, the delegation is not user specific - the delegator role is delegated to the delegatee role. This means, anyone who can activate the delegatee role can also activate the delegation role. The key difference is, in U2U, a user primarily decides (although not always) who he wants to delegate his role to, while in R2R, a role is delegated to another role (hence to all its authorized users) by the system based on some pre-specified rule. R2R can be viewed as a special case of the U2U delegation in which the delegator role is delegated to all the users authorized for the delegatee role. U2R and R2U delegations can be considered as in the middle of the two extremes U2U and R2R. That is, in U2R, an individual user delegates his role to the delegatee role, while in R2U, the delegator role is delegated to an individual delegatee. Example 4.1: Let us revisit example 3.1 and refer to Figure 4.2. Here, a user assigned to the PL role cannot acquire the permissions of the taskW role. Assume that one of the users, say John, assigned to P gets sick and his tasks need to be carried out by a user authorized for the PL role. The delegation involves giving the project leader the ability to activate taskW on John’s behalf. This can be achieved in several ways for this particular RBAC hierarchy and set of assignments. Figure 4.2(b) shows one way in which the delegation roles P’ and taskW’ are created as Iseniors of P and taskW. PL is made A-senior of P’. Hence, anyone assigned to PL can activate both P’ and taskW’. It could be an R2R delegation or a U2R delegation depending upon whether the system or John authorizes the delegation. Figure 4.2(c) shows the second case of U2U delegation (or R2U if the system rather than John is responsible for authorizing delegation), where user u1 is explicitly assigned to the senior role P’. Figure 4.2(d) shows the delegation role P’ assigned to the user u1 (hence it is U2U or R2U delegation). Here, P’ is assumed to have been explicitly assigned the set of permissions to be delegated that can be acquired through roles P and taskW. 4.1.2 Downward, Cross-sectional and Upward Delegation Each delegation scheme may further be categorized as downward, cross-sectional or upward. In downward and upward delegation schemes, the delegator role and the delegatee role are hierarchically related by direct or derived I, A, or IA relations. In downward delegation, the delegator role is a senior of the delegatee role, whereas, in the upward delegation, the delegator role is a junior of the delegatee role. In cross-sectional delegation, the delegator role and the delegatee role are not hierarchically related. Both downward and cross-sectional delegation schemes have been the main focus of earlier role-based delegation models. Upward delegation, however, has been dismissed as not being of any practical use [Zha03a]. In this paper, we introduce upward delegation primarily for two purposes The example shows that delegation in hybrid hierarchies becomes complex and more fine-grained control of delegated permission can be imposed. For instance, in figures (b) and (c), if we do not include taskW’, the delegation would include only permissions authorized for P. We could also simply delegate taskW by not including P’, and making taskW’ an A-junior of PL in (b) or by assigning u1 to taskW’ in (d). RBAC RBAC Delegation Delegation Schemes Schemes assigned to PL U2U U2U delegation delegation U2R U2R delegation delegation R2R R2R delegation delegation assigned to P Downward Downward assigned to u1 PL u1 R2U R2U delegation delegation Cross-sectional Cross-sectional Upward Upward u2 u3 u4 u5 (a) P’ P (b) taskW’ Total Total Partial Partial Total Total Partial Partial Total Total Partial Partial PDR PDR PAP PAP PDR PDR PAP PAP PDR PDR PAP PAP taskR taskW assigned to PL BA BA TEA TEA PAP: Partial Authorized Permissions BA: Blocking Assignment TEA: Total Explicit Assignment BA BA TEA TEA BA BA taskR taskW assigned to u1 PL u1 assigned to TEA TEA assigned to P’ R2R-PDR-TEA or R2R-PAP-TEA delegation P (c) (d) Figure 4.1 GTRBAC delegation schemes (1) to facilitate fine-grained delegation in presence of the hybrid hierarchy and (2) to provide more fine-grained support for accountability of delegated authority. taskR P P’ taskW’ taskW taskR taskW Figure 4.2 Upward delegation example Accountability: As shown in example 4.1, it may be necessary for a user who is assigned to a junior role to delegate his authority to a user assigned to a senior role. However, as a delegatee, the project leader should be made accountable for any work that he does on behalf of the delegator. Note that as a user assigned to a Presence of hybrid hierarchy: In a hybrid hierarchy, a complex inheritance and activation semantics between an arbitrary pair of roles may exist. In such a case, the upward delegation comes as a desirable mechanism to transfer user’s access authority to others 84 Table 4.2 Can delegate policy statement forms Can delegate statement (cd) cd1 cd2 cd3 can_delegate(rd, re) can_delegate(rd, ue,re) can_delegate(ud, rd, ue,re) cd4 can_delegate(ud, Pd, ue, re) cd5 can_delegate(ud, Pd , ue, re) Meaning Role rd can be delegated to re (R2R) Role rd can be delegated to user ue assigned to role re (R2U) User ud can delegate role rd to user ue assigned to role re (U2U) User ud can delegate permission set Pd to user ue assigned to role re if the following holds: ∀ p∈Pd , can_acquire(ud, Pd) (U2U) User ud can delegate permission set P- Pd to user ue assigned to role re if the following holds: Pd ⊆P ∧∀p∈P, can_acquire(ud, Pd). (U2U) acquired by the delegatee. The TEA scheme, on the other hand, involves explicitly assigning the set of permissions that are to be delegated. Exisitng role-based delegation models use the TEA scheme for partial delegation and do not support the BA scheme. It is to be noted that the TEA scheme is static in nature and hence cannot be used in dynamic environments where role-permission assignments can continually change over time as is possible in the GTRBAC model. However, the TEA scheme is useful in cases where the delegator wants to ensure that in the delegation period, the delegatee does not have access rights that may be dynamically assigned/authorized to the delegation role. The advantage of the BA approach is that during the delegation period, if new permissions are available to the delegation role through new permission assignments to the delegator role or sub-roles, they will also be available to the delegatee. Furthermore, it also allows blocking sensitive permissions that exist prior to delegation or that may be available during the delegation period. senior role, the delegatee has access to the delegator role prior to the delegation as well. However, after delegation, accountability becomes a key issue, as the delegatee will be exercising permission on behalf of the delegator. Key to achieving accountability is to record the session information that indicates roles that are active in a delegatee’s session and the permissions that have been acquired through the active roles. Accountability has not been considered as a factor in earlier delegation models. 4.1.3 Total and Partial Delegation Each of the delegation schemes can further be categorized as total delegation (TD) or partial delegation (PD). In TD, unlike in PD, the entire authority that the delegator role embodies is delegated. That is, all the permissions that he can acquire (through assignments and inheritance) are made available to the delegatee. Such an approach will not be able to provide fine-grained control on delegation. In particular, the delegator role may represent authority to carry out several different tasks, particularly, if it is at the higher level of a role hierarchy. In such a case, the delegatee may simply want to delegate a part of the role that represents a particular subset of the delegated permissions. In earlier models, delegation schemes have only considered the permissions explicitly assigned to the delegation role instead of all the permissions that can be acquired through a role (using I-relations) or through the activation of authorized roles (using A-hierarchy). Our framework allows delegating the entire set of permissions that the delegatee can acquire by virtue of his membership to the delegator role. Initial GTRBAC Policy Configuration delegate rd to u e Delegation process revoke rd from u e Can delegate Policy base Partial delegation may be enforced using different schemes. In our framework, we allow it in two ways: (1) blocking assignment (BA), and (2) total explicit assignment (TEA). In the BA scheme, permissions that are not to be delegated are blocked from being New GTRBAC events enable r [ ud]:delegate rd to ue disable r [ ud]:revoke rd’ from u2 assignU r to u [ ud]:delegate rd to re deassignU r to u [ ud]:revoke rd’ assignP p to r block_assignP p to r deassignP p to r block_deassignP p to r Modified GTRBAC Policy Configuration Figure 4.3 Delegation and revocation process 4.2 Delegation and revocation in presence of the I, A and IA-hierarchies Table 4.3 Extended GTRBAC Events Existing GTRBAC events Revocation process Here, we detail fine-grained delegation semantics for each of the hierarchy types mentioned earlier. We differentiate several cases based on the hierarchical relations between the delegator role and the delegatee role. For each delegation scheme, we present the revocation scheme that follows the reverse steps. We focus on single step delegation and revocation only. For such simple cases, the revocation details are straightforward. We assume that a can delegate policy is specified to indicate who can delegate or which role can be delegated to which entities (users or roles). Formally, a can delegate policy base is defined as follows: s: activate r for u s: deactivate r for u 85 condition as the new definition of the I-hierarchy as it now allows filter roles to be a part of the role hierarchies. We use a filter role to support the BA scheme. Definition 4.1 (can delegate policy): A can delegate policy base (CDPB) is a set of expressions of the forms listed in Table 4.2. We extend the existing event set of GTRBAC with new events listed in Table 4.3 to facilitate the delegation process. Figure 4.3 depicts the general delegation process using an informal petri-net diagram. Delegation process is initiated by a delegation event provided there is a can delegate policy statement authorizing the event. For example, if the “ud: delegate rd to ue” event occurs, the system has to first ensure that there a role re for which cd3 ∈ CDPB, u_assigned(ud, rd) = true, and u_assigned(ue, re) = true. The delegation process includes creation of new roles and assignments as well as hierarchical structures to facilitate the intended delegation. The result hence is a new GTRBAC policy base. Given the modified policy base, a revoke event initiates the revocation process to undo the changes done by the delegation process. For our purpose, it involves removing newly created roles, new assignments and hierarchy structures to bring the policy back to the initial configuration. In actual implementation, it may simply be disabling the new entities created by the delegation process. 4.2.1 Downward Delegation in I-hierarchy Figure 4.4 depicts the delegation schemes when the delegator role rd is I-senior of the delegatee role re i.e., (rd ≥g re). Table 4.4 shows the delegation processes for each of them. The delegatee role may be related to junior roles through any of the three hierarchy types. To generalize the construction, the hierarchy includes three juniors (roles a, b and c) each related to the delegatee role with one hierarchy type. Total delegation (TD): Here, the delegatee needs to totally delegate the delegator role to the delegatee. As shown in Figure 4.4(b), the delegation role rd’ is created and the delegatee is assigned to it. rd’ is an empty role which is made I-senior of the delegator role. The delegatee can now activate rd’and acquire all the permissions that can be acquired through role rd because of the I-relation. However, the delegatee cannot activate rd and any roles junior to rd. Accountability is easily facilitated if we maintain an audit log of the sessions in which the delegation role is activated by the delegatee. Note that any of the permissions that can be acquired through the delegatee role (including those of re as as (rd≥g re) may be used by the delegatee. To support the blocking of a specified set of permissions from being delegated in BA schemes, we introduce filter roles, which are indicated by a line above the role name. A filter role is associated with a set of permissions, through what we call blocking assignments that are not to be made available through that role. In essence, a filter role may also have normal permission assignments. To define the filter roles, we introduce special blocking assignment event “block_assignP p to r ” and an associated status predicate block_p_assigned(p, r ,t) which implies that p is associated with role r through blocking assignment at time t. The semantics of the filter role is captured by the following definition: ue ue rd’ ue ue rd rd’ TD rxd rxd y PDR-BA (b) rd’ rd’ rxd re PDR-TEA (i) y y PDR-TEA (ii) y (c) a a ue PD R y ∀p, (x≥ r ) ∧ can_be_acquired(p, r , t) ∧ ¬block_p_assigned(p, r , t)→ can_be_acquired(p, x, t) (where y is a normal or a filter role) (new definition of I-hierarchy) c al • ue b rd re b Partial PAP c (a) ue y’ rd ’ rd’ rd rxd Pa rti ud Total Definition 4.2 (filter role): A filter role r is a special role for which the following rules apply: • block_p_assigned(p, r , t)→ ¬ can_be_acquired (p, r , t) (axiom 5) re ’ PAP-BA (i) PAP-TEA (ii) y OR Similar to PDR-BA (d) y OR Similar to PDR-TEA Figure 4.4 Downward delegation in I-hierarchy Partial Delegator Role (PDR): As indicated earlier, this scheme allows a subset of permissions explicitly assigned to the delegator role to be delegated. Inherited permissions are, however, passed on in totality. This can be achieved in two different ways as shown in Figure 4.4 (c). The first scheme, PDR-BA, involves specifying the permissions Pd of rd that are not to be delegated. Furthermore, we assume that for all normal permission-role assignments for which p_assigned(p, r, t) is true, block_p_assigned(p, r, t) is false. We use the first condition in the definition as a new axiom. The effect of axiom 5 is that permissions associated with the filter role through the blocking assignment cannot be acquired in a session. This is because, axiom 4 states that only those permissions that can be acquired through a role are acquired by a user who has activated that role – and axiom 5 essentially ensures that the blocking-assigned permissions cannot be acquired through that role. This condition, however, does not prevent the blockingassigned permissions from being acquired through a senior role, if the permissions that are to be blocked are inherited by the filter role from other roles. The second condition blocks the permission acquisition through hierarchy relation. This ensures that only permissions that can be acquired through a role and not blocked by it can be acquired through its I-senior role. We use the second As shown in the table, the delegation role is rd' a filter role to which Pd is blocking assigned. However, other permissions can be acquired through rd' because of the I-inheritance and are hence delegated to the delegatee. The second scheme, PDR-TEA can be implemented in two ways. In TDR-TEA(i), only the permissions assigned to rd that are to be delegated are assigned to rd’, which is made senior of rd’s junior role so that the permissions below the hierarchy are inherited. In TDR-TEA(ii), however, all the 86 Table 4.4. Semantics for the downward delegation in I-hierarchy2 Scheme TD cd3 ∈ CDPB; u_assigned(ud, rd) = true u_assigned(ue, re) = true Delegation process delegate rd to ue (1) create rd’; (2) add (rd’ ≥ rd) to H; (3) assignU rd’ to ue (1) Create PDR-BA cd5 ∈ CDPB; u_assigned(ud, rd) = true u_assigned(ue, re) = true Revocation Process revoke rd’ from ue (1) deassignU rd’ to ue (2) remove (rd’ ≥ rd) from H; (3) delete rd’ rd, (1) deassignU rd, to ue (2) ∀p∈ Pd , block_assignP p to rd, (2) ∀r, s.t. (rd’≥ r) ∈ H, remove ( rd, ≥ r) from H (3) ∀r, s.t. (rd ≥ r) ∈ H, add ( rd, ≥ r) to H (3) delete rd, (4) assignU rd, to ue PDR-TEA(i) Cd4 ∈ CDPB; u_assigned(ue, re) = true (1) create rd’ (2) ∀p∈ Pd , assignP p to rd’ (3) ∀r, s.t. (rd ≥ r) ∈ H, add (rd’ ≥ r) to H (4) assignU rd’ to ue (1) deassignU x’ to u2 (2) ∀r, s.t. (x’≥ r) ∈ H, remove (x’ ≥ r) from H (3) ∀p∈ assigned(p, x’), deassignP p to x’ (4) delete x’ PDR-TEA (ii) Cd4 ∈ CDPB; u_assigned(ue, re) = true (1) create rd’ (2) ∀p∈ Pd , assignP p to rd’ (3) assignU rd’ to ue (1) deassignU rd’ to ue (2) ∀p∈ assigned (p, rd’), deassignP p to rd’ (3) delete rd’ (1) Create PAP-BA cd5 ∈ CDPB; u_assigned(ud, rd) = true u_assigned(ue, re) = true X’: new filter delegation roles/sub-roles created (Or similar to PDR-BA) rd, (2) ∀p∈ Pd , assigned(p, rd) = true, block_assignP p to rd, (2) ∀r, s.t. (rd ≥ r) ∈ H, ∃p∈ Pd , assigned(p, r) = true (a) create r , ; (b) add ( r , ≥ rd, ) to H ; (c) block_assignP p to r , (3) ∀r1, r2, s.t. (rd ≥g r1) and (r1≥ r2)∈ H, ∃p∈ Pd , assigned(p, r2) = true (a) create r2, ; (b) add ( r2, ≥ r1, ) to H (c) block_assignP p to r2, (4) assignU PAP-TEA Cd4 ∈ CDPB; u_assigned(ue, re) = true X’: new delegation roles/sub-roles created (Or similar to PDR-TEA) rd, to ue (2) ∀ r1, , r2, ∈ X’, s.t. ( r1, ≥ r2, ) ∈H, (a) remove ( r1, ≥ r2, ) from H (b) delete r1, (c) delete r2, rd, to ue (1) create rd’ (2) ∀r, s.t. (rd ≥ r) ∈ H, ∃p∈ Pd , assigned(p, r) = true (a) create r’; (b) add (rd’ ≥ r’) to H (3) ∀r1, r2, s.t. (rd ≥g r1) and (r1≥ r2)∈ H, ∃p∈ Pd , assigned(p, r2) = true (a) create r2’; (b) add (r1’ ≥ r2’) to H (4) ∀r’∈ X’, ∀p∈ Pd , assigned(p, r) → assignP p to r’ (5) assignU rd’ to ue (1) deassignU rd’ to ue (2) ∀r’1, r’2∈ X’, s.t. (r’1 ≥ r’2) ∈H, (a) remove (r’1 ≥ r’2) from H (b) delete r’1 (c) delete r’2 details). The PAP-TEA scheme can be implemented similar to that of PDR-TEA method. Again the difference would be that the delegation role now is assigned all the permissions that can be acquired through the delegator role, while in PDR-TEA, only the subset of permission that are directly assigned to the delegator role is assigned to the delegation role. Figure 4.4(d) shows another way to implement this scheme by creating the delegation role and sub-roles. permissions that can be acquired through rd are assigned to the delegation role rd’. Partial Authorized Permission (PAP): PAP allows only a subset of permissions that can be acquired through the delegator role to be delegated to the delegatee. The BA and TEA approaches to achieving this are shown in Figure 4.4(d). PAP-BA can be implemented similar to the PDR-BA (hence, the steps for PDRBA can be reused with a minor modification). Here, all the permissions that can be acquired through rd (not just those assigned to rd, as in PDR-BA) but not to be delegated are blocked. Another way to achieve it is by creating each delegation sub-role and explicitly filtering from each delegation sub-role the permissions of the delegator sub-role that are not to be delegated. However, this would require reversing the hierarchical relations among the filter roles as shown in Figure 4.4(d) (see table for the 2 (1) deassignU It is to be noted that, besides the difference between BA and TEA schemes (i.e., dynamic vs. static), the BA method is preferable when the permissions that are to be blocked from being delegated is relatively small. The TEA scheme is more appropriate when only a small subset of permissions is to be delegated. Furthermore, although the PAP-BA and PAP-TEA scheme is easily implemented as in PDR-BA and PDR-TEA, the alternatives shown in Figure 4.4(d) will be required when the delegator roles/subroles have different temporal properties (e.g., enabling times). In such cases, employing the PAP-BA and PAP-TEA schemes similar to the PDR counterparts will not maintain these The tables only show U2U delegation. R2R delegation can be easily derived from these. 87 to be delegated; (2) unlike in PDR-BA, no hierarchical relation from rd’ to rd is created. Table 4.5 shows the details. temporal properties. Because of space limitation, how temporal hierarchies affect delegation semantics is not discussed in this paper3. rd’ rd’ rxd u1 rxd ue y’ y’ re’ PDR-BA b’ a b c rd’ rd ’ y’ y delegation sub-role re’ for the delegatee role re (note that it is also the delegator role) are related to the junior delegation sub-roles by the same hierarchical relations that relate the corresponding delegatee role with its corresponding juniors. The PAP-TEA scheme can be implemented similar to that of the PAP-BA scheme. Only difference is that the delegation role and all the delegation sub-roles are not hierarchically related to their original roles. PAP-BA re’ rze a’ a’ ue y re’ c PDR-TEA y’ ue (a) b a , for role a is created as shown in Figure 4.5(d); (2) the rxd PAP-TEA re a y c’ rd ue (c) rze (b) ud y’ y u2 b’ c’ (d) b’ a c’ b 4.2.3 Downward Delegation in IA-hierarchy Note that the IA-hierarchy is one that allows both permissioninheritance and role-activation semantics. This implies that when the delegator role is the IA-senior of the delegatee role, we can capture the delegation semantics by using the delegation schemes for I and A-hierarchies. Hence, we only illustrate the schemes in figures and do not provide details of each step. We categorize the following cases: c Figure 4.5 Downward delegation in A-hierarchy 4.2.2 Downward Delegation in A-hierarchy Figure 4.5 shows various downward delegation policies when the delegator role and the delegatee role are related by an Ahierarchy, i.e. the case (rd≽gy) and (y≽re). Permission-only (or activation-only) delegation: Here only authorized permissions (or role activations) are delegated. In permissions-only (activations-only) delegation the role activation (permission-inheritance) semantics is not delegated. Hence, for permissions-only (activations-only) delegation, we apply the Ihierarchy (A-hierarchy) semantics described earlier. In particular, in permissions-only delegation only the delegation role is created and the delegatee assigned to it, as shown in Figure 4.6. The authorized permissions are made available to the delegatee when he activates the delegation role. Note that in the original role hierarchy, the delegator has authority to activate junior roles as well. This capability is not delegated. Total delegation (TD): The delegatee needs to delegate in totality the delegator role to the delegatee. As shown in Figure 4.5(b), the delegation role rd’ and the delegation sub-roles are created and the delegator is assigned to rd’. Each of the delegation role/subroles created is an empty role and is made I-senior of its corresponding delegator role/sub-role. The delegatee can activate the main delegation role but to acquire the permissions of the roles junior to the delegator role, the delegatee has to activate the corresponding delegation sub-role. This is in par with the role activation capability of the delegator in the original hierarchy – the delegatee should be able to activate juniors but he does not acquire all the permissions simply by activating the main delegation role. Accountability is facilitated if we maintain log of the sessions in which the delegatee activates a delegation role/sub-role. ue ue ue rd rd’ TD Note that there is even a delegation sub-role re’ corresponding to the delegatee role re. Because of the separate A-path, the accountability can be easily achieved by logging the session information. The steps needed for enforcing this scheme is shown in Table 4.5. It is to be noted that if the delegatee role is related to its junior by an I-hierarchy, the delegation sub-role corresponding to that junior need not be created because the delegatee can acquire its permissions through the delegation role. rd’ rd’ rxd rxd rxd y PDR-BA (b) re PDR-TEA (i) y y PDR-TEA (ii) y (c) a ud Partial Delegator Role (PDR): PDR-BA scheme involves employing a filter delegation role as shown in Figure 4.5(c). The remaining part of the hierarchy structure below delegator role rd is recreated as in TD. PDR-TEA can be implemented similar to PDR-BA as shown in Figure 4.5 (c). Only difference will be (1) the delegation role rd’ is assigned all of rd’s permissions that need ue a b c ue rd y 3 ue rd’ PD R y tia l TD ue Total rxd Partial Authorized Permission (PAP): The first PAP scheme, PAP-BA is almost the same as TD. The difference is: (1) unlike in the TD, even the filter delegation sub-role for all roles in the subhierarchy below rd (inclusive of rd) is created; e.g., even filter role rd’ re b Partial PAP c (a) ue y’ rd’ rd’ rd rxd Pa r ue re’ PAP-BA (i) PAP-TEA (ii) y OR Similar to PDR-BA (d) y OR Similar to PDR-TEA Figure 4.6. Permission-only delegation Permission-and-activation delegation: This feature allows both the authorized permissions and role activation capabilities to be We refer the readers to reference [Jos02a] for relevant information on temporal hierarchies. 88 delegated. The downward delegation in IA-hierarchy from the delegator role to a delegatee can be obtained by making simple modifications to the A-hierarchy, shown in Figure 4.7, as the structural changes are similar. ue rd’ rd’ rxd rd’ rxd u1 rxd ue y PDR-BA b’ a b c rd’ rd ’ a’ b’ ud ue rd’ rd b’ a b c a b c’ c rze (a) a’ y ⊗ (a) rd TD PAP-BA re’ re ’ re ud y re ⊗ (b) ⊗ y’ ue ue ⊗ indicates I, A or IA relation y ue rxd PAP-TEA c re ⊗ y’ y b ue PDR-TEA (c) c’ rd a y rze (b) ue y’ y u2 re ’ ud ue y’ y’ TD Partial Authorized Permissions (PAP): For PAP-BA scheme, the newly created delegation role rd' is made I-senior of the delegator role rd. As shown in Figure 4.8, the filter delegation sub-roles for A and IA-juniors (b and c) of the delegator role rd are created and made A-juniors of the delegation role ( rd' ) and the I-seniors of their corresponding roles, respectively. For the PAPTEA, the sub-hierarchy with the delegator role rd as the seniormost role is recreated and the original hierarchical relations are c’ (d) b’ a c’ b ue rd’ c 4.2.4 Upward Delegation in hybrid hierarchy For upward delegation the delegator role is junior to the delegatee role. Hence, as in downward delegation, we do not have to worry about the various hierarchical relations that may exist between the two roles. As the steps can be easily derived as in tables 4.4 and 4.5, and because of the lack of space, we illustrate various U2U delegation schemes through the transformations illustrated in Figure 4.8. rd’ b’ c’ b c PDR-BA ue rd’ a’ b’ (d) (c) a Figure 4.7 Permission and activation delegation ue rd’ b’ c’ a PDR-TEA a b’ c’ b c PAP-BA c’ PAP-TEA Figure 4.8 Upward delegation in a hierarchy introduced between corresponding delegation roles and sub-roles, as depicted in Figure 4.8. 5. CONCLUSION AND FUTURE WORK Total delegation (TD): For the TD, we create the delegation role (rd’) and make it the I-seniors of the delegator role rd. For each of the roles that is I or IA-junior of the delegation role (rd), we create a delegation sub-role and make it A-junior of the delegation role rd’. The delegation role and the delegation sub-roles are empty roles but are I-senior of the corresponding original roles. The delegatee is assigned to the delegator role as usual. The delegatee can activate each role separately, conforming to the original semantics. Note that we do not create a delegation sub-role for a role that is I-junior to the delegator role (role a in the figure) - the I-hierarchy between the delegation role and the delegator role allows the inheritance and hence the junior’s permissions (role a’ permissions in the figure) are acquired through rd’ by the delegatee. We have addressed the issues of delegation within the context of different role hierarchy types and hybrid hierarchies. We have presented several fine-grained downward and upward delegation schemes. We have shown that upward delegation plays an important role within the RBAC models. Furthermore, we argued that accountability consideration is crucial when delegation policies are considered. This affects the use of hierarchical relations when, during the delegation process, new roles are created. The delegations schemes subsume existing role-based delegation schemes. Due to space limitation, we focused on userto-user delegation which is more fine-grained than role-to-role delegation and hence R2R delegation schemes can be easily derived from the U2U schemes presented here. Furthermore, cross-sectional delegation was not addressed due to space limitation; but it is simpler than delegation in the presence of hierarchies and can be easily derived from downward and upward schemes presented in detail here. Furthermore, we have not dealt with constraints on delegation such as specifying intervals or durations in which the delegation is to be valid, as well as the multi-step delegation and revocation schemes. We plan to pursue these as future work. Another future work is to develop a generic analysis framework for verifying correctness of policies when hierarchical, SoD, and delegation policies co-exists. Partial Delegator Role (PDR): The PDR-BA scheme is similar to TD scheme. Only difference is that here the delegation role rd' is related to delegation sub-roles by the same hierarchical relations as those of their corresponding delegator role and sub-roles (filter) respectively. As in previous cases, the permissions assigned to the delegator role rd and any I-junior of rd not to be delegated are filtered. The PDR-TEA is similar to PDR-BA – the only difference is, here, no delegation role/sub-role is hierarchically related to its corresponding delegator role/sub-role. The permissions to be delegated corresponding to each delegation role/sub-role are explicitly assigned to them. Acknowledgement: This research has been supported by the US National Science Foundation award IIS-0545912. We thank the anonymous reviewers for their helpful comments. 89 [Liu04] R.W.C. Lui and L.C.K. Hui, A Model for Delegation of Accountability, IASTED International Conference on Software Engineering, SE 2004. 6. REFERENCES [Atl05] V. Atluri, J. Warner, Supporting Conditional Delegation in Secure Workflow Management Systems, ACM Symposium on Access Control Models and Technologies, Sweden, Jun 1-3, 2005. [Mof90] J. D. Moffett, Delegation of Authority Using Domain Based Access Rules, PhD Thesis. Dept of Computing, Imperial College, University of London. 1990. [Bar00] E. Barka and R. Sandhu, A Role-Based Delegation Model and Some Extensions, Proc. of 23rd National Information Systems Security Conference, Dec, 2000. [Nag98] N. Nagaratnam, D. Lea, Secure Delegation for Distributed Object Environments, USENIX Conference on Object Oriented Technologies and Systems. April, 1998. [Bar05] E. Barka and R. Sandhu, Role-Based Delegation Models/Hierarchical Roles, Proc Annual Computer Security Application Conference. 2004. [Osb00] S. Osborn, R. Sandhu, Q. Munawer. Configuring Rolebased Access Control to Enforce Mandatory and Discretionary Access Control Policies. ACM Transactions on Information and System Security, 3(2):85-106, May 2000. [Fer93] D. F. Ferraiolo, D. M. Gilbert, and N Lynch. An Examination of Federal and Commercial Access Control Policy Needs. In Proceedings of NISTNCSC National Computer Security Conference, pages 107116, Baltimore, MD, September 20-23 1993. [Fer01] [San96a] R. Sandhu, E. J. Coyne, H. L. Feinstein, C. E. Youman. Role-Based Access Control Models. IEEE Computer 29(2): 38-47, IEEE Press, 1996 D. F. Ferraiolo, R. Sandhu , S. Gavrila , D. Richard Kuhn , R. Chandramouli. Proposed NIST Standard for Role-based Access Control. ACM Transactions on Information and System Security (TISSEC) Volume 4, Issue 3, August 2001. [San96b] R. Sandhu. Role Hierarchies and Constraints for Lattice-based Access Controls. In E. Bertino, H. Kurth, G. Martella, and E. Montolivo Eds., Computer Security - Esorics'96, LNCS N. 1146, Rome, Italy, 1996, pages 65-79. [Gas90] M. Gasser, E. McDermott, An Architecture for practical Delegation in a Distributed System, 1990 IEEE Computer Society Symposium on Research in Security and Privacy. May, 1990. [San98] R. Sandhu, Role Activation Hierarchies, 3rd ACM Workshop on Role-Bused Access Fairfax VA, 1998. [San99] R. Sandhu, V. Bhamidipati and Q. Munawer, The ARBAC97 Model for Role-Based Administration of Roles, ACM Transactions on Information and System Security, Volume 2, Number 1, February, 1999. [Giu97] L. Giuri. Role-based access control: A natural approach. In Proceedings of the 1st ACM Workshop on RoleBased Access Control. ACM, 1997. [Goh98] C. Goh and A. Baldwin, Towards a more Complete Model of Role, Proc. of 3rd ACM Workshop on RoleBased Access Control. October, 1998. [Sha04] B. Shafiq, J. B. D. Joshi, E. Bertino, A. Ghafoor, Secure Interoperation in a Multi-Domain Environment Employing RBAC Policies, Submitted to IEEE Transactions on Knowledge and Data Engineering (2004). [Jos01a] J. B. D. Joshi, A. Ghafoor, W. Aref, E. H. Spafford. Digital Government Security Infrastructure Design Challenges. IEEE Computer, Vol. 34, No. 2, February 2001, pages 66-72. [Ste87] [Jos01b] J. B. D. Joshi, W. G. Aref, A. Ghafoor and E. H. Spafford. Security models for web-based applications. Communications of the ACM, 44, 2 (Feb. 2001), pages 38-72. [Tho97] R. K. Thomas. Team Based Access Control (TBAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments. ACM Proceedings of the second ACM workshop on Role-based access control Fairfax., Nov, 1997. [Jos02a] J. B. D. Joshi, E. Bertino, A. Ghafoor. Temporal hierarchy and Inheritance Semantics for GTRBAC. 7th ACM Symposium on Access Control Models and Technologies. Monterey, CA, June 3-4, 2002. [Jos03] J. B. D. Joshi, E. Bertino, A. Ghafoor. Hybrid Temporal Role Hierarchies in GTRBAC. Submitted to ACM Transactions on Information and System Security. [Jos05] J. B. D. Joshi, E. Bertino, U. Latif, A. Ghafoor. Generalized Temporal Role Based Access Control Model. IEEE Transactions on Knowledge and Data Engineering, Vol 17, No. 1 pages 4-23, Jan, 2005. L. A. Stein, Delegation Is Inheritance, Proc. Of ObjectOriented Programming Systems, Languages, and Applications (OOPSLA ’87). October, 1987. [Wai05] J. Wainer, A. Kumar, A Fine-grained, Controllable, User-to-user Delegation Method in RBAC, ACM Symposium on Access Control Models and Technologies, Sweden, Jun 1-3, 2005. [Zha03a] X. Zhang, S. Oh and R. Sandhu, PBDM: A Flexible Delegation Model in RBAC, SACMAT 2003. [Zha03b] L. Zhang, G. Ahn, and B. Chu, A rule-based Framework for Role-Based Delegation, ACM Transactions on Information and Systems Security, Vol 6, No. 3, August 2003, Pages 404-4. 90