Access Control Models for Enterprise Systems

One of the alternative approaches to traditional subject-operation-object paradigm is task-

based access control (TBAC) proposed by Thomas and Sandhu [THOM93]. TBAC views access

control and authorization not in terms of individual subject and objects, but in terms of long-lived

tasks that need to be authorized and managed in information systems. This approach has some

advantages over the subject-operation-object approach, because the term “task” is more generic

than the combination of operation and object. The TBAC model can very well model task-

oriented security policies like Separation of Duty (SoD) and the Chinese Wall, as well as carry

out work flow control effectively. However, this model is specifically designed to protect

business activities and transactions in a distributed environment. It does not provide generic

access control mechanisms for handling a variety of situations in enterprise-wide systems.

With the popularity of the Object-Oriented (OO) paradigm, an Object-Oriented access control

model was proposed for general OO-based systems [EVER00, EVER02]. This model uses per-

method access control based on the interface methods of an object. At the same time, constraints

can be imposed on user-to-system interactions, based on the parameters of the methods. This

allows the per-method access control to provide fine-grained semantic protection that the

traditional per-attribute (data item) access control models are unable to achieve. In the security

specification, the concept of method can describe user-to-system interaction more efficiently than

the traditional per-attribute access control. However, per-method access control is only

applicable to Object-Oriented database systems. Yet an enterprise access control system should

Although both models have improved object heterogeneity by using “task” or “method” as

the basic access control unit, they are still unable to manage large numbers of users in enterprise

systems. Both models fall short of generality as each of them targets at a specific problem or a

specific system in the area. Hence, they cannot be used to support a unified access control

framework that involves heterogeneous users and resources.

3.2.3 Role-based Access Control

The background chapter introduced the main components and contributions of Role-based

Access Control (RBAC) [SAND96]. Among all existing models, RBAC is considered to be the

most suitable for enterprise systems, due to its generality and expressiveness [AHN00, CHAN03].

This section will focus on how authorization is represented in RBAC and the concept of

constraints in RBAC. In RBAC96, a permission is described as an approval of a particular mode

of access to one or more objects in the system [SAND96]. Permissions are assigned to roles rather

than individual users, since the concept of role provides long-term identity for the system. For

instance, in a company, if a user is a system administrator and is assigned to the role “Sys

Admin”, then this user is more likely to hold this role as long as they work as a system

administrator in the company. Hence, the notion of role has modelled the position and privileges

of a user in an organisation concisely. Therefore, permissions assigned to each role are changed

less frequently than permissions assigned to individual users. Compared with the huge number of

users in a distributed system, the number of roles is much smaller and thus becomes more

manageable. This has significantly reduced the size of the authorization base and the level of

be established. In a role hierarchy, senior roles inherit all privileges from their junior roles. By

using role inheritance, only permissions that are specific to the role are defined; permissions that

are common to both senior roles and junior roles are specified for the junior roles only. This

structure avoids repetition of permission specifications and can further reduce the number of

authorizations stored in the authorization base.

Figure 3.2 RBAC model (modified from Figure 1 in [SAND96])

However, in RBAC96 [SAND96], a permission is still represented in the form of operation-

object which describes the traditional database access paradigm. In enterprise systems, there are

a large number and types of resources, such as database items, files, and heterogeneous hardware.

When authorizations are specified by operation-object paradigm, an enterprise system needs to

define a set of access modes for each type of resource, such as read, write, update for databases,

User Assignment Permission Assignment Permis -sion Role User Constraint Ses- sion

view element, view schema, destroy and create for documents – which is inefficient. With the

use of access rights hierarchy and object hierarchy, this paradigm becomes even more

complicated, hence is no longer suitable for describing heterogenous resources in distributed

systems.

RBAC96 uses the concept of constraint to specify conditions that must be satisfied in

authorizations. Constraints (as indicated by the Figure 3.2) can be applied virtually to any of the

concepts specified in the RBAC model. Yet when the concept of constraint is used in a user/role

assignment in an active session directly, it will affect authorization decisions. By using

constraints, the authors demonstrated that RBAC is capable of supporting some well-known

security policies such as Separation of Duty (SoD) and prerequisite role. However, constraints in

the context of RBAC did not receive enough attention in RBAC96, although they carry great

importance as they can be used in various situations to specify a wide range of security policies.