Task Based Access Control (TBAC) is well suited for distributed computing and information processing activities with multiple points of access, control, and decision making such as those found in workflow and distributed processes and transaction management systems. TBAC differs from traditional access controls and security models in many respects (Thomas and Sandhu, 1997). Instead of having a system-centric view of security, TBAC approaches security modelling and enforcement at the application and enterprise level, which makes it more desirable in real world enterprises.
In 2000, Sandhu et al. pioneered NIST (National Institute of Standards and Technology) RBAC models (W3 website, 2001). Like other RBAC models, permissions are given to the roles rather than the users, where roles are defined to be mutually exclusive. Sandhu et al introduced two types of hierarchies: a role hierarchy and an activity hierarchy. In the role hierarchy, senior roles inherit all permissions of junior roles, whereas in the activity hierarchy senior roles inherit only partial permissions of junior roles.
There are some non-canonical (or non-"standard") access control models (besides the well-known MAC, DAC and RBAC) that are simply not well defined. Anyone can define or redefine them as they want, as long as the model makes sense. In most cases TBAC is aggregated back up into roles.
65
That is, the access is granted based on a task but the access check then compares this task to roles that contain that task, and users that are part of one of those roles. In other words, tasks can be seen as "sub-roles" - or if it is easier to understand, roles become role-containers, and the tasks are the real roles.
Clearly, this is a huge improvement on straight RBAC, since it gives you some granularity and dynamics to play with, but it is still a form of (extended) RBAC. It allows many dynamic information processing activities with multiple points of access, control, and decision making. An active security system takes into account the impact of context as it emerges with progressing tasks and distinguishes task-based and context-based permission activation from permission assignment.
TBAC differs from traditional access controls and security models in many respects. Instead of having a system-centric view of security, TBAC approaches security modelling and enforcement at the application and enterprise level. Secondly TBAC lays the foundation for a new breed of what is called “active” security models. By active security models, the researcher means models that approach security modelling and enforcement from the perspective of activities or tasks, and as such, provide the abstractions and mechanisms for the active runtime management of security as tasks progress to completion. In an active approach to security management, permissions are constantly monitored and activated and deactivated in accordance with emerging context associated with progressing tasks (such as in workflows). Such a task-based approach to security represents a radical departure from classical passive security models such as those based on one or more variations of the subject-object view of security and access control. In a subject object view of security, a subject is given access to objects in a system based on some permission (rights) the subject possesses. However, such a subject-object view typically divorces access mediation from the larger context (such as the current state of tasks) in which a subject performs an
66
operation on an object. The most obvious application of TBAC is in secure workflow management.
TBAC enables the granting, usage tracking, and revoking of permissions to be automated and co-ordinated with the progression of the various tasks. Without active authorisation management, permissions will in most cases be “turned on” too early or too late and will probably remain “on” long after the workflow tasks have terminated. This opens up vulnerabilities in systems. Any attempt to minimise such vulnerabilities will require a security administrator to keep track of the progress of the tasks for all enacted workflow instances; an error prone and impossible task! Thus what is needed is an approach where access control permissions are granted and revoked according to the validity of authorisations and one where this can be done without manual security administration. The authorisations themselves are of course processed strictly according to some application logic and policy. In the remaining sections of this project the researcher will describe how TBAC ideas can be used to accomplish this.
TBAC focuses on security modelling and enforcement at the application and enterprise level. In the TBAC paradigm of access control, permissions are associated with contextual information about on-going activities when evaluating an access request. Permissions are checked-in and checked-out from protection states in a just-in-time fashion based on activities or tasks and synchronised with the processing of authorisations in progressing tasks. Thus, TBAC dynamically manages permissions as authorisations by progress to completion and minimises the vulnerabilities in a system.
There are basically two broad objectives guiding the research efforts in TBAC. The first is to model from an enterprise perspective, various authorisation policies that are relevant to organisational tasks and workflows, and a set of user friendly envisioned tools to help a security officer model and specify policies. The second objective is to seek ways in which these modelled
67
policies can be automatically enforced at runtime when the corresponding tasks are invoked. Preliminary ideas for TBAC that recognised the need for active security were presented in (Thomas and Sandhu 1997). More recently, a workflow authorisation model (WAM) was presented in (Qin and Atluri 2003). WAM has the same general motivation as TBAC in that it tries to provide some notions of active security and just-in-time permissions.
TBAC keeps track of the usage and consumption of permissions, thereby preventing the abuse of permissions through unnecessary and malicious operations. However, in TBAC as in all the modified Access Control family, there are no contexts in relation to activities, tasks, or workflow progress and it only keeps track of usage and validity of permissions. This is insufficient for collaborative systems that require a much broader definition of context. More fine grained components need to be defined to support dynamic environments motivated by TBAC. TBAC can be used effectively in an application or enterprise, but for most collaborative environments, TBAC is used within other access control models.
In conclusion, TBAC would have the same problem that RBAC has in complex systems such as large healthcare systems. In that the privacy extension will add to the complexity of the system. And the context issue needs to be well addressed in TBAC before it could be applied in real application. And in (Omran et al. 2010 and Omran et al. 2012), the researchers have presented a study that has real numbers for comparing the required number of tables, SQL statements and policies to show how the complexity of the design using RBAC and TBAC as compared with our method.
68