Role-Based Access Control in Real Systems Tom Parker Chris Sundt Payoff

Transcription

1 Role-Based Access Control in Real Systems Tom Parker Chris Sundt Payoff Role-based access control can be used to support the real-world access control requirements of a distributed system. This article describes a role model as used in the context of a distributed security infrastructure such as SESAME or OSF/DCE security. It is based on practical experience in the use of roles in real product and shows how role-based access control benefits both the user and the security manager. It also highlights the key practical issues that needed to be resolved in deriving this model. Introduction 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 Open Software Foundation's Distributed Computing Environment, 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. 44 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. 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 electronic 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 inonline 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 44 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 article.

2 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 article. 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 Open Software Foundation's Distributed Computing Environment 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 Data Circuit-terminating Equipment, attributes are held in the Registry and accessed via a Privilege Server; this article 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 article, can be used to help with changes caused by partitioning jobs in different ways over time.

3 A Stable Link Between Users and Resources Accountability and Separation of Duty However, if a resource owner no longer manages or knows about individual users, how are those users to be made individually accountable for what they do? How do we retain the advantage of not having to manage users at the resource server but still provide those users' identities in audit trails at the server? The answer to these questions is to provide the server with a trusted audit identity value through external means. It is this value that will be blindly inserted into audit trail entries. Here is a specific example of how this is done using SESAME technology. In SESAME, a user authenticates and ultimately obtains a Privilege Attribute Certificate (PAC). The PAC contains attributes representing the access rights of the user. A role attribute is optionally one of these. The PAC is a cryptographically protected data structure that the user subsequently presents to resource servers as evidence of authorization for access. The server's access control logic, receiving the PAC, extracts the role attribute that it now uses in its access control decisions. However, the PAC also contains other administrative information, including an audit identity field, quite separate from the access control attributes. It is the value in this field that the server's security functions insert into audit records for actions authorized on the basis of the PAC. Individual accountability is achieved at the server, but its resource controller does not need to manage, or even know about, individual identities. Whatever audit identity value is in the PAC is simply inserted into the audit trail entries. The PAC may also contain other access control attributes for use when RBAC is inappropriate or needs supplementing. One of these might be an identity for access control purposes an access identity. SESAME maintains a clear separation between this value and the audit identity, permitting users to use other identities from an access control perspective (perhaps the other user is away on leave) but is still accountable as himself or herself through his or her audit identity. The question of separation of duty also arises. 45 If access is by role, and individual identities are not used in access decisions, how do we ensure that the same individual cannot perform two duties that are required to be separate? One solution is to assign the different duties to different exclusive roles, thereby preventing any one user being granted two mutually exclusive roles. However, mistakes can be made if individuals can be granted multiple roles, and roles that appear to be different may actually be related hierarchically. Yet, when used with care, this approach can be made to work. This form of separation of duty is known as static separation of duty. Another solution is to use the audit ID as a record of the identity of the individual who performed an action (e.g., in relation to Duty 1), and to check that the audit identity of an individual requesting the right to perform the Duty 2 action is different. This does not require any management of the individuals in the server; just a blind comparison of audit identity values. Such a flexible implementation is known as dynamic separation of duty. However, the audit identity rather than the access identity should be used, because if a user is allowed to act for another user while the latter is on leave (a common requirement), that same user may be using a different access identity from his or her own and so may appear to be two different people.) 45 First formally defined in computer terms in the seminal paper by D. D. Clark and D. R. Wilson. ÒA Comparison of Commercial and Military Computer Security Policies.Ó Proceedings of the IEEE Symposium on Security and Privacy. April 1987.

4 Roles in Context The Access Control Cube Role is not the only dimension to organizational responsibility. Role primarily determines the functions that a user needs. For example, an invoicing clerk may need to examine delivery notes, raise invoices, issue reminders, and so on. The accounts department manager may need to be able to perform these functions along with such others as invoice cancellation or modification. Other job types specifically to do with the computer system itself will also commonly be relevant(e.g., security manager, audit manager, or system manager). However, a further dimension can be identified organizational affiliation, which concerns the part of the organization within which the role is being exercised. Examples of affiliation might be that the user is a member of the London branch or the Las Vegas family. Affiliation primarily determines the data to which the functions of the user's job can be applied. The manager of the London branch may be able to perform exactly the same functions as the manager of the New York branch, but only on the data of London customers. Therefore, in systems terms, roles relate primarily to high-level access rights that are expressible in business language (e.g., raise an invoice). These are realized in the computer system as complex applications, application functions, or transactions. Affiliation determines which data objects the user may access. In some servers, applications themselves cannot be guaranteed to confine access to the underlying data objects through the high-level operations that they are permitting for the role. In such cases, it is helpful to use roles also at an operating system level to limit the basic types of access that the user is to be granted (e.g., read, write) to the data objects that affiliation has identified. Hard-and-fast rules cannot be set, but it is useful to take a view of these different properties so that when design choices have to be made, they can be optimized for the most frequently encountered situations. What is important is that the role concept should not be extended to include controls that are due to affiliation. Most models fail to make this distinction (see the discussion of other role models later in this article), but it is an important one. Clearly, individual identity cannot be ignored as an access control attribute. Even in systems using job type and affiliation, an individual can be given special responsibility or may have personal data. Thus, a view of access control with three main dimensions, a sort of access control cube, is shown in Exhibit 2. Each cell of the cube would represent the access rights of a particular user with a particular job in a particular part of the organization. The Access Control Cube Despite this apparent three-dimensional complexity, it is important that, in most practical access control policies, for any one resource, if a user's identity figures in the access control decision, it is usually not used in conjunction with the other two dimensions identity is adequate. Conversely, affiliations and roles are typically considered together; user identity is not involved. This point becomes important in considering the practicability of implementing such controls using access control lists. The User's View In practice, not only can roles be used to constrain users; they can also provide users with clearly visible benefits. The basic idea is that users sign on nominating a specific role that represents their job or current task, which results in desktops being presented that include only those services that are appropriate to this choice. When requesting access to a

5 particular service, the sign-on role is also used to decide whether users can access that service. By limiting the desktop only to those services permitted by a role, users are prevented from surfing the distributed infrastructure in an attempt to access services they are not entitled to access. They also benefit from having a desktop uncluttered with icons in which they have no interest. The desktop is constructed only for their needs. In practice, however, users rarely have well-defined jobs with clearly defined services, and a user's desktop can vary in a number of ways from the simple setting of preferences to the creation of personal icons associated with variations of particular applications (e.g., creating icons for specific spreadsheets). Users often have multiple roles and need to switch between them. Users work shifts and want the same role to be transferred between them and other users without being closed down. The security administrator may want to remove the right to use a particular service from the role of a particular employee, because he or she has yet to be trained in its use. Thus, in practice, the assignment of services to roles is more dynamic than those allowed by the classic models. The use of roles to control the desktop frequently has three aspects, each with different implications for the application of security policy: It must be possible for a user to create a personalized desktop. This allows users to decide which options are not security critical (e.g., foreground and background colors and position and content of program groups). These preferences should be available at whatever workstation the user signs on to, subject to the characteristics of the workstation permitting it. Within their role definition, users must be able to extend their desktop with personal icons. For example, the user entitled to use the Excel spreadsheet should be allowed to create icons for individual spreadsheets created under Excel. The security administrator must be able to change the content of a role definition for a particular user to account for local variations. Beyond this, users must be able to switch roles dynamically and to attach, after suitable authorization, to an active role, even to extend an active role with additional components that are required to perform specific tasks. Role hierarchies help in this area. Defining Roles Three different security management activities are involved in role management: The defining of roles. The allocating of roles to users. The allocating of access rights to resources based on roles. Who should be responsible for these activities? The last two are relatively easy to position. It is a user administrator (at some level of the organization) who allocates users to roles, and it is the controller of the resource who has the ultimate responsibility for its security, and, therefore, who should decide which roles get access to it. However, it is more difficult to pin down who should be able to define roles. If roles vary at different levels (and not all roles will be understood across the whole organization), the roles with a wide scope should reflect the overall job for which a user was and should be defined at the whole enterprise level. It is essential that the business significance of such a definition be clearly understood across the entire organization,

6 because it will be this level of role that will be used ubiquitously. Clearly, it jeopardizes security if a resource controller thinks that the role of company secretary indicates that of a company board member or director, or if the user administrator thinks that it was just any secretary working for the company. It seems reasonable that such roles would be defined as part of the company security standards. In contrast to these globally understood roles, some roles may be specific to a particular department, and some even to a team level. Almost all organizations, in practice, are hierarchical in some way, and any security administration system must reflect this hierarchical organization, enabling authority to be placed where it is most appropriate. Some roles may be artificial, merely existing to group together users who have a particular series of system-related activities they need to be able to perform. Thinking of this kind of role as a set of activities allows roles of this type to be defined by resource controllers, rather than, as is more intuitive, defined by the user administrator. These pseudo-roles stretch the concept of role, but they form a useful extension if used with moderation and are confined to coherently related groups of activities that are stable over time. Typically, such roles would not be allocated directly to users but might be identified as part of other more traditionally defined job roles. Role Hierarchies Stemming from the concept of roles is the concept of role hierarchies. More precisely, it is the concept of directed graphs, but it is easier to think of it as a set of multiple-linked hierarchies. Specifically, role types should be related to each other so that one role can encompass other roles, which can encompass others. In general, any given role can be contained in more than one higher role, but there must be no loopbacks. The rule is that a user who has been granted a higher-level role is also automatically granted the roles contained in it. The definition of roles becomes an activity that is extended to include the definition of these relationships. Organizational affiliation can also be defined in this way. Although further discussion of this topic is not within the scope of this article, much of what is said about role definition applies equally well to affiliation. Exhibit 3 illustrates a role/hierarchy graph. The exhibit shows three interlinked role hierarchies, based on three enterprise-level roles: Management Administration, Order Clerk, and Financial Controller. Each of the top-level roles contains other roles shown by the arrows. Of these lower-level roles, some may be visible at the enterprise level (e.g., the Expenses Authorization role) and be granted directly as one of the highest-level roles a particular user may have, but others are more resource-oriented roles (e.g., Office System Functions), which would be defined by a resource controller. Role Hierarchies Engineering the Role Concept In engineering roles within actual product, it is convenient to make a distinction between different uses of roles on the one hand, as seen and used by the user; on the other hand, as seen and used at the protected resource. Role Names and Role Attributes Users see roles as names to be used when signing on to the system. A user might say, I am signing on in the role of Duty Officer. Roles used in this way are called role names. At the resource end, access control logic looks at a role field in a security record and compares it directly with a value associated with the resource, typically in an access control

7 list. Roles used in this way are called role attributes. Using this terminology, when a user specifies a role name like Order Clerk, it describes how multiple role attributes may being given to that user (e.g., in a PAC). Using the graph in Exhibit 3, the role attributes are resource related: Office System Functions and Orders. Some roles appear in both forms. All roles that are not part of a hierarchy are likely to be named by users and to appear as attributes in their access control data. However, one example of such a role in a hierarchy is Expenses Authorization, shown in Exhibit 3. A Financial Controller might sign on specifically to authorize expenses and, therefore, would say with a role of Expenses Authorization. This role, however, is sufficiently precise in its focus to be used directly by resource access control logic and could, therefore, be mapped directly into a role attribute. At ICL, the name and attribute distinction has been a great benefit in clarifying thinking in this area. ICL's AccessManager product maintains the distinction explicitly. The user signs on specifying (or defaulting to) a role name. This affects the attributes the user will be granted and also directly affects the desktop that appears, coordinated with what the user is allowed to access in that role. If the target resource is capable of receiving PACs, the underlying SESAME technology will convert this role name to one or more role attributes in the PAC, and such attributes can then be made available at the server for use in access control decisions. This concept of converting role names into one or more role attributes enables an organization to specify much more clearly what actually happens in the engineering of role hierarchies. Handling Access Controls at the Server Other articles on roles have suggested implementing new forms of access control logic to support them. This is perhaps the ideal theoretical solution, but in line with the practical approach taken in this article. It is possible to use the access control list (ACL)logic that already exists in the majority of server operating systems for legacy systems. This requires that incoming attributes be mapped onto the ones supported by the Audit Command Language in the target server. Mapping ontoacls should be thought of as a bridging mechanism. The approach is much simpler for applications that have been written to use the role and affiliation attributes directly, as described later in this section. First, however, how role and affiliation data is carried to the target server in the PAC must be identified. (Both SESAME and Open Software Foundation's Distributed Computing Environment permit an enterprise to define its own attribute types.) It is possible, as suggested earlier, for the role to be carried as a role attribute. Affiliation could sensibly be carried either as a separate group attribute or specifically as an affiliation attribute. For the purposes of this article, assume that the server operating system understands user identities (UIDs) and groups that are defined locally to the operating system. Users can be members of a number of groups. Applications run under a single UID, which may have associated with it none or more groups of which the UID is a member. ACLs are associated with protected operating system objects (e.g., typically files) and have entries specifying which UIDs and groups have what kinds of access to these objects. The types of access supported are the simple traditional ones such as read, write, update, execute, append, and delete. One UID is identified in the ACLs as the owner of the object protected by that ACLs. This UID can modify the ACLs itself and, therefore, control access to the object. The component of the SESAME technology implemented in target servers includes the function that allows a resource controller to specify how attributes in an incoming PAC are to be mapped onto local operating system UID and group attributes. Thus, a SESAME conformant application that is started up as a result of an access request can be started under

8 whatever UID the controller specifies should be mapped from whatever incoming PAC access control attributes that he or she chooses to identify. Further, other incoming access control attributes can be mapped onto local group values. This enables operating system ACLs to be used for controlling access by the application to operating system objects. The application can use the role attribute directly to dictate what functions the user is allowed to perform, and the underlying operating system can dictate through its normal ACLs controls the data objects on which these transactions can be performed. There are many ways of doing the mappings, but in all cases the ACLs entries must be set up so that the group or UID values in the ACLs entries are mapped from incoming affiliation (and optional role) attributes. Applications that handle personal data without using RBAC control can run under a UID mapped from the incoming user's access identity attribute, creating conditions that would have applied had the user signed on directly to the target server. TP applications would usually be under an RBAC regime, but they work in a different way from client/server applications. Because the application is usually multithreaded, its UID is likely to be related to the application itself (or to the administrator who set it up)rather than to the user on whose behalf it is currently working, so it is not possible to use operating system access controls sensibly to control the usual users' access rights. Therefore, Transaction Processing applications must perform their own access checks, and to do this they must use a suitable Application Program Interface to extract the current user's access attributes from the security infrastructure. A generally accepted API for doing this is the extended Group Support System-API, which is being adopted by X/Open, International Standards Organization, and theinternet Engineering Task Force. In OSF/DCE, a different approach is taken. The security functions in the server include a distributed ACLs (DACL) service that is independent of the local operating system's ACLs and that is available for use through an API (not the GSS-API), which enables a calling application to use incoming attributes directly, without needing to know specifically how they are used. The DACL entries contain global user and group identity values that directly correspond to the incoming ones. Thus, a role must be represented directly in the PAC as one of these attribute types. Specific extensions to the DACL semantics to handle roles more effectively have been proposed, but have not yet been adopted. A Simple Example Exhibit 4 demonstrates an example of how ACLs may be set up and mapped from incoming PAC attributes. The scenario is a hospital with two wards. Nurses in either ward are required to use the same nursing support application. By using this application, they should be able to view patient data in the other ward, but should only be able to modify the data for patients in their own ward. Control of the individual ward's data base lies with each of the two ward administrators. Example of Role and Affiliation Mapping The enterprise management view is very simple, and it is a view that can easily be reflected in the actual engineering representation: An administrator has the role of ADMIN; a nurse the role of NURSE. Any Ward 1 person has an affiliation of WARD1. Any Ward 2 person has an affiliation of WARD2.

9 When a PAC is received at the server, the following steps are taken: Previous screen The role attribute is used to determine whether the application requested by the user is accessible, so that nurses in both wards have access to the same nursing applications and administrators to the same administration applications. The mapping logic is examined, as shown in Exhibit 4, which results in the following: An administrator's application operating under the UID owning the data file of that administrator's ward. This UID has no access to the data file from the other ward. The nursing application operating under a group appropriate to the nurse's ward. This group has read access to the data file of the other ward. The UID under which the application operates has no access in itself to the file concerned. Note that the affiliations in rows 3 and 4 of the mapping table could have been mapped onto a UID instead of a group (e.g., WARD1could have been mapped to UID3 instead of G1, and UID3 put in the ACLs instead of G1). In this case, the application would have had to run under UID3. The difference lies in the access rights established for objects now created by the application, which in the UID3 case would be effectively owned by the ward with which the nurse is affiliated. In the example case, objects created are owned by a UID that can be chosen using other policy criteria. Either mapping choice could be appropriate depending on requirements. Roles In Action The following examples have been drawn from actual experiences. The names of the companies have been omitted. These illustrate the extent to which a straightforward RBAC policy should be flexible to account for the complexities of modern business organizations and for the needs of the individual end-user when the role is also used to define the user's desktop. Much of this complexity affects the way roles are managed rather than the way in which they are used to simplify the access decision function in target systems. A Construction Company This company has many project managers, all of whom use the same applications and services, but each of whom is allowed only to access the files relating to those projects for which he or she is responsible. This fits very well with the access control cube model, with the project manager as a role and the specific data sets as affiliations. A Government Department This entity has created generalized roles, but removes access to specific applications for individuals, because they have yet to be trained in their use. In addition, each user has a list of desktop applications from which those the individual wants can be selected(i.e., each individual is permitted to access a subset of the global set of desktop applications defined for a role). This setup illustrates the necessity of tailoring a general role to specific user needs, thereby avoiding many almost identical roles.

10 An Educational Organization This organization has created role hierarchies along the lines described in this article. For example, a student role has been created, as well as a teacher role that includes the student role. A Multinational Systems Integrator In this case, users need to be able to create icons representing particular instantiations of desktop applications (e.g., particular Excel spreadsheets, Word documents, or Powerpoint presentations). In this situation, the access control policy is not being violated, but users are being allowed to tailor the desktop to their particular needs within the access control policy set down for that role. A Hospital On a ward, many nurses would like to use a workstation to prescribe drugs and other medicines. The workstation is signed on at start of day in the role of nurse, but for each prescription the specific nurse must be specifically authorized as part of the task protocol. An alternative in which each nurse signs on and signs off would create an overhead of closing and recreating the desktop for each nurse, which would take an unacceptably long time. Shift Work A continuous session under the role is active, but the person executing the role changes at intervals. The role cannot be closed and reopened, because the information must be continually presented. However, the identity of the person undertaking the role must be recorded for accountability purposes. There are similarities to the hospital scenario previously described. Manufacturing People often have one role most of the time (e.g., as a shopfloor worker), but occasionally need to assume a different role (e.g., acting supervisor). They do not want to close the first role to do the second, but rather suspend the first role. A similar situation occurs when someone in his or her normal role temporarily wants to look at someone else's mailbox. Retail Banking The range of transaction types permitted for different people in such an environment varies. For example, a teller role will be allowed one set of transaction types and the manager role some additional transaction types. This is probably the archetypal role example. Manager roles may or may not encompass the roles of the individuals under them, depending on separation-of-duty requirements. Further, the same role at different branches may have different affiliations, allowing access only to data relevant to each branch. Senior manager roles may be created that include affiliations that permit them to access data at more than one branch.

11 Other Role Models A 1993 article introduced the concept of roles in its simplest form, without looking at hierarchies or separating the concept of affiliation. 46 A 1994 article defined the concept of role profiles, which it describes as all the resources needed for a given role. 47 The appropriate role profile is assigned to users who have the associated role. The article distinguishes between static and dynamic role profiles, the former relating to long-term business roles, the latter to project-related roles. This article shows how a role profile fits into a more general access control profile hierarchy, thereby linking the role profile in one direction to users and, in the other direction, to either transaction profiles (static)or project profiles (dynamic). Both of the latter then link down to resource profiles. There is no concept of role hierarchies or affiliation. The National Institute of Standards and Technology is adopting yet another model, which includes role hierarchies but bundles up affiliation within the role concept itself. One paper analyzed the role model against general requirements such as least privilege and separation of duty. 48 Other papers and articles on various aspects of roles are by Mohammed and Dilts, 49 who take a very dynamic view of roles in a data base context; Sterne, 50 who discusses the construction of a trusted computing base that can support RBAC, and Baldwin, who describes extensions to Structured Query Language that permit users and resources to be grouped into named protection domains, which have many features in common with roles. Conclusion This article has demonstrated the benefits obtained from using roles. The role concept is utilitarian not only for users, who get a simple view of the access rights available to them, but also for managers, the concept forming a stable bridge between the volatility of the user population and the volatility of the resources being accessed. Roles should be used in the context of other access rights. Individual identity and organizational affiliation are two major orthogonal dimensions, the whole making an access control cube. This article has also described the various ways in which different organizations actually use the RBAC concept. A unique feature of this article is that role-based access control is viewed as being only one mode of control that must exist within a context of other modes the access control cube. This reflects real-life requirements of systems running many heterogeneous applications. Author Biographies Tom Parker Tom Parker is an ICL Fellow. He is also the editor of the European Computer Manufacturers' Association standard on distributed system security. Parker is actively involved in the security work of the International Standards Organisation and a member of the OSF Security Special Interest Group. Chris Sundt 46 L. G. Lawrence. ÒThe Role of Roles.Ó Computers and Security, 12(1): S. H. von Solms and I. VanderMerve.ÒThe Management of Computer Security Profiles Using a Role- Oriented Approach.Ó Computers and Security, 13(8): D. F. Ferraiolo and J. A. Cugini. ÒRole Based Access Control (RBAC): Features and Motivations.Ó Draft paper from NIST, Gaithersburg MD. 49 I. Mohammed and D. M. Dilts. ÒDesign for Dynamic User-Role-Based Security.ÓComputers and Security, 13(8): D. F. Sterne. ÒA TCB Subset for Integrity and Role-Based Access Control.ÓProceedings of the 15th US National Computer Security Conference. October 1992.

12 Chris Sundt is a Chief Consultant for ICL Enterprise Technology. He is the vicechairman of IBAG and chairman of the UK CBI Security Working Group. Sundt has given papers on a variety of security related topics at conferences and seminars in Europe and the United States.

13

14

15

16