Work-Based Access Control Model for Cooperative Healthcare Environments: Formal Specification and Verification

Abstract

In this study, an access control model for cooperative healthcare environments is presented. A work-based access control (WBAC) model is proposed by introducing the concept of team role classification based on Belbin team role theory and modifying the user-role assignment model from previous work. Roles are used in conjunction with team roles to handle access control in dynamic collaborative environments. To evaluate and analyze the security, efficiency, and practicality of the proposed model, we first formalize the model (events and policies), define the basic element set and relations in the WBAC model, present the WBAC authorization constraints, and define the WBAC access control decision function. Second, we evaluate the model’s security and manageability validity to ensure that the security and management requirements of our WBAC model are met. Finally, we evaluate the performance of the proposed model and compare it with relevant existing models. Verification indicates that WBAC is flexible, easy to manage and meets our expectation of allowing fine-grained access control, and it enhances the practicability of access control in dynamic collaboration environments.

Introduction

Electronic health records (EHRs) [14, 49] can be improved with a collaborative environment, through which medical providers such as physicians and specialists share information and work together as a team to solve particular medical cases. However, the collaborative environment might also leave users (e.g., patients) more susceptible to insider threats [22, 23, 53], a serious calamity that endangers the privacy and well-being of patients and medical personnel alike. Here, confidential information is improperly accessed and exploited by insiders. They are initially given permission to share information for purely benign purposes. In light of this, proper security mechanisms such as access control must be put in place to protect information residing on the health facility [2].

Access control is ideal for managing access to information and controlling the activities of legitimate users by mediating every attempt by a user to access a resource in the system [36]. Access control in distributed environments (e.g., inter-organization) has a different focus from centralized environments [39, 44, 51, 63, 65]. In centralized environments, access control policies can be defined in terms of role (job function), attributes, and privileges of users who are permitted to access resources according to their identities and associated privileges [28]. Role-based access control (RBAC) [31, 32, 55] and attribute-based access control (ABAC) [30, 37] are familiar examples of access control mechanisms. The access right decision to perform an action is made by analyzing the requester’s credentials (e.g., role and/or attributes) and his/her set of access rules/privileges. Due to the dynamic nature of collaboration and team work, it is important to understand to what extent and under what conditions other parties are granted with access rights [44, 65]. It is also necessary to employ access control policies to control the way in which information or services are shared between different parties [47, 54]. In distributed environments such as healthcare, different participants (individuals or organizations) can play several different roles at a given time (e.g., resource owner, agent or consumer) [5, 7]. Moreover, each participant manages his/her own resources and defines their own access control policies. Thus, participants collaborate with each other in various ways, which requires appropriate access control mechanisms in place to ensure that information is accessible only to those authorized to have access [59].

In our previous work [2–7], the work-based access control (WBAC) model was proposed by introducing the team role concept and modifying the team user-role assignment model from RBAC and ABAC. In [2], we proposed a team role classification based on Belbin team role theory [16]. The team is segregated into thought, action, and management based on contributions to the collaborative work. WBAC handles access control based on collaborative work and team role. Role is used in conjunction with team role to handle access control in dynamic collaborative environments. The team role determines the finer role and the extend of access of each team member. To the best of our knowledge, we are the first to use the team role theory with access control.

This study extends the work done in [7]. In this study, the general principles of the WBAC model are defined. We first formalize the model (events and policies), define the basic element set and relations in the WBAC model, present the WBAC authorization constraints, and define the WBAC access control decision function. Second, we evaluate the model’s security and manageability validity to ensure that the security and management requirements [4] are met. Finally, we evaluate the performance of the proposed model and compare it with RBAC and ABAC models.

The remaining part of this study is organized as follows. Section 2 presents a usage scenario of collaboration and sharing of healthcare data to better understand collaborations in the healthcare domain. In Section 3, a formal description and verification of the WBAC model is presented. Section 4 presents WBAC model security evaluation. In Section 5, WBAC model performance evaluation and comparing WBAC with the RBAC and ABAC models is given. Finally, discussion, future work, and conclusions are given in Section 6.

Collaboration and Secure Sharing of Healthcare Data

As shown in Fig. 1, a typical use case scenario adopted from [67] is presented. A patient named Alice is recently diagnosed with gastric cancer. Surgical removal of the stomach (gastrectomy) is the only curative treatment. For many patients, chemotherapy and radiation therapy are given after surgery to improve the chances of curing.

Fig. 1.

An example scenario of collaboration and sharing of healthcare data

Alice entered a cancer-treatment center at her chosen hospital (e.g., hospital A ). Alice has a primary care doctor (Dean) who she regularly visits. Upon entering the hospital, Alice also sees an attending doctor (Bob) from the hospital. Alice’s health condition has caused some complications, so her attending doctor would like to seek expert opinions and consultation regarding Alice’s treatment from different hospitals (e.g., hospital B), including Alice’s specific primary care doctor who is fully informed about Alice’s medical history. Note that the invited practitioners are specialized in different areas, where some are specialists and others are general practitioners. Also, the final medical report of Alice’s treatment should be signed by appropriate practitioners using digital signatures [18, 48]. Alice should be able to verify the authenticity of the consultation results through the practitioner’s digital signature [5, 6].

In such group consultation, also so-called multidisciplinary team consultation [19, 50, 62], it is noticeable that several healthcare professionals are involved in various roles to provide patient care. That involves many healthcare organizations and individuals, includes primary care doctors, general physicians and specialists. Every participant needs to obtain the medical records they request based on “minimum necessary”1 standard to uses and disclosures for treatment [13]. In this case, the act of managing the collaborative work must be clearly defined [5, 6]. By default, only the main practitioner should be aware of the patient’s personal information. The other medical practitioners with supporting roles are given information based on their contributing roles. For instance, if the supporting party is included solely for consultation purposes concerning the disease, only information essential for diagnosis is provided. It is not necessary to allow perusal of personal information related to the patient. Therefore, sharing and accessing healthcare records with efficient coordination between healthcare practitioners to perform collaborative work is a critical function in access control models [10]. The main concern is about losing control over the sensitive healthcare records while sharing them with multiple parties.

Insider abuse or misuse of privileges can be a threat to patient information and a liability for health care providers [2]. One of the main causes of insider threats is information leakage, which emerges when a supporting party is granted access beyond what is actually required. For instance, in treating a patient (Alice) case, the main practitioner Dean consults a specialist Cara from another department. In doing so, improper information access might occur if the Cara (Gastroenterologist) obtains more permissions than required. The key to solving this issue is to minimize the discrepancy between the granted access and the required access based on what is really needed. In this way, improper access to the patient’s sensitive information can be prevented [2].

Work-Based Access Control

The basic element set and relations of WBAC model are defined in Fig. 2. The WBAC includes sets of data elements called sessions, users, roles, teams, team roles, works, permissions, operations, and objects. The WBAC model is fundamentally defined in terms of users being assigned to roles or teams, team members being assigned to team roles, work being assigned to teams, and permissions being associated with roles and team roles.

Fig. 2.

WBAC model

In the following, we formally express entities and relations for the proposed access control model (WBAC) and verify the main ideas for WBAC approach and policies.

WBAC Formal Description

WBAC policies consist of a number of access control rules. Each rule is a logical expression of the basic access control elements (i.e., users, roles/team roles, permissions, operations, and objects) and relations between these elements (e.g., user to role assignments, permission to role assignments, etc). We now define and explain the element sets and relationships between the elements presented in Fig. 2. The Core WBAC definitions OBJ, OPR, PER, R, TR, USR, T, W, and S are object, operation, permission, role, team role, user, team, work, and session, respectively.

Definition 1

An object is considered as any resource in the system that can be assigned with access rights. For example, records, files and/or devices such as patient medical devices (e.g., pacemakers, blood pressure device, etc.) [1, 29]. Access to an object potentially implies access to the information it contains [36]. The set of all objects is denoted by OBJ.

Formally: $\mathit{OBJ}=\{\mathit{ob}{j}_1,\mathrm{...},\mathit{ob}{j}_{n_{\mathit{ob}}}\}$ where $n_{\mathit{ob}}\in \mathbb{N}$. Objects covered by WBAC are classified into two sets of objects: O B J _A and O B J _B such that O B J = {O B J _A ∪ O B J _B}, listed in the permissions that are assigned to roles (Definition 4) and team roles (Definition 5) which will be accessed by a users (Definition 8).

1. P r i v a t e object denoted by O B J _A. We assume that, O B J _A contains resources related to personal information including names and addresses as well as resources that are not related to the current patient case such as family medical history, psychotherapy notes [35] and sexually transmitted diseases (STD) records, among others.

2. P r o t e c t e d object denoted by O B J _B. We assume that this object contains resources related to current patient case. For example, consider scenario (Section 2), we could say that O B J _B contains resources related to Alice’s current case such as past surgical history, date related to abdominal CT scan (computed tomography scan) and gastroscopy data, to name a few.

Definition 2

An operation is a term used to describe an action performed on resources (e.g., read, write, etc). The set of all operations is denoted by OPR.

Formally: $\mathit{OPR}=\{\mathit{op}{r}_1,\mathrm{...},\mathit{op}{r}_{n_{\mathit{op}}}\}$ where $n_{\mathit{op}}\in \mathbb{N}$. Any operation that a user would perform on an object is defined entirely within the permission.

Definition 3

Permission specifies a special rights to perform some operation on resources for a subject (e.g., human users, machines, or processes). The set of all permissions are denoted by PER and it is a combination of object and operation.

Formally: P E R ⊆ O B J × O P R. Role and team role are associated with a set of permissions which are an approval to perform an operation on one or more objects.

Definition 4

A role is a collection of job functions within the context of a healthcare organization with some associated responsibility conferred on the user assigned to the role. Each role is authorized to perform one or more operations on objects.

In WBAC, we defined two types of roles. First is the main role (R), which represents the organizational role where the user has a common set of permissions to perform the job function associated with the role name. Formally, we have $R=\{r_1,\mathrm{...},r_{n_r}\}$ where r _i ⊆ P E R. Second is the team role (TR), which is a collection of various roles assigned to different users contributing in several ways to a team with objective of accomplishing a specific work.

Definition 5

Team role (TR) is a set of roles defined within a team to restrict the roles memberships and also restrict access permissions to individuals who not only have the right organizational roles but also are associated to the task via team memberships.

In [2], we proposed a team role classification based on Belbin team role theory [15, 16]. For the propose of this study, the nine different team roles that Belbin identified were rephrased and classified into thought, action, and management as illustrated in Fig. 3. Team member must be assigned to one team role (determined by their professional and/or technical knowledge) based on the goal, task, and contributes toward achieving the team’s objectives. The team role determines the finer role and the extend of access of each team member.

Fig. 3.

Taxonomy of team role [2]

Formally, we have T R = 〈t r _t,t r _a,t r _m〉 where t r _t is thought role, t r _a is action role, t r _m is management role and t r _i ⊆ P E R where i ∈{t,a,m}.

Definition 6

Authorized role and authorized team role denoted by a u t h _r(u s r), a u t h _tr(u s r,t), respectively, are a subset of roles and team role that user is authorized to assume. We say that, a role r is authorized for a user if r is assigned to user. A u t h _r(u s r) ⊆ R and a u t h _tr(u s r,t) ⊂ T R, where usr is user (Definition 8) and t is a team (Definition 9).

Definition 7

An active role denoted by a c t _r(u s r) is a subset of a u t h _r(u s r) that user is currently performing. In other words, the active role of a user is a subset of his/her authorized roles. A c t _r(u s r) ⊂ a u t h _r(u s r). A user can execute a privilege only if the user has selected an active role.

Definition 8

A user is a term that is used to denote a subject. It is human users, machines, or processes that require access to system resources. The set of all users is denoted by USR.

Formally: $\mathit{USR}=\{\mathit{us}{r}_1,\mathrm{...},\mathit{us}{r}_{n_{\mathit{usr}}}\}$ where $n_{\mathit{usr}}\in \mathbb{N}$ and u s r _i = {s _u,a u t h _r(u s r _i),t e a m _member};t e a m _member ∈ (T × T R)^p where T is a team, s _u ⊂ S is a session (Definition 11, $p\in \mathbb{N}$ is the number of teams which the u s r _i is a member of and t e a m _member = {t _i,a u t h _tr(u s r,t _i)}_i∈[0..p],t _i ∈ T,a u t h _tr(u s r,t) ∈ T R.

Definition 9

A team (t) encapsulates a collection of users in various roles and team role with the objective of accomplishing specific work. $T=\{t_1,\mathrm{...},t_{n_t}\}$ is a set of teams, where $n_t\in \mathbb{N}$ and t _i ⊆ U S R.

In this study, we consider users as human beings (i.e., patients and healthcare providers), practically as an individual user or group of users that access the objects in the system to perform their jobs. For simplicity, we do not model the patient, but the data related to the patient (patient’ healthcare records) is modeled. The permissions available to the user are the union of permissions directly assigned to an active role or team role in a session (Definition 11).

Definition 10

Work is an entity comprising a collection of elements named personnel, role, resource, context, and policy (Fig. 4) that interact with one another for a particular outcome to be achieved successfully. The set of all works are denoted by W . $W=\{w_1,\mathrm{...},w_{n_w}\}$, where $n_w\in \mathbb{N}$ and w _i = (t,o b j,s t a t e) where $t\in T^{n_{\mathrm{wt}}}$, $\mathrm{obj}\in \mathit{ob}{J}^{n_{\mathrm{wobj}}}$, $n_{\mathrm{wt}}\in \mathbb{N}$ is the number of teams assigned to w _i, $n_{\mathrm{wobj}}\in \mathbb{N}$ is the number of objects assigned to work w _i, and s t a t e ∈{0,1 }:

$$\mathit{state}=\left\{\begin{array}{cc}1& \text{if}{w}_i\text{is active}\\ 0& \text{otherwise.}\end{array}\right.$$

Fig. 4.

Work model for collaboration [2]

In WBAC, the treatment of Alice’s case (Section 2) is called a work. This work is performed by a group of personnel (healthcare providers) who play different roles in Alice’s treatment and also require access to different resources in different contexts. We consider patient’ healthcare records (patient’ EHRs) as objects which need to be accessed by healthcare providers.

A healthcare provider (who joins a team) can have various team roles whereby each of them is tied to a different collaborative work. TR restricts the role which each member of the team belongs to. Each team has a responsible person (head or manager) that decides who should join the team and who can perform what? For example, consider Alice’s case (Fig. 1), we have the primary doctor (Dean) as the team manager. Dean decides who would join the team and what team role each team member should have. A team member can perform what task in the collaboration is decided by what team role is assigned to him/her in the team. Moreover, the work is associated with a lifecycle (state) and only in active state, the team assigned to this work can perform their duties on it. Accessing resources and performing an operation related to work is controlled by WBAC authorization policies (Definition 12).

Definition 11

Session is an entity where user may activate a subset of role or team role he/she is assigned to. S denotes the set of sessions. Formally: $S=\{s_1,\mathrm{...},s_{n_s}\}$ where $n_s\in \mathbb{N}$, s _i = {a c t _r(u s r),a u t h _tr(u s r,t),a w}, where a w ⊆ W is an active work.

Each session is a mapping of one or many users to possible many roles and team roles. The permissions available to the user are the union of permissions from the activated role a c t _r(u s r) or team role a u t h _tr(u s r,t) in that session. Sessions include role and team role activation/deactivation, the enforcement of constraints on role and team role activation, and they are used for calculation of an access decision. Constraints such as separation of duty (SoD) [42] (discussed in Section 3.2) on sessions can limit the number of roles and team roles that a user can activate at the given time.

Definition 12

Authorization policy (AP) is a security statement of what is, and what is not allowed in the organization.

The goal of an authorization policy is to examine conditions in order to send an authorization result (permit or deny) for an authorized subject to access objects. It is possible to be an authorized user but not have access to a specific object. A policy may be presented mathematically or written on human language such as English to describes what a user and other entities (e.g., machines or process) on the system are allowed and/or disallowed to do. An example of policy in healthcare organization, only physicians, not nurses may prescribe a certain drug (e.g., antibiotics) to patients. To support a collaborative environment requirement [4], specially in the case where two or more different organizations cooperate and each of which might have its own resources’ policy based on the owner’s objectives and requirements, a dynamic policy with dual inclination is proposed in WBAC model [2], whereby the normal policy of enforcing access control is contained within the main policy. On the other hand, any policy that mediates resource sharing during collaborative work is covered by the collaboration policy.

1. Main policy ( M P ): The MP depends on the role (R). Therefore, it is only considered if the personnel (user) possesses a role.

2. Collaborative Policy ( C P ): CP depends on the team role (T R). In this respect, even if the personnel do not have the required personal roles, they can still gain access if they are invited into the collaboration. Team role (T R) provides a demarcation between the roles played by personnel within a collaboration work w.

Definition 13

Policy Set (P S ∈ A P) for a given system is the representation of the system’s access control mechanisms. In [4], we implemented two policy sets using XACML, where the first policy set is for MP and the second is for the CP.

Definition 14

Policy change is a sequence of modifying a policy set in the access control policies. Formally:

Let P be a policy that needs to be added or modified and PS is the policy set. Then,

1. If P ∈ P S, the change contains the activity of retracing P from PS and modifying it. Formally: P S ⊕{P,P ^′} = (P S∖{P}∪ P ^′) then, P S ^′ = P S ⊕{P,P ^′}.

2. Else if P∉P S, the change contains the activity of adding P ^′ to PS. Formally: P S ^′ = P S ∪ P ^′.

Definition 15

Relation assignment is a many-to-many mapping of the defined data element to one another.

In the WBAC model, there is a number of assignment relations that are described as follows:

1. User to role assignment: It is a many-to-many roles (R) to a users (USR) assignment relation. A user can have one or many roles and a role can be assigned to one or many users. For each user usr and role r, the Function (1) returns true if r is assigned to usr, false otherwise. Also, the set of roles assigned to user are updated in the a u t h _r(u s r). Formally:

   $$\begin{array}{cc}\mathit{USR}\text{-}R\text{-}A:\mathit{USR}\times R& \to \mathit{Bool}\\ \{\mathit{usr},r\}& \mapsto \mathit{aut}{h}_r\left(\mathit{usr}\right)=\left\{\mathit{aut}{h}_r\right(\mathit{usr})\cup r\}\mathrm{.}\end{array}$$ 1
2. User to team assignment: It is a many-to-many user to a team assignment relation. A team could have none or multiple users and a user could join one or multiple teams. The sets of users assigned to team t is defined in Function (2). Formally:

   $$\begin{array}{cc}\mathit{USR}\text{-}T\text{-}A:\mathit{USR}\times T& \to \mathit{Bool}\\ \{\mathit{usr},t\}& \mapsto t=t\cup \mathit{usr}\mathrm{.}\end{array}$$ 2
3. Team member to team role assignment: It is a many-to-many team members to a team roles assignment relation. It defines a user that participates in a team should have one team role and a team role (tr) can be assigned to none or multiple users. Formally:

   $$\begin{array}{rcl}\mathrm{TM}\text{-}\mathrm{TR}\text{-}A:\mathrm{USR}\times T\times \mathrm{TR}& \to & \mathrm{Bool}\\ \{\mathrm{usr},t,\mathrm{tr}\}& \mapsto & \mathrm{tea}{m}_{\mathrm{member}}=\{t,\mathrm{aut}{h}_{\mathrm{tr}}(\mathrm{usr},t)=\mathrm{tr}\}\mathrm{.}\end{array}$$ 3
4. Team to work assignment: It is a many-to-many relation assigning team t ^′ to work w = {t,o b j,s t a t e}∈W. A work can have one or many teams and a team can be assigned to one or multiple works. Formally, we have:

   $$\begin{array}{rcl}T\text{-}W\text{-}A:T\times W& \to & \mathrm{Bool}\\ \{t^{\prime },w\}& \mapsto & w=\{t\cup t^{\prime },\mathrm{obj},\mathrm{state}\}\mathrm{.}\end{array}$$ 4
5. Permission to role assignment: It is many-to-many relation assignment defines a permission per which a role (r) can have. A role can have one or multiple permissions and a permission can be assigned to one or many roles. Formally:

   $$\begin{array}{rcl}\mathrm{PER}\text{-}R\text{-}A:\mathrm{PER}\times R& \to & \mathrm{Bool}\\ \{\mathrm{per},r\}& \mapsto & r=\{r\cup \mathrm{per}\}\mathrm{.}\end{array}$$ 5
6. Permission to team role assignment: A many-to-many permissions (per) to a team role (tr) assignment relation. A team role can have one or multiple permissions and a permission can be assigned to one or many team roles. Formally:

   $$\begin{array}{rcl}\mathrm{PER}\text{-}\mathrm{TR}\text{-}A:\mathrm{PER}\times \mathrm{TR}& \to & \mathrm{Bool}\\ \{\mathrm{per},\mathrm{tr}\}& \mapsto & \mathrm{tr}=\{\mathrm{tr}\cup \mathrm{per}\}\mathrm{.}\end{array}$$ 6
7. Session to user assignment: A many-to-many assignment relation of a session s _i = {a c t _r(u s r),a u t h _tr(u s r,t),a w} to a user usr.

   $$\begin{array}{rcl}S\text{-}\mathrm{USR}\text{-}A:S\times \mathrm{USR}& \to & \mathrm{Bool}\\ \{s,\mathrm{usr}\}& \mapsto & s_u=\{s_u\cup s\}\mathrm{.}\end{array}$$ 7
8. Session to role assignment: A many-to-many assignment relation of a session s to an active role a c t _r(u s r).

   $$\begin{array}{rcl}S\text{-}R\text{-}A:S\times \mathrm{aut}{h}_r\left(\mathrm{usr}\right)& \to & \mathrm{Bool}\\ \{s,r\}& \mapsto & \mathrm{ac}{t}_r\left(\mathrm{usr}\right)=r\mathrm{.}\end{array}$$ 8
9. Session to team role assignment: A many-to-many assignment relation a session s to a team role tr.

   $$\begin{array}{rcl}S\text{-}R\text{-}A:S\times \mathrm{aut}{h}_{t}r\left(\mathrm{usr}\right)& \to & \mathrm{Bool}\\ \{s,\mathrm{tr}\}& \mapsto & \mathrm{aut}{h}_{\mathrm{tr}}(\mathrm{usr},t)=\mathrm{tr}\mathrm{.}\end{array}$$ 9

In the three relations (Functions (7), (8), and (9)), we assume the user can be assigned to one or multiple sessions and have one role and/or one team role in its participating team. To support the principle of least privilege, a user should be allowed to activate only those roles appropriate for a given occasion. But with constraints such as separation of duty (SoD), it may not be possible for a user to activate all his/her roles simultaneously.

WBAC Authorization Constraint Specification

Authorization constraint such as SoD [9, 42, 43, 60] and prerequisite constraints can be used to enforce conflict-of-interest polices that organizations may employ to prevent users from exceeding a reasonable level of authority for their roles. SoD is also used in multi-person control policies that show two or more different persons responsible to complete the task and set of related task. The purpose of this principle is to prevent one user from doing all parts of a task that requires two or more, in order to prevent collusion or fraud [43]. Two major types of SoD, static and dynamic, are presented in the literature [42]. Here, we discuss these two major types of SoD. Subsequently, we also define a variety of SoD and prerequisite constraints and their relationships in secure WBAC model.

Definition 16

Static separation of duty (SSoD) generally place restrictions on administrative operations that have the potential to undermine higher-level organizational SoD policies.

In other words, SSoD is used to enforce constraints on the assignment of users to set of roles or team roles to avoid a user from gaining authorization for permissions associated with conflicting roles. Examples of SSoD constraints are as follows:

Constraint 1 (C1)

Static-user-role-SoD: Two roles should never be assigned to the same user at a given time. Formally: Let mutual exclusion of role set be S S o D ⊆ R ² ,

$$\begin{array}{c}\forall \mathit{usr},\forall r_1,r_2\in R:r_1\in \mathit{aut}{h}_r\left(\mathit{usr}\right)\wedge \{r_1,r_2\}\in \mathrm{SSoD}\Rightarrow \neg \mathit{USR}\text{-}R\text{-}A(\mathit{usr},r_2)\mathrm{.}\end{array}$$ 10

Constraint 2 (C2)

Static-user-team-role-SoD: Two team roles should never be assigned to the same user at one team. In other word, a user in one team can only be assigned to one team role at a given time.

Formally:

$$\begin{array}{cc}\forall t{r}_a,t{r}_t\in \mathrm{TR},\forall t\in T,\forall \mathit{usr}\in \mathrm{USR}:\mathrm{usr}\in t\wedge \{t,t{r}_t& \}\in \mathrm{tea}{m}_{\mathrm{member}}\Rightarrow \\ \neg \mathrm{TM}\text{-}\mathit{TR}\text{-}A(\mathit{usr},t,t{r}_a)\mathrm{.}\end{array}$$ 11

Constraint 3 (C3)

Object-based SSoD: Restricts that a user cannot perform an operation on a specific object. For example we have:

1. Only a user ( usr) assigned with a team role ( t r _a ) can access objects of O B J _A . Formally we have:

   $$\begin{array}{cc}\forall \mathrm{opr}\in \mathrm{OPR},\forall \mathrm{tr}\in \mathrm{TR},\forall \mathrm{obj}& \in \mathrm{OBJ}:\mathrm{tr}\ne t{r}_a\wedge \mathrm{obj}\in \mathit{ob}{J}_A\wedge \\ \mathrm{per}=\{\mathrm{obj},\mathrm{opr}\}\Rightarrow \neg \mathrm{PER}\text{-}\mathit{TR}\text{-}A(\mathrm{per},\mathrm{tr})\mathrm{.}\end{array}$$ 12
2. Only a user (usr) assigned with a team role(t r _m)can access doctors’s information. Formally: Let o b j _doctorInfo ∈ o b j _b,

   $$\begin{array}{cc}\forall \mathrm{opr}\in \mathrm{OPR},\forall \mathrm{tr}\in \mathrm{TR},\forall \mathrm{obj}\in & \mathrm{OBJ}:\mathrm{tr}\ne t{r}_m\wedge \mathit{OBJ}=\mathit{ob}{j}_{\mathrm{doctorInfo}}\wedge \\ \mathrm{per}=\{\mathrm{obj},\mathrm{opr}\}\Rightarrow \neg \mathrm{PER}\text{-}\mathit{TR}\text{-}A(\mathrm{per},\mathrm{tr})\mathrm{.}\end{array}$$ 13

Definition 17

Dynamic separation of duty (DSoD) [42, 43] enforces constraints to limit the availability of the permissions over a user’s permission space by placing constraints on the roles and team roles that can be activated within or across sessions. Examples of DSoD constraints as follows:

Constraint 4 (C4)

Session-role DSoD : Session to role assignment disallows a user from activating two particular roles at the same time. Formally:

$$\begin{array}{cc}\forall r\in R\forall s\in S,\forall \mathit{usr}\in \mathrm{USR}:s\in \mathrm{usr}\wedge \mathit{card}\left(\mathrm{ac}{t}_r\right(\mathit{usr}\left)\right)=1& \Rightarrow \\ \neg S\text{-}R\text{-}A(s,r)\mathrm{.}\end{array}$$ 14

Where card(i.e., cardinality of a set) is the number of elements of the a c t _r(u s r)set.

Constraint 5 (C5)

Session-team-role DSoD : Session to team role assignment disallows a user from activating two particular team roles at the same time. Formally:

$$\begin{array}{cc}\forall s\in S,\forall \mathit{usr}\in \mathrm{USR}\forall t\in T:s\in \mathrm{usr},\mathrm{usr}\in t\wedge \mathit{card}& \left(\mathit{aut}{h}_{\mathit{tr}}\right(\mathit{usr},t\left)\right)=\\ 1\Rightarrow \neg S\text{-}\mathit{TR}\text{-}A(s,\mathrm{tr})\mathrm{.}\end{array}$$ 15

Definition 18

Prerequisite constraint is based on competency and appropriateness, whereby a user can be assigned to role r _i only if the user is already a member or not a member of specified roles, and similarly for permissions. Examples of prerequisite constraints can be presented as follows:

Constraint 6 (C6)

The number of authorized users for any team role does not exceed the cardinality of that role. Formally: Let n be the number of users a team role t r _a should has. Then,

$$\begin{array}{cc}\forall t\in T,\mathit{card}\left(\right\{\mathit{us}{r}_i=\left\{\mathit{aut}{h}_r\right(\mathit{us}{r}_i),\mathrm{tea}{m}_{\mathrm{membe}{r}_i}\})\in t:\{t,& t{r}_a\}\in \\ \mathrm{tea}{m}_{\mathrm{member}}\}=n\mathrm{.}\end{array}$$ 16

Constraint 7 (C7)

A collaborative work w has to be active, such that team members can work on it. Formally we have:

$$\begin{array}{c}\forall w\in W,\forall s\in S:w=\{t,\mathrm{obj},\mathit{state}\}\in s\iff \mathit{state}=1.\end{array}$$ 17

Definition 19

Delegation is referred to as a process in which one active entity (e.g., usr) in the system delegates its privileges to another entity (e.g., u s r ^′) to carry out some function on behalf of the former user (usr) [61].

To fulfill a dynamic collaboration requirement [4], WBAC model supports delegation in which a user can delegate privileges to another user.

Constraint 8 (C8)

Delegation:

Let d e l e g a t e(u s r,u s r ^′,r)be the role r which usr delegates to u s r ^′ and r e v o k e(u s r,r)to revoke role,

$$\begin{array}{cc}\forall \mathit{usr}\in \mathrm{USR},\forall r\in R:\mathit{USR}\text{-}R\text{-}A(\mathit{usr},r)& \wedge \neg \mathit{USR}\text{-}R\text{-}A(\mathit{us}{r}^{\prime },r)\wedge \mathrm{const}\Rightarrow \\ \mathrm{delegate}(\mathit{usr},\mathit{us}{r}^{\prime },r)\wedge \mathrm{revoke}(\mathit{usr},r)\mathrm{.}\end{array}$$ 18

¬U S R-R-A(u s r ^′,r)is required because it is not useful to delegate a role (r) to user(u s r ^′) whohas already been assigned to r. Also, usr should hold the role which he/she would delegateto u s r ^′(USR-R-A(usr, r)). Moreover, constraints const(e.g., C1and C6) mustbe satisfied to enable the delegation.

Definition 20

Revocation is process of revoking the privileges that have been delegated. Often it is necessary to revoke privileges that have been delegated to a user [61] (e.g., when a healthcare provider returns back from holiday). Moreover, in WBAC, we have team revocation to revoke a team from a work (w), team membership revocation to revoke a user form team and active work should be revoked once the work is finished (more in Definition 27).

Constraint 9 (C9)

Revocation of delegated role:

$$\begin{array}{c}\forall \mathit{usr}\in \mathrm{USR},\forall r\in R:\wedge \mathit{USR}\text{-}R\text{-}A(\mathit{us}{r}^{\prime },r)\wedge \mathrm{const}\Rightarrow \mathrm{revoke}(\mathit{us}{r}^{\prime },r)\mathrm{.}\end{array}$$ 19

Constraint 10 (C10)

Revocation of work: work should be revoked after it finishes. Let:

$$\begin{array}{c}\mathrm{revoke}:W\to W\\ w=(t,\mathrm{obj},1)\mapsto (t,\mathrm{obj},0)\\ \mathrm{then}w=\mathrm{revoke}\left(w\right)\mathrm{.}\end{array}$$ 20

Definition 21

An access query (Q) is a tuple (u s r,o p r,o b j), where u s r ∈ U S R, o p r ∈ O P R and o b j ∈ O B J. A query q = (u s r,o p r,o b j) means that user (usr) requests to perform an operation (opr) on an object (obj).

Definition 22

Access state (Γ) is a particular model assignment to a given WBAC system. An access state γ ∈ Γ contains all the information necessary to make access control decisions for a given time. When a query q ∈ Q arises from an access request, γ ⊣ q means that the access request decision corresponding to q is permitted or denied in access state γ.

Definition 23

Access control decision function ( DF ) is defined as follows: if condition is evaluated as true, then there is decision d ∈{p e r m i t,d e n y}, according to the decision in the authorization policy.

Formally: Let U S R = {s _u,a u t h _r(u s r _i),t e a m _member}, and authorization policy A P = {a p _i ∈ U S R × P E R}_i∈[0...n] be a set of n permitted actions. Then,

$$\begin{array}{c}\mathrm{DF}:Q\to \{0,1\}\\ m=\{\mathrm{usr},\mathrm{per}\}=\left\{\right\{s_u,\mathit{aut}{h}_r\left(\mathit{usr}\right),\mathrm{tea}{m}_{\mathrm{member}}\},\mathrm{per}\}\mapsto \\ F\left(m\right)=\left\{\begin{array}{cc}1& \text{if}\mathrm{per}\in \mathrm{ac}{t}_r\left(\mathit{usr}\right)\wedge m\in \mathrm{AP}\\ G\left(m\right)& \text{otherwise}\end{array}\right.\end{array}$$ 21

$$\begin{array}{c}G:Q\to \{0,1\}\\ m=\{\mathrm{usr},\mathrm{per}\}=\left\{\right\{s_u,\mathit{aut}{h}_r\left(\mathit{usr}\right),\mathrm{tea}{m}_{\mathrm{member}}\},\mathrm{per}\}\mapsto \\ G\left(m\right)=\left\{\begin{array}{cc}1& \text{if true}\\ 0& \text{otherwise}\end{array}\right.\\ \mathrm{true}=\exists w=(t,\mathrm{obj},\mathit{state}):\mathit{state}=1\wedge \{t,\mathrm{per}\}\in \mathrm{tea}{m}_{\mathrm{member}}\wedge m\in \mathrm{AP}\mathrm{.}\end{array}$$ 22

WBAC Model Security Evaluation

Security evaluation answers questions such as whether an undesirable state is reachable and if every reachable state satisfies certain safety or availability properties [45]. Examples of undesirable states include states in which an untrusted user obtains access and states in which a user is entitled to access permission but does not get it. Security evaluation generalizes safety analysis as discussed in [33, 34, 41]. In this section, we evaluate the WBAC model based on the given scenario (Section 2).

Assumption 1

A patient, Alice, is a subject of medical records.

Assumption 2

Alice’s medical records include information about her health condition and treatments.

We assume that O B J _A(Alice) = {F i l e ₁,...,F i l e _n}, where f i l e _i is private information such as Alice’s personal data and other information not related to Alice’s current case, and O B J _B(Alice) = {F i l e ₁,...,F i l e _n}, where f i l e _i is information related to Alice’s current case, such as her old medical records (see Definition 1).

Assumption 3

Dean, Bob, Cara, and Alex are healthcare professionals who require access to Alice’s medical records while working on her treatment.

We assume Dean (head of the team) decides who should access what based on the required job. Table 1 presents the policy data used as input for our example proof.

Table 1.

Sample policy data

Subject	Role	Object	Action	Permission
Dean	Primary doctor	O B J A(Alice), O B J B(Alice)	Read/write	Permit
Bob	General practitioner	O B J A(Alice), O B J B(Alice)	Read/write	Permit
Cara	Gastroenterologist	O B J B(Alice)	Read	Permit
Alex	Medical coordinator	O B J B(Alice)	Read	Permit

Assumption 4

Role and team role assignment: If constraints C ₁,...,C _n are true, then role r and tr are assigned to users.

For the given system, the following access control policies are defined as follows:

• A private object can be accessed only by users with an associated action team role or a main role. Formally:

  $$\begin{array}{rcl}& & \mathrm{ac}{t}_{\mathrm{Primary}-\mathrm{doctor}}\left(\mathit{usr}\right)\wedge \mathrm{PER}\text{-}R\text{-}A(\mathrm{Primary}\text{-}\mathrm{doctor}=\{(\mathrm{read},\mathit{ob}{j}_a),\\ & & (\mathrm{write},\mathit{ob}{j}_a),(\mathrm{read},\mathit{ob}{j}_b),(\mathrm{write},\mathit{ob}{j}_b)\left\}\right)\iff \mathrm{Permit}\mathrm{.}\\ & & \mathit{aut}{h}_{t{r}_a}\left(\mathit{usr}\right)\wedge PER\text{-}\mathit{TR}\text{-}A(t{r}_a=\{(\mathrm{read},\mathit{ob}{j}_a),(\mathrm{write},\mathit{ob}{j}_a),(\mathrm{read},\mathit{ob}{j}_b)\left\}\right)\\ & & \iff \mathrm{Permit}\mathrm{.}\end{array}$$
• A read operation can be performed on a protected object by any user with an associated team role. Formally:

  $$\begin{array}{rcl}\mathrm{ac}{t}_{\mathit{tr}}\left(\mathit{usr}\right)\wedge \mathrm{PER}\text{-}\mathit{TR}\text{-}A(t{r}_i=\{(\mathrm{read},\mathit{ob}{j}_b)\left\}\right)\iff \mathrm{Permit}\mathrm{.}& & \end{array}$$

Each user, object, or operation is associated with a set of attributes that may be used for access control decisions. For example, a user’s attributes may include the user’s role, team role, and ID. An object’s attributes may include the file type (private or protected) and file name. In our model, policy rules are specified that are applicable to multiple-attribute requests [4].

Example 1

Access state.

Consider Alice’s case. We assume that in the initial state denoted by γ ₁ the formal model assignment is presented in Table 1 as follows:

$$\begin{array}{rcl}& & \mathit{USR}=\{\mathit{Dean},\mathit{Bob},\mathit{Cara},\mathit{Alex}\},\\ & & R=\{\mathit{Primary}\text{-}\mathit{doctor},\mathit{General}\text{-}\mathrm{practitioner},\mathit{Gastroenterologist},\mathit{Medical}\text{-}\\ & & \mathit{coordinator}\},\\ & & \mathit{TR}=\{t{r}_a,t{r}_t,t{r}_m\},\\ & & T=\left\{t_1\right\},\\ & & W=\left\{w_1\right\},\\ & & \mathit{OBJ}=\{\mathit{ob}{j}_a,\mathit{ob}{j}_b\},\\ & & \mathit{OPR}=\{\mathit{Read},\mathit{Write}\},\\ & & \mathit{PER}=\left\{\right(\mathit{read},\mathit{ob}{j}_a),(\mathit{write},\mathit{ob}{j}_a),(\mathit{read},\mathit{ob}{j}_b),(\mathit{write},\mathit{ob}{j}_b\left)\right\},\\ & & \mathit{AR}=\left\{\mathit{USR}\text{-}R\text{-}A\right(\mathit{usr},r),\mathit{USR}\text{-}T\text{-}A(\mathit{usr},t),T\text{-}W\text{-}A(t,w),\mathrm{...}\},\end{array}$$

where:

$$\begin{array}{rcl}& & \mathit{USR}\text{-}R\text{-}A(\mathit{Dean},\mathrm{Primary}\text{-}\mathit{doctor})\to \mathit{aut}{h}_r\left(\mathit{Dean}\right)=\left\{\right(\mathit{Primary}\text{-}\mathit{doctor}\left)\right\},\\ & & \mathit{PER}\text{-}R\text{-}A(\mathit{PER},\mathrm{Primary}\text{-}\mathit{doctor})\to \mathit{Primary}\text{-}\mathit{doctor}=\left\{\right(\mathit{read},\mathit{ob}{j}_a),\\ & & (\mathit{write},\mathit{ob}{j}_a),(\mathit{read},\mathit{ob}{j}_b),(\mathit{write},\mathit{ob}{j}_b)\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Bob},t_1)\to t_1=\left\{\mathit{Bob}\right\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Cara},t_1)\to t_1=\{\mathit{Cara},\mathit{Bob}\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Alex},t_1)\to t_1=\{\mathit{Alex},\mathit{Cara},\mathit{Bob}\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Bob},t_1,t{r}_a)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Bob},t_1)=\left\{t{r}_a\right\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Cara},t_1,t{r}_t)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Cara},t_1)=\left\{t{r}_t\right\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Alex},t_1,t{r}_m)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Alex},t_1)=\left\{t{r}_m\right\},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_a)\to t{r}_a=\left\{\right(\mathit{read},\mathit{ob}{j}_a),(\mathrm{write},\mathit{ob}{j}_a),(\mathit{read},\mathit{ob}{j}_b\left)\right\},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_m)\to t{r}_m=\left\{\right(\mathit{read},\mathit{ob}{j}_b),(\mathit{read},\mathit{ob}{j}_{\mathit{doctorInfo}}\left)\right\},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_t)\to t{r}_t=\left\{\right(\mathit{read},\mathit{ob}{j}_b\left)\right\},\\ & & T\text{-}W\text{-}A(t_1,w_1)\to w_1=\{t_1,(\mathit{ob}{j}_a,\mathit{ob}{j}_b),1\}\mathrm{.}\end{array}$$

Security Analysis

Given access D F,Q,P S, and Γ, the security analysis takes the form (γ ₁,q,p s,D F) where γ ₁ ∈ Γ is the state, q ∈ Q is the access request, p s ∈ P S is the rule applicable to make a decision regarding an access request and D F ∈{0,1} is the decision function. Given a request q = {u s r,(o p r,o b j)}, if all rules (conditions) in PS are all evaluated as true, then the request is either permitted or denied according to the decision, as described in the access control decision function (Definition 23).

The proof of Example 1, let q = {C a r a,(w r i t e,o b j _b)}. q is an access request from Cara who has been assigned t r _t and wants to write in Alice’s file O B J _B(Alice).

Proof 1

$$\begin{array}{rcl}& & q=\left\{\right(\mathit{Cara},(\mathit{write},\mathit{ob}{j}_b)\left)\right\}\\ & & \mathit{aut}{h}_r\left(\mathit{Cara}\right)=\varnothing \to (\mathit{write},\mathit{ob}{j}_b)\notin \mathit{aut}{h}_r\left(\mathit{Cara}\right)\to \\ & & f(\mathit{Cara},(\mathrm{write},\mathit{ob}{j}_b\left)\right)=G(\mathit{Cara},(\mathit{write},\mathit{ob}{j}_b\left)\right)\\ & & w_1=\{t_1,(\mathit{ob}{j}_a,\mathit{ob}{j}_b),1\},\{t_1,\{\mathit{write},\mathit{ob}{j}_b\left\}\right\}\notin \mathit{tea}{m}_{\mathit{member}}\\ & & G(\mathit{Cara},(\mathit{write},\mathit{ob}{j}_b\left)\right)=0\\ & & f(\mathit{Cara},(\mathit{write},\mathit{ob}{j}_b\left)\right)=0\end{array}$$

It is noted that the access request is mapped to 0 because Cara is not permitted to write Alice’s O B J _B(Alice). With security analysis we can study safety properties, availability and mutual exclusion properties. Given access state γ ₁ and S P ∈ A P, we can answer the questions concerning safety (is u s r ⊂{U S R} possible?) and availability (is u s r ⊂{U S R} necessary?) presented in [45] as follows:

1. Safety: Let usr be a presumably untrusted user. Is u s r ⊂{U S R} possible? In other words, is there a state in which user usr (presumably untrusted) could be included in the user set USR? A “no” answer means the system is safe. In our model, we assume that state γ ₁ fully determines who can perform what on which object. Also, we assume that, in addition to administrative information, S P ∈ A P contains all the information about trusted users in user set (USR). In WBAC, users are considered as the healthcare providers who, on the one hand, are fully trusted and have the authority to (unintentionally) take the system to a state that violates the security requirements, but they are trusted not to do so. On the other hand, an insider who is trusted and included in the user set u s r ∈ U S R can intentionally take the system to a state that violates the security requirements.

2. Availability: Let usr be a presumably trusted user. Is u s r ⊂{U S R} necessary? In other words, in any state, should user usr be allowed to be included in user set USR? In WBAC, the answer should be “yes” because we want every healthcare provider to have access to resources when necessary. But we also want to ensure that every healthcare provider who has permission to access resources is included in user set USR.

Security analysis could ensure that the security requirements of our WBAC model are met, as long as the trusted users behave according to the defined policies. However, since we are dealing with insider issues, we could assume that a trusted user attempts to gain access to an object that is not associated with his/her privileges. The fact that access state γ ₁ (Example 1) limits the user from accessing any object that is not associated with his/her privileges, it does not mean that the user (insider) cannot do it if he/she is motivated and has the capability to do so. However, it can be said that the security of the WBAC model is preserved as long as the trusted users are cooperating and behaving according to the defined policies.

Policy Management

Policy management forms the basis of access control. The security of any access control model is based on how the access control policies are defined and implemented in real situations. A policy should precisely capture the privileges and capabilities of users, and any action taken by users should be allowed by the policy [45]. To support dynamic environments such as healthcare, access policies need to be updated in a timely manner. A change or update in the access control system causes a state change from the current access state γ ₁ (Definition 22) to a new access state (γ _n). Examples of state changes are adding user, deleting user, adding roles, and/or deleting roles. Corresponding to a state change, there could be a policy change. For example, if a new role (r _i) is added to the system, r _i should have a new policy or update an existing policy for it.

Example 2 shows how to revise (if needed) the policy set when the access state of the WBAC system changes.

Example 2

Policy Revision.

Recall Alice’s treatment case and assume that the primary doctor (Dean) decides to consult another physician (gastroenterologist), and Cara cannot help to solve Alice’s case and she must be replaced. Lisa (gastroenterologist) is now joining Alice’s treatment team t ₁ and she will be assigned the thought team role t r _t. Then we have a new access state change γ ₂ as underlined below.

$$\begin{array}{rcl}\mathrm{USR}& =& \{\mathrm{Dean},\mathrm{Bob},\mathrm{Cara},\mathrm{Alex},\underset{\_\_\_}{\mathrm{Lisa}}\},\\ R& =& \{\mathrm{Primary}\text{-}\mathrm{doctor},\mathrm{General}\text{-}\mathrm{practitioner},\mathrm{Gastroenterologist},\\ & & \mathrm{Medical}\text{-}\mathrm{coordinator}\},\\ \mathrm{TR}& =& \{t{r}_a,t{r}_t,t{r}_m\},\\ T& =& \left\{t_1\right\},\\ W& =& \left\{w_1\right\},\\ \mathrm{OBJ}& =& \{\mathrm{ob}{j}_a,\mathrm{ob}{j}_b\},\\ \mathrm{OPR}& =& \{\mathrm{Read},\mathrm{Write}\},\\ \mathrm{PER}& =& \left\{\right(\mathrm{read},\mathrm{ob}{j}_a),(\mathrm{write},\mathrm{ob}{j}_a),(\mathrm{read},\mathrm{ob}{j}_b),(\mathrm{write},\mathrm{ob}{j}_b\left)\right\},\\ \mathrm{AR}& =& \left\{\mathrm{USR}\text{-}R\text{-}A\right(\mathrm{usr},r),\mathrm{USR}\text{-}T\text{-}A(\mathrm{usr},t),T\text{-}W\text{-}A(t,w),\mathrm{...}\},\end{array}$$

where

$$\begin{array}{rcl}& & \mathit{USR}\text{-}R\text{-}A(\mathit{Dean},\mathit{Primary}\text{-}\mathit{doctor})\to \mathit{aut}{h}_r\left(\mathit{Dean}\right)=\left\{\right(\mathit{Primary}\text{-}\mathrm{doctor}\left)\right\},\\ & & \mathit{PER}\text{-}R\text{-}A(\mathit{per},\mathit{Primary}\text{-}\mathit{doctor})\to \mathit{Primary}\text{-}\mathit{doctor}=\left\{\right(\mathit{read},\mathit{ob}{j}_a),\\ & & (\mathit{write},\mathit{ob}{j}_a),(\mathit{read},\mathit{ob}{j}_b),(\mathit{write},\mathit{ob}{j}_b)\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Bob},t_1)\to t_1=\left\{\mathit{Bob}\right\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Cara},t_1)\to t_1=\{\mathit{Cara},\mathit{Bob}\},\\ & & \mathit{USR}\text{-}T\text{-}A(\mathit{Alex},t_1)\to t_1=\{\mathit{Alex},\mathit{Cara},\mathit{Bob}\},\\ & & \underset{\_\_\_}{\mathit{USR}\text{-}T\text{-}A(\mathit{Lisa},t_1)\to t_1}=\{\mathit{Alex},\mathit{Cara},\mathit{Bob},\underset{\_\_\_}{\mathit{Lisa}}\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Bob},t_1,t{r}_a)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Bob},t_1)=\left\{t{r}_a\right\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Cara},t_1,t{r}_t)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Cara},t_1)=\left\{t{r}_t\right\},\\ & & \mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Alex},t_1,t{r}_m)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Alex},t_1)=\left\{t{r}_m\right\},\\ & & \underset{\_\_\_}{\mathit{TM}\text{-}\mathit{TR}\text{-}A(\mathit{Lisa},t_1,t{r}_t)\to \mathit{aut}{h}_{\mathit{tr}}(\mathit{Lisa},t_1)=\left\{t{r}_t\right\}},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_a)\to t{r}_a=\left\{\right(\mathit{read},\mathit{ob}{j}_a),(\mathrm{write},\mathit{ob}{j}_a),(\mathit{read},\mathit{ob}{j}_b\left)\right\},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_m)\to t{r}_m=\left\{\right(\mathit{read},\mathit{ob}{j}_b),(\mathit{read},\mathit{ob}{j}_{\mathit{doctorInfo}}\left)\right\},\\ & & \mathit{PER}\text{-}\mathit{TR}\text{-}A(\mathit{per},t{r}_t)\to t{r}_t=\left\{\right(\mathit{read},\mathit{ob}{j}_b\left)\right\},\\ & & T\text{-}W\text{-}A(t_1,w_1)\to w=\{t_1,(\mathit{ob}{j}_a,\mathit{ob}{j}_b),1\}\mathrm{.}\end{array}$$

Within the new access state γ ₂, a new user called Lisa joins the team. She holds team role t r _t. Similar to Cara, Lisa will get access (read only) to Alice’s O B J _B resources in order to perform her task. Based on the state change here, it is unnecessary to modify the policy because Lisa was assigned with team role t r _t and obtained all permissions associated with t r _t.

Example 3

Policy Revision 2.

Continuing from Example 2, assume that Lisa wants to write in Alice’s O B J _B. In this case, and based on our defined policy for t r _t, Lisa does not have permission to write in Alice’s files. Currently, the system only allows the primary doctor Dean and healthcare providers who are assigned t r _a to write to Alice’s objects. We do not want to assign Lisa to team role t r _a because she is predominantly preoccupied with diagnosing the disease, and there is no urgent need for her to know Alice’s personal information and other information in O B J _A.

To give Lisa permission to write in Alice’s O B J _B, we assume a new team role “evaluator” (Fig. 3) would be added to the system. Evaluator is a sub-team role of thought [2]. Based on our team role classification, access to a collaborative resource can be tailored more specifically by harnessing the stipulated team roles.

Then, we have a new access state γ ₃ where Lisa will be assigned a new team role. Let the new team role be t r _evaluator, and we have (the complete γ ₂ will not be repeated but the part that would be changed is shown):

$$\begin{array}{rcl}& & \underset{\_\_\_}{\mathrm{TR}=\{t{r}_a,t{r}_t,t{r}_m,t{r}_{\mathrm{evaluator}}\}},\\ & & \underset{\_\_\_}{\mathrm{TM}\text{-}\mathit{TR}\text{-}A(\mathrm{Lisa},t{r}_{\mathrm{evaluator}})\to \mathit{aut}{h}_{\mathit{tr}}(\mathrm{Lisa},t_1)=\left\{t{r}_{\mathrm{evaluator}}\right\}}\end{array}$$

Now, based on the state change, we need to modify our access policies by adding a policy for the new team role t r _evaluator. In this case, it is only necessary to modify a policy in collaborative policy set CP (Definition 12) since the changes are done on the collaborative resources. In the new policy, a write operation can be performed on an object protected by any user with associated team role t r _evaluator. Formally: $\mathrm{ac}{t}_{t{r}_{\mathrm{evaluator}}}(\mathit{usr},t)\wedge \mathrm{PER}\text{-}\mathit{TR}\text{-}A(t{r}_{\mathrm{evaluator}}=\{(\mathrm{read},\mathit{ob}{j}_b),(\mathrm{write},\mathit{ob}{j}_b)\left\}\right)\iff \mathrm{Permit}$.

In Example 3, the policy change (Definition 14) entails adding a new policy for the new team role t r _evaluator. Therefore, it becomes P S ^′ = P S ∪ P ^′ in access state γ ₃. The complexity of access control policy revision is dependent on a number of factors, such as the number of users, number of roles, and number of resources. Due to these factors, one important aspect is to guarantee policy completeness [57] and consistency [58].

Policy completeness means that the decisions the access control model should take are completely specified in the access policy. That is, there is no situation in which the system cannot reach the goal specified by the policy because it lacks an appropriate defined policy set for any access request [40]. For example, let P S = {p ₁,p ₂,...,p _n} be a set of policies in PS for team roles and p ₁ = t e a m r o l e(t r _t) ∧ r e s o u r c e(O B J _B) ∧ o p e r a t i o n(r e a d) → a l l o w. PS is said to be incomplete if there is no policy defined for every particular team role.

Detecting incompleteness in a large set of policies is very cumbersome. This challenge increases when the number of users, roles, resources, and environment conditions (e.g., time and location) are included in the policies [57]. The problem of incompleteness has been studied intensively in the access control community [57]. Therefore, automated mechanisms or tools are highly needed to assist policy administrators with detecting incompleteness and validating policy sets. However, policy incompleteness is out of the scope of this study. In our work [4], incompleteness is resolved by denying all access in unspecified cases.

Policy consistency means there are no contradictions or inconsistencies in a particular set of policies. Policies are said to be inconsistent for a specific situation when different incompatible policies are applicable [58]. Some researchers have attempted to solve the problem of inconsistency by adding special meta-rules to access control policies [56]. For example, XACML contains conflict resolution combining algorithms (e.g., deny-overrides algorithm, first-applicable algorithm, etc.) for combining rules and policies to solve a decision conflict between multiple policies [46].

Another important aspect of policy revision is the correctness of policy implementation. In our work [7], we apply modeling checking tool ACPT (access control policy testing) [38] to specify policy models and their properties during policy modeling to assure that WBAC policies satisfy the security properties intended by the model.

WBAC Model Performance Evaluation

In this section, we apply an evaluation framework adapted from [11, 12] to compare the performance of our model with the traditional RBAC and ABAC models. Since the WBAC model is based on RBAC and ABAC, here, we want to understand how WBAC model performance responds to changes in dynamic environments. The evaluation framework uses big O notation [17, 21] to describe the model’s functional capabilities. The framework supports a quantitative analysis based on the core function of access control as follows.

Definition 24

Authorization complexity is the process of evaluating the complexity of the access control decision function (Definition 23) to make an authorization decision (permit or deny) for an access request by a user to perform an operation on an object.

Definition 25

Permission modification is the process of modifying and updating the sets of permissions associated with roles and team roles to meet the authorization requirements of an organization. The following schema formally describes permission modification, where k is the number of roles or team roles represents changes.

Definition 26

Privilege modification is the process of changing and modifying user membership into a role or team role (e.g., Example 2). Formally:

Definition 27

Revocation process is the process of revoking user membership in a role or team role. In WBAC, there are four types of membership revocation: (1) user revocation, where the user membership of a role is revoked; (2) team membership revocation, where the user is removed from the team by revoking his/her team role; (3) team revocation, where a complete team (t) is revoked from work (w); and (4) work revocation, the complete collaborative work is revoked. Formally:

In the case of work revocation, the complete set of teams assigned to work is automatically revoked.

Definition 28

Permission review is the process of reviewing all available permissions (role and/or team role) assigned to a particular user. This can be done by checking the set of authorized role/team role (Definition 6) assigned to the user.

WBAC Performance Analysis

1. Authorization complexity: WBAC makes an access decision based on the role and team role assigned to a user as well as the permission associated with the role/team role. When a user requests an operation over an object, WBAC checks what role and/or team role is assigned to this user and the permission associated with the user’s active role or authorized team role, then returns with an access decision. The access control decision function (DF) (Definition 23) takes the access request (Q) (Definition 21) as an input and returns a Boolean value presenting the access control decision. The pre-condition for the success of DF is as shown in (21) and (22). In the worst case, the complexity of WBAC’s DF is O(c a r d(a c t _r(u s r)) + (c a r d(w) × c a r d(t e a m _member))).

2. Permission modification: In WBAC, permissions are modified by updating the permissions associated with roles and team roles in P E R-R-A(p e r,r) (5) and P E R-T R-A(p e r,t r) (6) without changing the privilege for each user. The permission modification function (Definition 25) takes p e r ₁, p e r ₂ ∈ P R E, and r ∈ R or t r ∈ T R as input. The function revokes p e r ₁ if p e r ₁ is mapped to r in P E R-R-A(p e r,r), and then grants r the new permission p e r ₂. The case is similar to team role tr. In this case, the complexity of the WBAC permission modification function is $O\left({\sum }_{i\in k}\mathit{card}\right(r_i\left)\right)$, where k index of roles and team roles to be changed. In the worst case, it is assumed that the function would go through the complete set of R and TR to find the p e r ₁ to be updated. However, in practice, the set of TR is very small. Therefore, the realistic complexity for team roles policy modification would be O(1).

3. Privilege modification: WBAC handles the change of user privilege by modifying user membership into role or team role relations ((1) and (3)). When a user permission changes, the user is revoked from the current a u t h _r(u s r) and/or a u t h _tr(u s r,t) (authorization constraint Section 3.2 must be true) and the new privilege is established based on the new access requirements.

   The privilege modification function (Definition 26) takes r ₁, r ₂ ∈ R and u s r ∈ U S R as input, deletes the assignment of usr to r ₁ and establishes a new assignment of usr to r ₂. The function goes through the complete set of a u t h _r(u s r) ∈ u s r to find the r to be updated. Therefore, the complexity of the WBAC privilege modification function is O(c a r d(a u t h _r(u s r))). In case of team role, the privilege modification function takes t ∈ T, u s r ∈ U S R and t r _a, t r _t ∈ T R as input, deletes the assignments of usr to {t,t r _a} and establishes a new assignment of usr to {t,t r _t}. The difference between role r and tr is that, in tr the function goes through all teams to check the team membership and find the assignment of {t,t r _a} to usr and update it accordingly. Therefore, the complexity of the WBAC privilege modification function in case of team role is O(c a r d(t e a m _member)).

   In the worst case, the privilege modification function goes through the complete set of a u t h _r(u s r) ∈ u s r and t e a m _member to find the assignment of role and team role to be updated. Thus, the complexity of the privilege modification function is O(c a r d(a u t h _r(u s r)) + c a r d(t e a m _member)).

4. Revocation: WBAC handles four revocation functions as shown in Definition 20.

   • The user role revocation function takes user u s r ∈ U S R as input and deletes all user assigned relations in U S R-R-A(u s r,r). The function goes through the complete set of a u t h _r(u s r) to find all usr assignments to be deleted. In this case, the complexity of the WBAC user revocation function is O(c a r d(a u t h _r(u s r))).
   • The team membership revocation function takes t ∈ T, t r ∈ R T and u s r ∈ U S R as input and goes through the complete set of t e a m _member to delete the user team membership by revoking his/her team role. In the worst case, the complexity of the team membership revocation function is O(c a r d(t e a m _member)).
   • The team revocation function takes w ∈ w and t ∈ T as input and revokes the complete team from the work. In the worst case, it is assumed to go through the whole set of W to find the assigned team to be revoked. Thus, the complexity of the team revocation function is O(c a r d(w)) + (c a r d(t))).
   • The work revocation function takes w ∈ W as input and goes through the complete set of W to find the w to be revoked by changing the work state (Definition 10) to 0. Thus, the complexity of work revocation function is O(c a r d(W)).

5. Permission review: The permission review function (Definition 28) determines what permission (roles and/or team roles) a single user has. It takes usr as input and goes through the set of a u t h _r(u s r) and t e a m _member to find all permissions assigned to usr. The complexity of the permission review function is $O\left(\mathit{card}\right({\sum }_{i=1}^n\mathit{card}\left(\mathit{aut}{h}_r\right(\mathit{usr}\left)\right)+\mathit{card}\left(\mathrm{tea}{m}_{\mathrm{member}}\right))$.

Comparing WBAC with the RBAC and ABAC Models

WBAC model was proposed to support the collaboration requirements and improve the manageability of access control. Here, we compare WBAC with RBAC and ABAC. Table 2 presents a comparison summary of the performance complexity of RBAC, ABAC and WBAC.

Table 2.

Comparison summary of the performance complexity of RBAC, ABAC, and WBAC

Function	Access control model
	RBAC	ABAC	WBAC
Authorization complexity	O(c a r d(R))	O(c a r d(P S) + c a r d(R U))	O(c a r d(a c t r(u s r)) + (c a r d(w) × c a r d(t e a m member)))
Permission modification	$O\left({\sum }_{i\in k}\mathit{card}\right(r_i\left)\right)$	O(c a r d(P S))	$O\left({\sum }_{i\in k}\mathit{card}\right(r_i\left)\right)$
Privilege modification	O(c a r d(U S R))	O(1)	O(c a r d(a u t h r(u s r)) + O(c a r d(t e a m member)))
Revocation	O(c a r d(U S R))	Undefined	O(c a r d(a u t h r(u s r)) + O(c a r d(t e a m member)))
Permission review	O(c a r d(U S R) × c a r d(R))	O(c a r d(P S))	$O\left(\mathit{card}\right({\sum }_{i=1}^n\mathit{card}\left(\mathit{aut}{h}_r\right(\mathit{usr}\left)\right)+\mathit{card}\left(\mathrm{tea}{m}_{\mathrm{member}}\right))$

RBAC makes authorization decisions based on a set of permissions associated with the roles. Therefore, when a user requests an operation over an object, RBAC checks the user’s role and if the requested permission is associated with the role, access is permitted; otherwise, it is denied. In the worst case, the authorization complexity of RBAC is O(c a r d(R)) (Table 2) [11]. ABAC makes authorization decisions based on a user’s attributes, object’s attributes, and operation’s attributes against the rules in the applicable policy sets (PS) [12]. ABAC takes the user’s attributes, object’s attributes, and the requested operation and checks them against the applicable policy. If the policy is satisfied with the requested attributes, access is permitted, otherwise the access is denied. In the worst case, the complexity of the ABAC authorization decision is O(c a r d(P S) + c a r d(R U)), where SP is the policy sets and RU is applicable rules.

To compare the authorization complexity of the access decision function of RBAC with WBAC, we assume the active role assigned to a user in RBAC is equal to the active role (a c t _r(u s r)) assigned to the user in WBAC. However, the WBAC model was proposed to support the collaboration requirements and improve the manageability of access control during collaboration. Thus, WBAC adds insignificant time complexity when checking the collaboration policies (Definition 12). WBAC has to check the set of active work W and teams assigned to w _i in order to make the authorization decision. RBAC denies an access request if a user does not have a role, while WBAC investigates further to check if the user is invited to the collaborative work. As we mentioned earlier, in most cases, especially in healthcare organizations, the invited user is an outsider who does not have an organization role [3]. Therefore, considering the collaboration requirements [4] and the granularity provider by WBAC based on the team role classification as well as object classification, the difference in time complexity added by T and TR is insignificant. Compared with WBAC, ABAC access evaluation depends on the process of finding the set of applicable policies in the complete policy set and the number of applicable rules that need to be evaluated.

Concerning the permission modification of WBAC and RBAC, WBAC performs similar to RBAC. RBAC makes the permission change by modifying and updating the permission sets associated with roles without changing the privileges for each user in the system. In the worst case, the permission modification of RBAC is $O\left({\sum }_{i\in k}\mathit{card}\right(r_i\left)\right)$, where it is assumed to go through the complete set of R to find the permission to be changed or updated. We believe the proposed team roles do not add much complexity to WBAC because there is only O(1) and WBAC performance can be improved by the way the data structures are used to store R and TR as well as what searching function or algorithm is used to find r ∈ R and t r ∈ T R to be updated for the changes. ABAC treats permission modification differently from RBAC and WBAC. It modifies the permission by updating or changing all the relevant attributes associated with the users. However, permission modification in RBAC is a very complex process. The complexity (O(c a r d(P S))) is dependent on the number of attributes used in the policy, namely 2ⁿ, where n is the number of attributes [11].

Considering the privilege modification of RBAC is O(c a r d(U S R)) as shown in Table 2, RBAC changes and updates the privilege by modifying the user membership into roles. WBAC handles user permission change similar to RBAC. Thus, the modification of user privilege in WBAC is as complex as in RBAC because in RBAC it is assumed that [11] the privilege modification function goes through the complete set of users to find the user role assignment that needs to be changed. In WBAC, the complexity is O(c a r d(a u t h _r(u s r)) + O(c a r d(t e a m _member))), in which it is assumed that set (c a r d(a u t h _r(u s r,t)) ≤ (c a r d(R)) while set (c a r d(t e a m _member) is also less than or equal to O(c a r d(U S R)) in RBAC. ABAC makes the privilege modification based on the user attribute and policy. The complexity of modifying user privilege is O(1). For example, if the user changes his/her position, only the position attribute needs to be changed. Moreover, all relevant policies associated with the old and new positions need to be updated to accommodate the current requirements.

The revocation process in WBAC is a little more complex compared to RBAC. Due to the use of work entity W to manage the collaborative work, WBAC adds four processes to the revocation process as shown in Definition 27. The user role revocation process in WBAC is similar to RBAC. WBAC and RBAC handle user role revocation by modifying the user membership in the U S R-R-A(u s r,r) assignment relation. The team membership revocation process in WBAC updates the user membership in the U S R-T-A(u s r,t) assignment relation. Its complexity is O(c a r d(t e a m _member)), whereby the process must check the user memberships in all teams to find the team in which the user membership needs to be changed. Moreover, the team revocation process revokes the team assignment in relation T-W-A(t,w). Also, in WBAC, work w has to be revoked upon the completion of work (patient treatment). Once w is revoked, complete set of teams assigned to w will be revoked.

The permission review in RBAC is done by checking the set of permissions associated with the roles assigned to the user. The complexity is O(c a r d(U S R) × c a r d(R)) and WBAC handles this in a similar manner to RBAC. In WBAC, the system checks the set of a u t h _r(u s r)) and the set of t e a m _member for each user to determine all available permissions associated with a user’s authorized roles and authorized team roles. ABAC complicates the permission review because a large set of policies must be checked (O(c a r d(P S))) to determine the available permissions for every user.

Discussions, Future Work, and Conclusions

In this section, discussions, future works, and conclusions are presented.

Discussions

The healthcare environment is complex environment, where we have strong security and privacy requirements. The environment can be highly dynamical and the total number of objects and subject involved is potentially very high. That is, for the actual collaboration cases, only a fairly small subset of object and subjects will be involved, but we cannot know the participants in advance. One example of such a situation is explained in our case scenario (Section 2), which may not be predictable and it would be hard to express the condition of who should join the collaboration and when Dean necessitates collaborative support from other parties. Moreover, in deciding on the extent and limit of resource sharing, for instance, in the case of Alice’s treatment, which sensitive data should be disclosed to an assisting practitioner so collaboration can be effective, and which should be hidden to safeguard the patient’s privacy?

WBAC was proposed to address these concerns and support the security and collaboration requirements in access control [2, 4]. The major contributions of the WBAC model include ensuring that access rights are dynamically adapted to the actual needs of healthcare providers and providing fine-grained control of access rights with the least privilege principle, whereby healthcare providers are granted minimal access rights to carry out their duties. In our case scenario (Section 2), it was noted that primary doctor Dean could not solve Alice’s case alone. He invited a multidisciplinary team including Bob, Cara, and Alex to help. In this team, Dean is the core physician in the collaborative work and serves as the group manager. He is responsible for initiating the work (Alice’s treatment case) and choosing practitioners (group of doctors) who may be required to attend Alice’s consultation and treatment. This implies that Dean holds the main role. In other words, he owns the initiated collaborative work. Therefore, Dean is given a full access (based on his role as primary physician, Table 1) with regard to patient-related information. Bob, Cara and Alex are assigned to team roles based on the job function they will perform in Alice’s treatment.

The main advantage of WBAC is that it simplifies manageability in terms of modifying and updating the sets of permissions associated with roles and team roles, modifying and updating user-role and user-team role assignment, as well as reducing the complexity of permission reviews. Another advantage of WBAC is the least privilege and separation of duties (SoD) of team membership. Team roles define the least privilege and SoD that a user is required to perform on a particular object and also to restrict objects that are considered very sensitive (need-to-know principle). Users are assigned to classified team roles based on their required jobs during collaboration and no user should have more rights that can be misused. This minimizes potential damage due to unauthorized and improper access.

WBAC inherits the disadvantage of RBAC in the way that it requires very complex role engineering in terms of role predefining and role support. It necessitates intimate knowledge of the objects’ (i.e., healthcare records) classification and how permission (i.e., operation on an object) is granted to what role/team role. Healthcare records contain a wide range of information and healthcare record classification is also expensive as it requires skilled and knowledgeable people. Failure to achieve appropriate classification of healthcare records would render WBAC less secure. Other concerns with collaboration using WBAC are collaboration policy conflicts and permission constraints between collaborative parties. A collaboration pattern for information sharing is required to provide the set of rules regarding how the collaboration should be carried out. A control guideline is also required to secure collaboration between collaborative parties.

Although many challenges remain, WBAC seems to be a very promising candidate indeed. We are optimistic that WBAC can handle dynamic environments and scales well. This conclusion is based on case evaluations. While this allows for optimism about the suitability of WBAC for use within cooperative healthcare environments, final judgment must be reserved until field tests have been conducted.

Future Work

This research work can continue in the following directions.

1. Prototype the functionality to be implemented: develop and prototype the WBAC functionality to be implemented to understand the possible difficulties in managing the model during actual implementation; model performance validity could also be evaluated in terms of resource consumption, e.g., time and computational capability.

2. Cross-Border Healthcare Collaboration: European Union (EU) countries are seeking new ways to modernize and transform their healthcare systems by using information and communications technology in order to provide EU citizens (patients) with safe and high quality treatment in any EU country [20, 66] (EU directive 2011/24/EU framework on cross-border health care collaboration in the EU [25–27, 52]). Access to cross-border healthcare in the EU has undergone many developments in both academia and industries to meet EU healthcare domain needs. The eHealth Action Plan 2012–2020 [24] and the EU-funded project “UNIversal solutions in TELemedicine deployment for European HEALTH care” (United4health) [64] are among such developments. The aim of these projects is to provide solutions to improve healthcare quality, provide access to a high-quality healthcare system to all EU citizens around Europe, and support close cooperation between healthcare professionals and care providers from different organization. Therefore, in the future, the WBAC model can be further investigated in terms of cross-border healthcare collaboration. The plan is to evaluate the validity of the model to provide solutions to improve healthcare quality, provide access to a high-quality healthcare system to all EU citizens around Europe, and supporting secure cooperation between healthcare professionals and care providers from different organization.

Conclusions

According to the security and performance analysis of the proposed model, WBAC is suitable for collaborative healthcare systems in addressing information sharing and information security matters. It caters to the requirements of access control in collaborative environments and provides a flexible access control model without compromising the granularity of access rights. Moreover, this model is secure and easy to manage for supporting cooperative engagements that are best accomplished by organized, dynamic teams of healthcare practitioners within or among healthcare organizations whose objective is to achieve a specific work (patient treatment case). We believe WBAC meets our expectation of allowing fine-grained access control as well as enhances the practicability and manageability of access control in dynamic collaboration environments. Our conclusion is based on case evaluation. While this allows us to be optimistic about the suitability of WBAC for use within cooperative healthcare environments, we must reserve final judgment until field tests have been conducted.