R. Thomas, R. Sandhu. 1997. "Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management"

TBAC is well suited for distributed computing and information processing activities with multiple points of access, control, and decision making.

Unique properties

1. Instead of having a system-centric view of security, TBAC approaches security modeling and enforcement at the application and enterprise level.
2. Lays the foundation for active security models - models that approach security modeling and enforcement from the perspective of activities or tasks.
   • permissions are constantly monitored and activated and deactivated in accordance with emerging context associated with progressing tasks
   • in contrast with passive models, which typically does not relate access mediation to the larger context (such as the current state of tasks) in which a subject performs an operation on an object
     

Motivation
to automate the manual process of granting authorization

• person granting the authorization usually takes responsibility for the actions that are authorized by the authorization
• authorization has a lifetime; once an authorization becomes invalid, organizations require that the associated permissions no longer be available

Objectives

• to model from an enterprise perspective, various authorization policies that are relevant to organizational tasks and workflows
  
• to seek ways in which these modeled policies can be automatically enforced at runtime when the corresponding tasks are invoked

Subject-object access control characteristics

• The implicit assumption that there is a central pool of resources to which we need to provide access control.
• Access control information represents isolated units of security information.
• Access mediation is not related to larger operation context.
• There is no memory of any evolving context associated with past accesses.
• There is no record of the usage of permissions.
• Existing permissions can be revoked but cannot be put on hold.
• Requires fine-grained security administration.
• No contextual information about ongoing activities or tasks can be taken into account when evaluating an access request.

TBAC basic ideas
Authorization-step - represents a primitive authorization processing step and is the analog of a single act of granting a signature in the forms (paper) world

• a group of individuals may be allowed to grant a signature; all sales clerks may sign sales orders
• a single instance of a signature is granted to only one individual; sales order 1208 is signed by sales clerk Tom
• group of individuals = trustee-set
• Tom = executor-trustee of the authorization-step
• executor-permissions - set of permissions required by the executor-trustee to invoke and grant the authorization-step
• enabled-permissions - set of permissions that are enabled by every authorization-step
• we associate a period of validity and a lifecycle with every authorization-step
  

TBAC as an active-security model

• the modeling of authorizations in tasks and workflows
• monitoring and management of authorization processing and life-cycles as tasks progress
• the use of both type-based as well as instance and usage-based access control
• the maintenance of separate protection states for each authorization-step
• the dynamic runtime check-in and check-out of permissions from protection states as authorization-steps are processed

Every authorization-step maintains its own protection state

• initial value of a protection state is the set of permissions that are turned on (active) as a result of the authorization-step becoming valid
• with each permission we associate a certain usage count; when a usage count has reached its limit, the associated permission is deactivated and the corresponding action is no longer allowed
  • activation of permission - check-in of the permission to the protection state
  • deactivation of a permission - check out from the protection state
• protection states of individual authorization-steps are unique and disjoint (every permission is unique to the task where it is used)

TBAC uses type-based access control and instance and usage-based access control.

• type-based access control is used to encapsulate access control restrictions as reflected by broad policy and applied to types
• instance and usage-based access control is used to model and manage the details of access control and protection states (permissions) of individual authorization instances including keeping track of the usage of permissions

Summary of TBAC vs subject-object

1. Protection states, which represent active permissions that are maintained for each authorization step. Traditional subject-object models have no notion of access control for processes or tasks.
2. TBAC recognizes the notion of a life-cycle and associated processing steps for authorizations.
3. TBAC dynamically manages permissions as authorizations progress to completion. This differs from subject-object models where the primitive units of access control information contain no context or application logic.
4. TBAC understands the notion of “usage” associated with permissions; authorizations have strict usage, validity, and expiration characteristics that may be tracked at runtime. In a typical subject-object access control model, a permission implies nothing more than the fact that the subject has the permission for the object.
5. TBAC can form the basis of self-administering security models as security administration can be coupled and automated with task activation and termination events.

Family of TBAC models


TBAC0
Components of an authorization-step

• Step-name- name of the authorization-step
• Processing-state - indicates how far the authorization-step has progressed in its life-cycle
• Protection-state - defines all potential active permissions that can be checked-in by the authorization-step
  • validity-and-usage specification - associated with every permission, it specifies how the usage of the permissions will relate to the authorization remaining valid (or becoming invalid)
• Trustee-set - contains relevant information about the set of trustees that can potentially grant/invoke the authorization-step such as their user-identities and roles
• Executor-trustee - records the member of the trustee-set that eventually grants the authorization-step
• Task-handle - stores relevant information such as the task and the event identifiers of the task from which the authorization-step is invoked

Processing states and life cycles of authorizations

• Dormant - an authorization-step is in this state if it has not been invoked by any task
• Started - once an authorization-step has been successfully invoked, it enters this state where processing begins
• Aborted - similar to dormant except that a failed attempt to start the authorization-step was made in this case
• Valid-unused - after an authorization-step has been started and subsequent processing was successful
• Valid-used - if an authorization was in a valid-unused state, and it is subsequently used or consumed, then it enters the valid-used state. Depending on policy, an authorization may be used multiple times before it enters the invalid state.
• Invalid-unused - this state is entered if certain conditions for an authorization to be valid are not met upon termination or if the authorization had entered the valid-unused state and was subsequently revoked
• Invalid-used - this state is entered either as a result of a last-use transition from the valid-unused state or as a result of a revoke or last-use event (transition) from the valid-used state
• Hold-used/unused - the (unused) authorization is temporarily suspended. All associated permissions will be inactive

Basic dependencies to construct authorization policies


TBAC1
composite authorization - abstraction that encapsulates two or more authorization-steps

• example: transfer funds from one bank to another
• first authorization is withdrawal from source account, second authorization is deposit funds into target account
• can be modeled as a composite-abstraction
• authorization-steps in a composite-abstraction are not visible to authorization-steps outside of the composite-abstraction (encapsulation, information hiding)

critical-set - subset of the total number of component authorization-steps

• when any member of the critical-set has reached the start state, then the composite authorization is started
• when all members of the critical-set are valid, then the composite authorization is valid
• when any members of the critical-set becomes invalid, then the composite authorization becomes invalid
• composite authorization can also declare noncritical-sets to define additional states of validity (valid/invalid only when critical-set is valid/invalid)

TBAC2
static constraints and dynamic constraints similar to that of RBAC

start-condition - can be used to specify a rich set of constraints that govern whether an authorization-step can transition into the started state

scope - can be used to control if an authorization step is visible to an entire workflow, a task, or other finer units such as subtasks.