A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <s> A multiuser database system must selectively permit users to share data, while retaining the ability to restrict data access. There must be a mechanism to provide protection and security, permitting information to be accessed only by properly authorized users. Further, when tables or restricted views of tables are created and destroyed dynamically, the granting, authentication, and revocation of authorization to use them must also be dynamic. Each of these issues and their solutions in the context of the relational database management system System R are discussed. When a database user creates a table, he is fully and solely authorized to perform upon it actions such as read, insert, update, and delete. He may explicitly grant to any other user any or all of his privileges on the table. In addition he may specify that that user is authorized to further grant these privileges to still other users. The result is a directed graph of granted privileges originating from the table creator. At some later time a user A may revoke some or all of the privileges which he previously granted to another user B. This action usually revokes the entire subgraph of the grants originating from A's grant to B. It may be, however, that B will still possess the revoked privileges by means of a grant from another user C, and therefore some or all of B's grants should not be revoked. This problem is discussed in detail, and an algorithm for detecting exactly which of B's grants should be revoked is presented. <s> BIB001 </s> A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <s> Griffiths and Wade ( ACM Trans. Database Syst. 1,3, (Sept. 1976), 242-255) have defined a dynamic authorization mechanism that goes beyond the traditional password approach. A database user can grant or revoke privileges (such as to read, insert, or delete) on a file that he has created. Furthermore, he can authorize others to grant these same privileges. The database management system keeps track of a directed graph, emanating from the creator, of granted privileges. The nodes of the graph correspond to users, and the edges (each of which is labeled with a timestamp) correspond to grants. The edges are of two types, corresponding to whether or not the recipient of the grant has been given the option to make further grants of this privilege. Furthermore, for each pair A, B of nodes, there can be no more than one edge of each type from A to B . We modify this approach by allowing graphs in which there can be multiple edges of each type from one node to another. We prove correctness (in a certain strong sense) for our modified authorization mechanism. Further, we show by example that under the original mechanism, the system might forbid some user from exercising or granting a privilege that he “should” be allowed to exercise or grant. <s> BIB002 </s> A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <s> OASIS is a role-based access control architecture for achieving secure interoperation of services in an open, distributed environment. The aim of OASIS is to allow autonomous management domains to specify their own access control policies and to interoperate subject to service level agreements (SLAs). Services define roles and implement formally specified policy to control role activation and service use; users must present the required credentials, in an appropriate context, in order to activate a role or invoke a service. All privileges are derived from roles, which are activated for the duration of a session only. In addition, a role is deactivated immediately if any of the conditions of the membership rule associated with its activation becomes false. These conditions can test the context, thus ensuring active monitoring of security.To support the management of privileges, OASIS introduces appointment. Users in certain roles are authorized to issue other users with appointment certificates, which may be a prerequisite for activating one or more roles. The conditions for activating a role at a service may include appointment certificates as well as prerequisite roles and constraints on the context. An appointment certificate does not therefore convey privileges directly but can be used as a credential for role activation. The lifetime of appointment certificates is not restricted to the issuing session, so they can be used as long-lived credentials to represent academic and professional qualification, or membership of an organization.Role-based access control (RBAC), in associating privileges with roles, provides a means of expressing access control that is scalable to large numbers of principals. However, pure RBAC associates privileges only with roles, whereas applications often require more fine-grained access control. Parametrized roles extend the functionality to meet this need.We motivate our approach and formalise OASIS. We first present the overall architecture through a basic model, followed by an extended model that includes parametrization. <s> BIB003 </s> A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <s> Information sharing among collaborating organizations usually occurs in broad, highly dynamic network-based environments, and formally accessing the resources in a secure manner poses a difficult challenge. The mechanisms must be provided to protect the resources from adversaries. The proposed delegation framework addresses the issue of how to advocate selective information sharing among collaborating organizations. We introduce a systematic approach to manage delegated privileges with the specification of delegation and revocation policies using a set of rules. We demonstrate the feasibility of our approach by providing a proof-of-concept implementation. We also briefly discuss several issues from our experiment including future directions. <s> BIB004 </s> A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <s> In digital business, the need for efficient frameworks to address the multifaceted security issues related to Web-based applications, has led to efforts towards the development of dynamically administered access control systems that implement robust access control models, to allow controlled access of information based on content or context of processing, and secure interoperation in a dynamic distributed enterprise environment. Pure RBAC seems to be suitable for function-oriented organization structures usually used in relatively stable environments. On the other hand, TBAC and TMAC provide a complementary support in environments that are based on process-oriented organization structures. However, current organizational alternatives lead to the combination of the above approaches, in the form of a matrix organization structure that maximizes the advantages of functional and process-oriented structures and introduces the need for new access control administration paradigms. In this paper, we discuss our approach for dynamically administered role-based access control, which covers the need-to-know requirements of users and missions are involved with, and provides tight and just-in-time access control without sacrificing operability and simplicity of administration. <s> BIB005 </s> A Survey of Delegation from an RBAC Perspective <s> 6) Sessions: <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> BIB006
Recall that a session involves a user and the roles activated for a user at run time. In  , a medical example is used to motivate delegating extra permissions to a user for a specific instance of an active role. The roles active in a session can be used to decide which roles or permissions are delegatable in either role-based delegation or permission-based delegation. The use of active roles and permissions to specify a delegation at run time is the basis for dynamic delegation as described in  . Looking at the example in Figure 5 (a), if Alice has activated SAccnting in a session, she could create the delegation role Del1 during this session. Given the user-role assignments in Figure 4 , no one is assigned to the Director role, so it is unlikely any of the present users would have a session containing all the permissions of Del2 in Figure  5 (b); Del2 could be defined by an administrator using static delegation. 7) Administration: With static delegation, many of the above features of delegation could be designed by an administrator at design time rather than by a user at run time. An administrator could decide on potential delegatees, delegators, design delegation roles, decide on delegatable permissions, etc., all at design time. An administrator can also define the rules or constraints to be discussed below. The system needs to be designed with the required flexibility in place. The most flexibility will occur when delegation can be defined at run time when a truly unanticipated situation occurs. An example of this, in our running example, is if all the accountants are sick, and the delegation has been designed so that only members of the AccountantsGr group can be assigned to the accountant roles. Without dynamic delegation, the business would not be able to operate properly. As noted in BIB006 ,  , if the role hierarchy is modified by regular administrative operations on the system, and a role thus affected is a delegation role, then regular administration of the system may affect delegations which are currently in effect. Other examples of administrative operations that might affect delegation are deleting a role, and altering user-role assignments. 8) Revocation: Revocation, as we saw in section IV-A, can be grant dependent or grant independent. When it is grant dependent, the delegator has to issue the revoke. This is also called source dependent revocation in BIB006 ,  . With grant independent revocation, the revoker can be any user in the delegation role, if it is the same as a regular role, or some administrator or superuser who has this authority. Since we are not studying administrative models in this paper, we will not say much about this except that the permission to revoke a delegation should be part of the permissions given to someone, or revocation will have to rely completely on timeout rules. When there are delegation chains, authors discuss the ability of some delegatee part way along the chain to be able to revoke their delegation. In this case, the permission to revoke has been given to some or all of the users on the delegation chain. Cascading revocation is a variation of the revocation permission, i.e. the permission is "revoke with cascade" rather than just revoke. The algorithm to handle cascading revocations of permissions, first given in the context of relational databases by Griffiths and Wade BIB001 and Fagin BIB002 , mentioned in Section III-B, is applicable to cascading revocation of delegation chains. Where there is a delegation chain, and revocation is not cascading, the chain can be shortened by one; for example if the original delegator revokes the first delegation on a chain, this delegator then takes over the position of the first delegatee on the chain BIB004 . Other forms of revocation mentioned in Bacon et al. BIB003 are by resignation (the delegatee terminates their session) or by a rule-based system revocation (called constraint violation revocation in BIB006 ), which would occur if some prerequisite required to activate the delegated role is revoked, triggering a revocation of those role assignments based on the prerequisite. Revocation of delegated permissions or roles can also occur at the end of a session BIB005 . Wang and Osborn BIB006 ,  introduce a rich model for revocation. If the delegation chain has unlimited depth, one additional form of revocation is to convert it from unlimited depth to limited depth. They also discuss partial revocation, which can be partial revocation of the privileges, partial revocation of the delegatees, or partial revocation of the delegation chain or path, which can take place at the beginning, end or middle of a delegation path.