E. Bertino, P. Bonatti, E. Ferrari. 2001. "TRBAC: A Temporal Role-Based Access Control Model"

Even though RBAC has reached a good maturity level, there are still significant application requirements not addressed by current RBAC models.


Roles’ temporal dimension
Example: the case of part-time staff in a company

• assume that part-time staff is authorized to work within the given organization only on working days, between 9 AM and 1 PM
• if part-time staff is represented by a role, then the above requirement entails that this role should be enabled only during the aforementioned temporal intervals
• similar requirements can be supported by specifying—for each role—the time periods in which they can be activated

Role dependencies
Example:

• the doctor-on-night-duty role is enabled during the night
• since doctors may need the assistance of a nurse, one should make sure that the corresponding role—say, nurse-on-night-duty—is enabled whenever doctor-on-night-duty is

TRBAC model
Periodic expression - denotes an infinite set of periodic time instants
Examples:

• all * Years + {3, 7} Months -> 2 = intervals that start at the 3rd and 7th months of the year and that have a length of 2 months
• night-time, day-time
• Mondays
• third hour of the first day of each month

Prios - totally ordered set of priorities
- has at least two distinct members (HIGHEST and LOWEST)


Event expression - "enable R" or "disable R", R is a role


Prioritized expression - p:E, p = priority and E = event expression


Role status expression - "enabled R" or "not_enabled R" (says if R is enabled or not)


Conflicting events - "enable R" and "disable R" are conflicting events
- conf(enable R) = disable R and vice versa


Role enabling base - basic logic of TRBAC; is composed of

• periodic events (I, P, p:E) - [1/1/2000, infinity], nighttime, VH: enable doctor-on-night-duty
• role triggers E1, ..., En, C1, ..., Cn -> p:E after delta_t (after delta_t is for delay; optional)
  • enable doctor-on-night-duty -> H: enable-nurse-on-night duty

Run-time expression - used by Security Officer to enable and disable roles dynamically
- p:E after delta_t


Request-stream - sequence of run-time expressions requested by the SO
- RQ = - an RQ(t) can be empty


Blocked-event - events are blocked according to the denial-takes-precedence principle
Nonblocked(S) - set of nonblocked events


System trace

• EV - the tth element of EV, denoted by EV(t), is the set of events that occur at time t
• ST - the tth element of ST, denoted by ST(t), is the enabled roles at time t

Caused events at time t

• all events scheduled via a periodic event or an explicit request are caused
• all events scheduled by a trigger are caused, provided that
  • the role status expressions in the body are satisfied
  • the event expressions in the trigger are caused before time t, even with delay
    
  • such events must not be blocked by any concurrent event

Execution model - EV with all caused events


Individual exceptions - "disable R for U" or "enable R for U", U is a username or a variable ranging over usernames

J. Barkley, K. Besnozov. 1999. "Supporting Relationships in Access Control Using Role Based Access Control"

Consider access policies associated with content rating systems in entertainment media. A movie rated “PG13” may only be viewed by a minor over the age of 13 unless accompanied by an adult. An access decision for this policy includes the following factors:

• the age attribute of the user,
• the rating attribute of the object, i.e., the movie to which access is sought,
• the relationship, i.e., simultaneous access, with another user, and
• the age attribute of the other user.

- Using roles to express relationships may be inefficient and/or counter intuitive.
- When roles cannot be used to represent relationships, it is common to program access decision logic directly into an application. This approach restricts the ability to change access policy in a timely manner.



- Consider the relationship “attending-physician” between a physician and a patient.
- An authorization service may need to know if an attending physician relationship exists between patient Peter and the user with ID smith.

• In an RBAC system where a role is a data attribute of the user, this could be modeled by creating an “attending-physician-to-Peter” role. (very inefficient!)
  
  • the attending-physician relationship likely being redundantly stored in two locations: the patient record database and the role database;
  • security administrators having to update the role database whenever the attending-physician relationship changes for a user, and;
  • potentially very large active role sets when the user is a doctor

- relationships, as opposed to traditional security attributes such as roles, can have short lifetimes



RAD





The RAD facility is composed of the following elements:

• An Access Decider (AD) which receives requests for authorization decisions from RAD clients.
• Zero or more Policy Evaluators which provide evaluation decisions for those policies that govern access to the given resource. If a Policy Evaluator does not have any policy associated with the given resource name, the evaluator returns the result “don't know.”
• A Policy Evaluator Locator which provides references to potentially more than one Policy Evaluator.
• A Dynamic Attribute Service which provides dynamic attributes of the subject in the context of the intended access operation on the given resource associated with the specified resource name.
• A Decision Combinator which combines results of the evaluations made by Policy Evaluators into a final access decision by resolving evaluation conflicts and applying combination policies.

RAD vs other approaches
User attributes and relationships are usually stored in an information system as part of normal business processing, not for the purpose of access control. Requiring such information to also be stored as security metadata creates redundant information managed by different administrators
with different perspectives as to its use. In general, it is counter intuitive.

Another approach which is commonly used to include relationships and other factors in role based access decisions is to locate such access decision logic within application code. From a policy management point of view, this is very undesirable. Any time a policy changes, application code must be changed.

However, the ability to integrate access decisions made in different parts of an enterprise and the capability of including factors in access decision where the values of those factors are naturally very dynamic can result in unacceptable performance.

R. Thomas, R. Sandhu. 1993. "Towards a task-based paradigm for flexible and adaptable access control in distributed applications"

Authorizations in distributed applications should be seen in terms of tasks or activities rather than individual subjects and objects, based on two emerging trends:

1. The integration of computing within organizations, and the subsequent increase in the automation of organizational functions and work-flows.
2. The shift from main-frame computer systems to workstations and client-server technologies.

A task:

• is long-lived;
• may involve multiple subtasks, where a subtask may need to be individually or collectively authorized;
• may involve multiple and often distinct principals to carry out individual subtasks;
• is distributed in space and time.

R. Thomas, R. Sandhu. 1994. "Conceptual Foundations for a Model of Task-based Authorizations"

Computer security models have a bias towards a centralized notion of computing.

• good for a computer security model, bad for an information-oriented model (higher level)

(first mention of task based authorization: R. Thomas, R. Sandhu. Towards a task-based paradigm for flexible and adaptable access control in distributed applications.)

	Abstraction stages	Security model stages	examples
What needs to be done? (people oriented)	Trust objectives	Organizational requirements	little work has been made
	External-interface requirement	Computer policy models	non-interference model, task-based authorization
	Internal requirements	Access control models	Bell-LaPadula model, HRU model, typed access matrix model
	Rules of operation	Implementation models
How to do it? (computer oriented)	Functional design	???

Paper based model
Authorization of transactions

• each source document should be authorized
  
• authorization can come in the form of signatures or authorization codes

Source documents (deposit slips, sales order forms) are also good for

• verification of data
• constructing audit trails
• recovery in the event that processed data is lost

Transaction processing in computerized information systems often do not involve source documents in the loop. (is this still true now?)




Transient objects

• documents - vouchers, purchase orders, sales slips
• issue a finite set of operations then leave the system

Persistent objects

• inventory databases
• bank accounts

Enforce controls primarily on the transient objects.
Transaction to be executed on persistent objects only as a side effect of executing transactions on transient objects.


Transaction control expressions
Example:

1. Clerk prepares a check
2. 3 separate supervisors approve the check
3. Check is issued by (a different) clerk

Transaction control expression for above is:
prepare * clerk;
3: approve * supervisor;
issue * clerk;

Each expression consists of a transaction and a role.
Separation of duty is achieved by requiring the users that execute different transactions in the expression to be distinct.
Provides support for linear sequences of authorizations.



Task-based authorizations
Authorization function


Each authorization function is a point in a network where responsibilities are accepted, and one from which associated obligations are discharged and new responsibilities created.


Issues
Abstraction and composition

• authorized-task-unit to model the authorizations associated with every authorization function
• an authorization unit may be composed of other smaller units called approval-steps

Dependencies

• must model dependencies between authorization-units as well as those internal to the authorization-unit
• temporal - relates to the order of execution of authorizations
• semantic - relates to the implied authorizations that may be needed as part of the authorization to be performed
• atomic - grant all or none

Incorporation of controls

• what constructs and mechanisms are needed to incorporate controls

Delegation and revocation
Authorization expiration
Authorization deadlines

• example, manager responsible for giving approvals may be available only for certain hours during the week

Failure and exception handling
Deadlocked authorizations



Groundwork for building a model


Authorization-task-unit(task name)

• Originating function
• Attributes: atomic, expiration, deadline
  
• Dependency specifications: {}
• Approval-steps: {}

Approval-step

• a tuple of the form {step-name, role, expiration, deadline}

Dependency specification

• {task-name, dependency type} OR
• {step-name, dependency type}

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.

D. Kuhn. 1997. "Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems"

Safety condition
- a condition that must be met to ensure that separation of duty requirements are not violated
- no user should have access to all the privileges that are required for any task requiring separation of duty

- M[i] = users authorized for role i
- P[i] = privileges that are authorized for role i
- C[t] = mapping from tasks requiring separation of duty to sets of privileges required for those tasks



Degree of privilege sharing by mutually exclusive roles and other roles

• disjoint/disjoint (D/D) - if two roles are designated as mutually exclusive, then each privilege is assigned to only one of them
  • if a privilege has been assigned to a role that has been designated as mutually exclusive with another role, then it is not assigned to any other role
  • complete exclusion
    
• disjoint/shared (D/S)
  
• shared/disjoint (S/D)
  
• shared/shared (S/S) - privileges may be shared between roles that are mutually exclusive, but each must have at least one privilege not available to the other (to avoid redundancy?)
  
  • privilege assigned to mutually exclusive role with another role may be assigned to roles outside the mutual exclusion relationship
  • partial exclusion

Basic properties

• If authorization-time exclusion (static SoD) holds, then run-time exclusion (dynamic SoD is maintained.
• If complete exclusion holds, then partial exclusion is maintained.
• Mutually exclusive roles cannot be brought into the active set A.
• Two roles i and j can be mutually exclusive only if they are incomparable within the role hierarchy. (neither of them inherits the other directly or indirectly)
  • a role cannot inherit another role that has been designated as mutually exclusive with it
• A role cannot be mutually exclusive with itself.

Constraints introduced by mutual exclusion

• If there are any mutually exclusive roles, then those roles cannot have a common upper bound. (there is no role that inherits them both because that role would violate the mutual exclusion)
• Rules also prohibit the existence of a "superuser" or "root" role that contains all other roles on the system. (what does this say about the RBAC products that limit role hierarchy structure to a tree?)
• If roles i and j are mutually exclusive with each other, then either P[i] and P[j] are disjoint sets or else #P[i] >= 2 and #P[j] >= 2.
• if complete exclusion is in effect then they are disjoint
• if partial exclusion is in effect then they should have at least one privilege each not in common
  

Maintenance of safety condition

• If there are no empty privilege sets, then authorization-time/complete exclusion is sufficient to ensure the safety condition.
  • run-time/complete exclusion will ensure SoD safety within a single user session
• The safety condition can be met for a subject s only if (at least) partial exclusion is maintained. (necessary but not sufficient)
  

R. Sandhu, D. Ferraiolo, D. Kuhn. 2000. "The NIST Model for Role-Based Access Control: Towards A Unified Standard"

Flat RBAC
- user-role-permission
- many to many relationship for user-role and role-permission
- roles/users assigned to a specific user/role can be determined (user-role review)
- users can simultaneously exercise permissions of various roles
* does not exclude other means by which users can acquire permissions (direct assignment, security labels in lattice-based access control)
* does not rule out negative permissions that deny access
* concept of a session not explicitly part of flat RBAC



Hierarchical RBAC
- adds role hierarchies
- inheritance hierarchies - activation of a role implies activation of all junior roles
- activation hierarchies - junior roles need to be explicitly activated
- (can be both. activation hierarchy may extend the inheritance hierarchy or be separate and independent of it.)

General Hierarchical RBAC
- support for an arbitrary partial order to serve as the role hierarchy

Restricted Hierarchical RBAC
- some systems may impose restrictions on (structures of) the role hierarchy (limited to trees, inverted trees)



Constrained RBAC
- add separation of duties (SOD)
- static SOD - based on user-role assignment
- dynamic SOD - based on role activation



Symmetric RBAC
- adds permission-role review (similar to user-role review of Flat RBAC)

Requirements
1. must return complete set of (objects OR operation and object pairs) that are associated with the permissions assigned to a particular user or role
2. include the ability to selectively define direct and indirect permission assignment
3. include the ability to select the target systems for which the review will be conducted



Other RBAC attributes
Not included because not suitable for standardization, or lack of consensus to justify standardization.

1. Scalability
2. Authentication
3. Negative permissions
4. Nature of permissions - fine grained VS coarse grained; primitive operations VS abstract
5. Discretionary role activation
6. Role engineering - designing roles and assigning permissions and users to roles
7. Constraints - other forms of SOD (role-centric, permission-centric, user-centric)
   
   • obligation constraints - require something to happen, VS prohibition constraint (SOD)
8. RBAC administration
9. Role revocation - immediacy of revocation (instantly, allow user to finish, etc)