A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> The conventional models of authorization have been designed for database systems supporting the hierarchical, network, and relational models of data. However, these models are not adequate for next-generation database systems that support richer data models that include object-oriented concepts and semantic data modeling concepts. Rabitti, Woelk, and Kim [14] presented a preliminary model of authorization for use as the basis of an authorization mechanism in such database systems. In this paper we present a fuller model of authorization that fills a few major gaps that the conventional models of authorization cannot fill for next-generation database systems. We also further formalize the notion of implicit authorization and refine the application of the notion of implicit authorization to object-oriented and semantic modeling concepts. We also describe a user interface for using the model of authorization and consider key issues in implementing the authorization model. <s> BIB001 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> Security administration of large systems is complex, but it can be simplified by a role-based access control approach. This article explains why RBAC is receiving renewed attention as a method of security administration and review, describes a framework of four reference models developed to better understand RBAC and categorizes different implementations, and discusses the use of RBAC to manage itself. <s> BIB002 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> We describe in more detail than before the reference model for role-based access control introduced by Nyanchama and Osborn, and the role-graph model with its accompanying algorithms, which is one way of implementing role-role relationships. An alternative role insertion algorithm is added, and it is shown how the role creation policies of Fernandez et al. correspond to role addition algorithms in our model. We then use our reference model to provide a taxonomy for kinds of conflict. We then go on to consider in some detail privilege-privilege and and role-role conflicts in conjunction with the role graph model. We show how role-role conflicts lead to a partitioning of the role graph into nonconflicting collections that can together be safely authorized to a given user. Finally, in an appendix, we present the role graph algorithms with additional logic to disallow roles that contain conflicting privileges. <s> BIB003 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> In role-based access control (RBAC), permissions are associated with roles' and users are made members of roles, thereby acquiring the roles; permissions. RBAC's motivation is to simplify administration of authorizations. An appealing possibility is to use RBAC itself to manage RBAC, to further provide administrative convenience and scalability, especially in decentralizing administrative authority, responsibility, and chores. This paper describes the motivation, intuition, and formal definition of a new role-based model for RBAC administration. This model is called ARBAC97 (administrative RBAC '97) and has three components: URA97 (user-role assignment '97), RPA97 (permission-role assignment '97), and RRA97 (role-role assignment '97) dealing with different aspects of RBAC administration. URA97, PRA97, and an outline of RRA97 were defined in 1997, hence the designation given to the entire model. RRA97 was completed in 1998. ARBAC97 is described completely in this paper for the first time. We also discusses possible extensions of ARBAC97. <s> BIB004 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> Access control models have traditionally included mandatory access control (or lattice-based access control) and discretionary access control. Subsequently, role-based access control has been introduced, along with claims that its mechanisms are general enough to simulate the traditional methods. In this paper we provide systematic constructions for various common forms of both of the traditional access control paradigms using the role-based access control (RBAC) models of Sandhu et al., commonly called RBAC96. We see that all of the features of the RBAC96 model are required, and that although for the manatory access control simulation, only one administrative role needs to be assumed, for the discretionary access control simulations, a complex set of administrative roles is required. <s> BIB005 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> The essential properties of a simple model for users, groups and group hierarchies for role-based access control, embodied in a group graph, are presented. The interaction between the group graph and the role graph model of Nyanchama and Osborn is shown. More complex models of users and their compatibility with the group graph model are discussed. <s> BIB006 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> Role-based Access Control (RBAC) models have been implemented not only in self-contained resource management products such as DBMSs and Operating Systems but also in a class of products called Enterprise Security Management Systems (ESMS). ESMS products are used for centralized management of authorizations for resources resident in several heterogeneous systems (called target systems) distributed throughout the enterprise. The RBAC model used in an ESMS is called the Enterprise RBAC model (ERBAC). An ERBAC model can be used to specify not only sophisticated access requirements centrally for resources resident in several target systems, but also administrative data required to map those defined access requirements to the access control structures native to the target platforms. However, the ERBAC model (i.e., the RBAC implementation) supported in many commercial ESMS products has not taken full advantage of policy specification capabilities of RBAC. In this paper we describe an implementation of ESMS called the 'Role Control Center' (RCC) that supports an ERBAC model that includes features such as general role hierarchy, static separation of duty constraints, and an advanced permission review facility (as defined in NIST's proposed RBAC standard). We outline the various modules in the RCC architecture and describe how they collectively provide support for authorization administration tasks at the enterprise and target-system levels. <s> BIB007 </s> A Survey of Delegation from an RBAC Perspective <s> C. Role-Based Access Control <s> While Mandatory Access Controls (MAC) are appropriate for multilevel secure military applications, Discretionary Access Controls (DAC) are often perceived as meeting the security processing needs of industry and civilian government. This paper argues that reliance on DAC as the principal method of access c ontrol is unfounded and inappropriate for many commercial and civilian government organizations. The paper describes a type of non-discretionary access contro l - role-based access control (RBAC) that is more central to the secure processing needs of non-military systems than DAC. <s> BIB008
Role-based access control models have been discussed since the mid 1990's BIB002 , BIB008 -  . In RBAC, a role has a unique name, and has a set of permissions assigned to it. Users are assigned to roles, thus assigning them to a set of permissions in one operation, rather than having to assign the permissions individually. A big advantage to security administrators is that when someone changes their job or leaves the company, they can be removed from roles in one operation, thus having all the corresponding permissions revoked in one operation. RBAC is considered to be "policy neutral", in that it can be configured to mimic DAC, MAC BIB005 or just to satisfy the requirements of the enterprise, however strict or complex they may be. Ferraiolo et al. BIB008 contains an extensive discussion of RBAC and its applications. The ANSI standard  has grown out of the Sandhu and NIST models. As well as having permissions and users assigned to them, roles (in hierarchical RBAC  ) can be arranged in a partial order or role hierarchy, which can be represented as a directed acyclic graph. An example role hierarchy for a wholesale business is given in Figure 1 . The basic components of an RBAC model are users, roles and permissions. In the role graph model BIB003 , each of these three components is potentially represented by a hierarchy or graph. Concerning users, groups of users, which are simply sets of users, are also allowed, so that a set of users can be assigned or removed from a role in one operation. Membership in a group can be decided by a security administrator or derived from user attributes, such as being a qualified accountant BIB006 . There is also a hierarchy of groups determined by set containment, as shown in Figure 2 . Individual users are modeled as groups of cardinality 1. In the example group graph, the AccountantsGr group is a subgroup of Everybody, so if Everybody is assigned to role r, all the members of the AccountantsGr set, as well as all the users, are implicitly assigned to r. Groups are not part of the ANSI model. The security designer can use the AccountantsGr to assign them together to a role, or, as we will see later, can use this group to specify potential delegatees in a delegation. Concerning permissions, implications among permissions can be modeled by several hierarchies or graphs. If the object portion of the permission has a complex structure, then having, say, a read permission on a complex object implies having the read permission on all the parts of the object. The object structure which determines how permissions propagate can be shown in an Authorization Object Graph. Figure 3 shows a portfolio of objects representing sales from our warehouse business. The "Sales" object represents a set of objects, each of which is a sale, which in turn contains a number of items. Giving a user read permission on "Sales" would imply read permission on all the contained objects. Implications can also be made concerning the access mode part of a permission. In some systems, having permission to update an object also implies permission to read the same object. These implications can be shown in an Authorization Type Graph. These ideas were originally described for object-oriented databases BIB001 and have been adapted for RBAC  . Concerning roles, we have role hierarchies or role graphs. In such a graph or hierarchy, a directed edge from a junior role to a more senior role represents the fact that the set of permissions available in the junior role is a proper subset of the permissions available in the senior role. Permissions assigned to a junior role are inherited by its senior roles. Users assigned to a senior role are implicitly assigned to its junior roles. In the role graph model, algorithms are given for insertion and deletion of edges, roles, and permissions. One difference between the role graph model and the other models, especially the ANSI model  , is that in the role graph model, when the permissions of role r 1 are a subset of those of r 2 , a path must exist in the graph from r 1 to r 2 -an edge will be inserted if there is no such path -whereas no such edge will be inserted in the ANSI version. As well as users, roles and permissions, other components of RBAC models are user-role assignment, also called membership in a role, and permission-role assignment. Figure 4 shows permission-role and user-role assignments for our example. Constraints can also be specified to express many additional ideas, such as separation of duty, conditions under which roles may be assigned to a user or under which a user may activate a role, etc. We will not give details for a constraint language, but will discuss later how constraints or rules may be used to govern delegation. It is customary to consider the role(s) to which a user is assigned through user-role assignment (i.e. the roles the user can perform) to be distinct from the role(s) currently activated. In the Sandhu model BIB002 , the concept of a session is introduced to model the mapping from each user to the set of roles they currently have activated. Administration of role-based models was first mentioned in Sandhu et al. BIB002 , where separate administrative roles have permissions in which the object being acted on is a "regular" role in the role hierarchy. The purpose of these administrative roles is to effect the design of the access control for an application. Administrative models for RBAC have been discussed also in BIB004 - BIB007 . The components of RBAC, which we will use in the next section to describe different kinds of delegation are, then: 1) roles and the role hierarchy 2) users and user groups 3) permissions and object/access mode hierarchies 4) user-role assignments 5) permission-role assignments 6) sessions and 7) administration IV. DELEGATION IN ACCESS CONTROL As we saw above for relational databases, it is possible to have delegation in relational databases, or in a similar way to do delegation in any discretionary access control system by making permissions available at run time and then revoking them a short time later. However, all of the dimensions of delegation are best explored in terms of role-based access 