## 4 Workflow-Based Access Control with Authorization Policies
### Access Control Language  
Discretionary Access Control (DAC), Mandatory Access Control (MAC) and Role Based Access Control (RBAC) ([19; 20; 21]) are several well-known identity-based access control models. Recently, there has been growing interest in Attribute-Based Access Control (ABAC) ([22]), as it offers more expressivity and flexibility compared to the aforementioned access control models. The ABAC model grants access rights to subjects through the use of policies or rules that combine various types of attributes to facilitate user access to the right resources under the right conditions:  
* A resource defines the data, system component or service to be accessed. * The subject is the actor who makes a request to access a certain resource. * The action declares the operation (e.g., read, write, update, delete) on the resource for which permission is requested. * The environment is a set of attributes (independent of a particular subject, resource or action) that is relevant to an authorization decision. In policy-based access control (with the eXtensible Access Control Markup Language (XACML) 3.0 specification ([23]) being the industry standard), regulation of access to protected resources is expressed external to the applications as high-level rules that define who has access to what resources under what conditions. In XACML, a policy set represents a container of other policy sets and policies (see Figure 6). A policy consists of zero or more rules. Each rule can specify certain conditions as additional constraints to determine whether a rule applies, and the desired effect (i.e., permit or deny). A policy set, policy and rule can define a target, which lists the conditions that determine whether a policy applies to a particular request. Additionally, a policy set declares a policy combination algorithm (e.g., permit overrides and deny overrides), and a policy declares a similar rule combination algorithm. An XACML 3.0 policy is defined in XML and is therefore fairly complex to parse and modify. Additionally, for workflow-based authorization with delegated policy evaluation (each microservice evaluates part of the policy based on its own information), our framework must be able to frequently and dynamically rewrite authorization policies to reduce policy complexity after partial evaluation. As XACML is less suited for such purposes, we defined a more lightweight access control policy language based on the JavaScript Object Notation (JSON) specification leveraging the most important concepts as XACML, but with a few simplifications. Figure 7 illustrates our policy language by means of a small example. Each authorization policy has a unique identifier and a version number with an optional description that expresses the corresponding permissions in a human-understandable language. Resources are identified with a reference to the relevant microservice (in the example patientappointments) and path, and the four actions (i.e., read, write, update and delete) correspond to the typical RESTful Hypertext Transfer Protocol (HTTP) requests (i.e., GET, POST, PUT and DELETE). Our policy language allows for variable binding in resource identifiers, as illustrated for the policyid variable. Based on the resource description of the access request, the variable will be instantiated so that it can be used in the remainder of the policy evaluation and, more particularly, in the evaluation of the conditions. Note how the resources attribute refers to a single entity. Our policy language also allows a list of resources in a similar way as for the actions attribute. The effect attribute is either permit or deny. The conditions attribute is a list of Boolean expressions with the implicit assumption that the conditions are evaluated in Conjunctive Normal Form (CNF), i.e., an AND of ORs. The current example has only one equality condition. Other condition expressions are!=, >, <, >= and <=. If multiple conditions are defined, they all have to be fulfilled.