Domain 7
Application Program Security

Chapter 7-1-1 instructs us in the application of role-based access controls for business systems. Traditionally, access controls are individually imposed at the system, data base, and/or application layers, which is a cumbersome administrative burden. Client-server access controls can be invoked at the group or departmental level. This chapter instructs us in the most efficient, effective method for controlling access to computing resources, the employment of roles or profiles. Using the methodologies put forward by SESAME and OSF/DCE, two recognized security architectures, the author illustrates the effective use of roles and role hierarchies in the protection of resources.

Section 7-1
Application Security

Chapter 7-1-1
Role-Based Access Control in Real Systems

Tom Parker
Chris Sundt

Using role-based access control (RBAC), roles can support the real-world access control requirements of a distributed system. The model has been developed in the context of a system supporting single sign-on (e.g., SESAME and the security functions of OSF/DCE, which is based on Kerberos technology with proprietary access control extensions), because it is in this context that the benefits of roles are best demonstrated. This role model can be realized using both conventional and distributed computing environment (DCE) access control list mechanisms.¹ However, roles can also be used to support a range of functions in secure distributed systems, and these wider usages and their management implications are described here.

---

¹Special thanks are due to Piers McMahon and Belinda Fairthorne of ICL, whose ideas and comments have heavily influenced the development of the role model described in this chapter.

---

ICL, as part of its AccessManager product, implemented RBAC and other role-related benefits as a key element of that product at the user desktop.

WHAT ARE ROLES?

Real business systems are used by people doing a job for that business. Although some aspects of an individual’s work generate and use personal data (e.g., such office functions as diary management, word processing, and E-mail), in a large number of business activities an individual’s identity is relevant only from the point of view of accountability. An important example is in online transaction processing (TP) systems, frequently central to the functioning of the business. These systems can be large and highly distributed. In multinational corporations they can be global in size.

Such systems, on which the life of a company can depend, are precisely those that are in most need of good quality, easily managed security. In these systems, for access control purposes it is much more important to know what a user’s organizational responsibilities are rather than who the user is. The conventional discretionary access control mechanism, in which individual user ownership of data plays such an important part, is not a good fit. Neither are the full mandatory access controls of the military, in which users have security clearances and objects have security classifications. A new access control model is needed, and RBAC fills this gap.

A role is a way of expressing an organizational responsibility that can be directly used at the technological level within a computer system. The responsibility can be widely scoped, mirroring a user’s job title, or it can be more specific, reflecting, for example, a task that the user currently wishes to perform. This flexibility of interpretation of the concept is essential in real business contexts, where people have a variety of different responsibilities that may be exercised both simultaneously and separately. For these reasons, the more generally scoped roles must be hierarchically related to the more focused ones, described later in this chapter.

Resource Owners

Using RBAC, a resource owner can decide and, more importantly, manage, who can access a particular resource on the basis of their role, not their identity. This function is particularly valuable in distributed systems that contain new technology that supports generation and presentation of a user’s access control attributes (under the control of an independent user administration) separately from the end systems that use them. This contrasts with the traditional style of working in which each resource controller simply learns through authentication who the user is and has to oversee which users have which access control attributes, a task that is repeated on every mainframe and server in the corporate network.

Looking at SESAME or OSF/DCE as typical examples of the new technologies, users can authenticate to an authentication service and then obtain their access control attributes, including a role attribute, from a service dedicated to this purpose. In SESAME, this is the Privilege Attribute Service (in DCE, attributes are held in the Registry and accessed via a Privilege Server; this chapter uses the SESAME terminology). These services are managed by the user administrator.

The attraction is that resource owners need only know about roles, getting users’ roles from an external trusted source. The management of change is therefore greatly simplified. Some examples illustrate:

•  When people leave or join the company, the user administrator removes them from the Privilege Attribute Service or adds them to it with the appropriate role. There is no need for resource owners to do anything.

•  When a person changes jobs within the organization, the user administrator simply changes the roles associated with that user in the Privilege Attribute Service. There is no need for resource owners to do anything.

•  When a new application or transaction type is added to a server, the resource administrator needs only decide which roles are permitted to access it. There is no need for a user administrator to do anything.

As Exhibit 1 illustrates, all these examples depend for their ease of management on the stability of the role concept, because if the meaning of a role changes, the change must be managed simultaneously at all points in the system where that role is used. For this reason, the role concept is specifically appropriate. It is in the nature of a business organization that the jobs to be done in it are reasonably stable conceptually (even though the number of staff in these jobs may not be as stable in uncertain economic times). In addition, the concept of role hierarchies, described later in this chapter, can be used to help with changes caused by partitioning jobs in different ways over time.

Exhibit 1.  Stable Link Between Users and Resources