## 4 Workflow-Based Access Control with Authorization Policies
### Access Control Language
The first condition states that the variable patientid must be equal to the id attribute of the subject or to the admin user. If other conditions exist under which access should be granted, then this can be realized with another policy. Figure 8 depicts a policy set holding a list of policies. The salience attribute defines the evaluation order of the different policies. Figure 6: Metamodel of authorization policy language. * (1) {
* \"policy\": {
* \"/ List of resources including all appointments of a given patient \"resources\": \"patientappointments:$[patient]/appointments\", \"actions\": [ \"read\", \"write\", \"update\", \"delete\" ], \"effect\": \"permit\", \"conditions\": [ {
* \"=\": {
* \"// The subject is either the patient himself OR the system administrator \"subject:id\": [\"\$[patient]\", \"admin\"] } },{
* \"=\": {
* \"=\": {  
Our framework imposes a default policy that denies access to all resources. If multiple policies exist for a given resource, all with a permit effect, then access is granted if the conditions of at least one policy hold (i.e., a permit-overrides policy combination). If one or more policies declare a deny effect, then the first policy whose conditions are fulfilled will determine the outcome (i.e., a first-applicable policy combination). This means that the order of policy evaluation plays a role. The salience attribute will determine the order in which policies are evaluated, i.e., policies with a higher salience value will be evaluated first. If the salience attribute is not specified, a default value of 100 is assumed, and policies with the same salience value are evaluated in a non-deterministic order. A schematic overview of the policy evaluation is given in Figure 9.  
In summary, the simplifications imposed by our JSON-based access control policy language with respect to the XACML specification are listed below:  
* There is always a default and implicit deny policy
* Rule conditions are declared in conjunctive normal form
* No explicit definition of policy targets. * Simplified policy combinations with salience values  
A first advantage is that there is always a policy decision (i.e., permit or deny), whereas XACML policies may result in a indeterminate or notapplicable decision outcome. The conjunctive normal form has the advantage that if one of the constituents of the conjunction fails, then the whole conjunction is not fulfilled. In that case, the policy set (as depicted in Figure 8) can be reduced in complexity simply by removing that particular policy from the policy set. XACML policies typically define targets that indicate which conditions must be fulfilled before a policy set, policy or rule is evaluated. These conditions complement the ones of the rules that produce the permit or deny decision. Our policy language eliminates this dual constraint complexity, combining all the conditions in the corresponding conditions section of the policy (see Figure 7). Last but not least, these simplifications make it easier for policy editors to understand and reason about the correctness of a policy. Figure 9: Policy evaluation flow.