## 4 Workflow-Based Access Control with Authorization Policies
### Delegated Policy Evaluation
#### 4.3.1 Enforcing the Need-To-Know Principle through Delegation  
The need-to-know concern imposed for accessing medical records requires that there is a future patient appointment, either scheduled by the patient himself/herself (and implicitly approved) or scheduled by the physician and explicitly approved by the patient. As illustrated in Figure 7, the Patient Appointment microservice offers a REST interface to retrieve all appointments for a given patient, as shown below:  
\"patientappointments:${patientid}/appointments\"  
When a read access request to a set of resources is issued (in this case, a list of appointments), only those resources are returned for which access is granted. A read access request can also target a specific resource, such as an appointment with a given identifier, as shown below:  
\"patientappointments:${patientid}/appointments/${appointmentid}\"  
In that case, either the appointment is returned if access is granted, or otherwise, nothing is returned if access is denied or the appointment does not exist.  
The authorization policy in Figure 11 is put in place of the Patient Appointment microservice, stating that only the patient and the physician are allowed to read an existing and write a new appointment, and only the organizer of the appointment (patient or physician) can update an existing appointment. Let us assume that access to the medical records of a patient is granted according to the following simplified authorization policies:  
* A patient can read his/her own medical records
* A physician (or any other healthcare professional) can read and write medical records of a patient only if he/she has established a therapeutic relationship with the patient
* A physician can only access the medical records he/she created himself/herself, unless the patient provided informed consent to share his/her medical records with other healthcare professionals  
To enforce the need-to-know principle, the following policy with additional conditions must be checked before access is granted.  
The policy in Figure 12 states that there must be an appointment in the future that the patient accepted, either implicitly as he/she scheduled it himself/herself or explicitly after someone else scheduled it. The patient acceptance is necessary as the mere existence of an appointment would allow the physician to schedule an appointment with a patient (with which he/she already has a therapeutic relationship), hereby bypassing the need-to-know access restriction of the Medical Records microservice.  
A straightforward solution would be to augment the above policy to grant the Medical Records microservice read access to all patient appointments. However, this is a potential security or privacy risk as sensitive information is shared with other parties. In case of a data breach with a third party microservice, sensitive information might leak, even if the microservice from which the data originated is properly secured. Furthermore, such a solution would complicate the definition and the maintenance of the authorization policies whenever new microservices are added to the system.  
Our solution is to define the need-to-know access restriction at the level of the Medical Records microservice, but to outsource the evaluation to the Patient Appointment microservice, hence the term 'delegated policy evaluation'. The policy evaluation then becomes a workflow of its own orthogonal to the data processing workflows on top of the core functionalities of the microservices.  
Figure 11: Authorization policy for the Patient Appointment microservice.