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.