The First ACM Workshop on Role-Based Access Control (RBAC) was held at the National Institute of Standards of Technology (NIST) in Gaithersburg, Maryland on November 30th and December 1st, 1995. The Workshop was sponsored by ACM SIGSAC, ACM DC Local Chapter and NIST. Proceedings of the workshop are in preparation and should be available in the May-June timeframe from ACM.
The Call for Papers describes the organizers' motivation in creating this series of workshops. Relevant portions are quoted below.
"In a nutshell, the essence of Role-Based Access Control (RBAC) is that rights and permissions are assigned to roles rather than to individual users. Users acquire these rights and permissions by virtue of being assigned membership in appropriate roles. This simple idea greatly eases the administration of authorizations. The basic concepts behind RBAC have been around since the advent of multi-user computing and information systems in the late 60's and early 70's. There has been a recent resurgence of interest in RBAC. This is in large part due to the user community's expression of interest in RBAC, and disenchantment with traditional mandatory and discretionary access controls.The ACM Workshop on Role-Based Access Control has been created to bring together users, vendors and researchers who are interested in fostering and promoting RBAC. The Workshop's objectives are to provide a forum for rapid dissemination of new ideas and developments in RBAC, and to cultivate convergence towards a standard framework for RBAC and related access control issues.
This is the first in a series of workshops to be held on a fairly frequent basis. Ideally, we would like these workshops to develop a standard reference model for RBAC. We recognize this cannot be accomplished in a single meeting, but we are seeking progress towards this end at a rapid pace. In the first workshop we seek input from users regarding their access control needs, from vendors regarding plans for products, and from researchers concerning conceptual frameworks from which to approach these issues.
Although there is much agreement on the basic concepts and value of RBAC, there remain a number of issues on which different researchers and vendors are proposing different approaches. The user community is also often doing access control and management in a way that is very similar to RBAC without actually applying that name. At the same time, the scope of RBAC ranges from very simple and straightforward at one end, to very sophisticated and complicated at the other. Much remains to be done to develop a scientific and engineering discipline in this arena. The ACM Workshops on RBAC are primarily intended to support this goal."
The Workshop attracted attendees from the US, Canada and various West European countries. Many of the attendees met for the first time at the Workshop. We had representation from users, vendors, academia, research laboratories and standards organizations. Because the need for RBAC is pervasive in computer systems it was particularly gratifying that we had representation from the database, network, distributed systems and operating systems communities. Concepts of RBAC have evolved more or less independently in these communities and it is important to have Workshops such as this to foster cross-fertilization of ideas.
The Workshop was successful in its modest goal of taking a first step towards a consensus reference model for RBAC. There was substantial agreement among attendees regarding the general outlines of RBAC and its various components. There was considerable discussion about the details, including the reconciliation of different terminology used by different groups working in the field. There was also extensive discussion concerning the priorities and importance of various aspects of RBAC. Nonetheless, in general, there was substantial agreement.
From the workshop discussion two issues have emerged as significant ones for further work in similar workshops and study groups. Firstly, any scientific discipline needs an internally consistent and widely used terminology and vocabulary. In the early stages, as the discipline emerges, different people use the same words to mean different things, and sometimes major concepts have not yet been articulated and named. As the discipline matures a de facto standard terminology emerges. Efforts to impose a standard terminology by committee are rarely successful. These efforts can be premature if major concepts are still emerging in the field. As the field matures development of a de facto standard can be encouraged and helped by workshops where disagreements about terminology and standards can be articulated and discussed. Discussions at the first workshop indicate that RBAC is at the right point of maturity to merit such efforts.
Secondly, RBAC is an expansive concept. In order to scope the problem the RBAC community needs to clearly articulate what is excluded as being outside the scope of RBAC proper. This relates to the terminology issue because we need to decide what should legitimately be called RBAC. But there is a bigger issue than terminology here. A sound technical discipline draws boundaries around its major concepts for technical reasons. The RBAC community needs to clearly identify where it is useful to draw these boundaries for technical reasons (and not merely for convenience of terminology).
In the rest of this report I describe my impression of the sessions as they actually took place. Let me emphasize that this is my personal impression and I have not verified these remarks with other attendees. A revised report incorporating feedback from attendees will appear in the workshop proceedings.
After introductory remarks from representatives of the various sponsoring organizations, the Workshop's first session on "What is RBAC?" followed. The first talk was presented by me. My objective was to present a framework of models for RBAC and the rationale which led to this framework. (This family of RBAC models was recently published in IEEE Computer, Feb. 1996). As is appropriate in a workshop setting there were many questions and comments during the presentation. The central notion of this framework is that users and permissions are brought together indirectly by roles. So a user acquires a permission by virtue of being assigned to a role that has been assigned that permission. The framework begins with a base model to which role hierarchies and constraints are added in the extended models. This piecemeal approach is motivated by the use of the term RBAC in the literature to include simple as well as sophisticated concepts.
My talk was followed by a presentation from Virgil Gligor concerning a RBAC model that has been developed for implementation on NSA's Synergy platform. Interestingly both talks presented work funded in part by NIST. A major discussion point during Virgil's talk concerned the review of access rights and its importance in context of RBAC. Virgil argued that a central aspect of RBAC is that access review on a per subject or per object basis involves similar effort. Several attendees noted that there are systems (such as Novell's NetWare) which store access control data so that per object or per subject review requires traversal of the access control data structures, but such traversal has been demonstrated to be practical. Cipher readers: please note the following paragraph, which is revised by the author from the originally published version of this report. This revision entered on the Cipher Web April 30, 1996 -- CEL] My talk was followed by a presentation from Virgil Gligor concerning a RBAC model that he has developed. Virgil began by noting that if RBAC proponents believe the notion of a role is fundamentally different from that of a group of users we should be able to articulate the essential difference. Since access review is among the basic aspects of access control, he proposed we distinguish between roles and groups by requiring that roles allow us to perform per-subject review of rights. Moreover, per-subject review is needed for separation-of-duty and conflict-of-interest properties generally considered important in RBAC. Virgil observed that per-subject review is difficult in large distributed systems using traditional access control lists (ACLs) because, given a user or group identity, one does not know where to start the review. Potentially, one would have to search the entire set of objects' ACLs to determine the extent of a user's permissions. In discussion some attendees argued that such searches to determine per-subject review are conducted by several practical systems (such as Novell's NetWare, IBM's RACF and IBM's OS/400 list). Virgil maintained that none of these systems provide this support with "group" mechanisms alone, and their access control models do not scale up to large distributed systems. Virgil argued that access control policies, such as RBAC, that need both per-object and per-subject review could be derived from the storage of the access matrix, redundantly, on both rows and columns.
The second session continued the theme of "What is RBAC?" Emile Lupu of the Imperial College in London, UK presented a talk on a policy based framework for RBAC. His co-author and thesis advisor Morris Sloman has been conducting research in this area from the perspective of distributed systems management. Lupu's talk introduced the concepts of obligations and duties going beyond the access control notion of permissions. Lupu and Sloman were careful to point out that obligations and duties are outside the scope of access control. In their view roles are a larger concept beyond access control and it is important to distinguish and recognize the scope of access control roles in contrast to roles in general.
Chris Sundt presented a talk on ICL's experiences with deploying RBAC in actual products and their experience with real users. Chris noted that RBAC makes it easy to split the administration of the role-user relationship from that of the role-permission relationship. He said users find this very useful. He also introduced the notion of an affiliation whereby a role can be further qualified. Thus a role of branch manager could be qualified by an affiliation to a particular branch thereby conferring branch manager permissions only within that branch. This was another facility that ICL found to be popular with users.
The second session on "What is RBAC?" concluded with three shorter talks. Sylvia Osborne of the University of Western Ontario in Canada presented an overview of RBAC research by her group. Among other things this work has developed algorithms for recognizing redundant assignment of permissions to roles, as well as algorithms for deletion and addition of roles in a hierarchy and similar operations. Luigi Guiri of Fondazione Ugo Bordoni in Rome, Italy presented an extension of a model of Baldwin's based on a role as a named protection domain. Luigi argued that a role should be viewed a set of named protection domains (and roles). He presented a role algebra for constructing such sets based on the notion of and-roles (that are simultaneously activated) and or-roles (that are mutually exclusive). For logistical reasons, the third short talk of this session was actually presented later but logically belongs in this session where it had been originally scheduled. The talk was by Fang Chen who is a student of mine at George Mason University. He described some preliminary work in designing a language to express constraints on components of RBAC. Mutually exclusive roles, where one user cannot be assigned both roles, are perhaps the most common example of constraints in RBAC, but there are also many other useful constraints.
After lunch, the third session on "What are user needs?" had two presentations. The first talk by Yahya Al-Salqan of West Virginia University described an application of RBAC in the health care domain. In this project RBAC provided by the Oracle database management system (DBMS) was being considered as a means to enforce patient privacy and confidentiality requirements. Possible extensions to an inter-organizational environment were also being studied. The second talk by Trent Jaeger looked at the possibility of using RBAC in collaborative systems. RBAC facilitates the use of least privilege because different code can be executed with different roles by the same user. This makes it safer to use agents supplied by other users, since these agents can execute on a user's workstation but with restricted roles. Further, different roles can be assigned to different agents depending upon the trust and requirements of these agents.
The fourth session consisted of a group exercise developed by Charles Youman of SETA Corporation. The exercise was conducted in two break out groups. The objective of the exercise was to rank order different aspects of RBAC with respect to their priority or importance. The results indicated that there were some differences in priorities assigned by individual attendees, but by and large there was considerable agreement on what the more important aspects were. This is an encouraging finding which suggests that there is substantial consensus within the RBAC community upon which a widely accepted reference model can be developed. This concluded the first day.
The second day began with a number of short talks in a session called "Available and Emerging Technologies." LouAnna Notargiacomo of Oracle Corporation described various aspects of RBAC in Oracle 7 and Trusted Oracle 7. Oracle has pioneered the use of roles in relational DBMSs and these features are being incorporated into SQL standards. Jeremy Epstein of Cordant Inc. presented a talk on "NetWare 4 as an Example of Role Based Access Control." Jeremy's talk focused on identifying how Netware can implement the concepts of the RBAC models introduced earlier in my talk. Netware has a built-in concept of Organizational Roles but attaches very little semantics to it beyond that associated with any other Netware Directory Service object. Jeremy's finding was that some aspects of RBAC do translate quite easily on to Netware roles but others would be difficult to support. These two talks demonstrate that there is available technology on popular platforms that can be used today to support RBAC (at least to some extent).
The remaining papers in this session addressed emerging technologies. T.C. Ting of the National Science Foundation (on leave from University of Connecticut) described ongoing RBAC research at U. Conn. concerned with implementing RBAC in object-oriented systems. Their project seeks to develop RBAC notions consistent with object-oriented conceots such as encapsulation, information hiding and inheritance. They have used a health-care case study in their project. John Barkley of NIST gave a talk on "Implementing Role Based Access Control using Object Technology." In this project John used a concept of layered objects to facilitate flexible administration while minimizing impact of role changes on applications. A prototype demonstration of these concepts is available at NIST's RBAC home page (http://waltz.nist.gov/rbac). Rohan Thomas of Odyssey Research Associates (ORA) presented a talk on "RBAC and Distributed Object-Based Enterprise Computing." Roshan described ongoing work at Odyssey on next-generation security models that involve RBAC as a component. Roshan also mentioned ORA's efforts at including some of these concepts in OMG's CORBA initiative.
The next session consisted of open discussion on two important issues in making RBAC practical. Edward Coyne of SETA Corporation facilitated discussion on Role Engineering. The definition of roles, assignment of permissions to roles and definition of other components of an RBAC model, is essentially a requirements engineering process. Attendees agreed that this is an important and complex topic which should be approached with a engineering methodology. Charles Youman of SETA Corporation facilitated discussion on RBAC Transition. The question is how to get from here (no RBAC) to there (RBAC)? Attendees agreed that RBAC would co-exist with other access control mechanisms. Moreover, RBAC would need to be deployed incrementally in an orginazation rather than totally replacing legacy approaches. Further details of these two discussion will be available in the Workshop proceedings.
After lunch there was a discussion session on "Consensus Reached and Remaining Issues," moderated by me. A number of open issues were enumerated. The discussion focussed entirely on the most important which was to define the concept of a role and distinguish it from the familiar concept of a group in access control. There was agreement that the notion of a directory and a file and fairly standard notions in operating systems (OSs) even though the details do vary from one OS to another. Similarly the concept of a group as a collection of users (and possibly other groups) is well-known in access control systems. The discussion attempted to develop a notion of role along the same line. The concept of a role in access control is currently being used in two different ways. Some use role to mean a named collection of permissions (and possibly other roles). Others use role to mean a named collection of permissions and a named collection of users (and possibly other roles). The discussion could not reconcile whether one of these was the "correct" use of the term role. Further details and thoughts on this discussion will be provided in the Workshop proceedings. It might seem that a discipline that cannot even agree on the meaning of its key term (role in this case) is in deep trouble. I am, however, much more optimistic and feel there is substantial consensus that can overcome these minor disagreements of terminology. Perhaps the term role can be used in both ways, but we just need to make clear how it is being used in a given context. Or perhaps we need to agree as a community to use two different term for these two different concepts of a role. It would be inappropriate to discard the entire disciple of RBAC just due to some minor disagreement in basic terminology.
The final session of the workshop was devoted to discussion of future plans. Based on these discussion the Workshop Steering Committee is planning for a second workshop to be held in the early part of 1997.
In conclusion I reiterate my earlier statement that the first RBAC Workshop was successful in its modest goal of taking a the important first steps towards a consensus reference model for RBAC. Overall success of this series will depend upon what happens subsequently. Anyone interested in being involved should contact me.