task–role-based access control model

Information Systems 28 (2003) 533–562

Task–role-based access control model$

Sejong Oh*, Seog Park

Department of Computer Science, Sogang University, 121-742 Seoul, South Korea

Received 3 November 2000; received in revised form 22 April 2002; accepted 1 May 2002

Abstract

There are many information objects and users in a large company. It is an important issue how to control user’s

access in order that only authorized user can access information objects. Traditional access control models—

discretionary access control, mandatory access control, and role-based access control—do not properly reflect the

characteristics of enterprise environment. This paper proposes an improved access control model for enterprise

environment. The characteristics of access control in an enterprise environment are examined and a task–role-based

access control (T–RBAC) model founded on concept of classification of tasks is introduced. Task is a fundamental unit

of business work or business activity. T–RBAC deals with each task differently according to its class, and supports task

level access control and supervision role hierarchy. T–RBAC is a suitable access control model for industrial

companies.

r 2002 Elsevier Science Ltd. All rights reserved.

Keywords: Access control; RBAC; Enterprise environment; Task; Role

1. Introduction

As many companies recognized that the computer is an important means to increase their competitivepower, they have competitively built computer systems. Thus, company size, volumes of information, andthe number of related personnel has increased. As a result, security problems have become increasinglydifficult.The methods of information protection used are authentication, authorization, access control, audit,

encryption, etc. In this paper, we focused on access control. Access is the ability to perform work such asreading, writing, and execution of system resources. Access control is the means to control the ability toperform above work. Access control of the computer system describes whether specific users or processorscan access specific system resources or not, and their allowed access type.There are various types of organizations that need access control. Access control reflects the real world

and each organization requires their own access control policy as shown in Table 1. As can be seen, accesscontrol in enterprise organizations is different from that of military or university organizations.

$Recommended by Professor P. Loucopoulos.

*Corresponding author. Tel.: +82-2-715-2234; fax: +82-2-704-8273.

E-mail addresses: [email protected], [email protected] (S. Oh), [email protected] (S. Park).

0306-4379/03/$ - see front matter r 2002 Elsevier Science Ltd. All rights reserved.

PII: S 0 3 0 6 - 4 3 7 9 ( 0 2 ) 0 0 0 2 9 - 7

Considering the cases of enterprise and military environments, maintaining ‘confidentiality’ of informationis the most important factor in access control for military organizations, while enterprise organizations alsoneed to maintain ‘confidentiality’ of their business information. Supporting ‘information sharing’ is anotherrequirement of access control for effective business activity in the enterprise environment [25]. Therefore,access control for the enterprise organization should support both ‘confidentiality’ and ‘informationsharing’; this is not a simple problem. More detailed differences between enterprise and militaryorganizations are as follows:

* In the enterprise environment, business information has the characteristic of ‘information sharing’. Thismeans that an information object is accessed by many work-related people, as business information isproduced during business processes composed of many business activities. Conversely, in the militaryenvironment, sharing information is very dangerous. Hence, only a few authorized personnel can createand access specific information.

* The enterprise environment changes rapidly, responding to changes in the business environment, but themilitary environment is stable. Rapid change of environment leads to rapid change of access rights andinformation objects. It makes administration of access authorization very difficult.

* In the enterprise environment, the basis of authorization is job position and assigned tasks (jobfunctions), whereas in a military environment, position and mission area are the major bases ofauthorization.

* Many business activities are connected with others in the enterprise environment. Thus, manyconstraints and business rules are related to access control. For example, specific customer orderinformation may be updated when the goods of the customer order are not received. We call thoseconstraints ‘business rules’ [16–18, 24]. ‘Separation of duty’ (SOD) is an important security principle forbusiness organizations, whereas in the military environment, connected activities are rare and theconstraints and activity rules are not the main factors to consider for access control.

So far, we have described the differences between the enterprise environment and others. Furthermore,there are various related factors to access control in the enterprise environment. Therefore, making aproper access control model that satisfies the enterprise environment is very difficult.

Table 1

Characteristics of some access control environments

Military environment University environment Enterprise environment

Basic requirements Strong confidentiality Good confidentiality Strong confidentiality

Good serviceability Strong information sharing

Generation of information Created by authorized person

or organization

Generated by tests, course

registration, etc.

Generated during business activity

Change of environment Stable Slow Rapid change of organization and BP

Basis of authorization Position, mission area Student-ID, registered

course

Job position, assigned tasks

(job functions)

General characteristics Position=authority level Users are separated into two

groups, ‘faculty’ and ‘student’

Complex business process (BP)

Core data: student,

course, score

Inheritance of authority

Many business rules

Suitable access

control model

Mandatory access

control (MAC)

Role-based access control (RBAC)

S. Oh, S. Park / Information Systems 28 (2003) 533–562534

Many researchers have developed access control models, such as discretionary access control (DAC),mandatory access control (MAC), and role-based access control (RBAC). An activity-based access control(ABAC) model has been introduced recently, which was designed for collaborative work environments.RBAC and ABAC are known as suitable access controls for enterprise organizations, but they do notconsider enterprise environment in depth and fail to meet the requirements of enterprise environment; thesecases are examined in detail in Section 3.The purpose of this paper is to propose a proper model of access control, T–RBAC, for large commercial

enterprise organizations. The name T–RBAC implies that ‘task’ and ‘role’ are core concepts of our model.We show that tasks and roles in the enterprise environment have various characteristics related to accesscontrol, and we use this as the basis of our model. As a result, our model meets the requirements of accesscontrol in the enterprise environment. The T–RBAC model increases the modeling power of enterpriseorganizations and supports simple authorization management. This paper is based on role-based securityadministration and adopts an active security model.The remainder of this paper is organized as follows. Section 2 describes the requirements and

characteristics of access control in the enterprise environment. We suggest seven characteristics of theenterprise environment related to access control, and show the relationship between them. Section 3describes the previous research related to this paper, including the weaknesses of their securityadministration in the enterprise environment. Section 4 describes the T–RBAC model that overcomesthe disadvantages of prior works. We propose the T–RBAC model as an improved access control modelcompared with RBAC and ABAC. Section 5 evaluates the proposed T–RBAC model. To evaluate, we usecomparative analysis and implementation. First, we compare the RBAC, ABAC, and proposed T–RBACmodels. Second, we show the implementation of T–RBAC model, including the access control engine in theWeb environment. Section 6 presents the conclusion and proposes further work.

2. Requirements analysis of access control in enterprise environments

2.1. Factors related to access control in the enterprise environment

To develop a proper access control model for enterprise organizations, we need to know the requirementsfor access control in the enterprise environment. The first step of requirements analysis is to investigate thefactors related to access control in the enterprise environment. From the perspective of access control, theenterprise environment can be depicted by Fig. 1. Users want to access some information resources for theirbusiness activities. The final goal of access control is to decide whether an access request from a specific useris valid or not. There are several factors that are related to the access control mechanism in the enterpriseenvironment, the main ones being: organization, job positions, business roles, tasks, business processes, andbusiness rules. In general, users who belong to the organization structure in the company perform theirassigned tasks (job functions) according to their job positions or business roles. Some tasks composebusiness processes, which have special access control requirements. A number of business rules are involvedin various business activities and access controls. Let us take a look at the user, and information resources,and each related factor in detail.

User: Users are the subjects of access control. In general, they are employees of a company. They executetheir job function to achieve the company’s goal. They produce business information and this information isstored for future business activities. They may use information resources that were created by other employees.

Information resources: Information resources are the objects of access control, such as files, tables in adatabase, executable programs, etc. Information resources contain business information. We use the term‘information object(s)’ instead of ‘information resource(s)’ in this study.

S. Oh, S. Park / Information Systems 28 (2003) 533–562 535

Organization: An organization is a group of employees who form business activities together in order toachieve a particular aim. From the perspective of access control, an organization has two functions. One isgrouping users, and the other is grouping tasks (job functions). In spite of increasing non-hierarchicalorganization structure such as team-based organizations, many companies have a hierarchical organizationstructure.

Job position and business role: Job position and business role are similar in concept, but job positionemphasizes management activities, and business role emphasizes business work activities. In the accesscontrol’s point of view, users may have access rights for executing their job positions or business roles. Inother words, job positions and business roles restrict the authority of users.

Task: Task is a fundamental unit of business work or business activity. ‘Job function’ isanother expression of task. ‘Material resource planning’, ‘check issuing’, ‘purchase approval’, and‘sales decision’, are examples of tasks. Tasks are assigned to users by their job positions or businessroles. In the access control’s point of view, users read or write information objects when executingtheir tasks. Access rights are required only for executing the assigned tasks. If we know a user’s assignedtasks, we can decide which access rights are assigned to the user. Therefore, the tasks of a user are the basisof access control. A task can be expressed as a pair, comprising information object and allowing accesstype.

Business process: The business process is defined as a set of some tasks that are connected to achieve acommon goal. Workflow is an IT term of business process. In general, it means a product or methodologyfor supporting business process in the enterprise environment. The tasks belonging to business process andthe non-belonging tasks have different access control characteristics. In Fig. 2, the task ‘monitor salesachievement’ does not belong to the purchasing process. In this case, user John executes the task ‘monitorsales achievement’ and accesses information objects file1 and file2 at any time if the task is assigned to him.It means that authorization (access right assignment) causes immediate activation of access right. This caseof access control is called passive access control. The task ‘approve customer order’ belongs to receiving

Business Processes

Tasks(Job Functions)

InformationResources

Users

Business Rules

Organization

Job positions

BusinessRoles

r

Fig. 1. Access control in the enterprise environment.


customer order process. Executing tasks in the business process should submit to a defined process order andavailable time period. Although task ‘approve customer order’ is assigned to John, he can activate hisaccess rights when the prior tasks ‘check customer credit’ and ‘check product stock’ are completed. In thiscase, authorization (access right assignment) is separated from activation of access rights. This case ofaccess control is called active access control. In conclusion, all tasks are grouped into two classes accordingto whether they belong to business processes or not. They are applied to passive or active access controlaccording to their class.

Business rule: A business rule is a formal regulation, or bylaw, imposed by an organization, or is simplythe standard practices of users, which governs the way the organization conducts its business. SOD and‘delegation’ are examples of business rule.

2.2. Requirements of access control for the enterprise environment

In this section, we show the access control characteristics of the enterprise environment. Even thoughmany researchers have dealt with access control for enterprise organizations, they only superficiallyacknowledge the related factors of access control in the enterprise environment. As a result, their claims donot completely meet the access control requirements of enterprise organizations. By observation andanalysis of the access control characteristics of the enterprise environment, we found facts that priorresearch studies failed to notice, as follows:

* Organizations, job positions, business roles, tasks, and business processes, are the main related factors ofaccess control in the enterprise environment. They have a relationship with access control as shown inTable 2.

* They are related to each other as shown in Fig. 1.* The ancestor job positions or business roles inherit, through the hierarchy, some authorities of theirdescendant job positions or business roles. This means ‘partial’ inheritance of authorities. (Previousresearches say ‘full’ inheritance of authorities from lower role to higher role.)

Monitor sales achievement

file1

file2

file3

file4

r

r

ApproveCustomer order

ww

John

passiveaccess

activeaccess

r credreceivecustomer

checkcustomercredit (T2) approve

customerorder (T4)

requestproduction (T5)

tasks

order (T1) receivecustomerorder (T1)

Fig. 2. Example of passive and active access.


* There are several types of tasks in the enterprise organizations. They have different characteristics foraccess control, according to their class.

* Both active and passive accesses occur.* We describe general business rules including two new principles, ‘auditing of task execution’ and ‘closingaccount’.

The characteristics of access control in the enterprise environment lead us to security requirements asfollows:

Req. (1) General users cannot discretionary change security attributes, for example access rights, ofinformation objects. Changing security attributes may induce an outflow of information. Onlysecurity administrator can do it.

Req. (2) Access control model reflects organization structure and its characteristics of authorityinheritance.

Req. (3) It should support full and partial authority inheritance on the organization structure.Req. (4) It should support active and passive access control.Req. (5) It should support general business rules includes of least privilege.Req. (6) It should support different access control for several types of tasks.Req. (7) The access control model for enterprise environment should be able to deal with many users

and many information objects. Therefore the design for authorization, assignment of accessrights, and change of them should be easy.

The above requirements are the basic criteria for known access control models and our proposed accesscontrol model. Requirements (1), (2), (5), and (7) are general and well known, while (3), (4), and (6) are newto this paper.

Table 2

Factors of the enterprise environment related to access control

Factors Relationship with access control

User Subject of access control

Information object Object of access control

Organization A basis of grouping users, job positions, and tasks

Has an organization hierarchy

Job position Deep relationship with supervision tasks

Has a job position hierarchy

Business role Group of tasks

Has a business role hierarchy

Task A basis of assigning permission (access right)

Has a several characteristics of access control

Business process Define the sequence of execution of tasks

Divide active and passive access

Business rule Constraint for access control


2.3. An example of enterprise environment

This section describes an example of an enterprise environment for a more effective explanation of thispaper. We choose a sales department as the example area. A part of the organization structure shows‘sales manager’ is a superior position to ‘salesclerk’ and ‘salesman’ in the sales department. There are threeemployees who have their own job positions and business roles. The example of the business process showsreceiving customer order; it also shows T1 and T4 are mutually exclusive tasks. The task assignment tabledescribes which tasks are assigned to which job position or business role. The permission assignment tabledescribes which permissions are assigned to which task, and file1[r,w] means the read and write privileges for file1.


3. Related works and problems

Information security is a vital issue in enterprise organizations. Researchers in the security area havemade every possible effort to find proper security solutions for enterprise organizations, and as a result,many papers have been written. In this section, we summarize major research results focused on accesscontrol.

3.1. Access control list and access control matrix

Access control lists (ACLs) [1,2] and an access control matrix (ACM) [1,2] are earlier model of accesscontrol. ACL and ACM are simple and intuitive, but the two models are not suitable for largeorganizations that have many subjects and objects. Increases in the number of subjects and objects requirean increase in the cost of managing the ACL or ACM. For example, an ACM can be represented as a list oftriples, having the form /subject, object, rightsS. Searching a large number of these triples is so inefficientthat this implementation is seldom used.

3.2. Discretionary access control and mandatory access control

Discretionary access control [1,3], as its name implies, depends on the discretion of an object’s owner oranyone else who is authorized to control the information object’s access. The obvious advantage of DAC isthat users are afforded great flexibility. However, these policies do not provide high security assurance. Forexample, DAC allows copying of data from one object to another, which can result in allowing access to acopy of data to a user who does not have access to the original data. In the example of Section 2.3, John canread file6 but Smith cannot. If John copies file6 to file7, Smith may also read file7. It is an unexpectedsituation in the enterprise environment and it is difficult for DAC to guarantee integrity rules such as ‘leastprivilege’ and SOD, that are required for the enterprise environment. Furthermore, the owners ofinformation objects are not individuals (users) in the enterprise organization. (The owner of file6 is notJohn). DAC is proper to the environment when information sharing is more important than protection ofinformation.

Mandatory access control [4,3] means that access control policy decisions are made beyond the control ofthe individual owner of an object. A central authority determines what information is to be accessible bywhom, and the users cannot change access rights. MAC ensures confidentiality and integrity of theinformation, something which is not addressed by DAC. However, security labeling is difficult in anenterprise environment and is not convenient for job (task) execution. In the example of Section 2.3, howdo we decide that File1 has higher security level than File2? Further, how do we decide that Smith has ahigher security level than File1? Thus, MAC is not suitable for the enterprise environment.

3.3. Role-based access control

RBAC [5,6] has the central idea of preventing users from accessing company information at theirdiscretion. Instead, access rights are associated with roles, and users are assigned to appropriate roles. Thenotion of role is an enterprise or organizational concept. Therefore, RBAC allows us to model securityfrom an enterprise perspective, since we can align security modeling to the roles and responsibilities in thecompany. This greatly simplifies the management of access rights. Fig. 3 shows the basic components ofRBAC and a sample of a role hierarchy. Although the RBAC model has advantages, there exist thedisadvantages that RBAC is not covered efficiently in the enterprise environment.


* The basic RBAC model has a role hierarchy concept where a higher role inherits all access rights of alower role in the role hierarchy, but in the real world, a person who has a higher job position or businessrole inherits partial access rights of a lower job position or business role, because full inheritance ofaccess rights can violate the ‘need-to-do’ principle. Furthermore, if R1 is a mutually exclusive role of R2,R1 and R2 cannot have the same parent role R3 because of the SOD principle [19].

* RBAC does not consider workflow. Workflow needs a dynamic activation of access right and thespecification of application level constraints [7]. RBAC is one of the passive access control models, and itdoes not support active access control.

* RBAC does not separate ‘task’ from ‘role’. The task concept is implied, as the role concept andvarious types of tasks that have different characteristics of access control, are dealt with in the samemanner.

3.4. Activity-based access control

The ABAC model [7–10] was investigated for a collaborative work environment represented as‘workflow’. (Not all researchers agree on the term ‘ABAC’, with some using the term ‘TBAC’ rather than‘ABAC’.) Workflow is defined as a set of activities (tasks) that are connected to achieve a common goal.ABAC separates access right assignment for users and access right activation. The ABAC model has thefollowing limitations in the enterprise environment:

* There exist many tasks that do not belong to the workflow in the company, and the ABAC model doesnot deal with them. Therefore, extra access control methods need to be added to the ABAC model. Inthe example of Section 2.3, ‘receive customer order’ belongs to the business process, but‘review sales result’ has no relationship with the business process. The latter requires passive accesscontrol, and ABAC does not deal with passive access control.

* In the real world, a superior officer supervises and reviews the execution of tasks of his/her inferiorclerks. This is important for security and integrity; however, the ABAC model does not take review andsupervision into consideration.

user(U)

role(R)

permission(P)

userassignment

(UA)

permission assignment

(PA)

session(S)

..

role hierarchy(RH)

Engineering Department(ED)

Director(DIR)

Project lead 1(PL1) Project lead 2(PL2)

QualityEngineer 2

(QE2)

ProductionEngineer 2

(PE2)

QualityEngineer 1

(QE1)

ProductionEngineer 1

(PE1)

Engineer 1(E1) Engineer 2(E2)

Employee(E)

(a) Basic component of RBAC (b) An example of role hierarchy

constraint

Fig. 3. Basic RBAC model: (a) basic component of RBAC; (b) an example of role hierarchy.


3.5. Summary

Table 3 shows their main features and disadvantages from the perspective of the enterprise environment.DAC and MAC are obviously not suitable for the enterprise environment. RBAC and ABAC are also notsufficiently suitable for the enterprise environment. Therefore, an improved access control model is requiredfor enterprise organizations.

4. Task–role-based access control model

4.1. Introduction of T–RBAC

As shown above, previous works on access control do not adequately meet the requirements of theenterprise environment. Here we propose an improved access control model named task–role-based accesscontrol (T–RBAC). As the name implies, T–RBAC is based on the RBAC model, and therefore T–RBACcontains the basic features of RBAC. However, T–RBAC is more than an improved model for theenterprise environment, compared to RBAC. It seriously considers characteristics of the enterpriseenvironment and accepts the requirements of access control. In the RBAC approach (Fig. 4(a)), the userhas a relationship with permission through a role. In the T–RBAC approach (Fig. 4(b)), the user has arelationship with permission through role and task. Task is not only ‘sub-role’, it has a separate meaningfrom role. It also has various characteristics related to access control as shown in Section 2.1. Therefore, thecharacteristics of tasks are the basis of access control in T–RBAC.T–RBAC accepts the main factors of enterprise organization related to access control that are described

in Section 2. Each factor is reflected in T–RBAC as shown in Fig. 5. Task classification according to theircharacteristics is important in T–RBAC. First, we will describe the classification of tasks in Section 4.2.Then we will describe the T–RBAC model in Section 4.3.

4.2. Classification of tasks

As described above, the tasks in the company can be classified by their characteristics of access control[20–23]. Fig. 6 shows some factors related to task classification. There are two major factors in the

Table 3

Main features of each models and their weaknesses in the enterprise environment

Related works Main features Major weakness

DAC Ownership-based Low assurance of security

Flexible

MAC Administration-based Less flexible

Information flow control rules Security labeling is difficult

Support multi-level security

high level of security, high assurance

RBAC Policy-neutral Unrealistic authority inheritance

Flexible Does not separate task from role

Use concept of hierarchy and constraint No active access control

Can be easily incorporated into current technology

ABAC Activity-based (active security model) No passive access control

Workflow friendly


enterprise environment: one is the organization structure including job position and business role, and theother is the business process. The business rules have a relationship with task execution rather than taskclassification.

Organization structure: Organization structure reflects an authority hierarchy in the company. Someauthorities of descendant job positions, or business roles, are inherited to ancestor job positions, or businessroles, through the hierarchy line. Therefore, tasks are divided into two classes: inheritable tasks and non-

inheritable tasks.Business process: As can be seen in Section 2.1, all tasks are grouped into two class according to whether

they belong to business processes or not, and they are applied to passive or active access control accordingto their class.

User Role Permission

User Role PermissionTask

(a) RBAC approach

(b) T−RBAC approach

Fig. 4. RBAC and T–RBAC approaches: (a) RBAC approach; (b) T–RBAC approach.

Main factors of Enterprise organization

Main components of T-RBAC model

task

role

Role hierarchy

Workflow schema

Constraint

object

UserUser

Info. object

Organization

Job position

Business role

Task

Business process

Business rules

Fig. 5. Relationship between factors of enterprise organization and components of T–RBAC.

Task classification

OrganizationJob position

Business roleBusiness process Business rule

inheritanceof access right

active/passiveaccess

Fig. 6. Related factors for task classification.


By the characteristics of the organization structure and business process, we can define four classes oftasks as shown in Fig. 7.

Class P (Private): The access rights for the tasks in the class P are not inherited to the ancestor jobpositions or business roles. They do not belong to a business process and are dominated by passive accesscontrol principles. Therefore, they have the characteristic of ‘private’. In Fig. 8, the task ‘vendor analysis’ isassigned to ‘sales client’. Although ‘sales manager’ is a manager of ‘sales clerk’, it does not inherit accessrights to perform the task ‘vendor analysis’ from ‘sales clerk’. Also, performing the task ‘vendor analysis’does not have a relationship with the other tasks. Analysis, planning, and decision-making are generalexamples of tasks belonging to class P.

Class S (Supervision): The access rights for the tasks in the class S are inherited to ancestor job positionsor business roles. They do not belong to a business process and are dominated by passive access controlprinciples. The tasks in class S are related to management or supervision. An employee as a manager has aduty of supervising his/her subordinate employees and approving some documents. Most of the tasks for‘job positions’ rather than ‘business roles’, belong to class S. In general, the access rights for the tasksrelated to supervision are inherited to ancestor job positions, or business roles. For example, the accessrights for task ‘approve customer registration’ in Fig. 9, which is assigned to ‘sales clerk’, are inherited to‘sales manager’. Management or supervision activities occur in a single department of an enterprise

non-inheritable inheritable

passive access P S

active access W A

Fig. 7. Classification of tasks.

SalesSalesDept.

salesmanagersalesClerk

vendor analysis

receivecustomerorder (T1 ) check

productstock (T3 )

approvecustomerorder (T4)


checkcustomer

credit (T2 )

Fig. 8. An example of class P.

SalesSalesDept.


approve customer reg.

receivecustomerorder (T1) check

productstock (T3)

approvecustomerorder (T4 )

requestproduction (T5 )

checkcustomer

credit (T2)

Fig. 9. An example of class S.


organization without relationship with other departments. Therefore, they do not belong to a businessprocess. Review, audit, monitoring, approval, and delegation are examples of tasks belonging to class S.

Class W (Workflow): The access rights for the tasks in the class W are not inherited to ancestor jobpositions or business roles. They belong to a business process and are dominated by active access controlprinciples such as task ‘check product stock’ in Fig. 10. Many tasks in the enterprise environment belong toclass W because the tasks have a relationship with others in the business activities. One characteristic oftasks in class W is that the tasks require repeated execution. For example, receive customer order process

in Fig. 10 is executed many times a month. As a result, the information objects accessed by the tasks inclass W have many instances, and a predefined identifier such as ‘customer order no.’ identifies eachinstance.The tasks in class W have several attributes such as activation condition, duration, and activation

cardinality. Activation condition is the condition that a specific task is activated. Duration is an availabletime that an activated task owns. Activation cardinality is the maximum number of activations of a specifictask at the same time.

Class A (Approval for activity): Class A has characteristics of class S and class W. If a task belongs toclass A, the access rights for the task are inherited to ancestor job positions, or business roles, in the rolehierarchy and the task belongs to workflow. Most tasks of approvals in the workflow belong to class A

(see Fig. 11).We described above the classification of tasks, and this is summarized in Table 4. Table 5 shows the

classification result of the example of Section 2.3.

4.3. Formal description of T–RBAC

Fig. 12 shows a brief overview of T–RBAC. In the T–RBAC model, access rights (permissions) areassigned to tasks, and tasks are assigned to roles, unlike in RBAC where access rights are assigned to roles.

SalesSalesDept.


Check product stock


productstock (T3)



checkcustomer

credit (T2)

Fig. 10. An example of class W.

SalesSalesDept.


Approve customer order


productstock (T3)



checkcustomer

credit (T2)

Fig. 11. An example of class A.


Table 4

Summary of task classification

Class Characteristic Description

Class P Private Non-inheritable, passive access

E.g. analysis, planning, and decision-making

Class S Supervision Inheritable, passive access

E.g. review, audit, monitoring, approval, and delegation

Class W Workflow-oriented Non-inheritable, active access

E.g. tasks in the workflow

Class A Approval for activity Inheritable, active access

E.g. tasks related with approval in the workflow

Table 5

Classification result for the example of Section 2.3

Task Class

Review sales results (T5) Class P

Approve customer order (T4) Class A

Review customer order statistics (T6) Class P

Receive customer order (T1) Class W

Review detail customer info (T7) Class P

Execute promotion budget (T8) Class P

View general customer info (T9) Class S

User Role

Permission

SessionConstraint

S-RH

Workflowschema

Class S

Class P

Task

URA TRA Class W

Class A

TWA

PTA

• Activation condition• Time constraint• cardinality

Workflow Instances

Fig. 12. The T–RBAC model.


In the real world, access rights are required for a user to perform tasks so the assignment of access rights totasks is reasonable. T–RBAC uses the supervision role hierarchy (S-RH) instead of the general rolehierarchy. In the S-RH the higher role does not inherit all access rights of a lower role in the role hierarchy.Only access rights of class S or class A are inherited from the lower role to higher role in the role hierarchy(strict inheritance). ‘Read’ privilege can be inherited from a lower role to a higher role on the role hierarchy,adding to the access rights of class S or class A (audit-oriented inheritance).Tasks in the T–RBAC model are classified into four classes. Tasks in class W or class A are used to

compose the workflow schema. Workflow creates the workflow instances that are a set of task instances.Access rights are assigned statically to tasks in class W or class A, but the access rights are bound andactivated during the execution of a task instance. Task instance has three attributes: activation condition,time constraint, and cardinality: activation condition is the condition that the task can be activated, time

constraint is the available time after the task is activated, and cardinality is the number of specific taskinstance that can occur at the same time.A number of investigations for the specification of constraints [11–13] exist. We only deal with SOD and

‘auditing of task execution’ constraints in the T–RBAC model.The properties below show the formal description of T–RBAC.

[Notation]USERS: a set of users PERMS: a set of permissionsROLES: a set of roles RioRj : Rj is direct parent role of Ri on S-RHSESSIONS: a set of sessions Rio�Rj : Rj is direct or indirect parent role of Ri on S-RHWFS: workflow schemaTASKS: a set of tasks Ti-Tj : Ti is a direct prior task of Tj on WFSS-RH: supervision role hierarchy Ti-

�Tj : Ti is a direct or prior task of Tj on WFS

Definition 4.1 (Role and task). Role is the function, or position, that somebody has, or is expected to have,in an organization. An organization unit itself is a role. Task is the minimal piece of work that somebodyhas to do, and it is expressed as a set of permissions.

Property 4.1 (Classification of tasks). All of the tasks are classified into four classes, and they are allmutually disjoint.

* class S: supervision oriented tasks8i; task TiA class S ) TiA set-of-inheritable-tasks 4Tie set-of-active-tasks

* class W: workflow oriented tasks8i; task TiA class W ) Tie set-of-inheritable-tasks 4TiA set-of-active-tasks

* class P: private tasks8i; task TiA class P ) Tie set-of-inheritable-tasks 4Tie set-of-active-tasks

* class A: approval tasks for workflow activity8i; task TiA class A ) TiA set-of-inheritable-tasks 4TiA set-of-active-tasks

Property 4.2 (Cardinality and type of role). A role has a maximum number of users authorized for the role(Card U: assign user cardinality), and maximum number of activations at one time (Card A: activationcardinality). A role has also its type, which is one of the values {ORGANIZATION, POSITION,BUSINESS ROLE}.


Property 4.3 (Permission-task Assignment (PTA)). A task has permissions for executing itself. Permissionis defined as a pair of information objects and access mode.

PTADPERMS� TASKS

Property 4.4 (Task-role assignment (TRA)). Role is defined as a set of tasks. A role has one or more tasks.A task can be assigned to many roles.

TRADROLES� TASKS

Property 4.5 (User-role assignment (URA)). A user has one or more roles. A role can be assigned to many users.

URADROLES�USERS

Property 4.6 (Supervision role hierarchy and strict inheritance (S-RH(s))). If R1 is a higher role than R2 ina role hierarchy, R1 inherits only the tasks of R2 that belong to class S or class A:

R1;R2A S-RHðsÞ;R1 >� R2;

8TiAR2 ) R1 inheritsfTi jTiA class S or TiA class Ag

Property 4.7 (Supervision role hierarchy and audit-oriented inheritance (S-RH(a))). If R1 is a higher rolethan R2 in a role hierarchy, R1 inherits both the tasks of R2 that belong to class S or class A; and all ‘read’privileges of R2:

R1;R2A S-RHðaÞ;R1 >� R2; 8TiAR2 )

R1 inheritsfTi jTiAclass S or TiA class Ag,‘read’ privileges of R2

Property 4.8 (Task-workflow assignment (TWA)). Only the tasks that belong to class W or class A can beassigned to workflow.

TiA WFS) TiA class W3TiA class A

Property 4.9 (Task attributes). If task Ti belongs to class W ; Ti has three attributes as follows:

* Activation condition (AC): it is an activation condition of Ti: It is expressed as an AND/OR conditionbetween prior tasks. For example, if AC ¼ T24T3; Ti can be activated when prior tasks T2 and T3 arefinished.

* Time constraint (TC): is the effective execution time of Ti: If the starting time of Ti is over after TC, Ti isautomatically deactivated.

* Cardinality (CD): the maximum number of activated task instances for a specific task at the same time.

These attributes are inherited to new task instances when they are created in new workflow instances.

Property 4.10 (Execution order). If T1;T2;y;Tn are prior tasks of Ti; and Ti is activated now,T1;T2;y;Tn are completed or activated.

fT1;T2;y;Tng-Ti : activateðTiÞ ) completed

ðT1;T2;y;TnÞ3activatedðT1;T2;y;TnÞ


Property 4.11 (Access right activation). If Ti belongs to class W or class A; the access rights assigned to Ti

can be allowed to the user only if Ti is activated.

PiAP;PiA assignedðTiÞ : TiA class

W3TiA class A ) activateðPiÞ only if activatedðTiÞ

Property 4.12 (Session). User can choose an active role through the session. The user can open one ormore sessions.

U can open 2session

Property 4.13 (Separation of duty (SOD)). T–RBAC offers the task and instance level SOD policy. Instancelevel SOD policy apply to tasks belonging to class W, and is effective for tasks belonging to the sameworkflow instance. For example, if tasks Ti and Tj are mutually exclusive at the instance level, and theinstances of Ti and Tj belong to different workflow instances, the SOD policy does not apply to Ti and Tj : Allconstraints on the task schema are inherited to all task instances. Therefore, TD-SOD dominates ID-SOD.

* [TS-SOD] task schema level static SOD

UiAU ;RiAR;Ti;TjAT ;TiaTj ;

TiAassignedðRiÞ4TjA assignedðRiÞ4RiA assignedðUiÞ

) Tie mutually-exclusive taskðTjÞ

* [TD-SOD] task schema level dynamic SOD

UiAU ;RiAR;Ti;TjAT ;TiaTj ;

TiA assignedðRiÞ4TjA assignedðRiÞ4activateðTiÞ4activateðTjÞ

4RiA assignedðUiÞ ) Tie mutually-exclusive taskðTjÞ

* [ID-SOD] task instance level dynamic SOD

UiAU ;RiAR;Ti;TjA class W ;Ti;TjA same instance of W ;TiaTj

TiA assignedðRiÞ4TjA assignedðRiÞ4activateðTiÞ4activateðTjÞ

4RiA assignedðUiÞ ) Tie mutually-exclusive taskðTjÞ

Property 4.14 (Restriction of SOD). If both task Ti and Tj belong to class S or class A; static SOD policycannot be applied to Ti and Tj :

ððTiA class S3TiA class SÞ4ðTjA class S3TjA class SÞÞ4ðTi;TjA same roleÞ )

Tie mutually-exclusive taskðTjÞ

Note: In properties 4.8, 4.9, and 4.10, task means task instance in the workflow. Instance level static SODhas the same meaning and effect as task level static SOD.

4.4. Consistency principles for the T–RBAC system

The T–RBAC system is a set of software modules and access control information based on the T–RBACmodel. If anyone implements the T–RBAC system, the system has to satisfy the T–RBAC features, and


maintain the consistent state of the T–RBAC system. This section suggests guidelines to maintainthe consistent state of the T–RBAC system. To maintain a consistent state, the T–RBAC system shouldalways check the completeness of a state every time changes occur in the state. Gavrila and Barkley [26]defines the consistency requirements for the general RBAC system. It also suggests safe conditions foradministrative operations for RBAC administration. However, Gavrila and Barkley [26] do not considerimportant consistency rules such as the ‘referential integrity rule’ Gavrila and Barkley [26] and he focuseson the user-role assignment and role–role assignment. We extend Gavrila and Barkley [26] and suggestcomplete administrative operations for the T–RBAC model. We redefine system state, complete state, fullsets of administrative operations, and completeness state checking rules. Based on these concepts, wesuggest the condition that determines that the T–RBAC system is consistent.At first, we define T–RBAC system state and its completeness. A state is a tuple

ðUSERS;ROLES;TASKS;ACTIVE TASK PROPERTY ;WFS;WF INSTANCES;

PERMS;URA;TRA;PTA;TWA;RRA;SOD;ACTIVE ROLES;ACTIVE TASKSÞ

Each tuple element is denoted in Section 4.3. RRA stands for role–role assignment which is the same as S-RH. We denote the set of states by STATES. Each tuple element is a data set containing access controlinformation. Below is a minimal request of the data schema. Application developers may add any attributesto it. ACTIVE-ROLES and ACTIVE-TASKS are temporal data sets. In other words, they have data valueswhen the T–RBAC system is running, while others have permanent data values. (Underlining indicates theprimary key of the data set.)

USERS(user id)

ROLES(role, type, user-assign-cardinality, activation-cardinality)

TASKS(task, class)

ACTIVE-TASK-PROPERTY(task, activation-condition, time-constraint, cardinality)

WFS(workflow-id)

WF-INSTANCES(workflow-id, instance-id, task, activating-user, status)

PERMS(permission-id, object, access-type)

URA(role, user id)

TRA(role, task)

PTA(task, permission-id)

TWA(workflow-id, prior-task, rear-task)

RRA(parent-role, child-role)

SOD(task1, task2, sod-type)

ACTIVE-ROLES(user, role)

ACTIVE-TASKS(user, task)

The state transitions are only triggered either by administrative operations or by users activating ordropping roles on their T–RBAC sessions. Each operation needs one or more arguments. We define legaladministrative or user-requesting operations as OPERATIONS.

OPERATIONS ¼ ðaddUser; rmUser; addRole; rmRole; addTask; rmTask;

addPermission; rmPermission; addWorkflow; rmWorkflow;

addURA; rmURA; addRRA; rmRRA; addTRA; rmTRA; addTPA;

rmTPA; addTWA; rmTWA; addSOD; rmSOD; addActiveRoles;

rmActiveRoles; addActiveTaskProperty; rmActiveTaskProperty;

addWorkflowInstance; rmWorkflowInstanceÞ


When the state transition occurs by the above operations, we must decide if the new state is completefrom the T–RBAC viewpoint. In order to decide, we need rules that check for completeness, ‘completeness-

checking rules’. Below is a part of the completeness checking rules.

8rA ROLES; number of ðauthorized usersðrÞÞpcard uðrÞ

8rA ROLES; role activationðrÞpcard aðrÞ

8uA USERS;8r1; r2A ROLES; 8r1; r2A assigned rolesðuÞ ) :ðr1 >� r2Þ4:ðr2 >� r1Þ

The first rule means, ‘‘The number of authorized users for any role cannot exceed the number of ‘assign-user’ cardinality of that role’’. If any of the given rules are violated at any time, this complete state will bebroken. All the rules are in Appendix A.Now we can define the concept of consistency of the T–RBAC system.

Definition 4.2. The new state S’ of a T–RBAC system is consistent with the complete state S if and only if allthe completeness checking rules are satisfied on S’:

It is clear that to maintain consistent states requires that all the administrative or user-requestingoperations follow the completeness checking rules. We add completeness-checking rules and some examplesof pre-condition for administrative operations to Appendix A; these can be very useful guidelines for T–RBAC developers. If developers implement T–RBAC systems and administration tools according toAppendix A, the system and tool always maintain a consistent state.For the sake of brevity, we simplified the workflow part in the T–RBAC model, but a real system may

require more complicated features. [Gav98] has already proved that its administrative operations do notbreak a consistent state. Thus, we omit the proofs since the same approach can be applied in our case.

4.5. Discussion of some aspects of T–RBAC

There are two main ideas in the T–RBAC model. One is to use intermediate tasks between access rightsand roles instead of assigning access rights to roles. This allows the roles to be linked to access rightsthrough the intermediate tasks. Moreover, it makes the point that RBAC could be integrated into theABAC model. The other is the classification of enterprise tasks (job function of contacts) according to theircharacteristics. Fig. 13 shows access control in the T–RBAC model, where a user can run various tasksthrough assigned roles. Some tasks, those that belong to class S or class A, are inheritable and their accessrights are inherited to higher roles in the role hierarchy. Some tasks, those that belong to class P; are privateand are not inherited to higher roles. Some tasks, those that belong to class W or class A, follow activesecurity policy and they are managed by the workflow mechanism.

The fundamental difference between ‘role’ and ‘task: Some may think there is no difference between ‘role’and ‘task’, but as can be seen in Table 6, they have different conceptual meanings. The concept ‘role’focuses on ‘actor’ and the concept of ‘task’ focuses on ‘activity’, and therefore ‘task’ is not sub-concept of‘role’. Grouping permissions is possible by role and task, but grouping permissions by role leads tounexpected results, as described in Section 3.3, since the concept ‘task’ has been removed.

Are the tasks classified into only four classes?: Tasks are classified into four classes in the T–RBAC modelbased on ‘inheritance’ and ‘active/passive access’ concepts. There can be more classes in the real world, butif we classify the tasks according to our guidelines, major requirements including Req. (3), Req. (4), andReq. (6) of Section 2.3 can be met in the enterprise environment. Furthermore, the fundamental point oftask classification is not that tasks are classified into ‘four’ classes, but that a task can be ‘classified’ by their‘characteristics’. Therefore, if anyone wants to implement a real system based on T–RBAC for a certain


company, he/she may define other characteristics of tasks depending on the company, and thus he/she canclassify the tasks into five or more classes for access control.

The effects of task classification: The classification of tasks has the following effects according to theircharacteristics.

* It offers the rules by which task/access rights can be inherited to higher roles from lower roles on the S-RH. It can also support partial inheritance of access rights according to security policy. It solvesproblems of general role hierarchy in RBAC.

User

Role

Role Hierarchy

Workflow Management

Information objects

Class S, A Class P Class W, A

Task Task Task Task Task Task

Fig. 13. Access control on T–RBAC model.

Table 6

Comparison of ‘role’ and ‘task’

Role Task

Definition from dictionary The function or position that somebody

has or expected to have in an organization

A piece of work that somebody has to do

Physical meaning

in T–RBAC

Group of users, group of tasks Group of permissions

Example in the Companies Sales manager Issue sales order

Purchasing clerk Approve customer order

Account analyst Analysis of production result

Usage Meaning Used for expressing ‘actor’ Used for expressing ‘activity’

Relations with others Related to hierarchical structure Related to sequential flow of execution

(business process)

The role structure implies

‘authority inheritance’


* T–RBAC deals with classes in different ways, according to the class. It is also possible to apply an active

security model to tasks that belong to class W or class A; and apply the general passive security model totasks belonging to class S or class P: Thus, task is a base concept for the integration of RBAC andABAC.

* It is the basis for deciding which tasks can be in a relationship for SOD. (See restriction of SOD).

5. Evaluation of the proposed T–RBAC model

5.1. Comparison of access control models

Section 3 leads us to the fact that ACL, ACM, DAC, or MAC are not appropriate for an enterpriseenvironment. Therefore, we compare three models, RBAC, ABAC, and T–RBAC. The basis of comparisonis the access control requirement of an enterprise environment as mentioned in Section 2.2 (we add moredetailed comparison items). The result is shown in Table 7.From Table 7 it can be seen that T–RBAC meets the requirements of an enterprise environment better

than the other two models. This means that T–RBAC is an improved model and has better modeling powerthan the other two models. Table 7 can be expressed as a diagram, Fig. 14, which shows the coverage of themodeling powers of the three models. ‘Role hierarchy’ is an original concept of RBAC and ‘Task’ is anoriginal concept of ABAC. ‘Role’ and ‘SOD’ are common concepts of RBAC and ABAC, but theseconcepts do not properly cover the requirements of the enterprise environment. Areas (a), (b), (c), and (d) inFig. 14 are areas not covered by RBAC and ABAC. T–RBAC covers the whole covered and uncoveredareas of RBAC and ABAC. For example, role hierarchy is a concept of the RBAC model and it supportsfull inheritance of access rights on the role hierarchy, but RBAC does not support partial inheritance ofaccess rights; area (a) points to partial inheritance. For ‘Task classification’, there is a remarkable differencebetween T–RBAC and the other two models. Some areas remained uncovered by T–RBAC, which areresearch issues for future work. (For the comparison, we select the feature of access control of workflow

Table 7

Comparison between access control models

No. Comparison criteria RBAC ABAC T–RBAC ETC

1. Keep away discretionary access J J J Req. (1)

2. Support role concept J J J Req. (7)

3. Support task concept � J J

4. Access control by unit of role J J J

5. Access control by unit of task � J J Req. (6)

6. Access control based on characteristics of tasks � � J

7. Support role hierarchy J � J Req. (2)

8. Support partial authority inheritance on the role hierarchy � � J Req. (3)

9. Support passive access control J � J Req. (4)

10. Support active access control � J J

11. Support separation of duty (SOD) J J J Req. (5)

12. Has a restriction for SOD � N/A J

13. Support delegation N/A N/A N/A

14. Support auditing of task execution � N/A J

15. Support closing account � N/A �16. Support methodology for implementation of constraints � J �


management coalition (WfMC) [14] as an ABAC model. The contents in ETC are related to requirementnumber in Section 2.2.)In the T–RBAC model, conspicuous improved points are the criteria items in Nos. 6, 8, 9, 10, 12, and 14

of Table 7. Now we discuss the improved points of the T–RBAC model and their effects on access control.Access control based on characteristics of tasks: As described above, tasks in the T–RBAC model should

be classified into four classes according to their characteristics related to authority inheritance and passive/active access models. RBAC and ABAC do not consider a task’s characteristics (Fig. 15(a)). They deal withall tasks in the same way, which can confuse security administrators. Usually, tasks have their owncharacteristics, and security administrators may feel there is some non-conformity between the real worldand the access control model. The T–RBAC model solves this problem. Access control based on a task’scharacteristics is an important approach for enterprise organizations because access privileges are assignedto users according to their assigned tasks. Two factors related to access control characteristics aresuggested, but we may find other factors related to them, which may lead to a more adaptable T–RBACmodel. The effects of task classification are implied in the items below.

Support partial authority inheritance in the role hierarchy: T–RBAC suggests two role hierarchies, S-RH(a) and S-RH(s). They support partial authority inheritance in the role hierarchy, which solves aproblem in the RBAC model—if role A and role B are in a mutually exclusive relationship, they cannothave the same ancestor role in the role hierarchy. Full authority inheritance in RBAC may induce violationof the ‘need-to-do’ principle, whereas partial authority inheritance prevents it.Fig. 16 shows the comparison of three role hierarchy models—general RH, S-RH(s), and S-RH(a)—by

inheritance structure of the example of Section 2.3. The inheritance structure contains the role hierarchyand related tasks. In the inheritance structure, the higher node inherits access rights from connected lowernodes. Partial inheritance can be expressed by the ‘private role’ concept [15]. General RH (Fig. 16(a)) hasthe characteristic of full inheritance of privileges of lower roles. So, R1 has rights for T1; T4; T5; T6; T7; and

Whole requirements of access controlin the enterprise environment

RBAC ABAC

T-RBAC

Rolehierarchy

RoleTask

Task classification

passive access control

(a) partial inheritance (b) inheritable task, non−workflow task

(c) three role types (d) restriction of SOD

active access control

applicationlevel

constraints

Workflow(a) (b)

(c)

SOD

(d)

Fig. 14. Modeling power diagram of RBAC, ABAC, and T–RBAC: (a) partial inheritance; (b) inheritable task, non-workflow task; (c)

three role types; (d) restriction of SOD.


T9: In the S-RH(s) (Fig. 16(b)), R1 has rights for T4; T5; and T9: In the S-RH(a) (Fig. 16(c)), R1 has readrights for T1; T6 and T7 and on T4; T5; and T9:We know that S-RH(s) or S-RH(a) have better expressionand dealing power of authority inheritance than the general RH. In spite of the improved representation,T–RBAC does not require extra information on authority inheritance. T–RBAC uses a simple rolehierarchy similar to the general RH of RBAC, and task classification information. S-RH has a simple butpowerful authority inheritance.

Support both passive and active access control: Most research on access control is focused on the passiveaccess model; MAC, DAC, and RBAC are passive access control models. Passive access models are basedon the ownership of access rights. If anyone has an access right, he/she can use them at any time, buttoday’s business environment is changing rapidly, for example, as regards workflow or collaborative work.Therefore, passive access models do not adequately represent enterprise organizations. Active access

receive customerorder

approve customerorder

execute promotionbudget

view general customer info

onepolicy

accesscontrol

Policy(1)

accesscontrol

Policy(2)

Policy(3)

Policy(4)

(a) Previous works (b) T-RBAC model

(Tasks) (Tasks)receive customer

order

approve customerorder

execute promotionbudget

view general customer info

Fig. 15. Tasks and access control policies.

R1

R2 R3

R5

T 9(s)

R1’

R2’ R3’

R5’

R1

R2R3

R5

T 4(a) T 1(w)

(a) General RH (b) S−RH(s) (c) S−RH(a)

[Notation]

R i : role (i=1,2,3,…)R ’i : sub−role of R iT i(j) : task or a set of privileges that T i(j) owns. (i=1,2,3, …, j is a class of Ti)T i(j)*r : a set of read privileges of T i(j)T i(j)*w : a set of write privileges of T i(j)

T i(j) = T i(j)*r ∪ T i(j)*w

T 5(p)

T 6(p) T 7(p)

T 9(s)

T 5(p)

T 6(p)

T 4(a)

T 1(w) T 7(p)

R1’

R2’ R3’

R5’

R1

R2R3

R5

T 9(s)

T 5(p)*w

T 6(p)*w

T 4(a)

T 1(w)*w T 7(p)*w

T 1(w)*r T 7(p)*rT 6(p)*r

T 5(p)*r

Fig. 16. Comparison of three role hierarchies by inheritance structure.


models are based on task activity, where assigned access rights are available only if the activity status isactive. These active access models are applied to most workflow products. Enterprise organizationsneed both active and passive models, but they are developed separately. Therefore, the informationsystem for a company has two separate access control, which induces inefficient access controlmanagement—duplicated access control information, hard transformation between two access controlsystems, etc. The T–RBAC model supports a unified access control mechanism for passive and active accessmodels.

Support auditing of task execution: Auditing of task execution is one of the important business rules. TheSOD principle is a good way to prevent fraud at security design, whereas auditing of task executionprevents fraud at execution time. The T–RBAC model supports this principle by S-RH(a) in Fig. 16(c). If anew task is inserted to a role Rn; the senior roles of Rn automatically receive auditing authority for the newtask, which does not lead to any side effects.We describe the creative features of the T–RBAC model. It is suitable for enterprise environ-

ments, especially for large companies that have many users, information objects, and complex businessprocesses.

5.2. Implementation of T–RBAC model

As a means of evaluation, we implemented the T–RBAC model. Fig. 17 shows the implemented T–RBAC middleware system. Users access the Web documents through a Web browser. The T–RBAC engineruns access control, co-working with the Web server. The main modules were implemented by Java servlets.The advantage of our system is that it can be build in current web server without changes of web server orweb documents. The detailed results of the implementation are introduced in Appendix B. Byimplementation, we showed that the T–RBAC model runs well in the real world.

Browser

WebServer

Web Document

( )

Access controlSession management

AdminTool

Sharedmemory

RBACcatalog

load

T-RBAC middleware

User/Role/Task/ObjectURA, PRA, RH, SOD

: Java Servlet

DatabaseEngine(Jrun)

Servlet

EngineT−RBAC

Fig. 17. T–RBAC middleware system.


In this section, we described the evaluation criteria for the T–RBAC model. The T–RBAC model hasmore creative features than the RBAC or ABAC models. T–RBAC model accepts many of therequirements of access control in the enterprise environment.

6. Conclusion and further work

Today’s enterprise organizations face serious security problems. One of them is access control—theyneed a proper model for access control. The model should meet both ‘confidentiality’ and ‘availability’. Inthis paper, we propose an improved model named ‘task–role-based access control (T–RBAC)’. This modelis based on the characteristics of tasks. The availability of T–RBAC model is supported by implementationexperiences. The main contribution of T–RBAC model is as follows:

* It analyses the main factors of the enterprise environment related to access control and shows therelationship between them.

* It shows that some authorities of descendant job positions or business roles are inherited to ancestor jobpositions or business roles through the hierarchy line. It means ‘partial’ inheritance of authorities.(Previous research uses ‘full’ inheritance of authorities.)

* It shows that there are several types of tasks in enterprise organizations. They have differentcharacteristics of access control according to their class.

* It shows that both active and passive access takes place in the enterprise world.* It describes general business rules, including two new principles ‘auditing of task execution’ and ‘closingaccount’.

* The T–RBAC model contains the above access control characteristics and it overcomes the weaknessesof the RBAC and ABAC models.* supports task level access control,* supports both active and passive access control,* supports different access controls according to task class,* supports partial inheritance of access rights in the role hierarchy,* has a restriction of SOD,* supports the principle of ‘audit task execution’ by S-RH(a).

The conclusion is that T–RBAC supports increased modeling power. Although T–RBAC has manyadvantages important research topics remain.

* T–RBAC does not deal with two business rules: delegation and closing account. It is importantfor enterprise organizations to support efficient execution of business activities. The generalsolution for delegation is to use a delegation server. Furthermore, the implementation of variousconstraints is a research issue. Most related research is focused on developing a description language forconstraints. A practical method for merging the description language and the T–RBAC model isrequired.

* In this paper, we assumed a centralized enterprise environment. It has a single computer system andsingle location. The requirements of a distributed enterprise environment are different from thiscentralized one. For the distributed environment, we need to consider local and global access controlmanagers and their communication.

* Most business information is stored in a database in large enterprise organizations. The informationobject of the database system is a table, view, or stored procedure, etc. A tuple (record) in the table is notan object of access control, because there is no way to distinguish tuples by their ‘explicit name’, but


tuple-level access control is required in many cases. Therefore, we need further research on anefficient means to solve this problem. One possible solution is to insert a column into a table fordistinguishing tuples. Another is to use a stored procedure for modifying the ‘WHERE’ clause of theSQL statement.

Appendix A. Completeness-checking rules and administrative operations for T–RBAC system

A.1. Completeness checking rules

During system operation, we require each system state to satisfy the following rules:

R1. All data sets subject to referential integrity rule of relational database(1) 8(-, user) A URA, user A USERS(2) 8(r; -) A URA, (r; -, -, -) A ROLES

(3) 8(r1; r2) A RRA, (r1; -, -, -) A ROLES 4 (r2; -, -, -) A ROLES

(4) 8(r; -) A TRA, (r; -, -, -) A ROLES

(5) 8(-, task) A TRA, (task, -) A TASKS

(6) 8(task,-) A PTA, (task, -) A TASKS(7) 8(-,task1, task2) A TWA, (task1, -) A TASKS 4 (task2, -) A TASKS(8) 8(-, -, task, -, -) A WF-INSTANCES, (task, -) A TASKS(9) 8(task1, task2, -) A SOD, (task1, -) A TASKS 4 (task2, -) A TASKS(10) 8(task,-, -, -) A ACTIVE-TASK-PROPERTY, (task, -) A TASKS(11) 8(w-id,-, -) A TWA, w-id A WFS(12) 8(w-id, -, -, -, -) A WF-INSTANCES, w-id A WFS(13) 8(-, p-id) A PTA, p-id A PERMS

R2. Two cardinalities of a role are greater than 0R3. All role types are one of ‘ORGANIZATION’, ‘POSITION’, and ‘BUSINESS-ROLE’R4. If role Ri and Rj have same tasks, then Ri ¼ Rj

R5. The class name of a task is one of ‘P’, ‘S’, ‘W’, and ‘A’R6. The number of a task instance subjects to cardinality of the taskR7. The access type of permissions are one of ‘READ’, ‘WRITE’, and ‘EXECUTE’R8. Only the tasks that classified into class-W or class-A can belong to workflowR9. The status of task instances is one of ‘DEACTIVE’, ‘ACTIVE’, and ‘COMPLETED’R10. If T1;T2;y;Tn are prior tasks of Ti in the same workflow and Ti is activating now, T1;T2;y;Tn

are completed or activatedR11. If task Ti and Tj have same permissions, then Ti ¼ Tj

R12. The number of authorized users for any role does not exceed the assign user cardinality of that roleR13. The number of activation for specific role does not exceed the activation cardinalityR14. No role inherits (directly or indirectly) itselfR15. Any two roles assigned to same user do not inherit (directly or indirectly) one anotherR16. There is no cycle in the S-RHR17. All roles type of ‘ORGANIZATION’ are direct or indirect child of the roles type of ‘POSITION’or ‘BUSINESS-ROLE’ on the S-RHR18. The roles type of ‘BUSINESS-ROLE’ cannot belong between roles types of ‘POSITION’ on the S-RHR19. The roles type of ‘POSITION’ cannot belong between roles type of ‘BUSINESS-ROLE’ on the S-RH


R20. The roles that type is ‘ORGANIZATION’ have only inheritable tasksR21. Static SOD is applied for only un-inheritable tasksR22. The type of SOD is one of ‘TS’, ‘TD’, and ‘ID’R23. Any two tasks authorized for same role are not in static separation of dutiesR24. There is no task in static separation of duties with itselfR25. The static separation of duties relation is symmetricR26. The active role set of any user is a subset of his or her authorized rolesR27. Any two tasks in task level dynamic separation of duties do not belong both to the active task set ofany userR28. Any two tasks in instance level dynamic separation of duties do not belong both to the active taskinstance set of any userR29. The dynamic separation of duties and static separation of duties relations are disjointR30. There is no task in dynamic separation of duties with itselfR31. The dynamic separation of duties relation is symmetric

A.2. Examples of T–RBAC administrative operations

addUser(user) /*The new user is added to the USERS data set */

Semantics:USERS’=USERS , { user}

Conditions:J user e USERS

addRole(role, role type, card uaer assign, card activation) /* add new role to ROLES data set */

Semantics:ROLES’=ROLES , {(role, role type, card uaer assign, card activation)}

Conditions:J (role, -, -, -) e ROLES

J role type A {‘ORGANIZATION’, ‘POSITION’, ‘BUSINESS-ROLE’}J card uaer assign >0 4 card activation >0

addTask(task, class) /* add new task to TASKS data set */

Semantics:TASKS’=TASKS , {(task, class)}

Conditions:J (task, -) e TASKS

J class A { ‘P’, ‘S’, ‘W’, ‘A’}

addPermission(p-id, object, access-type) /* add new permission to PERMS data set */

Semantics:PERMS’=PERMS , {(p-id, object, access-type)} // p-id=permission id

Conditions:J (p-id, object, access-type) e PERMS

J access-type A {‘READ’, ‘WRITE’, ‘EXECUTE’}


Appendix B. Implementation of T–RBAC middleware system

We implemented access control engine and administration tool on the web environment. As wementioned before, target of access control is BK21 mirroring site which is http://dblab.sogang.ac.kr/trbac/BK21/rbac bottom.htm. Administration tool supports us to manage T–RBAC information such as user,role, task, user-role assignment, task-role assignment, etc. Also it supports monitoring of access control.(1) Example of T–RBAC Admin tool (role registration page)

ð2Þ

Administration tool subjects to completeness-checking rules

ð3Þ

After log in and role activation, T–RBAC control panel is added automatically


http://dblab.sogang.ac.kr/trbac/BK21/rbac_bottom.htm



References

[1] C.P. Pfleger, Security in Computing, 2nd Edition, Prentice-Hall International Inc., Englewood Cliffs, NJ, 1997.

[2] D. Russel, G.T. Gangemi Sr, Computer Security Basics, O’Reilly & Associates, Sebastopol, CA, 1991.

[3] J.B.D. Joshi, W.G. Aref, A. Ghafoor, E.H. Spafford, Security model for web-based applications, Communications ACM 44(2)

(2001).

[4] E.G. Amoroso, Fundamental of Computer Security Technology, PTR, Prentice-Hall, Englewoods Cliffs, NJ, 1994.

[5] R. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role-based access control method, IEEE Comput. 29 (1996) 20–26.

[6] D. Ferraio, J. Cugini, R. Kuhn, Role-based access control (RBAC): features and motivations, Proceedings of the 11th Annual

Computer Security Application Conference, New Orleans, LA, 1995, p. 12.

[7] Dagstull, G. Coulouris, J. Dollimore, A security model for cooperative work: a model and its system implications, Position paper

for ACM European SIGOPS Workshop, Dagstuhl Castle, September 1994.

[8] G. Herrmann, G. Pernul, Towards security semantics in workflow management, Proceedings of the 31st Hawaii International

Conference on System Sciences, Hawaii 1998.

[9] R.K. Thomas, Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative

environment, Proceedings of the Second ACM Workshop on Role-Based Access Control, Fairfax, VA, 1997.

[10] R.K. Thomas, R. Sandhu, Task-based authorization controls (TBAC): a family of models for active and enterprise-oriented

authorization management, Proceedings of the IFIP WG11.3 Workshop on Database Security, Vancouver, Canada, 1997.

[11] T. Jaeger, On the increasing importance of constraints, Proceedings of the Fourth ACM Workshop on Role-Based Access

Control, Fairfax, VA, October 1999.

[12] R.S. Sandhu, G.J. Ahn, The RSL language for role-based separation of duty constraints, Proceedings of the Fourth ACM

Workshop on Role-Based Access Control, Fairfax, VA, 1999.

[13] J.E. Tidswell, T. Jager, Integrated constraints and inheritance in DTAC, Proceedings of the Fifth ACMWorkshop on Role-Based

Access Control, Berlin, 2000.

[14] Workflow Management Coalition (WfMC), Workflow Reference Model, WF-TC-1003 V1.1, January 1995.

[15] R.S. Sandhu, Role activation hierarchies, Proceedings of the Third ACMWorkshop on Role-Based Access Control, Fairfax, VA,

1998.

[16] G.J. Ahn, R. Sandhu, The RSL99 language for role-based separation of duty constraints, Proceedings of the Fourth ACM

Workshop on Role-Based Access Control, Fairfax, VA, October 1999.

[17] E. Barka, R. Sandhu, Framework for role-based delegation models, Proceedings of the 14th Annual Computer Security

Applications Conference (ACSAC/2000), New Orleans, LA, 2000.


[18] D.R. 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, Fairfax, VA, 1997.

[19] J.D. Moffett, E.C. Lupu, The use of role hierarchies in access control, Proceedings of the Fourth ACMWorkshop on Role-Based

Access Control, Fairfax, VA, 1999.

[20] S. Oh, S. Park, The RBAC agent model on enterprise environment, 5-minute talk, 2000 IEEE Symposium on Security and

Privacy, Berkeley, CA, May 2000.

[21] S. Oh, S. Park, Task-role-based access control (T-RBAC): an improved access control method for enterprise environment, Lecture

Note in Computer Science, Vol. 1873, Database and Expert Systems Applications, Springer, Berlin, Proceedings of the 11th

International Conference, DEXA 2000, London, September 2000.

[22] S. Oh, S. Park, An integration model of role-based access control and activity-based access control using task, Proceedings of the

14th Annual IFIP WG 11.3 Working Conference on Database Security, Schoorl, The Netherlands, August 2000.

[23] S. Oh, S. Park, Task-role-based access control model for enterprise environment, J Korea Inst Information Security Cryptology

11 (1) (2000) 2.

[24] R.R. Simon, M.E. Zurko, Separation of duty in role-based environments, Proceedings of the 10th Computer Security

Foundations Workshop (CSFW’97), Rockport, MA, 1997.

[25] Y. Al-Salqan, N. Shahmehri, W. Wen, M. Debbabi, Final Summary Report on Enterprise Security, Proceedings of the IEEE 8th

International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’99), San Jose, CA,

1999.

[26] S.I. Gavrila, J.F. Barkley, Formal specification for role based access control user/role and role/role relationship management,

Proceedings of the 3rd ACM Workshop on Role-Based Access Control, Fairfax, VA, 1998.

[27] C.J. Date, An Introduction to Database Systems, 6th ed., Addison-Wesley, New York, 1995.


task–role-based access control model

Documents