A Review Paper Role Based Access Control Anthony Rhodes School of Computing Science Faculty of Information Technology Queensland University of Technology Brisbane AUSTRALIA
[email protected]
William Caelli Information Security Research Center Faculty of Information Technology Queensland University of Technology Brisbane AUSTRALIA
[email protected]
Abstract The essence of Role-Based Access Control (RBAC) is that system permissions are assigned to defined “roles” rather than to individual users. Users acquire these permissions by virtue of being authorised to act in a categorised manner known as a “role”. The driving motivation for RBAC is to simplify security policy administration while facilitating the definition of flexible, customised policies. Basic RBAC models have been successfully applied since the mainframe era, but emerging networked systems, which have greater numbers of users, roles, and program components, challenge the expressive power of these classical RBAC models. This is particularly true for cross-enterprise distributed networks for electronic commerce applications. The development of new modeling concepts and techniques is required to support large-scale, enterprise-wide, distributed systems. Role languages are needed that can simply modify constraints associated with roles thereby permitting dynamic response to enterprise policy changes in a transparent fashion to applications. Role definition and management thus becomes a process with high trust requirements.
1
Introduction
A study by the United States Government’s National Institute for Standards and Technology (NIST) [SAND95], (see also Common Criteria RBAC, http://csrc.nist.gov/cc/), found that Role Based Access Control (RBAC) addresses many of the systems security needs of both the commercial and government sectors. Many organisations base access control decisions on the “roles” that individual users take on as part of an organisation. The preferred information system of use for RBAC would exhibit the following characteristics: user characteristics: large number of users, few security administrators, frequent change of job responsibility; data and application characteristics: large number of data objects, sharing based on job functions; enterprise characteristics: data owned by enterprise, controlled by security administrators, before and after the fact audit, and periodic assessment of access control policy enforcement necessary. Ferraiolo [FERR95] believes that the principal motivations behind RBAC are firstly, the ability to articulate and enforce enterprise-specific security policies and secondly, to streamline the typically burdensome process of security management. A central notion of RBAC is that users do not have discretionary access to enterprise objects, i.e. it is a form of non-discretionary access control. In this form of access control, users do not own objects for which they are allowed access; enterprise based protection policies are unavoidably imposed on all users. This simplifies the management of authorisation and potentially provides increased flexibility in specifying and enforcing enterprise-specific protection policies. It is then very simple to make
users members of roles as dictated by their organisational responsibilities and qualifications. These users can be reassigned from one role to another without modifying the underlying access structure. As new applications and operations are developed, roles can be granted new permissions. Similarly, these permissions can be revoked as required. One of RBAC’s major points is its administrative capabilities. Systems administrators control access at a level of abstraction that reflects the way enterprises typically conduct their business. This is achieved by statically and dynamically regulating users’ actions through the establishment and definition of roles, role hierarchies, relationships and constraints. This is in contrast to the conventional and less intuitive process of administering lower level access control mechanisms directly on an object-by-object basis. RBAC [SAND96] is pervasive in computer systems enveloping the database, network, distributed systems, operating system, security and application communities. Concepts of RBAC have evolved more or less independently in these communities.
1.1
What is RBAC ? In Role-Based Access Control (RBAC) [SAND96], rights and permissions are assigned to roles rather than to individual users. Users acquire these rights and permissions as they are assigned membership in appropriate roles. This simple idea greatly eases the administration of authorisations. 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. Many such systems evolved from research and development efforts of the US Department of Defense (DoD). As such there was a strong use of mandatory access controls and such systems were B-level [TCSEC85] secure systems. There has been a recent resurgence of interest in RBAC with its inherent flexibility and detail of control. This is largely due to the user community's expression of interest in RBAC, and disenchantment with traditional mandatory and discretionary access controls, MAC and DAC. These two basic types of access control mechanisms are used to protect information from unauthorised access: DAC Because DAC places the decision of who can access information at the discretion of the creator on the information, DAC is not applicable to the majority of personal information systems. MAC Because MAC requires all those who create, access, and maintain information to follow rules set by administrators, MAC is the kind of access control mechanism required of personal information systems. The most commonly used MAC is the multilevel security (MLS) mechanism used by the US DoD. This mechanism associates information with such labels as TOP SECRET, SECRET, and CONFIDENTIAL. This type of MAC is not flexible enough for commercial use, nor is it adequate for the needs of personal information systems. RBAC then is a MAC, which has evolved to meet the needs of commercial information systems. Rather than labelling information, it associates roles with each individual who might have a need to access information. Each role defines a specific set of operations that the individual acting in that role may perform. The operations may be broad or very specific, e.g., when a diagnosis is entered into a patient record, the symptoms leading to that diagnosis must also be entered. Indeed the data “semantics” must be implemented by any RBAC scheme. Once an individual has been properly identified and that identification authenticated, the individual chooses a role that has been assigned and accesses information according to the operations assigned to the role.
RBAC does not enforce any one protection policy [FERR95]. It supports several well known security principles and policies critical to any information system. These include the enforcement of the concept of “Least Privilege” for administrators and general users; and the enforcement of conflict of interest rules that involve duty assignment and dynamic and static separation of duties. These policies can be enforced (1) at the time operations are enforced for a role, (2) at the time users are authorised as members of a role, (3) at the time of role activation during a user’s active session, or (4) when a user (application) attempts to perform an operation on an object. 1.2
Why is RBAC better than other Access Control policies? The major benefits of RBAC are the ability to express and enforce enterprise-specific security policies and to simplify the process of security management. RBAC is a framework of policy rich mechanisms that allow per-subject (role) as well as per-object access review. Its configuration is dependent on organisational policies. This allows RBAC to be adaptable (more so than other types of access control) to any organisational structure and means of conducting business. The policies implemented under RBAC can evolve over time as enterprise and organisational structure and security needs change. RBAC has been seen as a “commercial” and cost-effective alternative to the earlier “MAC” concepts as outlined in the “Rainbow Series [NCSC89]”. RBAC provides greater productivity on the part of security administrators, resulting in fewer errors and a greater degree of operational security. It can also be argued that RBAC/MAC actually simplifies information system management, administration and security. This is achieved [FERR95] by statically and dynamically controlling the actions of users by establishing and defining roles, role hierarchies, relationships and constraints. After this RBAC environment is established, the main administrative tasks tend to be adding and deleting users to and from roles. This differs from the more conventional and less intuitive process of directly managing lower level access control mechanisms, (e.g. access control lists (ACLs) or capabilities), on an object-by-object basis. Additionally, in a distributed environment, [FERR95] administrator responsibilities can be divided among central and local protection domains. In other words, central protection policies can be defined at the enterprise level while leaving protection issues that are of local concern at the organisational unit level.
1.3
RBAC Characteristics and Policies RBAC policies are described in terms of users, subjects, roles, role hierarchies, operations and protected objects. To perform an operation on a RBAC controlled object, a user must be active in some role. This assumes that the user is an authorised member of that role. RBAC enables administrators to place constraints on role authorisation, role activation and operation execution. Constraints could include cardinality and mutual exclusivity rules that can be applied on a role-by-role basis. Constraints can also be placed on the authorisation of an operation to a role and on operations being performed on objects, e.g. time and location constraints. The following itemised list outlines many of the characteristics of RBAC: [FERR95]
•
within the RBAC framework, a user is a person, a role is a collection of job functions, and an operation represents a particular mode of access to a set of one or more protected RBAC objects;
•
the type of operations and the objects that RBAC controls is dependent on the type of system in which it will be implemented, e.g. within a transaction management system, operations would take the form of and exhibit all the properties of a transaction;
•
roles can have overlapping responsibilities and privileges, i.e. users belonging to different roles may need to perform common operations. RBAC therefore supports the concept of role hierarchies;
•
a role hierarchy defines roles that have unique attributes and that may contain other roles, i.e. that one role may implicitly include the operations, constraints, and objects that are associated with another role;
•
role authorisation (association of user with a role) can be subject to the following: the user can be given no more privilege than is necessary to perform his/her job (principle of least privilege); the role in which the user is gaining membership is not mutually exclusive with another role for which the user already possesses membership (static separation of duty); & the numerical limitation that exists for role membership cannot be exceeded (cardinality property);
•
role activation involves the mapping of a user to one or possibly many roles. A user initiates a session during which the user is associated with a subset of roles for which that user has membership. A particular role for a user can be activated if: the user is authorised for the role being proposed for activation; the activation of the proposed role is not mutually exclusive with any other active role(s) of the user; the proposed operation is authorised for the role that is being proposed for activation; & the operation being proposed is consistent within a mandatory sequence of operations;
•
role execution of an operation can take place only if the subject is acting within an active role, i.e. once it is determined that a role is part of the authorised role set for the subject;
•
dynamic separation of duty can be provided with RBAC as long as the following rule is satisfied: a subject can become active in a new role only if the proposed role is not mutually exclusive with any of the roles in which the subject is currently active;
•
operation authorisation can only be granted to a subject if the operation is authorised for the subjects proposed active role;
•
operational separation of duty requires that for all the operations associated with a particular business function, no single user can be allowed to perform all of these operations. In other words, a role can be associated with an operation of business function
only if the role is an authorised role for the subject and the role had not been assigned previously to all of the other operations; •
object access authorisation requires subject access to RBAC objects to be controlled. This ensures enforcement of enterprise policies to RBAC objects. A subject can access an object only if: the role is part of the subjects current active role set; the role is allowed to perform the operation; & the operation to access the object is authorised.
As shown above, RBAC is a framework of robust security policies. This permits RBAC to map to various organisational structures and means of conducting business. Over time, the security policies implemented under RBAC can evolve as enterprise and security requirements change.
1.4 What is the difference between roles and groups? [SAND95] argues that many access control systems provide groups of users as the unit of access control. A major difference between most implementations of groups and the concept of roles is that groups are treated as a collection of users and not as a collection of permissions and users are seen as being people. A role is both a collection of users and a collection of permissions. The role serves as an intermediary to bring these two collections together. A well known operating system that uses the group concept is Unix. In Unix group membership is defined in the files /etc/passwd and /etc/group, from which it is easy to determine the groups a user belongs to or which users belong to a particular group. On the other hand determining the permissions of a group is not so straightforward. To do this will generally require a traversal of the file system as permissions are granted to groups on the basis of permission bits associated with individual files and directories. Additionally, the assignment of permissions to groups is highly decentralised (the owner of any Unix filesystem sub-tree can assign permissions for that sub-tree to a group). In certain situations, Unix groups can be used to implement roles, even though groups are not the same as the generally accepted [SAND95] notion of roles. Groups also imply a more static organisational structure that was actually inherent in the organisation where UNIX originated. To further highlight the distinction between group and role, consider a system in which it takes twice as long to determine group membership as to determine group permissions. Assume that group permissions and membership can only be changed centrally. This system then has a group mechanism that would be very close to the concept of a role. This suggests two characteristics of a role: 1) it should be almost equally easy to determine role membership and role permissions, and 2) control of role membership and role permissions should be centralised in a few users. Many mechanisms that claim to be role-based fail one or both of these requirements.
1.5
Do any standards incorporate RBAC? A number of organisations are including provisions for RBAC in open consensus specifications and in the standards area.
RBAC is an integral part of the security model and architecture for the Secure European System for Applications in a Multi-vendor Environment (SESAME) security scheme for distributed computer network systems. In addition, the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) security specification uses RBAC as an example of an access control mechanism that can be used with the Distributed Object Technology defined by the OMG. At the OMG Security SIG meeting in 1995, John Barkley from the US National Institute of Standards and Technology (NIST), gave a presentation on RBAC, and how it might be applied in a CORBA based environment. Roles are also being considered as part of the emerging SQL3 standard for an information access and manipulation language for database management systems. This has been based on their implementation, for example, under proprietary database management systems such as “ORACLE 7”. Finally, roles have been incorporated in the commercial security profile of the draft “Common Criteria” [SAND95], an international set of specifications for security in so-called “trusted systems”.
2
Role Based Access Control Models and Architectures
Role based access control has been proclaimed as being capable of representing many kinds of security policies, models and architectures. Basic RBAC models have been successfully applied since the mainframe era, but emerging systems, which have greater number of users, roles, and program components, are challenging the expressive power of these traditional models. Current research is focusing on the evaluation of the effectiveness of RBAC models and the development of newer, better modelling concepts and techniques. As stated previously, RBAC does not enforce any one protection policy. Coinciding with the First ACM Workshop on Role-Based Access Control in December 1995,and since then, a number of researchers have formulated or described models and architectures for RBAC. Below is a selection of these. Odyssey Research Associates (ORA) [THOM95] describe ongoing work at Odyssey on next-generation security models that involve RBAC as a component. ORA's efforts have also aimed at including some of these concepts in OMG's CORBA initiative. Sandhu [SAND95] describes a framework of models for RBAC and the rationale which led to this framework 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. Other RBAC models developed by researchers generally use the models described in this paper as reference points. In [FERR95a] the following Enterprise Authorisation Model is presented as a model for RBAC. Organisation
User
In this model: Role Types Role instances Job Positions Organisational Unit
capture generic functions of the enterprise; capture the specific organisational context for each role type; captures the constraints on user enrolment in different functions; & the captures the constraints placed on job positions and enterprise structure.
Fundamental to this model is that actions are selectively associated with roles, i.e. there is a binding associated with the role and the actions that are associated with the role. Also in this model there is provision for a Role Type Inheritance Property. This is important because under RBAC, roles can have overlapping responsibilities and privileges. Role hierarchies (via inheritance) are a natural way of organising roles to reflect authority, responsibility and competency, e.g. in a hospital information system, a role specialist could contain the roles doctor, registrar and resident. A new model suitable for both conceptual and logical database security design is described in [GIUR95]. The model attempts to address the semantic mismatch between the currently accepted notion of role-based access control and the real-world significance of the role concept. Additionally, a role algebra has been defined which constitutes the basis for the development of automated tools for database security design. Interestingly, to build a complete database design methodology the author suggests that the new model may be used together with a conceptual database model, such as the Entity-Relationship data model. [LUPU95] has been conducting research in RBAC from the perspective of distributed systems management. He and his co-researchers introduce the concepts of obligations and duties going beyond the access control notion of permissions, i.e. they 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 recognise the scope of access control roles in contrast to roles in general. They outline a framework for specifying management roles which define both authorisation and obligation policies for a particular management position. The framework caters for human and automated managers and includes interactions and concurrency constraints to specify aspects of the inter-role relationships. [YIAL96] describes a security architecture (being developed in the CORBA distributed programming environment), designed to support role-based access control for distributed object systems in a large-scale, multi-organisational enterprise. A prototype of this architecture
is being implemented using Orbix [LUPU95]. It is an implementation of the work described in [LUPU95]. In this security architecture, the concept of a role is used to define access control related to a position within an organisation although the role framework described caters for the specification of both authorisation and obligation policies. In this framework roles and role relationships represent enterprise security requirements. Roles are expressed in terms of policies that refer to domains to provide a very flexible basis for specifying RBAC that caters for large scale, inter-organisational distributed systems. The advantage of using roles for specifying enterprise policies is that individuals can be assigned or withdrawn from the role positions without having to respecify the policies applying to the role. An object oriented approach to specifying roles permits multiple instances of a basic role to be instantiated, e.g. all branch managers of a bank. The access control model is based on domains that are used to group objects (which may be subjects or targets), for specifying security policies. These domains are superior to the group concept traditionally used in access control and can be used to split responsibility or mirror the structure of large-scale enterprises. This domain concept can be used to model (job) positions and roles, such that the security service only has to know about domains. The authorisation or access control policies used in this architecture provide a very flexible means of specifying access control permissions and including constraints (such as a time validity policy), to limit their applicability. They can also be extended to specify delegation policy, including cascaded delegation of access rights. Policies explicitly identify both subjects and targets, and since domains maintain information about the policies applying to them, it is easy to analyse the policies to determine those applying to a specific object. Access control and authentication are implemented using security agents on a per host basis to achieve a high degree of transparency to the application level. The domain based authentication service uses symmetric cryptography and is implemented by replicated servers that maintain minimal state. More specifically, the security architecture consists of four main components: Policy Service used to maintain and distribute policy objects; Domain Service used to maintain domain objects and certify domain membership; Authentication Service to authenticate users and remote authentication agents and verify the authenticity of delegation tokens and domain membership statements which form the basis for access control decisions. The AS is based on symmetric cryptography to minimise the encryption overhead. It is provided by on-line servers with minimal state to facilitate replication; & Security Agents which are employed on a per host basis to provide a secure channel for authenticating remote objects, determining access control policies, and establishing session-keys for subject-target pairs. The operation of these agents is supported by the above three services. The distributed security provided by the system is transparent to the application level and API’s are provided to facilitate the development of security unaware applications. RBAC is also well suited in a transaction oriented environment such as the Web. [BARK98] states that one of the most demanding problems in managing large networked systems is the complexity of security administration. RBAC is then perfectly suited for use on both internets
and intranets. It provides a secure and efficient way to control access to an organisations Web data. In this article they describe RBAC/Web, an implementation of RBAC for use by Web servers. The components of RBAC/Web allow it to be incorporated into existing systems with no modifications to server code, making it portable to most Web servers. For more information, see http://hissa.ncsl.nist.gov/rbac.
3
Sample Uses of Role Based Access Control
3.1
Health Care Information Security Within the health care industry, there are continual problems associated with how to ensure the secrecy and integrity of health information, in particular, patient information. In Australia, health care information security and privacy is addressed by the Standards Australia publication AS4400 [SA95]. It is generally accepted [BARK95a] that RBAC is more suited to health care applications than other access control schemes due to the variety of people interested in the patients medical condition. A doctor (role) would require access to all patient information, whereas a pathologist (role) would only require access to some patient information, age, sex, and clinical data. At the First ACM/NIST RBAC Workshop in 1995 it was noted [HU95] that role is a fluid concept in hospitals. This strongly infers that dynamic discretionary roles are important. In other words, a mechanism is required for a user to change roles. This is an important area of RBAC for future applied research. A sample RBAC policy [BARK95a] related to clinical and administrative patient data exists. The draft specification, “A Strategy for Security of the Clinical Record and its Transfer” by Dr. Antony Griew of the Institute for Health Informatics in the UK describes a policy for patient information access. This policy is RBAC with the addition of the capability of labelling information that is only available to the patient and the doctor. It specifies roles and the level of access permitted by each role. Another application of RBAC in the health care domain is described in [ALSA95]. 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-organisational environment were also being studied. 3.2
Available Emerging Technologies for RBAC The Oracle Corporation [NOTA95] uses 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. [EPST95] describes NetWare 4 as an example of Role Based Access Control. It focuses on identifying how Netware can implement the concepts of the RBAC models. Netware has a built-in concept of Organisational Roles but attaches very little semantics to it beyond that associated with any other Netware Directory Service object. The main finding in [EPST95] was that some aspects of RBAC do translate quite easily on to Netware roles but others would be difficult to support. These two articles demonstrate that there is available technology on popular platforms that can be used today that supports RBAC concepts to varying extents.
3.3
Security Administration Manager (SAM) The Security Administrator Manager (SAM) [AWIS97] of Schumann Security Software, Inc. is a tool for enterprise-wide security management that implements many RBAC concepts. It has been commercially available since 1993. With SAM, all security systems and all application security of an enterprise can be administered from a single point of administration/control. SAM provides an architecture under which company-wide information security administration can be automated by interfacing to human resource applications, authentication servers, single sign-on services and access control systems. The SAM environment provides all features required to maintain users, their authorisations and privileges, and the authorised resources, across multiple platforms. SAM’s ability to centrally administer and audit the security of the whole enterprise is a major administrator benefit. Although this ability alone does not implement RBAC, SAM provides a number of powerful RBAC features to administer the data. SAM is designed to be the link between the high-level company security policy and the low-level security systems. It recognises role descriptions at a conceptual level and translates them into the native syntax of the security systems/applications. These features make SAM interesting in view of any RBAC discussions.
4
Implementing Role Based Access Control
4.1
Is RBAC object-oriented? In [FERR95a] a Role Type Inheritance Property is depicted as follows. This seems to infer that RBAC is well suited to the object-oriented paradigm.
RT0 Inherits
In fact, under the direction of John Barkley at NIST, a RT1 RT2 distributed, object-oriented, RBAC demonstration system has been developed [BARK95b]. This demonstration uses RT3 CORBA, ORACLE’s SQL/RDA (remote data access) and RBAC. In this demonstration, a patient record data base object (PRDBO) is defined. CORBA is used as a means of implementing the PRDBO. The methods in the object implementation access the data however and wherever the data is actually stored. SQL/RDA is used within the PRDBO methods to access the data. The PRDBO organises patient information into groups. Access to patient information is controlled using the RBAC mechanism. To successfully log into the system, a correct combination of username/role must be supplied. After successfully logging in, screens are
presented which are associated with the role chosen at login. These presented screens are related to the level of access that is associated with the role. 4.2 Implementing RBAC using Object Technology The abovementioned project [BARK95b] uses a concept of layered objects to facilitate flexible administration while minimising impact of role changes on applications. A prototype demonstration of these concepts is available for viewing at NIST's RBAC home page (http://hissa.ncsl.nist.gov/rbac). More specifically, with the Role Based Access Control (RBAC) implemented in this project, each role is associated with a set of operations which a user in that role may perform. The power of RBAC as an improved access control mechanism is centred on the concept that an operation may theoretically be anything an applications developer desires. This is contrasted to traditional access control mechanisms where labels are associated with information blocks. These labels indicate relatively simple operations, such as, read or write, which can be performed on an information block. In direct contrast, operations in RBAC may be arbitrarily complex, e.g., ``a night surgical nurse can only append surgical information to a patient record from a workstation in the operating theatre while on duty in that operating theatre from midnight to 8 AM.'' A goal for implementing RBAC is to allow operations associated with roles to be as general as possible while not adversely impacting the administrative flexibility or the behaviour of applications. One approach which can be used to realise this goal of maintaining flexible administration, minimising impact on applications, and maintaining a significant capability for defining complex role operations is to use Object Technology as described in [BARK95b]. In the demonstration system used in this paper, Barkley defines a complete set of operations based on access methods associated with the information storage mechanism. These are the operations that are made available to an application. They become the methods in a basic access methods class. Access control for the basic access methods class is provided by role classes, one for each defined role. The methods of the role classes have the same names, types and parameters as the methods of the basic access methods class. Access control to the information accessed by the basic access methods class is located exclusively in the role classes and not in any other part of the application. The bodies of the methods in the role classes are restricted to: conditionals which determine access for the role associated with that role class; and/or filters that constrict the flow of information between the application interface and the basic access methods. If access is permitted for a role, the methods of the role class then invoke the corresponding methods of the basic access methods class. If not all information obtained by the basic access methods is permitted to a role, then the parts of the information not permitted can be filtered out. Filtering may be more desirable in an application rather than generating an access violation for the entire information block. The methods of the application interface class also have the same names, types and parameters as the methods of the basic access methods class. The methods of the application interface class invoke the corresponding methods of the role classes. It is the methods of an application
interface object that the application invokes. Given the current role associated with the application, the methods of the application interface object select the appropriate role object. This approach has the following advantages: Applications need not change when access conditions for roles are changed. The methods of the application interface class and the methods of the basic access methods class are fixed and remain constant over time, only the access conditions for roles need to be changed. Access conditions for roles are easily changed. Access conditions for roles are located exclusively within the role classes. Consequently, role policy changes do not require modifications to the applications themselves, only to role classes. Performance overhead is minimal. If a simple “role language” was available to database security administrators for specifying access conditions, then a “role language compiler” could generate role objects and place them in libraries to be used by applications. With dynamically linked libraries, these role objects would be loaded when the application is loaded into memory for execution, i.e. such applications do not need to be re-linked when role classes are modified.
5
Role Based Access Control Research
The Fourth ACM Workshop on Role-Based Access Control was scheduled for October 28-29, 1999. The theme for this workshop will be the discussion of the RBAC applications (Web, CORBA), various implementations of RBAC and products and tools based on the RBAC model. The previous three workshops have examined the theoretical foundations of RBAC and application of RBAC models to a variety of systems. The inaugural workshop, held in November 1995, was successful in its modest goal of taking a first step towards a consensus reference model for RBAC. The second workshop, held in November 1997, saw applications of RBAC models in operating systems, databases, distributed applications, and the administration of RBAC policies themselves. In addition, several new modelling concepts were introduced in the second workshop that may enable complex systems to be built and administered more easily. The third workshop, held in October 1998 focused discussion on the application of RBAC models and concepts to both traditional and emerging systems. In particular, researchers looked at the evaluation of the effectiveness of current RBAC models and the development of new modeling concepts to address the needs of future applications based on the RBAC paradigm. Proceedings of the first three workshops are available from ACM. Probably the ideal way to portray what current research is being done in Role Based Access Control is to present an overview of the technical program for the Fourth ACM Workshop on RBAC: (1999) • Session 1: Applications RBAC on the WEB by Smart Certificates Role-Based Access Control on the Web Using JAVA
A Framework for Implementing Role-Based Access Control using CORBA Security Service •
Session 2: Constraints On the Increasing Importance of Constraints The RSL99 Language for Role-Based Separation of Duty constraints Supporting Relationships in Access Control Using Role Based Access Control
•
Session 4: Implementations Migrating to Role-Based Access Control SecureFlow: A Secure Web-enabled Workflow Management System RBAC in UNIX Administration
•
Session 5: Models and Model Extensions Managing Trust between Collaborating Companies Using Outsourced Role Based Access Control Dynamic Rights: Safe Extensible Access Control Attribute Certification: An Enabling Technology for Delegation and Role-Based Controls in Distributed Environments
•
Session 7: Tools Towards a UML Based Approach to Role Engineering Napolean Network Application Policy Environment The Uses of Role Hierarchies in Access Control
Sessions 3 and 6 were panel discussions (user’s perspectives, products and tools)
6
Role Languages
In [BARK95b] it is noted that access conditions (constraints) for roles are located within the role classes, therefore role policy changes do not require modifications to the applications themselves. This is important as it leads to the natural idea of constructing a role language that can simply modify constraints associated with roles therefore permitting immediate (dynamic) response to organisational policy changes in a transparent fashion to applications. Responding to dynamic changes of policy is important to the future of RBAC. This was noted at the first ACM Workshop on Role-Based Access Control, December 1995, when [DOBS95] suggested that RBAC is coming but is still a bit controversial. In particular, there is a need to deal with the dynamic nature of roles and changes in authorisation. Other researchers have made similar comments: “in addition to roles we may require abstractions to express sequences of access control decisions and various dependencies between them, exceptions and failures, and internal controls in organisations … “ [THOM95] “a goal is a common framework for the specification of rights (confidentiality), duties (integrity), and abilities (availability)” [BRUG95] “tools must be available for visualising composite functions and security conflicts when multiple roles are assigned to an individual. Each application database user in an organisation has a profile of roles which specifies the user’s functional responsibilities and security restrictions” [TING95a].
Recent research [BERT97], [THOM97], [KUHN97] also supports the concept of a role language to support a dynamic application environment. [THOM97] mentions two interesting requirements for collaborative environments: 1) the need for a hybrid access control model that incorporates the advantages of broad, rolebased permissions across object types, yet required fine-grained, identity based control on individual users in certain roles and to individual object instances; & 2) a need to distinguish the passive concept of permission assignment from the active concept of context-based permission activation (which could only be achieved through the use of a role language). [KUHN97] notes in his conclusion that there does not seem to be any obvious problem with implementing task sequencing or workflow mechanisms layered on top of a role (exclusion) mechanism in an RBAC system. A role language would seem the appropriate software tool to assist in the implementation of the requirements of these two articles. A Role Language could act as an interpreter process, i.e. a semantic role process that mediates/filters requests for security in an application environment. The outcome of this interaction between the role language process and the application security request would be a real-time privilege correct user transaction with some backend database. Typically, this interaction may involve the user's effective role changing for the time frame of that transaction, similar to the SUID capability offered by the UNIX operating system. As an example, in a hospital environment on special public holidays where staff are spread fairly thinly, particularly after hours, the following dynamic role change for an ordinary ward nurse may be necessary in an emergency to preserve the health of a patient: if Time > 4pm and Date = 25/12 and role = nurse and status = emergency, then role = nurse-in-charge. In this example the nurse would have to acquire from the system override approval to change the status of the situation from normal to emergency for the dynamic role change to ultimately take place. Inherent in a role language would be table(s) for both the simple roles and the complex roles of an organisational authorisation security policy. Role language research here at the ISRC will be based on the role model and role language described in [BERT97]. In this paper the authors present a language for defining constraints on role assignment and user assignment to tasks in a workflow. This role constraint language supports both dynamic and static separation of duties similar to that described in [KUHN97]. The language is specified using a logic program. The authors note that current RBAC models alone are not adequate to model such constraints and therefore require the support of a role language. Our aim is to further investigate their work such that a high level access control language/parser/interpreter will be defined and developed which is suitable for incorporation into modern Operating Systems. This will become the second version of our experimental RBAC environment. It will incorporate interpreter/object based management facilities, which will need to be tested for both efficiency and self-protection features. The initial version of this experimental RBAC environment will be a simple RBAC implementation in a Windows NT environment similar to that described in [BARK97]. Windows NT was chosen as this is quickly becoming the operating system of choice in many
organisations. This RBAC implementation would co-exist with the existing security provided by Windows NT. It is intended that the implementation adhere to the nine rules, outlined in [FERR95], which the authors believe a system must satisfy to be classified as a RBAC system. This initial version of the experimental RBAC environment would also contain a rule base with some minor complexities that will demonstrate the static and dynamic regulation of users’ actions through the definition of roles, role hierarchies, relationships and constraints. This would be the first stage of the development of a role language. Ultimately, the experimental RBAC environment system will incorporate extended RBAC and authorisation such that OS environments may be extended in a dynamic fashion. It is anticipated that it will include the digital signing of information/work (e.g. program source code, word processing documents) on the basis of identity and role. Extensions to X509 structures would need to be examined to support this idea. This extends the concept of roles to incorporate the idea of responsibility. Responsibility in this context would likely include: what you do (role), what access you have (permission) to an item of work & being able to sign (digitally) it irrevocably therefore claiming personal responsibility for the integrity, authenticity of the item of work.
Conclusions Role Based Access Control is increasingly being incorporated into the security features found in many operating systems and database management systems [THOM97]. With RBAC, permissions are assigned to roles rather than individual users. There are a number of advantages to using RBAC. Firstly, roles are an enterprise or an organisational concept. This allows the modelling of security from an enterprise perspective as security modelling can be aligned to the roles and responsibilities in an enterprise. Secondly, RBAC is more scaleable than user-based security mechanisms since security can be administered as a whole for all users belonging to a role. This reduces the cost and administrative overhead associated with fine-grained security administration at the level of individual users, objects and permissions. Current research in RBAC is focusing on the evaluation of the effectiveness of current RBAC models and the development of new modelling concepts to address the needs of future applications based on the RBAC paradigm. In particular, there is the need for a sophisticated role language mechanism that can be utilised with a RBAC model to deal with the dynamic nature of roles and real-time changes in authorisation. This has significant importance for supporting the specification and enforcement of role based authorisations in workflow management systems and collaborative environments.
References ALSA95
Y.Y.Al-Salqan et al, “Security and Confidentiality in Health Care Informatics”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
AWIS97
Roland Awischus, “Role Based Access Control with the Security Administration Manager (SAM)”, Proceedings of the Second ACM Workshop on Role-Based Access Control, November 1997
BARK95a
John Barkley, "Application Engineering in Health Care", Internal Report, Computer Systems Laboratories NIST, May 1995
BARK95b
John Barkley, "Implementing Role-Based Access Control using Object Technology", Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
BARK97
John Barkley, "Comparing Simple Role Based Access Control Models and Access Control Lists", Proceedings of the Second ACM Workshop on RoleBased Access Control, November 1997
BARK98
J.Barkley, D.Kuhn, L.Rosenthal, M.Skall, A.Cincotta, "Role-Based Access Control for the Web", CALS Expo International & 21st Century Commerce 1998: Global Business Solutions for the New Millennium.
BERT97
E.Bertino, E.Ferrari, V.Atluri, "A Flexible Model Supporting the Specification and Enforcement of Role-based Authorisations in Workflow Management Systems", Proceedings of the Second ACM Workshop on Role-Based Access Control, November 1997
BRUG95
Hans H. Bruggemann, “Report of discussion sessions following presentations, RBAC and Next-Generation Security Models?”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
CHEN95
F.Chen, R.Sandhu, “Constraints for Role Based Access Control”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
DOBS95
JE Dobson, “Report of discussion sessions following presentations, What have we learnt?”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
EPST95
J.Epstein, R.Sandhu, “Netware 4 as an Example of Role Based Access Control”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
FERR93
DF Ferraiolo, DM Gilbert, N Lynch, "An examination of federal and commercial access control policy needs", NIST-NCSC Computer Security Conf., pp107-116, September 1993
FERR95
DF Ferraiolo, JA Cugini, DR Kuhn, "Role-Based Access Control (RBAC): Features and Motivations", 11th Annual Computer Security Applications Proceedings, December 1995
FERR95a
DF Ferraiolo, JA Cugini, "Role-Based Access Control Slide Set - May 1995, National Institute of Standards, US Department of Commerce, May 1995
FERR95b
DF Ferraiolo, "An Introduction to Role-Based Access Control”, National Institute of Standards, US Department of Commerce, May 1995
GLIG95
Virgil Gligor, “Characteristics of Role-Based Access Control”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
GIUR95
L.Giuri, “Role-Based Access Control: A Natural Approach”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
HU95
M-Y Hu et al, “Report of discussion sessions following presentations, Session 3”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
JAEG95
T.Jaeger, A.Prakash, “Requirements of Role-based Access Control for Collaborative Systems”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
KUHN97
D. Richard Kuhn, "Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems", Proceedings of the Second ACM Workshop on Role-Based Access Control, November 1997
LUPU95
E.Lupu, N.Yialelis, M.Sloman, Ravi Sandhu et al, “A Policy Based Role Framework for Access Control”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
NCSC89
US Department of Defense, “The Rainbow Series,” NCSC-TG-001…028, 1989
NOTA95
L.Notargiacomo, “Privileges and RBAC in Oracle7 and Trusted Oracle7", Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
OSBO95
S.Osborn, M.Nyanchama, “Role-Based Security Research at the University of Western Ontario”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
PARK95
T.Parker, C.Sundt, “Role Based Access Control in Real Systems”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
SAND95
Ravi Sandhu et al, “A Framework for Role-Based Access Control Models”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
SAND96
Ravi Sandhu, “Report on the First ACM Workshop on Role-Based Access Control”, March 1996
SAND97
Ravi Sandhu et al, “The ARBAC97 Model for Role-Based Administration of Roles: Preliminary Description and Outline”, November 1997
SA95
Standards Australia, "AS4400 : Personal Privacy Protection in Healthcare Information Systems", 1995.
TCSEC85
US Department of Defense, “Trusted Computer Security Evaluation Criteria,” DoD 5200.28-STD, 1985
THOM95
R.Thomas, B.Hartman, “RBAC and Distributed Object-Based Enterprise Computing”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
THOM97
R.Thomas, “Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments”, Proceedings of the Second ACM Workshop on Role-Based Access Control”, November 1997
TING95
T.C.Ting, M.Y.Hu, “Role-Based Access Control for Object-Oriented/C++”, Proceedings of the First ACM Workshop on Role-Based Access Control”, December 1995
TING95a
T.C.Ting, “Report of discussion sessions following presentations, RBAC and NextGeneration Security Models?”, Proceedings of the First ACM Workshop on Role-Based Access Control, December 1995
YIAL96
N.Yialelis, E.Lupu, M.Sloman, “Role Based Security for Distributed Object Systems”, Proceedings of the IEEE Fifth Workshops on Enabling Technology; Infrastructure for Collaborative Enterprises (WET ICE’96), Stanford, California, June 1996
