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).