A Fine-grained, Controllable, User-to-User Delegation Method in RBAC Jacques Wainer
Akhil Kumar
Institute of Computing State University of Campinas Campinas, Brazil
Smeal College of Business Penn State University University Park, PA, USA
[email protected]
[email protected]
ABSTRACT This paper addresses the issues surrounding user-to-user delegation in RBAC. We show how delegations can be incorporated into the RBAC model in a simple and straightforward manner. A special feature of the model is that it allows finegrained control over what rights a user wishes to delegate as opposed to delegation at the role level where all the rights of a role must be delegated. In addition, the model provides a rich set of controls regarding further delegations of a right, generic constraints that further control delegations, and an innovative model for revocations. Properties of both delegation and revocation are discussed, and our work is compared with other related research.
Categories and Subject Descriptors D.4.6 [Operating Systems]: Security and Protection - Access controls
General Terms Security
Keywords Access control, RBAC, delegation, revocation
1. INTRODUCTION The Role-based Access Control Model (RBAC) (for example [12]) is receiving attention as a systematic way of implementing the security policy of an organization. It groups individual users into roles that relate to their position within an organization and assigns permissions to various roles according to their stature in the organization. An RBAC model is described by 1) entities: users U, roles R, privileges P, 2) relationships between these entities, and 3) constraints over these relationships.
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, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACMAT’05, June 1–3, 2005, Stockholm, Sweden. Copyright 2005 ACM 1-59593-045-0/05/0006 ...$5.00.
The term delegation is usually employed in the security literature to describe transfer or inheritance of rights from some user to a machine, that then acts as a surrogate for that user (as in an ATM transaction, for instance). Here, we restrict our scope to user-to-user delegation. Only recently researchers are starting to recognize the importance of introducing delegation into the RBAC framework. The significant research efforts that we are aware of in this direction are those of Barka and Sandhu [3, 4], Bacon, Moody and Yao [2], Zhang, et al. [17], and Ruan and Varadharajan [11]. The work of Barka and Sandhu allows a role to delegate to another role, and also considers multi-step delegations and revocations. [2] introduces the notion of an appointment whereby a user can appoint another user to perform a task. More discussion of the related research will be provided in Section 5. This paper is organized as follows. Section 2 describes the key intuitions and definitions behind our model of delegation. Section 3 discusses the intuitive and formal aspects of revocation of delegations. Next, Section 4 proposes some extensions of our approach to incorporate new types of delegations and revocations. Then, Section 5 discusses related work and, finally, section 6 gives the conclusions.
2.
DELEGATION
The essence of our delegation model is that a user (say, Alice) delegates to another user (say, Beth) a particular right, for example, the right to unlock the main door. We call this a delegation, where Alice is the grantor and Beth is the delegate, and the ”right to unlock the door” is the object of the delegation. In order for Alice to be able to perform the delegation, she must have the right to delegate the object to start with. She may have received it through some other delegation (to be discussed shortly) or she may possess the right already. We say that Alice has direct right to a privilege if the RBAC structure allows her to have that right, or more formally, there is a role that Alice can play, and the role holds the particular privilege. Alice may not only delegate the object right to Beth, but she may also delegate the right to further delegate it. In this case, it is possible that Beth may still further delegate the right to Carla, and so on, resulting in delegation chaining. Furthermore, delegation rights may be either restricted or unrestricted. Alice may want to restrict how Beth can further delegate the object right. Our extended model allows for delegations with restrictions, so that the receiver of a
restricted delegation right will not be totally free to delegate the object to anyone. Also the framework allows for generic constraints that cannot be violated in any delegation, and thus general, organization level policies must not be violated while performing the delegations. Thus, a delegation from a user to another is accepted by the system only if: (1) the grantor has the appropriate rights to make the delegation; (2) the delegate satisfies all restrictions specified in the restricted delegation right the grantor holds; and (3) the delegation itself does not violate any generic constraint; otherwise, the delegation request is rejected.
2.1 Right to delegate As mentioned above, delegation is a right represented in the RBAC structure. We will define several such delegation rights. If R is an (object) right, then the following are possible delegation rights: d(R,n), d*(R), cd(R,Q,n), cd*(R,Q) d(0) and d(R,0), where Q is a one place predicate and n > 0. The privilege d(R,1) allows a user, who already holds the object right R, to delegate R to anybody else provided the delegation does not violate the generic constraints. If one holds the privilege d(R,2), and also holds R, then one can delegate R, and d(R,1) as well. In general, if a user holds d(R,n), and also holds the right to R, then she can start a chain of delegations of R at most n steps long. The privilege d* (total delegation) is in fact d(R,∞); thus, if one holds d*(R), one cannot only delegate R but also d*(R). This is a special case in which the delegate can receive the same rights as the grantor. The privilege cd (for conditional delegation), allows one to set up further controls on the chains of delegation. If a user holds cd(R,Q,1), and can execute task T associated with right R herself, then she can also delegate T to a user U provided U satisfies the property Q, i.e., Q(U) is true. Q is the condition of the delegation. If the user holds cd(R,Q,n), then she can start a multi-step chain of at most n steps such that each delegate in the chain must satisfy the property Q. As usual, cd*(R,Q) is, for all purposes, equivalent to cd(R,Q,∞). The purpose of the delegation rights d(R,0) and d(0) will be discussed below, but their intuition is that they are rights that do not allow for delegation: d(R,0) does not allow one to delegate the right R and d(0) does not allow any delegation at all. In this paper, we will assume that one cannot delegate just delegation rights, but one must also delegate the object right. Thus if Alice holds d(negotiate-salary,3) she cannot just delegate d(negotiate-salary,2) to Beth, she must also delegate the right “negotiate-salary” itself. We will denote that Alice delegated right negotiate-salary and the right d(negotiate-salary,2) to Beth as: delegate(alice,beth,negotiate-salary + d(negotiate-salary,2))
2.2 Comparing delegation rights - Stronger relation We will define two relations between object rights and between delegation rights, both of them called stronger relation and with similar intuitions. In fact, strictly the relations are “stronger than or equal to,” and for both we will use the symbol ≥. Definition 1. The stronger relation ≥ among object rights
is defined as A ≥ B, iff A = B or imply(A,B) where imply is the RBAC relation between two rights. Definition 2. The stronger relation ≥ among the delegation rights is defined as follows: • A ≥ B, if A = B • d(R,n) ≥ cd(R,Q,n), for any n > 0 and any Q • d*(R) ≥ cd*(R,Q), for any Q • d*(R) ≥ d(R,n) ≥ d(R,k) for n > k • cd*(R,Q) ≥ cd(R,Q,n) ≥ cd(R,Q,k) for n > k • If R ≥ S, then cd(R,Q,n) ≥ cd(S,Q,n) and cd*(R,Q) ≥ cd*(S,Q) • If R ≥ S, then d(R,n) ≥ d(S,n) • If R ≥ S, then d*(R) ≥ d*(S) • If P and Q are one place predicates, then cd(R,P,n) ≥ cd(R,P∩Q,n), for any n and T • If P and Q are one place predicates, then cd*(R,P) ≥ cd*(R,P∩Q), for any T • cd(R,Q,n) ≥ d(R,0) for all Q and n > 0 • d(R,0) ≥ d(0) for all T If A ≥ B then we will say that B is weaker than A. We can also define A > B as A ≥ B and not A = B, and we call > as strictly stronger relation. Intuitively, a delegation right is stronger than another if it: (1) requires a higher privilege in an organization structure, (2) reaches more people, or (3) allows “more to be done”. d(R,3) is stronger than d(S,3) because of imply(R,S); and thus, having the privilege R allows one to “do more” than just having the privilege S. d(R,3) is stronger than d(R,2) because it allows chains of size 3 instead of 2. d(R,3) is stronger than cd(R,Q,3) because the three delegates allowed by cd(R,Q,3) must satisfy condition Q, whereas the three delegates allowed by d(R,3) are unconstrained. The purpose of d(R,0) and d(0) is to define a minimum or a weakest extreme for the stronger relation; thus, d(R,0) is weaker than any other delegation right for the object R, and d(0) is weaker than any delegation whatsoever. They will be useful when we define generic constraints below. The stronger than relation can be easily computed provided all One-place predicates used in the cd delegation are represented by names, which may indicate a particular database query on the RBAC data structures, or a logic program predicate that uses the RBAC objects and relations. In conditional delegation, the conditions are defined as oneplace predicates. Therefore, to determine if cd(R,P,n) is stronger than cd(R,Q,n), one has to determine if condition Q implies condition P. The less restrictive condition is stronger. For the object rights, the stronger relation is the imply relation in RBAC, whose truth can be determined with one query on the RBAC data structures, and the stronger relation among d rights can be determined just from their syntactic structure.
2.3 Generic Constraints In contrast to RBAC which mediates the relation between users and rights through the role concept, delegations create a direct, unmediated relation between users and rights - if right R has been delegated to U, then U has gained the privilege R independent of the roles she can or cannot play. Thus, constraints that limit delegation must limit directly this new relation between user and privilege. We will use the predicate has-right to indicate this new relation between user and privileges, unmediated by role, that underlies delegation. We express generic constraints as: ⊥ ← has-right(U, R), γ where γ is any conjunction of the RBAC primitive predicates (can-play between users and roles, hold between roles and rights, imply between rights, is-a between roles) or any other derived predicate that refer to users, roles, and rights. The constraint states that it is a violation for both hasright(U,R) and γ to be true at the same time. For example, we assume that relation subordinate(A,B) is a predicate that states that user A is subordinate to user B in the organizational hierarchy. To express that no subordinate can receive a right that is stronger than one that his superior has, one would define the generic constraint: ⊥
← has-right(user, p), subordinate(user, boss), can-play(boss, role), hold(role, q), imply(p, q)
(1)
Generic constraints cannot be used to restrict sets of rights. Thus, in the current version one cannot create constraints that would prevent a subordinate from holding more rights than his superior. That would require making a reference to the set of rights of both the superior and the subordinate. Finally, the two delegation symbols d(0) and d(R,0) should be used to specify that a user should not gain any delegation right at all, or only to a particular right R, respectively. The constraint: ⊥
← can-play(u, security-guard), has-right(u, d(unlock-door, 0))
(2)
states that a person who can play the role of a security guard cannot receive rights to delegate the task of unlocking doors. Similarly, a separation of duty constraint to express the idea that a guard who opens the front-door cannot also open the back door is expressed as: ⊥
← has-right(u, unlock-front-door), has-right(u, unlock-back-door)
(3)
Definition 4. The delegation delegate(U1,U2,R+D(R)) where R is an object right, and D(R) is a delegation right for R, is accepted when delegate(U1,U2,R) is accepted and then delegate(U1,U2,D(R)) is accepted, in that order. Definition 5. The delegation delegate(U1,U2,R), where R is an object right, is accepted when • case 1 (grantor holds d) – has(U1,R) – has(U1,d(R,n)) or has(U1,d*(R)) – adding has-right(U2,R) does not violate any generic constraint – for all rights R0 such that imply(R,R0 ), adding has-right(U2,R0 ) does not violate any generic constraint • case 2 (grantor holds cd) – has(U1,R) – has(U1,cd(R,Q,n)) or has(U1,cd*(R,Q)) – adding has-right(U2,R) does not violate any generic constraint – for all rights R0 such that R ≥ R0 , adding hasright(U2,R0 ) does not violate any generic constraint – Q(U2) is true Definition 6. The decrement operation (or function) on a delegation right is defined as follows: • decrement(d*(R)) = d*(R) • decrement(d(R,n)) = d(R,n-1) • decrement(cd*(R,Q)) = cd*(R,Q) • decrement(cd(R,Q,n)) = d(R,Q,n-1) The decrement function is needed to ensure that delegations of the form d(R,n) or cd(R,Q,n), where n controls the number of steps in a chain, work properly. In the next definition, we will use this function.
2.4 Delegation acceptance A delegation assertion is accepted by the system under certain conditions. In this subsection, we define these conditions formally. Let us call A the set of accepted delegations. We first define the relation has(U,R). Definition 3. has(U,R) is true if: • there is a role X and can-play(U,X) and hold(X,R0 ), and R0 ≥ R or • there is a delegation of the form delegate(x,U,R0 ) ∈ A and R0 ≥ R That is, has(U,R) is true if, by direct right or by delegation, user U has the right R, or a stronger right.
Definition 7. The delegation delegate(U1,U2,D), where D, of the form d[*](R,[n]) or cd[*](R,Q,[n]), is a delegation right for R, is accepted when: • delegate(U1,U2,R) is accepted (see Definition 5) • has(U1,X) and decrement(X) ≥ D (see Definition 6) • adding has-right(U2,D) does not violate any generic constraint • for all rights D0 such that D ≥ D0 ,adding has-right(U2,D0 ) does not violate any generic constraint
2.5 Algorithm for accepting a delegation A 2-step algorithm is required to verify if a delegation delegate(U1,U2,P ) can be accepted. Algorithm Accept 1. verify if U1 has the right to delegate P , i.e. has(U1,P + ) for some P + ≥ P . 2. check if U2 has the right to receive P, i.e. has-right(U2,P − ) does not violate any generic constraint, for all P − such that P ≥ P − These two steps are discussed in detail next. Step 1: Clearly, user U1 has the right to delegate P if she has direct rights for P or P + , or if she has received P + through delegation. Thus, in order to verify if U1 has the appropriate rights to assert the delegation delegate(U1,U2,P ), we have to: (a) verify if there is a stronger right P + that user U1 can hold. This information can be computed in advance in a table stronger(P0 ,P) of right pairs where P0 is stronger than P. (b) if no direct right P + is found, then consider all delegations received by U1. This is done by computing a table delegate(U 1,G,P 0 ), where U1 has received a delegation for right P0 from G. If there is any P 0 stronger than P in this table, then it means that U1 does have the right to delegate P. Step 2: This step requires checking against each relevant constraint for violations. As discussed above, the constraints are expressed in the form: ⊥ ← has-right(U, R), γ where R is an explicit right, and γ is a condition to be evaluated. This step can be optimized by recognizing that γ should be evaluated only if R0 is stronger than R.
2.6 Property of delegation There is no single definition of ”correct” delegations, and thus, we cannot prove that the delegation mechanism described above generates only correct delegations. In fact, our scheme is unconstrained by design in order to facilitate flexibility. Nevertheless, it is necessary to impose some control on who receives a certain right. This control is placed through the generic constraints. Our notion of correctness is that a delegation should not lead to a violation of a generic constraint. The following theorem shows that indeed all generic constraints will be enforced in our delegation scheme: Theorem 1. No set of delegations will give a right R to a user U if conferring such a right violates some generic constraints (that is, has-right(U,R) violates some generic constraint). Proof sketch: The proof is based on arguing that a delegation is accepted only if the right conferred by the delegation, and any right weaker than it (or implied by it), does not violate a generic constraint. 2 Another aspect of our delegation scheme is that it allows for multiple delegations of a right to the same user. User A may delegate to X the right to R, and the right to further delegate it to anyone that satisfies Q, provided the delegation delegate(A,X,R+cd(R,Q)) is accepted. On the other hand, user B may delegate to X the right to R
and the right to further delegate it at most three times (delegate(B,X,R+d(R,3))). Thus, user X receives two delegations of the right to R, and different sets of sub-delegation rights.
3.
REVOCATION
Revocation is the process by which a delegation that was accepted is removed or retracted. However, since delegations may be chained, a revocation can produce side effects and other consequences. This section will examine the details related to revocation, which are quite straightforward. The central issue in revocation is to undo the cascading effects of a chain of delegations. Thus, if Alice delegates R + d(R,3) to Beth, and Beth delegates R + d(R,1) to Carla, and Alice revokes her original R + d(R,3) delegation, then, at first glance, the delegation from Beth to Carla should also be revoked; and thus, not only Beth, but also Carla, loses the right to R. However, what really happens with that delegation also depends on whether Beth had rights to R + d(R,1) by other means than the delegation from Alice, say, because she had direct rights to it, or through delegation from somebody else as well. Thus, a chained delegation should only be revoked if it is solely dependent on the revoked delegation. To formally define revocation, we need the concept of a chain of delegation. A chain of delegation for a right R is a sequence of delegations hd0 , d1 , d2 , . . . dn i, where each di is of the form delegate(gi , ri , Xi + R, C), gi is the grantor of di and ri the delegate (or recipient) of di , such that: • g0 has the direct right X0 • ri = gi+1 , that is the recipient of di is the grantor of di+1 . • decrement(Xi ) ≥ Xi+1 , that is the delegation rights delegated in di+1 are at most as strong as decrement(Xi ) • no gi of any delegation di had the direct right to Xi • there is no pair di and dj in the chain, such that di = dj Intuitively, a chain of delegation is a way to “explain” or “justify” a sequence of delegation dependencies. In particular, the chain of delegations (d0 , d1 , . . .) is a possible way of explaining how an got the right to delegate Xn to an+1 . Furthermore, a chain has the added constraint that the first grantor did not receive the delegation rights from any one else, that each delegate in the chain did receive (from someone) the rights that allowed her to delegate it further, and that there are no cycles. The delegation d0 is called the starter of the chain. Also, given the chain hd0 , d1 , d2 , . . . dn−1 , dn i, we will say that hd0 , d1 , d2 , . . . dn−1 i is a support chain for dn . As an example, Figure 1 displays a chain of delegations, where d(4) is an abbreviation for delegate(Grantor, Delegate, R+d(R,4)) for some right R. The support chains for the delegation d(1) from C to G are: hd(5)A−B , d(4)B−C , d(1)C−G i and hd(5)A−B , d(4)B−F , d(2)F −C , d(1)C−G i. The support chain for d(2) from C to E is only hd(5)A−B , d(4)B−C , d(2)C−E i. Definition 8. A delegation dj is dependent on a delegation di if all support chains for dj contain di . That is, dj is dependent on di if di is the only reason the grantor of dj received the rights that allowed her to make the delegation dj .
D H
d(2)
d(1)
d(2) d(2)
d(5) A
d(4) B
E d(1)
C d(4)
4.
d(1) d(2)
F
4.1
Figure 1: Example of dependence of delegations
Definition 9. The effect of r(d), the revocation of the delegation d, given the set of accepted delegations A, is a new set of accepted delegations A0 = A − {d} − {x | x is dependent on d} For example, the effect of revoking the delegation of d(4) from B to C in figure 1 is illustrated in figure 2. The delegations from C to D, from D to C, and from C to E, all depended on the delegation from B to C, and were, therefore, removed from A. D H d(2) E
A
d(1) B
C d(4)
d(1) d(2)
EXTENSIONS
In this section, we discuss our preliminary ideas of strong delegation and revocation, revocation with downgrades and time-restricted delegations.
G
d(5)
Proof sketch: The central lemma of the proof is to show that for any given d ∈ D, no matter which subset of revocations in RV was executed, d belongs to at least one chain. Then by revoking the start of one of these chains, either d is removed, because that was the only chain to which d belonged, or there is one less chain to which d belongs, and so eventually d will be removed when one of the starts is revoked. Thus, no dangling delegations are left. 2
G
F
Figure 2: Delegations after the revocation of d(4) from B to C The important theorem of revocation is that revocation will leave no one with unsupported rights. For example, if the right to hire a new programmer has been delegated throughout the organizations such that eventually Alice received this right, and all users that started a chain eventually revoked the delegation, then Alice must also lose the right she received. Formally: Theorem 2. If there is a sequence of delegations D = hd1 , d2 . . . dx i of the right to R followed by a sequence of revocations RV = hr(di1 ) , r(di2 ) . . . r(diy )i, such that for all dj which start a chain of delegation in D, there is the corresponding r(dj ) ∈ RV , then no user U that received the right to R through some delegation dk in D will have the right after all the revocations in RV .
Strong delegation and strong revocation
In the present framework, in order to delegate a right R, the user must both have the right to R and also the right to delegate R. But there are many situations in which it is desirable that a user may delegate a right even if he does not possess the right to it. This can often happen in management situations - the user responsible for a process must delegate a particular task that is late, or cannot be performed by the assigned person to some other user, even though the person in charge does not have the right to perform it himself. The chief of medicine of a hospital should be able to delegate the right to perform an emergency eye operation to someone else, say an ophthalmologist, even though the chief, being an oncologist, is not qualified for eye surgery, and thus, should not have the right to operate on an eye himself. We define the rights sd(R,n), sd*(R), scd(R,Q,n), scd*(R,Q) as the strong versions of the delegation rights already discussed. The meaning of a scd(R,Q,n) is that the grantor can delegate the task R and the right cd(R,Q,n-1) to any delegate that satisfies the property Q, even if the grantor himself does not have the right to R. Notice that the strongness of the right is not itself delegated - if A strong-delegates R to B, B already has the right to R and thus does not need a strong delegation right. Revocation in our framework is not a standard right in the same sense as delegation, which is represented in the RBAC data structures. Revocation is an “automatic” right for anyone that made a delegation. For administrative purposes, however, it is important that others may have the right to revoke someone else’s delegation. We call this a strong revocation right. There are two situations in which a strong revocation right would be meaningful - (1) when the user (or the role) has power over the object right being delegated; and (2) if the role has power over the grantor. Because the grantor dimension can be defined either by role or by user we need two revocation rights as follows: • rev1 (U,P): where U is a user and P is a right. A user who holds rev1 (U,P) can revoke all delegations of a right P0 , weaker than or equal to P, whose grantor is user U. rev1 (*,P) allows its holder to revoke all delegations of P0 ≤ P by any grantor, and rev1 (U,*) allows the revocation of all delegations whose grantor is U. • rev2 (R,P): where R is a role and P is a right. A user who holds rev2 (R,P) can revoke all delegations of a right P0 , weaker than or equal to P, whose grantor can play the role R. (The symbol * again works as above.)
For example, the head of a department could have strong revocation rights to all users in his department, while the database administrator might have strong revocation rights to all database rights (of all roles). The introduction of strong revocation does not change any properties or definitions described earlier. If a revocation is issued, the system verifies that the user that issued it either was the grantor of the delegation being revoked, or had the appropriate strong revocation right.
4.2 Revocation with downgrade There is another possibly more complex definition of revocation. Let us see the example in figure 3. When the delegation from A to B is revoked, so are the delegations form B to C, C to E, C to G, and E to H, because they are all dependent on delegate(A,B,R+d(R,5)). Clearly B could not delegate R + d(R, 4) to C because with A’s revocation, she has no such right. But with the “remaining” delegation from F, at least B could delegate R + d(R, 1) to C, and C could have delegated R, to E and G. Revocation with downgrade will thus weaken some delegations rather than removing them when an alternative support chain (albeit a weaker one) is present. Of course, all delegations that cannot be downgraded in this way will necessarily be removed from the set of accepted delegations.
R+d(R,1) R+d(R,2) R+d(R,5) A
H
E
R+d(R,4) B
C
R+d(R,1)
R+d(R,2)
G
F
Figure 3: A set of delegations
4.3 Time-restricted delegations A further possible extension to the model proposed here is that of time-bound delegations such that: A delegates to B the right R for the next T hours. Thus, instead of expressing a delegation as: delegate(U1,U2,R), we would modify it to delegate(U1,U2,R, start time, end time) or delegate(U1,U2,R, now(), now()+T), where now() is a standard function that returns the current time. One simple implementation is to transform the time-bound delegation into a standard delegation and have a trigger to revoke it at the expiry time with a standard revocation. Such an implementation guarantees that the delegation will only last for the desired T hours, but does not allow one to reason about it. For example, in this simple implementation a user cannot ask the system for how long he will hold a delegated right, since such temporal information is not represented in the system. An authorization model for temporal and derived data has been proposed by Atluri and Gal [1]. This model enables temporal assertions to be made for read, update and
insert accesses to data items in a database. Algorithms are given to ensure that only accesses that do not violate these assertions can occur. Our intent is to extend some of these notions to the level of operations as opposed to data items. Thus, we would like to be able to express delegations such as: ”delegate Beth’s rights to Carla while Beth is on vacation, but for no more than one week.” Such temporal assertions would naturally need the notion of constraints, which is not present in the proposal in [1].
5.
DISCUSSION AND RELATED WORK
In this section, we will briefly address implementation issues, and also discuss recent research on delegation and relate our work to it.
5.1
Implementation Issues
The model described here was implemented as a proof of concept prototype in Prolog. The algorithms and definitions are easily translated to a logic programming form and the generic constraint formalism is exactly that of a Prolog clause. The permanent storage of the RBAC relations and the accepted delegations are implemented using BerkleyDB. Acceptance and revocation of delegations can be implemented by an O(n2 ) algorithm (where n is the number of delegations in A),with the exception of the verification of violations of the generic constraints. As it is currently implemented, the generic constraints are implemented as logic program clauses, and thus the verification of the constraints may belong to different complexity classes depending on the expressiveness of the clauses [5]. Furthermore, we feel that delegation is a somewhat ad hoc kind of event. Thus, delegation and revocation in this paper are not considered as part of an administrative practice, as in the ARBAC99 model [13], where the “grant” operation is used by an administrator to assign a user to a role. As such, the complexity of the algorithms is manageable. The management of delegations, at least at a first approximation, does not seem to be difficult. We envision that each user will enter his/her own delegation statements into the system. Obviously, delegations that are not accepted cannot be entered, and that includes cases in which the user has no right to make the delegations in the first place (because she does not hold the appropriate permissions).
5.2
Related Work
Some closely related works to ours are those of Barka and Sandhu [3, 4, 18] and of Zhang, et. al [17]. Barka and Sandhu [3] present a framework with the objective of identifying interesting cases that could be used for building rolebased delegation models. In terms of that framework, our model is: temporary (in the sense that a delegation can be revoked, but not in the sense that it has a predefined validity), monotonic, partial, self-acted, both single- and multistep (with a fine control over the multi-step delegation using different delegation rights), unilateral agreement, a version of cascading revocation (based on our definition of dependency), and grant-dependent. Our model has a complex structure regarding the multi-step delegation issue which is not discussed in that work, and includes the idea of generic constraints. In [4], the RBDM0 model (Role-Based Delegation Model) is proposed as an extension of RBAC (more specifically RBAC0 model of the RBAC96 family) to include delega-
tion. Being derived from RBAC0, it is restricted to flat roles and does not allow hierarchies. Moreover, RBDM0 is based on one-step, total delegation (of all rights attached to a role); revocation is either by an expiration mechanism or by any member of the same role as the grantor. Some extensions are discussed: grant-dependent revocation, delegatable and non-delegatable permissions, and two-step delegation, as well as delegation in hierarchical roles. This work is still further extended in [18] to a Permission Based Delegation Model (PBDM). The role-based delegation model of Zhang, et al. [17] is very interesting and useful. Their proposal allows delegations of the form DLGT(User1,Role1,User2, Role2), where User1 who holds Role1 delegates her role to User2 who holds Role2. Moreover, they also allow generic constraints in a manner similar to ours, and grant dependent as well as grant independent revocations. However, they do not allow partial delegation. In particular, our objective is to develop a more ”flexible” sort of delegation scheme. The delegation of a role results in an ”all or nothing” situation, i.e., either the grantor must either delegate all the privileges of her role, or none. In practice, a grantor may wish to delegate only certain privileges. A president may wish to delegate her privilege to sign checks, approve expenses and authorize capital expenditures, but not the privilege to hire new employees. This is not possible if the entire role is being delegated. Moreover, a president may like to delegate the check signing and expense approval tasks to a vice-president with a right to further delegate to one level lower, but the right to approve capital expenditures may not be further delegatable. The need for such partial delegation has also been noted in [18], and their PBDM models allow user-to-user and role-torole delegations in a more flexible way, such that a delegator can delegate her entire or partial permissions to others. Our approach has very similar goals to theirs; however, we offer conditional delegation subject to condition predicates being satisfied, and also allow users to specific generic constraints. Thus, any delegation specification that violates the condition predicates or the generic constraints is rejected. In another noteworthy work on delegation [11], the authors present a graph based approach where a delegation from A to B is shown as a link between nodes A and B on a graph. The line joining A and B can be of three types depending upon whether the delegation of the right is positive, negative, or delegatable (i.e., the right can be further delegated). The authors give various rules for correctness and consistency of delegation, along with algorithms. One difference in our approach is that it can fine tune the number of levels to which a right can be delegated (as opposed to making it binary). Moreover, we allow constraints and conditions as ways to exert still finer control over the delegation. In [2], delegation is achieved by the notion of an appointment. A user acting in the appointer role grants another user, called the appointee, a credential which may be used to activate one or more roles. Role activation takes places based on rules. Thus, it is possible for an appointer to give others access to privileges that she does not possess herself. This is somewhat similar to our notion of strong delegation. Still other related work on role hierarchy supporting restricted permission inheritance may be found in [10]. This approach is based on dividing a single role hierarchy into inter-related hierarchies for controlling permission inheritance behavior. Approaches for delegation in the con-
text of trust management systems are discussed in [14, 16]. Our proposal for revocation also differs from the wellknown Griffiths-Wade revocation mechanism [8, 6], where the issue centers around multiple chains of delegation. The Griffiths-Wade revocation mechanism uses a time stamp to identify which delegations causally derive from others. Figure 4.a) is an example from [6] where we assume that the right being delegated is R + d∗ (R), and the numbers on the arcs are the times at which the corresponding delegations were made. Figure 4.b) shows the result of the GriffithsWade revocation of the delegation from B to C. The result of revocation of the same delegation in our approach is shown in Figure 4.c). Here since the delegations from C to D and D to E are also in the chain that starts with the delegation from A to C, they are no longer dependent on the revoked delegation and are not removed. Finally, an alternative revocation framework is given in [9]. This work takes into account negative permissions (i.e. denials), in addition to positive permissions. The revocations are based on three dimensions: resilience, propagation and dominance. Since we do not allow negative permissions, the resilience aspect is not related to our approach. However, our approach addresses the latter two aspects. In particular, our algorithm for revocation performs global propagation and strong dominance. B
A
20
10
C 40
30
D
50
E
a) Original delegations B
A
10
C 40
b) Result of revoking delegation from B to C at time 70 using GW algorithm B
A
10
C 40
30
D
50
E
c) Result of revoking delegation from B to C at time 70 using our algorithm
Figure 4: Comparison of our algorithm with the Griffiths-Wade (GW) revocation algorithm
6.
CONCLUSIONS AND FUTURE WORK
In recent years, researchers have noted that it will be helpful to extend the RBAC model to allow for delegation, and conducted research in this direction. In this paper, we proposed a model that complements these related efforts by incorporating a fine-grained, user to user delegation, in which
rights and delegation rights are delegated among users in a flexible way, controlled by general, organization level constraints. The model is motivated by observations that delegation is often a special situation, and that delegation of a complete role is rather coarse-grained. Its unique feature is to allow a user to delegate only some of the privileges or rights that come with her role (not all) and also to restrict the sub-delegation rights of her delegates. We have also proposed extensions of our model to time restricted delegations, and strong delegations and revocations. We expect to develop these in our future work. Other aspects of delegation, such as transferability and complex empowerment conditions [7] must also be considered. Additional work is also required in developing a more complete constraint, role and rights management system along the lines of [13, 15]. Finally, investigating the feasibility of implementing this approach in a distributed setting is also a future research issue.
[12]
[13]
[14]
[15]
7. REFERENCES [1] Vijayalakshmi Atluri and Avigdor Gal. An [16] authorization model for temporal and derived data: securing information portals. ACM Trans. Inf. Syst. Secur., 5(1):62–94, 2002. [2] Jean Bacon, Ken Moody, and Walt Yao. A model of [17] OASIS role-based access control and its support for active security. ACM Trans. Inf. Syst. Secur., 5(4):492–540, 2002. [3] Ezedin S. Barka and Ravi Sandhu. Framework for [18] role-based delegation models. In 16th Annual Computer Security Applications Conference, December 2000. http://www.acsac.org/2000/abstracts/34.html. [4] Ezedin S. Barka and Ravi Sandhu. A role-based delegation model and some extensions. In 23rd National Information Systems Security Conference, October 2000. http://csrc.nist.gov/nissc/2000/proceedings/papers/021.pdf. [5] Evgeny Dantsin, Thomas Eiter, Georg Gottlob, and Andrei Voronkov. Complexity and expressive power of logic programming. ACM Comput. Surv., 33(3):374–425, 2001. [6] Ronald Fagin. On an authorization mechanism. ACM Trans. Database Syst., 3(3):310–319, 1978. [7] Cheh Goh and Adrian Baldwin. Towards a more complete model of role. In RBAC ’98: Proceedings of the third ACM workshop on Role-based access control, pages 55–62. ACM Press, 1998. [8] Patricia P. Griffiths and Bradford W. Wade. An authorization mechanism for a relational database system. ACM Transactions on Database Systems (TODS), 1(3):242–255, 1976. [9] Asa Hagstrom, Sushil Jajodia, Francesco Parisi-Presicce, and Duminda Wijesekera. Revocations - a classification. In CSFW ’01: Proceedings of the 14th IEEE Workshop on Computer Security Foundations, page 44. IEEE Computer Society, 2001. [10] JongSoon Park, YoungLok Lee, HyungHyo Lee, and BongNam Noh. A role-based delegation model using role hierarchy supporting restricted permission inheritance. In Proceedings of the International Conference on Security and Management, SAM ’03, pages 294–302. CSREA Press, 2003. [11] Chun Ruan and Vijay Varadharajan. Resolving
conflicts in authorization delegations. In 7th Australian Conference on Information Security and Privacy, volume 2384 of Lecture Notes in Computer Science, pages 271–285. Springer, 2002. R Sandhu, E. Coyne, H. Feinstein, and C. Youman. Role-based access control models. IEEE Computer, 29(2):38–47, 1996. Ravi Sandhu and Qamar Munawer. The ARBAC99 model for administration of roles. In Annual Computer Security Applications Conference, 1999. Roberto Tamassia, Danfeng Yao, and William H. Winsborough. Role-based cascaded delegation. In Proceedings of the 9th ACM Symposium on Access Control Models and Technologies, pages 146–155. ACM, 2004. Jacques Wainer, Paulo Barthelmess, and Akhil Kumar. WRBAC - a workflow security model incorporating controlled overriding of constraints. International Journal of Cooperative Information Systems, 12(4):455–486, 2003. Walt Yao. Fidelis: A policy-driven trust management framework. In Trust Management, First International Conference, iTrust, volume 2692 of Lecture Notes in Computer Science, pages 301–317. Springer, 2003. Longhua Zhang, Gail-Joon Ahn, and Bei-Tseng Chu. A rule-based framework for role-based delegation and revocation. ACM Trans. Inf. Syst. Secur., 6(3):404–441, 2003. Xinwen Zhang, Sejong Oh, and Ravi Sandhu. PBDM:a flexible delegation model in RBAC. In SACMAT ’03: Proceedings of the eighth ACM symposium on Access control models and technologies, pages 149–157. ACM Press, 2003.
