S. Oh, S. Park. 2002. "Task–role-based access control model"

Additional characteristics of enterprise environments:

• In the enterprise environment, business information has the characteristic of ‘information sharing’. This means that an information object is accessed by many work-related people, as business information is produced during business processes composed of many business activities.
• The enterprise environment changes rapidly, responding to changes in the business environment. Rapid change of environment leads to rapid change of access rights and information objects. It makes administration of access authorization very difficult.
• In the enterprise environment, the basis of authorization is job position and assigned tasks (job functions).
• Many business activities are connected with others in the enterprise environment. Thus, many constraints and business rules are related to access control. For example, specific customer order information may be updated when the goods of the customer order are not received. ‘Separation of duty’ (SOD) is an important security principle for business organizations.

Factors related to access control in the enterprise environment

• Users want to access some information resources for their business activities.
• The final goal of access control is to decide whether an access request from a specific user is valid or not.
• In general, users who belong to the organization structure in the company perform their assigned tasks (job functions) according to their job positions or business roles.
• Some tasks compose business processes, which have special access control requirements.

User

• The subjects of access control. In general, they are employees of a company.
• They execute their job function to achieve the company’s goal.
• They produce business information and this information is stored for future business activities. They may use information resources that were created by other employees.
  

Information resources

• The objects of access control, such as files, tables in a database, executable programs, etc. Information resources contain business information.
  

Organization

• A group of employees who form business activities together in order to achieve a particular aim.
• From the perspective of access control, an organization has two functions. One is grouping users, and the other is grouping tasks (job functions).

Job position and business role

• job position emphasizes management activities
• business role emphasizes business work activities
• In the access control’s point of view, users may have access rights for executing their job positions or business roles. In other words, job positions and business roles restrict the authority of users.
  

Task

• A fundamental unit of business work or business activity.
  
• Tasks are assigned to users by their job positions or business roles.
• In the access control’s point of view, users read or write information objects when executing their tasks.
• If we know a user’s assigned tasks, we can decide which access rights are assigned to the user. Therefore, the tasks of a user are the basis of access control.
• A task can be expressed as a pair, comprising information object and allowing access type.
  

Business process

• A set of some tasks that are connected to achieve a common goal, i.e. workflow.
• In general, it means a product or methodology for supporting business process in the enterprise environment.
• The tasks belonging to business process and the non-belonging tasks have different access control characteristics.
  • Non-belonging tasks can be executed any time if the task is assigned.
  • It means that authorization causes immediate activation of access right. (passive access control)
  • Belonging tasks should submit to a defined process order and available time period.
  • In this case, authorization is separated from activation of access rights. (active access control)

Business rule

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

Requirements of access control for the enterprise environment
Observations about enterprise environments

• Organizations, job positions, business roles, tasks, and business processes, are the main related factors of access control in the enterprise environment.
• The ancestor job positions or business roles inherit, through the hierarchy, some authorities of their descendant job positions or business roles. This means ‘partial’ inheritance of authorities. (Previous researches say ‘full’ inheritance of authorities from lower role to higher role.)
• There are several types of tasks in the enterprise organizations. They have different characteristics for access control, according to their class.
• Both active and passive accesses occur.

Security requirements for enterprise environments

1. General users cannot discretionary change security attributes, for example access rights, of information objects. Changing security attributes may induce an outflow of information. Only a security administrator can do it.
2. Access control model reflects organization structure and its characteristics of authority inheritance.
3. It should support full and partial authority inheritance on the organization structure.
4. It should support active and passive access control.
5. It should support general business rules includes of least privilege.
6. It should support different access control for several types of tasks.
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 access rights, and change of them should be easy.

Related works
RBAC disadvantages

• The basic RBAC model has a role hierarchy concept where a higher role inherits all access rights of a lower role in the role hierarchy, but in the real world, a person who has a higher job position or business role inherits partial access rights of a lower job position or business role, because full inheritance of access rights can violate the ‘need-to-do’ principle.
• RBAC does not consider workflow. Workflow needs a dynamic activation of access right and the specification of application level constraints. RBAC is one of the passive access control models, and it does not support active access control.
• RBAC does not separate ‘task’ from ‘role’. The task concept is implied, as the role concept and various types of tasks that have different characteristics of access control, are dealt with in the same manner.

ABAC (TBAC) disadvantages

• There exist many tasks that do not belong to the workflow in the company, and the ABAC model does not deal with them. Therefore, extra access control methods need to be added to the ABAC model.
• In the real world, a superior officer supervises and reviews the execution of tasks of his/her inferior clerks. This is important for security and integrity; however, the ABAC model does not take review and supervision into consideration.

T-RBAC
In the T–RBAC approach, the user has a relationship with permission through role and task.

Classification of tasks


Organization structure

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

Business process

• 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 according to their class.

The business rules have a relationship with task execution rather than task classification.



Class P (Private)

• The access rights for the tasks in the class P are not inherited to the ancestor job positions/business roles.
• They do not belong to a business process and are dominated by passive access control principles. Therefore, they have the characteristic of ‘private’.
• Analysis, planning, and decision-making are general examples of tasks belonging to class P.
  

Class S (Supervision)

• The access rights for the tasks in the class S are inherited to ancestor job positions/business roles.
• They do not belong to a business process and are dominated by passive access control principles.
• The tasks in class S are related to management or supervision. An employee as a manager has a duty of supervising his/her subordinate employees and approving some documents. In general, the access rights for the tasks related to supervision are inherited to ancestor job positions/business roles.
• Management or supervision activities occur in a single department of an enterprise organization without relationship with other departments. Therefore, they do not belong to a business process.
• 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 job positions or business roles.
• They belong to a business process and are dominated by active access control principles.
  
• Many tasks in the enterprise environment belong to class W because the tasks have a relationship with others in the business activities.
• One characteristic of tasks in class W is that the tasks require repeated execution. As a result, the information objects accessed by the tasks in class W have many instances, and a predefined identifier such as ‘customer order no.’ identifies each instance.
• The tasks in class W have several attributes such as activation condition, duration, and activation cardinality.
  • Activation condition is the condition so that a specific task may be activated.
  • Duration is the available time that an activated task can be performed.
  • Activation cardinality is the maximum number of activations of a specific task at the same time.

Class A (Approval for activity)

• Class A has characteristics of class S and class W. If a task belongs to class A, the access rights for the task are inherited to ancestor job positions/business roles in the role hierarchy and the task belongs to workflow.
• Most tasks of approvals in the workflow belong to class A.

Formal description of T-RBAC


Notation
USERS: a set of users
S-RH: supervision role hierarchy
ROLES: a set of roles

• Ri <>
• Ri <* Rj : Rj is direct or indirect parent role of Ri on S-RH

PERMS: a set of permissions
SESSIONS: a set of sessions
WFS: workflow schema
TASKS: a set of tasks

• Ti -> Tj : Ti is a direct prior task of Tj on WFS
• Ti ->* Tj : Ti is a direct or prior task of Tj on WFS

Permission-Task Assignment
Task-Role Assignment
User-Role Assignment
Task-Workflow Assignment

Role is the function/position that somebody has or is expected to have in an organization. An organization unit itself is a role.

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

Task is the minimal piece of work that somebody has to do, and it is expressed as a set of permissions.

Permission is defined as a pair of information objects and access mode.

Strict inheritance (S-RH(s)). If R1 is a higher role than R2 in a role hierarchy, R1 inherits only the tasks of R2 that belong to class S or class A.

Audit-oriented inheritance (S-RH(a))). If R1 is a higher role than 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.

Task attributes. If task Ti belongs to class W; Ti has three attributes. These attributes are inherited to new task instances when they are created in new workflow instances.

• Activation condition (AC): it is an activation condition of Ti: It is expressed as an AND/OR condition between prior tasks. For example, if AC = T2 and T3; Ti can be activated when prior tasks T2 and T3 are finished.
• Time constraint (TC): is the effective execution time of Ti : If the starting time of Ti is later than TC, Ti is automatically deactivated.
• Cardinality (CD): the maximum number of activated task instances for a specific task at the same time.

If T1, T2, ..., Tn are prior tasks of Ti, and Ti is activated now, T1, T2, ..., Tn are completed or activated.

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.

User can choose an active role through the session. The user can open one or more sessions.

Separation of Duty
Task schema level static SOD

• two different tasks are assigned to the same role
• the role is assigned to one user
• -> the tasks are not mutually exclusive

Task schema level dynamic SOD

• two different tasks are assigned to the same role
• the two tasks have been activated
• the role is assigned to one user
• -> the tasks are not mutually exclusive

Task instance level dynamic SOD

• two different tasks, but element of same instance of workflow oriented tasks, are assigned to the same role
• the two tasks have been activated
• the role is assigned to one user
• -> the tasks are not mutually exclusive

(Restriction of SOD). If both task Ti and Tj belong to class S or class A; static SOD policy cannot be applied to Ti and Tj.

Consistency principles for the T–RBAC system
(authors have designed guidelines that checks for consistency every time system state is to be changed. refer to paper for details.)




Discussion of some aspects of T–RBAC
Two main ideas in the T–RBAC model

• to use intermediate tasks between access rights and roles instead of assigning access rights to roles
  • allows the roles to be linked to access rights through the intermediate tasks
  • it makes the point that RBAC could be integrated into the ABAC model
• the classification of enterprise tasks (job function of contacts) according to their characteristics

• Tasks that belong to class S or class A are inheritable and their access rights are inherited to higher roles in the role hierarchy.
• Tasks that belong to class P are private and are not inherited to higher roles.
• Tasks that belong to class W or class A follow active security policy and they are managed by the workflow mechanism.

Are the tasks classified into only four classes?
The fundamental point of task 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 can classify the tasks into five or more classes for access control.



Comparison of access control models


*partial inheritance can be expressed by the private role concept - so how is this an advantage over RBAC?

*auditing of task execution - If a new task is inserted to a role Rn; the senior roles of Rn automatically receive auditing authority for the new task, which does not lead to any side effects.

M. Al-Kahtani, R. Sandhu. 2003. "Induced Role Hierarchies with Attribute-Based RBAC"

Rule-Based RBAC or RB-RBAC

These rules take into account:

• The attributes of the client that are expressed using attributes’ expressions as defined by the language provided by the model.
• Any constraints on using roles.

*double arrows mean many-to-many relation


Two different ways to assign users to roles:

• Implicit user-role assignment: In this mode, no human intervention is allowed and RB-RBAC automatically triggers authorization rules to assign users to roles.
• A hybrid of implicit and explicit user-role assignment: Users are assigned to roles either implicitly by invoking the appropriate authorization rules, or explicitly by security administrator(s).
  

Seniority among authorization rules:
Satisfying an attribute pair that has high seniority level implies satisfying all the ones that have lower seniority levels.


Example 1:


We define the dominance binary relation Ð on Attribute_Expressions such that:

Ð = {( AEi, AEj) | AEi → AEj is true}

Where both AEi and AEj belong to Attribute_Expressions and “→” represents logical implication. We write (AEi, AEj) ∈ Ð which means that AEi dominates AEj.

Another way of stating the above relation between AEi and AEj is to say that Rulei is senior to Rulej (denoted by ≥):

Rulei ≥ Rulej ⇔ (AEi, AEj) ∈ Ð.

If Rulei ≥ Rulej, then this implies that users who satisfy the attribute expression of rule Rulei also satisfy Rulej and are entitled to the roles produced by Rulej.


Example 2:




One can argue that attribute expressions 2 and 3 are logically equivalent and should be consolidated in one equivalent class. In other words, one of these attributes expressions, say AE3 should be deleted. The impact of this will be discussed later.



Induced roles hierarchy
It could be argued that the most crucial step in utilizing RB-RBAC model is specifying the authorization rules.

A starting policy document is expected to list a set of flat roles the permissions of which may not be disclosed for a two-fold reason:

• Knowing the exact permissions of each role is not needed to specifying authorization rules.
• The enterprise may want to hide the details of the permissions and their level of granularity.

As a by-product of specifying the authorization rules, an induced hierarchy among the roles is generated if the authorization rules hold seniority relations among them.

In order to assemble induced role hierarchy (IRH), we define dominance binary relation R on Roles such that:

R = {(ri,rj) | (∃ Rulei) (∃Rulej) [AEi → ri Λ AEj → rj Λ (AEi, AEj) ∈ Ð]}

such that (ri,rj) ∈ R means that ri is senior to rj in IRH. The IRH does not necessarily reflect the lines of responsibilities and authority as viewed by the enterprise.



In figure 4 (a) and (b), we maintain roles r2 and r3 as separate entities.

• However, the authorization rules set that produces figure 4 (a) will have 2 authorizations rules with identical attribute expressions such that one of these rules yields r2 while the other yields r3.
• On the other hand, the authorization rules set that corresponds to figure 4 (b) will have one rule that produces r2 and r3 simultaneously.
• From a functional standpoint, the two figures are identical.

Figure 4 (c) shows the case in which r2 and r3 are collapsed into one role (r6).

• From a functional perspective, this indicates that r6 is given the permissions of r2 and r3.
• From IRH standpoint, r6 is given the user assigned to r2 and r3.
• Nonetheless, collapsing roles is not always a prudent course of action.
  • When roles have different natures such as a striker and a defender in a video game. Combining these roles yields a role that is meaningless in this context.
  • When the new role has so much permissions, the corresponding workload of which cannot be shouldered by a single user.
  • When combining roles results in a violation of the principle of separation of duties. An example for this is the roles of programmer and tester. A user can be assigned to the programmer role. Alternatively, he may choose the tester role. If these two roles where combined, this dynamic separation will be violated.

In many situations, security officers come across a hierarchy that is not derived from the authorization rules. An example of such given roles hierarchy (GRH) is the one that reflects the current business practice of the enterprise.



Possible discrepancies between IRH and GRH
Two types of inheritance:

• User-role assignment inheritance, which flows from senior roles to their junior roles.
• Permission-role inheritance, which flows in the opposite direction.

Missing leaf node
Node r7 is missing in IRH, which means that no authorization rule assigns users to that role. But since the permissions of r7 are inherited by r2 and r3, both are captured in IRH, this scenario neither poses a threat to the system’s security, nor does it reduce its functionality.

To reconcile the two hierarchies, r7 is deleted from GRH and its permissions is added to its immediate ancestor(s).

If none of r7 ancestors in GRH belongs to IRH, then one of the following is true:

• The security policy, which was used to derive IRH, has overlooked parts of the business practice of the enterprise and, hence, some functionality is missing. In this case, the policy needs to be modified such that an authorization rule will assign users to the missed role.
• The business practice followed by the enterprise has created unnecessary roles to which no users are to be assigned. These roles have to be deleted from the GRH.

Missing non-leaf and non-root node
r3 is missing in the IRH part. This could result from the enterprise recognizing r3 as a semantic construct that groups several permissions, but not seeing any need for assigning users to it. From a functionality standpoint, no harm is done so long as at least one of r3 senior roles is part of IRH.

This discrepancy could be reconciled by removing r3 from GRH and assigning its permissions to its immediate senior role(s). If none of r3 ancestors in GRH belongs to IRH, then we are faced with a situation similar to the one discussed in the case above.


Missing stand-alone node
r4 in GRH represents this case. It entails harm only if the following holds:

(∀ri ∈ GRH, r4 permission set - ∪(ri permission set) ≠ φ

If the above formula holds, then some permissions of r4 can never be used. This indicates a flaw in either the security policy, or the business practice of the enterprise.


Missing root node
Assuming that node r1 in IRH is missing. This results in a loss of functionality since no user can be assigned to r1 and uses its permissions. In this case, the policy has to be modified.


Additional leaf node
Node r8 is an example of this case. To reconcile the hierarchies, r8 must be removed and the security policy must be modified such that the authorization rule(s), which produces r8, must be altered so that it does not yield this problematic role.

Alternatively, the current business practice has to be revised to incorporate r8 into GRH with the appropriate permissions.


Additional non-leaf and non-root node
r10 exists in the IRH but not in GRH.

If r10 has a single child, which belongs to GRH, then one can assume that r10 permissions set is identical to that of its child.

• However, the set of users assigned to r10 is a subset of its child’s users set.
• From a functional standpoint, r10 is redundant to its child, r5 in this case, because its users will be confined to the permissions associated with r5.

Role r10 should be removed from IRH and the authorization rules should be modified so they yield r5 instead of r10.

Alternatively, r10 can be added to GRH with permission set such that:

r5 permission set ⊂ r10 permission set ⊂ r2 permission set

However, if r10 has more than one child, which are nodes in GRH, then r10 can be added to GRH such that:

r10 permission set = ∪ ri permission set

where ri ∈ GRH Λ r10 ≥ ri


Additional stand-alone node
This role has no functional purpose and, thus, has to be discarded. An example for this is r9. The security policy should be modified to reflect this.


Additional root node
Assume there is a role in IRH that is senior to r1, say rroot, then we have 2 possibilities:

If r1 is the only child, then r1_permission_set = rroot_permission_set which results in functional redundancy. This can be solved by removing rroot from IRH.

If rroot has more than one child that belong to GRH, then:

rroot_permission_set = ∪ ri_permission_set

where: ri is the immediate child of rroot. GRH may be modified to adopt rroot.


Missing edges
There is an edge between r1 and r11 in GRH. However, the security policy does not recognize that and, therefore, no user-role inheritance exists between them.

The users assigned to r1 are capable of utilizing the permissions attached to r11 since they are a subset of r1 permissions even if IRH fails to reveal this hidden relation. This can be eliminated by modifying the policy so that the authorization rule that generates r1 becomes senior to the one that yields r11.


Additional edges
IRH has the edge that links r1 and r12, which GRH does not recognize.

From functional stance, this should not be a problem since it is acceptable to assign a user to roles that are not functionally related. To reconcile the two hierarchies, the permissions set of r1 need to be modified to include that of r12, which results in introducing an edge between the two roles in GRH.


Inconsistency


Part (a) of the figure suggests that since r2 is senior to r3, all users in r2 will be able to exercise the permissions of r3 in addition to those of r2. Accordingly, one can assume that r3 permissions set is included in r2.

However, part (b) shows that r2 permissions set is a subset of r3 permissions set, which indicates that any user assigned to r3 should be able to use the permissions assigned to r2. This result contradicts the one derived from part (a).

Either the policy or the role-permission assignment has to be modified.

K. Irwin, T. Yu, W. Winsborough. 2008. "Enforcing Security Properties in Task-based Systems"

In this paper, we introduce the concept of tasks into access control, and use tasks as a central and explicit means to constraining privileges of users.


Advantages

1. Tasks are a natural way to think about user actions and their contexts.
2. Many privacy policies require identifying the purposes of actions. It is much easier to categorize the purpose of a task than that of an individual action.

Given an assignment of privileges to tasks and tasks to users, and a high level security property, there are two questions which should be examined.

1. Whether it is possible for a user to abuse the granted privileges and violate a high-level security property. If the answer is no, the system simply needs to check a user’s privileges when she attempts an action. Otherwise, the system has to keep track of the operations that a principal has conducted thus far, and dynamically enforce the high-level security properties.
2. How to reduce the complexity of the dynamic enforcement of a security property.

Two types of security properties

• Intra-task properties proscribe action sequences that must not be performed by using the privileges granted for a single task.
• Inter-task properties must not be violated by using privileges obtained from any assigned tasks.

Access control policy level

• access control policies concern when and under what circumstances privileges may be granted to or revoked from principals
• distinguished from the current access control state which indicates what privileges each user holds at present
  • access control state may change as part of the normal operation of a system, as long as the change is allowed by the system’s access control policy

Ways to enforce security property

1. design an access control policy that ensures no user will ever obtain privileges that enable her to violate that security property.
   • For example, consider a security property that states Alice should never be allowed to perform action a. To enforce it at the access control-policy level, we need to show that, from an initial state, no matter how the access control state changes, as long as each change conforms to the policy, Alice will never get the privilege to perform a.
   • advantage of this approach is that the runtime execution of the system is quite simple.
   • however, the problem to determine whether an access control policy enforces a security property can be challenging
2. design policies conservatively so they are clearly sufficient to enforce security properties
   • this approach often force policies to be too conservative to be useful

Access control state level

• a system’s access control state describes the privileges each user has at a given time

Ways to enforce security property

1. when an action is performed that would change the privileges of a user (especially when new privileges are about to be granted), the reference monitor could first determine whether the new access control state would enable the user to perform actions that violate security properties. If so, the attempt to change the privileges can be denied even if it would have otherwise been allowed by the access control policy.

Action-execution level
Ways to enforce security property

1. monitor what actions are actually performed. A user’s action request will be denied if the action, taken in the context of the user’s previous actions, would violate a security property.
• When the manager attempts to submit a reimbursement request, the system allows it to be executed, but also records the action. If the manager later attempts to approve the same reimbursement, because the system records the prior action, it would determine that the approval would violate the security property, and rejects it.
• offers the maximum flexibility in terms of how users may fulfill their tasks
• the history information for each user might be quite large
• execution-level enforcement has to perform analysis every time a user attempts to take an action

In practice, it would be desirable to combine the above three types of enforcement mechanisms to secure an information system.



Task-based system

• U: a set of users.
• K: a set of tasks which users may carry on.
• A: a set of actions that can be taken by users.
• t: a clock t, which we represent as a real number.
  • At any time an action is attempted, the clock will have some value in the domain T = R+, with 0 indicating the system start time.
  • We assume that any two action attempts can be ordered. This can either be accomplished by assuming that no two action attempts happen at precisely the same time or by assuming that there is an ordering on the actions such that if two are attempted at precisely the same time, then they are still processed sequentially.
    
  • Although the set of reals is uncountable, we will only be dealing with a finite subset in practice since only time points at which actions occur or permissions change are relevant.
• P = A×T ×T : a set of privileges.
  • Each privilege (a, s, e) element_of P identifies a time window during which the permission for action a is available. That is to say, if s <>
  • We require s < style="font-style: italic;">element_of P.
• F: a privilege-granting function which takes as input a task k and a time point t, and returns a set of privileges.
  • A privilege granting function abstracts the access control policy of a system. It is intended to be flexible in several respects so that it can represent various policies for granting privileges to users.
  • First, the returned privileges of a privilege granting function are not restricted to a single user. This enables the modeling of privilege assignments for collaborative tasks.
  • Second, the returned privileges are not required to have the same time period. In other words, it is possible for a system to require that one privilege is used before another one.
  • Third, we allow different privileges to be returned if the same task is assigned at different times. This gives a system the flexibility to decide the necessary privileges for a task by considering the current state of a system.
  • Observe that if two privileges are about the same permission and their time periods overlap, we can always merge them into a single privilege by merging their time periods. Clearly, this will neither increase nor decrease what the user can do.

The access control state of a system is a subset of U × K × P. It contains one entry for each permission granted to each user and for each task assigned to the user that requires the permission. In other words, if a given user has a given permission that she needs for each of two tasks, there will be two entries in the access control state, one for each task.



Security properties
Most practical security properties should be amenable to modeling as a finite state automaton to be effectively enforced in an information system.

In our model, undesirable sequences of user actions and times are those that are accepted by the automaton, which are said to violate the modeled security property.

If an action sequence q violates a security property, all the sequences that have q as a prefix also violate that property.

NFA examples
It is a security violation if a summer intern modifies the database of a company.


The clerk initiating a legal draft should not be the principal who decides whether reviews
by stakeholders are required.



In order to use a company fax machine, an employee is required to log his usage first, e.g., where the fax is sent to and with how many pages. In other words, it is a violation of the company’s policy to send a fax unless it is logged, which is a compensatory action.

A computer system has a temporary directory used as a scratch space. To prevent information leakage, if a user queries a sensitive database and then writes to the temporary directory, then she must not copy anything from the temporary directory to a public ftp server, unless the system first empties the temporary directory.



We focus on enforcing a security property of the behavior of a single user. (when considering collusion among multiple users, the problem becomes intractable)



Enforcing intra-task property
Access state level enforcement
Given a user’s access state, whether it is possible for her to violate a security property.

• If the answer is that she cannot violate the property, then we only need enforce access control according to the user’s access state (i.e., whether she has a permission at the current time), and need not maintain any further information to check for violation of intra-task properties.

Let P be a user’s privileges obtained from a task k, and H be a intra-task property. If no action sequences compatible with P violates H, we say P enforces H.

• Basically, we convert P to a finite state machine M which accepts exactly those sequences compatible with P. P enforces H if and only if the intersection ofM andH is empty, which can be efficiently checked.

With system compensatory actions





Given a set of users along with their privileges and a security property H, do there exist fewer than k users whose privileges put together enable those users to violate H? NP complete in general


Reduce privileges to enforce property
Reducing a user’s privilege risks the possibility that we could prevent the user from carrying out legitimate actions which are needed to complete the task.
As such, if we are to change the access state, we must logically do it in a minimal way to reduce its impact on task fulfillment.

The problem to minimize the reduction of a user’s privileges to enforce a security property is intractable.


Action execution level enforcement
Conceptually, given an NFA H that defines a security property, the system maintains the set of states that a user is in.

• Whenever a user submits a request to take an action at time t, the system would first check whether the user has the right permission at t.
• If she does, the system would further consult H and determine, if the action is taken, what states the user would be in, and whether those states include a final state.

It would be expensive to consult the NFA, especially when we have to do so to handle every action request.

For a user with a particular set of privileges, however, very often only a small portion of the NFA is relevant. Not only some of the states in the NFA cannot be reached by the user, even for those that can be reached, they may not lead to the final state as the user may not possess necessary privileges anyway. By not keeping track of these irrelevant states, a system would be able to reduce the cost of dynamic enforcement.

(authors develop an algorithm to develop "personalised" NFAs)



Enforcing inter-task property
Action execution level enforcement
Enforcing inter-task properties requires recording a user’s actions.

• However, keeping record of their actions does not necessarily imply dynamically monitoring those actions at all times. If it is known that a user cannot violate a security property using their current privileges, then we do not need to actively monitor for security property violations, but instead we can simply keep a log of actions.

Use an intersection of finite state machines as in enforcing intra-task property.

• However, the NFA modeling the possible actions that a user can take should begin with a string of transitions that represent the actions that the user has already taken so far.
• That is, rather than have a set of states representing different time segments where the transitions model what actions the user is allowed to take, for time segments prior to the current time, only the transitions representing the actions which the user actually took should remain.

Task assignment
In many systems, tasks will arise in response to dynamic events.

• either users may observe events and initiate tasks in response to them
• or the system may observe events and have a means of assigning tasks to users

We can solve this question for inter-task properties by applying the same technique we just used.

• We simply add the permissions of the new task starting at the current time to the set of permissions that we are modeling before we take the intersection.
• If the intersection is empty, then the new task can safely be given to the user.
• If we cannot guarantee that a task can safely be given to a user, we can either give it to another user or dynamically monitor this user’s actions to ensure the high-level security properties are not violated.

J. Park, R. Sandhu, G.-J. Ahn. 2001. "Role-Based Access Control on the Web"

User-pull architecture


user-pull-host-based mode

• the user needs to download her roles from the role server and store them in her machine (which has her host-based authentication information, such as IP numbers)
• later, when Alice wants to access the Web server, which requires proper authentication information and roles, her machine presents that information to the Web server
• after client authentication and role verification, the Web server uses the roles for RBAC
• since this mode is host-based, it cannot support high user mobility
  

user-pull-user-based mode

• the user can download her roles to her current machine from the role server
• then, she presents those roles to the Web server along with her user-based authentication information, such as her passwords
• after user authentication and role verification, the Web server uses the roles for RBAC
• in this mode, the user can use any machine that supports HTTP, as long as she has the right user-based authentication information (e.g., passwords)

Server-pull architecture


server-pull-host-based mode

• she presents host-based authentication information (e.g., IP numbers) to the Web server
• the role-obtaining mechanism is transparent to the user, while limiting user portability
• after user authentication, the Web server downloads the user’s roles from the role server and uses them for RBAC
  

server-pull-user-based mode

• Alice presents user-based authentication information (e.g., passwords) to the Web server
• this supports high user portability, while it requires the user’s cooperation (e.g., typing in passwords)
• after user authentication, the Web server downloads the user’s roles from the role server and uses them for RBAC

Secure cookies
Authentication services verify the owner of the cookies.
Integrity services protect cookies against the threat that their contents might be changed by unauthorized modification.
Finally, confidentiality services protect cookies against having their values revealed to an unauthorized entity.

Common fields for cookies

• Cookie_Name and Cookie_Value contain information a Web site would want to keep. For example, in the figure, the values of Name_Cookie and Role_Cookie are “Alice” and “Manager,” respectively.
• Date is the cookie’s valid lifetime.
• Domain is a host or domain name where the cookie is valid.
• Flag specifies whether or not all machines within a given domain can access the cookie’s information.
• Path restricts cookie usage within a site (only pages in the path can read the cookie).
• If the Secure flag is on, the cookie will be transmitted over secure communications channels only, such as SSL.

According to the current HTTP state management mechanism, whenever a browser requests a URL to a Web server, it sends only the relevant Cookie_Name and Cookie_Value fields (selected by the Domain and Flag fields) to the server.
The cookie issuer is not important for validation; any Web server can issue cookies for other Web servers.

Security threats to typical cookies

• network security threats - cookies transmitted in clear text on the network are susceptible to snooping (for subsequent replay) and to modification
• end-system threats - Once the cookie is in the browser’s end system, it resides on the hard disk or memory in clear text. It is trivial to alter such cookies, and they are easily copied from one computer to another, with or without the connivance of the user on whose machine the cookies were originally stored.
• cookie-harvesting threat - an attacker collects cookies by impersonating a site that accepts cookies from the users (who believe that they are communicating with a legitimate Web server) and later using those harvested cookies for all other sites that accept them

• Name_Cookie contains the user’s name (e.g., Alice)
• Role_Cookie holds the user’s role information (e.g., Manager)
• Life_Cookie is used to hold the lifetime of the secure-cookie set in its Cookie_Value field and enables the Web server to check the integrity of the lifetime of the secure-cookie set
• IP_Cookie holds the IP number of the user’s machine
• Pswd_Cookie holds the user’s encrypted passwords
• Seal_Cookie has the digital signature or MAC (Message Authentication Code of the cookie-issuing server on the secure cookie set and protects cookies against the threat that their contents might be changed by unauthorized modification

RBAC implementation




Using secure cookies

1. She first connects to the role server in the beginning of the session.
2. After the role server authenticates Alice, it finds Alice’s explicitly assigned roles in the URA database and creates a set of secure cookies. Those secure cookies are then sent to and stored securely in Alice’s hard drive, so that Alice does not need to go back to the role server to get her assigned roles until the cookies expire.
3. When Alice requests access to a Web server—which has PRA information—by typing the server URL in her browser, the browser sends the corresponding set of secure cookies to the Web server.
4. The Web server authenticates the owner of the cookies by using the authentication cookies, such as IP_Cookie and Pswd_Cookie, comparing the values in the cookies with the values from the user.
5. Finally, the Web server checks the integrity of the cookies by verifying the role server’s digital signature in the Seal_Cookie using the role server’s public key.
6. If all the cookies are valid and successfully verified, the Web server trusts the role information in the Role_Cookie and uses it for RBAC with role hierarchy and permission-role assignment information in the Web server.

Creating secure cookies

1. When a user connects to the role server, she is prompted by the HTML form to type in her user ID and passwords for the domain. The “set-cookie.cgi” program authenticates the user by comparing the user ID and passwords with the ones in the authentication database. It then assigns the user to roles by matching the user ID and the corresponding roles from the URA (user-role assignment) database.
2. Subsequently, a subroutine for encryption is called to another CGI program (encrypt.cgi), which uses PGP to encrypt the passwords by the cookie-verifying Web server’s public key. These encrypted passwords will be stored in the Pswd_Cookie by the “set-cookie.cgi” program.
3. The “setcookie.cgi” program then creates IP_Cookie, Pswd_Cookie, Name_Cookie, Life_Cookie, and Role_Cookie.
4. To support the cookies’ integrity service, the “set-cookie.cgi” program calls another CGI program (sign.cgi), which uses PGP to sign the cookies with the role server’s private key.
   
5. The “set-cookie.cgi” then creates the Seal_Cookie, which includes the digital signature of the role server on the contents of the cookies.
6. Finally, the role server sends the HTTP response header, along with the set of secure cookies, back to the user’s browser, where the cookies are then stored until they expire.

Secure cookie verification

1. The two IP addresses, one from the IP cookie and the other from the environment variable, REMOTE_ADDR, are compared. If they are identical, then the host-based authentication is passed and a hidden field “status” with the “IP-passed” value is created to indicate that this stage was passed.
2. The first thing the “password-ver.cgi” does is to check the hidden field “status” to see if the previous stage was successfully completed. If this is “IP-passed,” the program decrypts the value of the Pswd_Cookie (encrypted user password) using the PGP with the Web server’s private key. The program then compares the password from the user and the one decrypted from the Pswd_Cookie. If they are identical, then the user-based authentication is passed, and a hidden field “status” with the value of “password-passed” is created to indicate that this stage was passed.
3. If the value is “password-passed,” then the program verifies the signature in the Seal_Cookie with the role server’s public key using PGP. If the integrity is verified, it means that the cookies have not been altered, and a hidden field “status” with the value “verify-passed” is created to indicate that this stage was passed and forwarded to the final program, “rbac.cgi.” This program uses the role information in the Role_Cookie for RBAC in the Web server.

Smart certificates
Public-key certificate (X.509)
A public-key certificate is digitally signed by a certificate authority (CA) to confirm that the identity or other information in the certificate belongs to the holder (subject) of the corresponding private key.

An X.509 certificate consists of the following:

• version of a certificate format
• certificate serial number
• subject’s X.500 name (assigned by a naming authority)
• subject’s public key and algorithm information
• validity period (beginning and end dates)
• issuer’s X.500 name (certificate authority)
• optional fields to provide unique identifiers for subject and issuer (Version 2)
• extensions (Version 3)
• digital signature of the certificate authority

Attribute certificate

• An attribute certificate binds attribute information to the certificate’s subject.
• Anyone can define and register attribute types and use them for his or her purposes.
• The certificate is digitally signed and issued by an attribute authority. Furthermore, an attribute certificate is managed in the same way as an X.509 certificate.
• However, an attribute certificate does not contain a public key. Therefore, an attribute certificate needs to be used in conjunction with authentication services, such as another certificate (X.509) and SSL, to verify the subject of the attribute.

Smart certificate overview


It is technically possible for certificate authorities to simply issue a certificate that includes the subject’s identity (e.g., public-key information) and attributes (e.g., roles) in the same certificate.

• However, the lifetime of the identity (public key) in the certificate may be different from that of other attributes (roles) in it.
• Furthermore, an organizational policy usually requires different authorities for maintaining attributes and public keys.

Smart certificate solution:

• After a public-key authority (basic CA) issues an X.509 basic certificate for a user, Alice, an attribute authority (for instance, Att_1_CA) adds attributes for Alice to an extension field of the basic certificate (which contains public-key information).
• Consequently, the attribute authority (Att_1_CA) signs on the basic certificate and the attributes the authority added and puts the signature to another extension field in the basic certificate.
• This can happen multiple times on a basic certificate by different attribute authorities.
  
• Later, another party, say Bob, verifies Alice’s identity first by the basic CA’s signature in the smart certificate. If the authentication is successful, Bob verifies Alice’s attributes by the corresponding attribute authority’s signature in the extension field.
• The contents of the attribute information in a smart certificate depend on applications.
• The public key and the attributes can be maintained independently. For instance, even though Alice’s attributes issued by her school-attribute authority expired (were revoked) in the certificate, the rest of the attributes, such as those issued by her company-attribute authority and public-key information in her basic certificate, are still valid.

Using smart certificates

1. She first connects to the role server at the beginning of the session.
2. After the role server authenticates Alice, it finds her explicitly assigned roles in the URA (user-role assignment) database and creates a smart certificate (which holds her explicitly assigned roles).
3. Then, the smart certificate is sent to and stored in Alice’s machine—which has Alice’s private key corresponding to the smart certificate—so that Alice does not need to go back to the role server to obtain her assigned roles until the certificate expires.
4. In this particular implementation, we used the OU (organization unit) field in X.509 certificates to store each subject’s role information, and both identity and roles are signed by a single certificate authority. (other implementations may be done)
   
5. When Alice requests access to a Web server, the browser and Web server authenticate each other over SSL.
6. After the browser receives and verifies the server’s X.509 certificate, Alice needs to select a proper smart certificate—which has her role information—and send it to the Web server.
   
7. The Web server authenticates Alice by verifying the smart certificate. If the smart certificate is valid and successfully verified, the Web server trusts the role information in the certificate and uses it for RBAC with a role hierarchy and PRA information in the Web server.

• one role for every member in team (project_lead1 for team 1, project_lead2 for team 2, etc)
• inelegant, inefficient

LDAP


Using LDAP

1. A client presents her authentication information to a Web server.
2. The Web server authenticates the user using a proper authentication mechanism.
3. Once a user is successfully authenticated by the Web server (otherwise the user gets an error message), the Web server triggers the CGI (common gateway interface) scripts that call the LDAP client software.
4. The LDAP software sends a search query to the LDAP server, which retrieves the user’s roles from the directory server through SSL. The retrieved roles are sent back to the LDAP client in the Web server during the same SSL session.
5. When the user requests an access to the resources that require particular roles to be accessed, the Web server compares the user’s roles (which it pulled from the role server) with the ones in its PRA table.
6. If the user has corresponding roles in the table, the Web server allows the user to access the resources.

(what is the advantage of using LDAP over a simple roles server, querying a database for instance?)



Comparison of user-pull and server pull architectures


user-pull

• enhances Web server performance
• once the user obtains her roles, she can use them in many different sessions, and even in different Web servers, until the roles expire; this increases reusability
• requires a user’s cooperation to obtain her roles
• the longevity of the roles decreases their freshness; if the user already pulled her roles, the updated version in the role server would not become effective instantly.
  • Consequently, an additional synchronization process is required. Hence the role server should push the status change in user roles, such as role revocation, to the Web server for updated information.
• user-pull architecture is a good solution for applications where the users’ convenience is required for maintaining and using their roles frequently in diverse Web sites
  

server-pull

• requires the Web server’s cooperation for obtaining the user’s role information from the role server
• In this architecture, the Web server retrieves the user’s role information from the role server for each session. This increases the freshness of the roles, so the information update (e.g., role revocation) is more efficient than user-pull architecture
• decreases reusability and increases the single-point failure vulnerability
• server-pull architecture is a good solution for applications where dynamic role update is critical

Related work
getAccess

• released by enCommerce
  
• uses encrypted cookies, but there is substantial difference between this and secure cookies
• their encrypted cookies are not stored in the user’s machine after the session
• in other words, if a session is ended by closing the browser, the encrypted cookies disappear
• this means that whenever a user, Alice, needs to connect to a Web server with her roles, she must connect to the registry server through the access server first

TrustedWeb

• released by Siemens Nixdorf
• combines elements from both Siemen’s SESAME and Kerberos
• provides a single list of users on its central domain security server and assigns roles to the users
• however, to use TrustedWeb, the client’s browser needs specific software installed in the client’s machine to communicate with the TrustedWeb servers in the Intranet
  

C. Georgiadis, I. Mavridis, G. Pangalos, R. Thomas. 2001. "Flexible Team-Based Access Control Using Contexts"

In this paper, we extend the original TMAC proposal in two key directions.

1. First, we give a framework to integrate TMAC concepts with RBAC.
2. Second, we extend TMAC to use general contextual information. Such contextual information can among others include the time of access, the location from which access is requested, the location where the object to be accessed resides, transaction-specific values that dictate special access policies etc.

This generalized model is referred to in the rest of the paper as C-TMAC (for context-based TMAC).



C-TMAC model

• A user (U) is simply a person.
• A role (R) is a job function within the organization.
• Permissions (P) are approvals of a particular mode of access to one or more data objects.
• User assignment (URS) and permission assignment (PRS) are both many-to-many relations.
• An important property of a session (S) is that the user associated with a session cannot change. The association remains constant for the life of a session. The permissions available to the user are the union of permissions from all roles activated in that session. In addition, active roles in a session can be changed at the user’s discretion.
• In context (C) is included information regarding the required data objects for a specific activity, as well as contextual information such as locations and time intervals etc.
• The team (T) entity is used to represent a group of users having specific roles with the objective of completing a specific activity in a particular context.
• The team concept is used also as a mechanism that associates users with contexts. The use of a team as an intermediary to enable a user to obtain a context is similar to the use of roles as an intermediary between users and permissions.
• Even when a user is acting alone, we may consider the user as the only member of a private team.
• During a session, a user can participate in a number of teams. So, each session is also a mapping of one user to a subset of teams that he is a member of.
• The contexts available to the user are the union of contexts from all teams that he participates in.
• Active teams in a session can be changed at the user’s discretion, just like his active roles.
• A team can also be seen as a mapping to multiple users. The roles activated by these users identify the permission set available to the team as the combination of permissions from all roles participating in that team.
• Context assignment (CTS) and team assignment (UTS) are both many-to-many relations.
  • However, there are constraints when assigning user to teams, e.g. a user that has been assigned the roles Physician and Director cannot participate in a care-team as a Director.

C-TMAC formal description

• U, R, P, S, T, C, stand for users, roles, permissions, sessions, teams and contexts, respectively
• PRS ⊆ P x R, is a many-to-many permission to role assignment relation
• URS ⊆ U x R, is a many-to-many user to role assignment relation
• CTS ⊆ C x T, is a many-to-many context to team assignment relation
• UTS ⊆ U x T, is a many-to-many user to team assignment relation
• session-user : S → U, is a function mapping each session s_i to the single user user(s_i) that is constant for the session’s lifetime
• session-roles : S → 2^R, is a function mapping each session s_i to a set of roles roles(s_i) ⊆ {r | (user(s_i), r) ∈ URS}, which can change with time, and session s_i has the permissions ∪nion_of r ∈roles(s_i) {p | (p, r) ∈ PRS} referred to as Session-Roles Permissions
• session-teams : S → 2^T, is a function mapping each session s_i to a set of teams teams(s_i) ⊆ {t | (user(s_i), t) ∈ UTS}, which can change with time, and session s_i has the contexts ∪nion_of t ∈ teams(s_i) {c | (c, t) ∈ CTS} referred to as Team-Context
• team-users : T → 2^U, is a function mapping each team t_i to a set of users users(t_i) ⊆ {u | (u, t_i) ∈ UTS} ∧ ∃ s_j : user(s_j) = u}, which can change with time
• team-roles : T → 2^R, is a function mapping each team t_i to a set of roles roles(t_i) ⊆ {r | (users(t_i), r) ∈ URS}, which can change with time, and team t_i has the permissions ⊕ r ∈ roles(t_i) {p | (p, r) ∈ PRS}, referred to as Team-Roles Permissions, and where ⊕ means “combination”

Different meanings of ⊕ (choose one):

• Aggregation: The set of access permissions of the team is the sum-up (union) of the individual assigned role-based access permissions of all team members.
• Maximum/Minimum: The set of access permissions is considered to be equal to the maximum or minimum permissions sets of the individual members of the team.
• Current team structure: The structure (formation) of the team is used to determine the credentials held by the team members. According to a team template, a certain number of members of the team is required. Individual users are not permitted to perform actions on their own but only in the presence of the remainder participants of the team.

Activation of final user permissions

1. Considering a user who has activated a subset of roles and participates in a subset of teams, initially the role-based permissions of this user are derived with the following definition, where the symbol ⊕ stands for “combined with”:
   • Role-based Permissions = Session-Roles Permissions ⊕ Team-Roles Permissions
2. Step 2: The final permissions activated are the context-based permissions, which are derived from role-based permissions (step 1) with the following definition, where x means “filtered by”:
   • Context-based Permissions = Role-based Permissions x Team-Context

C-TMAC example
Tasks in healthcare environments could be defined at runtime (dynamically) on the basis of the following contextual variables:

• patient: a user (doctor, nurse) gains additional permissions for a specific patient he is in care of.
• location: the collaborative activity depends on the specific area wherein the users (members) of a particular team are working
• time: all permissions are valid during a certain time (periodic) interval

A backend relational database management system is used.

• objects of protection are relations, tuples, attributes and views using modes of access operations such as SELECT, INSERT, DELETE and UPDATE
• permissions of users can be defined as data views (e.g. by using the SELECT statement of the Structured Query Language - SQL)

Assume the presence of the following table in the medical database: PATIENTS (PatientID, field1, field2, field3, field4, field5).

For roles Doctor, Head Nurse and Nurse, the sets of role permissions for this table, with view-based protection expressed in SQL form, are as follows:

• Permissions (Doctor): SELECT field1, field2, field3 FROM PATIENTS
• Permissions (Head Nurse): SELECT field1, field3, field4 FROM PATIENTS
• Permissions (Nurse): SELECT field1, field4 FROM PATIENTS

Assume an Emergency Room care-team.

Assume that context parameters for clinical tasks are:

• patientids
• current time
• current location of the users

Possible locations of users could be:

• ER-1 - emergency room 1
• ER-3 - emergency room 3
• GW-2 - general ward

The context assigned to the ER-Team could be as follows:

• Context (ER-Team):
• SetOfPatients: (200, 351, 402, 667)
• TimeZone: [10:00;12:00]
• SetOfLocations: (ER-1, ER-3, GW-2)

Assume that users Mary and Helen have already started their sessions s1 and s2 and activated their roles HeadNurse and Nurse respectively, and they are participating in the ER-Team.

• Session 1:
• session-user(s1) = ‘Mary’
• session-roles(s1) = [HeadNurse]
• session-teams(s1) = [ER-Team]
• Session 2:
• session-user(s2) = ‘Helen’
• session-roles(s2) = [Nurse]
• session-teams(s2) = [ER-Team]
• Team-users (ER-Team) = [Mary, Helen]
• Team-roles (ER-Team) = [Head Nurse, Nurse]

Then, Team-Roles Permissions (ER-Team) = SELECT field1, field3, field4 FROM PATIENTS

Assume that user Chris is starting his session s3 and is activating the role Doctor and is participating in the ER-Team.

• Session 3:
• session-user(s3) = ‘Chris’
• session-roles(s3) = [Doctor]
• session-teams(s3) = [ER-Team]
• Team-users (ER-Team) = [Chris, Mary, Helen]
• Team-roles (ER-Team) = [Doctor, Head Nurse, Nurse]

Assume aggregation (union) as the combination method for role-based permissions:

• Role-based Permissions(Chris) =
• = Session-Roles Permissions (Doctor) ⊕ Team-Roles Permissions (ER-Team)
• = {SELECT field1, field2, field3 FROM PATIENTS} ∪ {SELECT field1, field3, field4 FROM PATIENTS}
• = SELECT field1, field2, field3, field4 FROM PATIENTS
• Context-based Permissions (Chris) =
• = Role-based Permissions (Chris) x Team-Context (ER-Team)
• = SELECT field1, field2, field3, field4 FROM PATIENTS WHERE CurrentPatientID IN (200, 351, 402, 667) AND CurrentTime IN [10:00;12:00] AND CurrentLocation IN (ER-1,ER-3,GW-2) [view 1]
  

Assume Chris places the following access request at 11.30 (CurrentTime = [11:30], from Emergency Room Nr.1 (CurrentLocation = ER-1) and for patient with ID = 351 (CurrentPatientID = ‘351’):

• SELECT field1, field4 FROM PATIENTS WHERE PatientID = CurrrentPatientID [view 2]
  

This action has two effects. Firstly, view-1 expression is evaluated, since all variables contain specific values. Secondly, based on the user access request, the system evaluates and compares view-1 and view-2. The access control system examines whether the set of results from access request (view-2) is included (IN clause of SQL) in the set of results of context-based permissions (view-1).

R. Thomas. 1997. "Team-based Access Control (TMAC): A Primitive for Applying Role-based Access Controls in Collaborative Environments"

Three objectives:

• to provide a security environment that was non-intrusive to clinical staff.
• to provide very tight, just-in-time permissions so that only the appropriate clinical staff could get access to a patient’s records and only when they were providing care for the patient.
• to design a security framework that did not add any significant administrative overhead and was therefore self-administering to a great extent.

RBAC shortcomings:

• The need for a hybrid access control model that incorporated the advantages of having broad, role-based permissions across object types, yet required fine-grained control on individual users in certain roles and on individual object instances.
• A second requirement was the need to recognize the context associated with collaborative tasks and the ability to apply this context to decisions regarding permission activation.

Passive vs active security model:

• passive security model - primarily serves the function of maintaining permission assignments, such as in RBAC where permissions are assigned to roles
• active security model - distinguishes task- and context-based permission activations from permission assignment
• in particular, after a permission is assigned, it may be turned on (activated) and off (deactivated) several times in accordance with the evolving context associated with progressing tasks. Only when a permission is activated will the corresponding operation succeed
• notion of sessions in RBAC96 does not go far enough in encompassing the overall context associated with any collaborative activity
  

Example:

• Begins with a visit to the emergency room (ER) by a patient who is suffering from pneumonia
• Upon arrival, the patient is quickly screened by a triage nurse who determines that the patient needs to be admitted to the general medicine ward. The primary team that admitted the patient subsequently requests a gastroenterology consultation because the patient is beginning to develop gastrointestinal bleeding.
• The gastroenterologist who is consulted decides to investigate further and proceeds to do an upper GI endoscopy procedure.
• While undergoing this procedure the patient has a heart attack and is immediately transferred to the coronary care unit where a cardiology team takes over the care of the patient, becoming the primary team.
• Eventually the patient’s heart condition is stabilized and the patient is transferred back to the general medicine ward. After spending a few more days in the hospital, the patient recovers, is discharged, and is told to see his/her primary care doctor for follow-up care.

Observations:

• A number of clinical staff (users) was involved in various roles in providing care at various points in the workflow. These included general physicians, specialists such as cardiologists, residents and interns, nurses, etc.
• The staff was organized into care teams and each team was associated with a single department or unit in the organization.
• Care teams were often dynamically formed. For example, when the gastroenterologist joined the care team as the result of a request for a gastroenterology consultation. This dynamic formation can be distinguished from the case in which a staff member is preassigned by the scheduling department to be on a particular team.

Access control requirements:

1. The permissions a clinical staff member has to clinical records (documents) should reflect his/her role in providing care. For example, only the cardiologist may prescribe a certain drug for cardiac-related illness and only physicians, not nurses, may order lab tests.
2. Only members of a patient’s team should be able to get access to the patient’s records. Thus, although a physician, P, may have the right to order a lab test by virtue of the qualifications and responsibilities that determine his role, P should have the right to do so for Patient A’s record only when P is part of A’s care team.
3. Depending on the workflow, various clinical staff needs access to patient records at different points in the overall workflow. Therefore the primary care team in general wards should be given access to a patient’s records only after the ER unit has requested transfer of the patient to one of those wards.
4. Requirements 1 and 2 above should hold for any staff member who dynamically joins a team.
5. When a patient is transferred from one unit to another, the members of the primary care team of the second unit should be given access to the records of the patient (according to their roles) and no one else.
6. Certain team members may delegate duties and associated permissions to other team members. Thus a physician may authorize a resident or nurse to order a specific lab test or referral for a specific patient. The resident would, in this situation, would need limited (probably one-time) permissions to complete this order, even though under normal circumstances, he/she would not be able to give the order directly since their role is not endowed with such privileges.
7. Once the patient is discharged, all permissions to the patient’s medical records should be deactivated.

TMAC basic ideas:
A team consists of the following:

• A team name, t.
• A set of team members/users, TU.
• A set of team roles, TR, that restricts the roles which members of the team can belong to. TR is-subset-of R, where R is the total set of roles in the information system.
• A special role called team head (h), where h is-subset-of TR. Only one user can be the team head at any given time.
• A set of object types, OT.
• A set of object instances, 0.
• A set of team permissions TP, defined across TR and OT, i.e., TP is-subset-of TR x OT
• A collaboration context that consists of the following two components.
• A user context (UC), where UC : TR x TU
• An object context (OC), where OC : OT x O

• Use RBAC to define a set of permissions P across the domains of R and OT. Individual teams of the same structure (type/class) will encompass the same subset of roles, TR of R, and will thus inherit the same subset TP of P.
• However, TMAC calls for the run time binding of the TP for each team to the sets TU and 0 of the team. This allows run-time activation of permissions at the level of individual user and objects.

TMAC should support the following primitives to enable access control on the team as a whole:

• User-assign (user, team): assigns a user to a team.
• User-deassign (user, team): removes a user from a team.
• Team-activate(team): This binds the team permissions to the team members and the objects they need (TU and 0).
• Team-deactivate (team): This deactivates the permissions for the entire team.
• User-activate and User-deactivate

TMAC can be made self-administering by trapping basic calls issued by the host information system to assign and deassign team members, as well as by trapping at run-time when workflow instances are invoked. These can then be synchronized with the user assignment and activation primitives to automate security administration.
To preserve access control to individual objects across teams, the object context can be passed from one team to another.