Getting Started with the Basic Scenario

For getting started in the use of authorization policies let us consider a simple scenario and some examples of authorization policies. Let us assume that the default authorization policy is ALL+, meaning that all actions are authorized unless a negative authorization policy is specified. Let us start the Ponder2 interpreter loading the files for building the hospital domain structure and the managed objects. The command line arguments are shown below:

-auth allow -boot hospital/hdomain.p2 -boot hospital/basic/nurse-settings.p2 -boot hospital/basic/patient-settings.p2

The option -auth allow tells the interpreter to instantiate the PAF and that the default authorisation policy is ALL+.The file hospital/hdomain.p2 contains the definitions for loading the hospital domains as shown in the Figure below. The file hospital/basic/nurse-settings.p2 imports a Nurse managed object in the /personnel/nurse/ward1 path. Similarly, the file hospital/basic/patient-settings.p2 loads a Patient managed object in the /patient/ward1 path.

basic.gif

The setting file for the patient contains also the definitions of the authorisation policies A1, A2, and A3.

The code excerption below defines the authorisation policy A1.

  21 root/tauthdom at: "a1" put: (newauthpol subject: root/personnel/nurse/ward1/nurse1
  22                                        action: "getrecord"
  23                                        target: root/patient/ward1/patient1
  24                                        focus:"t").
  25 root/tauthdom/a1 reqneg.
  26 root/tauthdom/a1 active: false.

In line 21, the new policy is created in the domain /tauthdom (target authorisation domain) using the factory newauthpol. When an authorisation policy is created 4 arguments need to be given. The first argument sets the path of the subject of the action. In this case, the subject path points to nurse1. The second argument specifies the action that is controlled by this authorisation policy, that in this case is the getrecord method (see line 22). The third argument is the path to the target. The last argument specifies the focus of the policy. As we said, our authorisation policies can be specifies for either a subject or a target side of an action. If this argument is set to "s" then the policy is a subject authorisation, meaning that it will be enforced at PEP1 and PEP4. While setting the argument to "t" (as in line 24) the authorisation policy will be enforced at PEP2 and PEP3.

Line 25 sets that the policy is negative for the incoming part. This means that if such policy is enforced at PEP2 then the nurse1 cannot invoke the getRecord method of patient1. Line 26 is used to (de)activate the policy. As it is, the policy is not active and will not have any effect on the execution of the action. If we run the interpreter with this setting and invoke the getRecord method from nurse1 then the operation will succeed.

Now, let's activate policy A1 setting active to true, as show in line 26 below:

  26 root/tauthdom/a1 active: true.

Starting again the interpreter and executing the action from the nurse GUI we obtain the following result:

basic-scenarioGUI.gif

As we can see from the output panels of the nurse's GUI, the nurse managed object tried to access the record of patient1 but an authorisation exception occurred. This because at PEP2 the authorisation policy A1 was enforced and since A1 is a negative authorisation policy the action was not allowed.

Next, let's deactivate policy A1 and activate policy A2 that is shown below:

  33 root/tauthdom at: "a2" put: (newauthpol subject: root/personnel/nurse/ward1/nurse1
  34                                         action: "getrecord"
  35                                         target: root/patient/ward1/patient1 focus:"t" ).
  36 root/tauthdom/a2 reqneg.
  37 root/tauthdom/a2 reqcondition: [ :nurselevel | nurselevel < 3]. //set the condition
  38 root/tauthdom/a2 active: true.

This policy is similar to A1 except that it as a condition on the incoming part. Conditions can be specified on the arguments of the method that the policy controls. In particular, the condition in policy A2 is specified on nurselevel that is an argument of the getrecord method. This means that policy A2 is applicable only to nurses with a level less then 3. In other words, when policy A2 is enforced, any nurses that have a level less then 3 are not allowed to access patient1's record. Basically, if we run the example with the default nurse level (which is 4) then the action is executed. When the level is set to 2 then an authorisation exception occurs. The figure below shows the nurse GUI after the execution of the operation using the default nurse level, a level of 3 and finally a level of 2. When the level was set to 2 the authorisation exception is thrown:

basic-scenarioGUI2.gif

This behaviour can be explained as follows. The only authorisation policy that is active is policy A2. When the PAF search for a valid policy to enforce at PEP2, A2 is selected. However, before applying the policy its condition must be evaluated. For the first two executions the condition yelds false (since the level of the nurse is never strictly less than 3) and the policy is not applicable. Since there are no other policies, the PAF uses the default authorisation policy which is ALL+ and the action is allowed. In the last execution however, the condition yelds true, the policy A2 is enforced and the action is not allowed.

Finally, the last policy to consider is policy A3 that is shown in the excerpt below

  45 root/tauthdom at: "a3" put: (newauthpol subject: root/personnel/nurse/ward1/nurse1
  46                                         action: "getrecord"
  47                                         target: root/patient/ward1/patient1 focus:"t" ).
  48 root/tauthdom/a3 reqneg.
  49 root/tauthdom/a3 reqcondition: [ :nurselevel | nurselevel < 3].
  50 root/tauthdom/a3 repneg.
  51 root/tauthdom/a3 repcondition: [ :patrecord | patrecord =="[name= Harry;age= 12;symptom=BonelessArm]"].
  52 root/tauthdom/a3 active: true.

Similarly to A2, policy A3 has a condition for the requesting part (PEP2). Additionally, A3 is set to be a negative authorisation policy also for the replying part (PEP3) with a condition block, as specified in line 50 in line 51. respectively. The condition in line 51 says that if the patient's record (that is the value returned by the action) is equals to "[name= Harry;age= 12;symptom=BonelessArm]" then the result is not to be returned. The execution of the scenario when such a policy is activated is shown in the figure below:

basic-scenarioGUI3.gif

At PEP2 policy A3 is not enforced since the nurse level was greater then 3 and its condition for the incoming part yelds false. The action is executed by the patient1 (as we can see from the patient GUI in the right hand side). However, at PEP3 the policy A3 is enforced since the return condition yelds true and an authorisation exception is thrown.

The AdvancedScenarios page describes how to define more advanced policies and provides some details on the conflict resolution strategy that PAF uses.

BasicScenario (last edited 2008-05-17 20:53:17 by GiovanniRussello)