A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> Role-based access control (RBAC) is recognized as an efficient access control model for large organizations. Most organizations have some business rules related to access control policy. Delegation of authority is among these rules. RBDM0 and RDM2000 models are recently published models for role-based delegation. They deal with user-to-user delegation. The unit of delegation in them is a role. But in many cases users may want to delegate a piece of permission from a role. This paper proposes a flexible delegation model named Permission-based Delegation Model (PBDM), which is built on the well known RBAC96 model. PBDM supports user-to-user and role-to-role delegations with features of multi-step delegation and multi-option revocation. It also supports both role and permission level delegation, which provides great flexibility in authority management. In PBDM, a security administrator specify the permissions that a user (delegator) has authority to delegate to others (delegatee), then the delegator creates one or more temporary delegation roles and assigns delegatees to particular roles. This gives us clear separation of security administration and delegation. <s> BIB001 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> Delegation in computer systems plays an important role in relieving security officer’s management efforts, especially in a large-scale, highly decentralized environment. By distributing management authorities to a number of delegatees, scalable and manageable security management functionality can be achieved. Recently, a number of researches are proposed to incorporate delegation concept into Role-Based Access Control(RBAC) model, which is becoming a promising model for enterprise environment with various organization structures. In this paper, we propose a new role-based delegation model using sub-role hierarchies supporting restricted inheritance functionality, in which security administrator can easily control permission inheritance behavior using sub-roles. Also, we describe how role-based user-to-user, role-to-role delegations are accomplished in the proposed model and analyze our delegation model against various delegation characteristics. <s> BIB002 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> For the role graph model, we have always assumed that the administration of the role graph and group graph is carried out by a single (centralized) administrator. This is not realistic in practise. In this paper, we present a decentralized administrative model for the role and group graphs. The model uses administrative domains, and administrative roles which are part of the role graph. A discussion of why domains cannot overlap is given, as well as a discussion of how users and privileges might be in more than one domain. Details of administrative privileges are given. We also present a detailed discussion comparing the new model to other administrative models for role-based access control. <s> BIB003 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> The basic idea behind delegation is that some active entity in a system delegates authority to another active entity in order to carry out some functions on behalf of the former. User delegation in RBAC is the ability of one user (called the delegating user) who is a member of the delegated role to authorize another user (called the delegate user) to become a member of the delegated role. This paper introduces a new model, which we consider it to be an extension of REDM0 [BS2000]. The central contribution of this paper is to introduce a new model, referred to as RBDM1 (role-based delegation model/ hierarchical roles), that uses the details from RBDM0, which was described in the literature by Barka and Sandhu [BS2000] to address the temporary delegation based on hierarchical roles. We formally defined a role-based delegation model based on hierarchical relationship between the roles involved. We also identified the different semantics that impact the can-delegate relation, we analyzed these semantics to determine which ones we consider as more appropriate in business today, thus allowed in our model, and provided a justification to why those selections are made. <s> BIB004 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> Although Web-based information systems (WISs) have been widely used by enterprises to accomplish business tasks through the Internet, there is little research on designing a flexible access control and delegation model for WISs. In this paper, we design a user-to-user and role-to-role delegation model (called X-RDR model) for WISs. The authorization and delegation policies are encoded in XML and the granularity of control can be as small as a text-field or button. Additionally, the proposed model supports single-step delegation, multi-step delegation, multiple delegation, partial delegation, separation of duties, and cascading revocation. A prototype was also implemented to demonstrate the feasibility of the proposed model. <s> BIB005 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> 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 role-based delegation models and provide much more fine-grained control of delegation semantics. <s> BIB006 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> In existing delegation models, delegation security entirely depends on delegators and security administrators, for delegation constraint in these models is only a prerequisite condition. This paper proposes an Attribute-Based Delegation Model (ABDM) with an extended delegation constraint consisting of both delegation attribute expression (DAE) and delegation prerequisite condition (CR). In ABDM, a delegatee must satisfy delegation constraint (especially DAE) when assigned to a delegation role. With delegation constraint, a delegator can restrict the delegatee candidates more strictly. ABDM relieves delegators and security administrators of security management work in delegation. In ABDM, a delegator is not allowed to temporarily delegate permissions to a person who does not satisfy the delegation constraint. To guarantee its flexibility and security, an extension of ABDM named ABDMX is proposed. In ABDMX, a delegator can delegate some high level permissions to low level delegatee candidates temporarily, but not permanently. <s> BIB007 </s> A Survey of Delegation from an RBAC Perspective <s> 1) Roles and Role Hierarchies: <s> We present a model for delegation that is based on our decentralized administrative role graph model. We use a combination of user/group assignment and user-role assignment to support user to user,permission to user and role to role delegation. A powerful source-dependent revocation algorithm is described. We separate our delegation model into static and dynamic models, then discuss the static model and its operations. We provide detailed partial revocation algorithms. We also give details concerning changes to the role hierarchy, user/group structure and RBAC operations that are affected by delegation. <s> BIB008
As we saw in Section IV-A, roles can be delegated in their entirety or only part of a role can be delegated. The SAccnting role in our example could be delegated in its entirety, which would be total delegation, or the delegator might wish to delegate only two of the three permissions, say (read Sales) and (write Sales). Total delegation is found, for example, in RBDM0  . If partial delegation is desired, then these "sub-roles" have to be created by the delegator or by an administrator. Let us call such roles delegation roles. These delegation roles could form part of the regular role graph or role hierarchy, or could form their own separate hierarchy. In PBDM0 and PBDM1 (two of the delegation models proposed in BIB001 ), the roles to be delegated are regarded as being separate from the role hierarchy, in that the authors do not want any changes to a delegation role to affect any regular roles, and therefore do not want these delegation roles to be junior to any regular roles. In the role graph model, such roles could be placed in the role graph (as long as their permission set is distinct from all the other roles), and the role graph algorithms would add edges to show which roles offer a subset of these permissions and which offer a superset. The restriction being asked for by Zhang et al. BIB001 is that the designer of the delegation roles not be allowed to add new edges to the role graph, and that a change to a delegation role not affect any regular roles. Partial role delegation is also found in BIB002 and BIB006 . An example of partially delegating the SAccnting role in our example, say only including the (read Sales) and (write Sales) permissions, is shown as role Del1 in Figure 5 (a), which also shows where the role graph algorithms would place it. In  , extra permissions are delegated to a role which is already activated; this deals with existing roles, but alters the role at run time to accommodate delegation. Figure 5(b) shows where the SAccnting role with the (write Cheque) permission added, resulting in role Del2, would appear in the role graph. The role hierarchy is featured in RBDM1 BIB004 where the can-delegate relation is analyzed in terms of the role hierarchy. A member of role r 1 is not allowed to delegate r 1 or any role junior to r 1 to a user who is a member of a role senior to r 1 , since this potential delegatee is already implicitly a member of the junior role. In terms of our example, Ellen would not be allowed to delegate SalesPers (to which Ellen is assigned), or its juniors, to Bob because Bob is assigned to SalesMgr which is senior to SalesPers, and thus Bob can already perform all the permissions in SalesPers and its juniors. RBDM1 does not create any delegation roles. In BIB006 , a richer model of role hierarchy involving inheritance-only and activation-only hierarchies is used to further refine the choice and construction of delegation roles. The role structure also can be used in expressing revocation. In PBDM0 BIB001 , mention is made of partially revoking a delegated role. 2) Users and User Groups: Users are a primary focus of delegation. It is a user at run time who initiates a delegation, usually to one or more other users. This is the user-to-user delegation spoken of in the PBDMx models BIB001 . Users can be classified as to whether or not they should ever be a delegatee for a certain role or subrole delegation. This classification can be based on some user attributes, such as qualifications, or perhaps membership in a group or another role. A group can be a dele gatee as in Example 4.1. Example 4.1: Alice is unable to perform SAccnting. She delegates this role to the AccountantsGr Group, since these users would have the necessary qualifications. In BIB007 , user attributes are used to decide on role membership and on whether or not a user can be a delegatee; in the latter case this allows the delegator to specify qualifications for delegation, even if they do not know what users might satisfy the qualifications. The members of a role can be considered to be a group, although only the role graph model includes groups. Membership in one role, say PAccounting, can be used to indicate a set of delegatees, as in Example 4.2. Example 4.2: Alice delegates role SAccnting to the members of PAccounting. The delegation in Example 4.2 allows Carol to be delegated. This is a different delegation from Example 4.1, because although Dan is a member of the AccountantsGr group in the group graph, the delegation in 4.2 does not allow Dan to be delegated. This structure is found the role-to-role delegation in BIB002 . Such a requirement is usually expressed with a constraint, to be discussed below. In BIB008 ,  , a delegation model is presented based on an administrative model for the role graph model BIB003 . It makes extensive use of the user/group graph, to model delegators and delegatees. A delegatee group can be set up, and the delegatee can be made a member of this group. Also, delegation chains can be represented by special edges from one delegatee group to another. 3) Permissions and Object/Access Mode Hierarchies: Permissions can be labeled as being delegatable or nondelegatable. Permissions can be added one at a time to delegation roles, as is allowed by PBDM0 and PBDM1 BIB001 , or can be delegated independently of roles  . In  , extra permissions are delegated to an active role, so the unit of delegation in this case is a permission. The object of delegation in BIB005 , which deals with delegation for web-based information systems, is any sub-part of a web page to which the delegator has access; in other words the delegation uses the object structure from the object part of the permission in expressing the delegated permission. In our example, Ellen, who is assigned to the SalesPers role, which has one permission, (write Sales), could delegate only one subnode of the Sales object, say Sale42, to someone else, and Sale42 and all its subnodes would be writable by the delegatee.