Advanced Example 1

Description

This example shows that the XACL language simultaneously support multiple semantic interpretations for the access control policies. The target XML document is open_target.xml, which is identical with the one of Simple Example 2. While the access decisions in this example are similar to those in the simple example 2, the semantics for the access control policies are almost the opposite. For example, this applies an "open policy" instead of a "closed policy" as described below.

Policy Description

In the XACL language, the semantics for the policies are specified in the policy property section. This example specifies that read and write actions take the open policy and the grant-takes precedence policy. If the policy property section is omitted like the Simple Example 2, the closed policy and the denial-takes precedence policy is assumed by system default.

The associated policy is described as follows:

• The first rule below says that nobody is allowed to perform actions on any privacy related fields.
• The second rule says that people in the personnel group can read the privacy related fields.
• The third rule says that people in the personnel group who is authenticated to have the Manager role can write the privacy related fields.

<policy xmlns="http://www.trl.ibm.com/projects/xml/xacl">

  <property>
    <action_definition name="read" policy="open_policy"/>
    <action_definition name="write" policy="open_policy"/>
    <policy_definition id="open_policy">
      <conflict_resolution name="gtp"/>
      <default permission="grant"/>
    </policy_definition>
  </property>

<!-- ===================================================
  1. No one is allowed to perform actions on the salary field
 =================================================== -->
  <xacl>
    <object href="/personnel_info/entry/*[@category='private']"/>
    <rule>
      <acl>
        <action name="read" permission="deny"/>
        <action name="write" permission="deny"/>
        <action name="create" permission="deny"/>
        <action name="delete" permission="deny"/>
      </acl>

<!-- ===================================================
  2. People in the personnel group can read any
     elements that are categorized as private.
 =================================================== -->
      <acl>
        <subject>
          <group>personnel</group>
        </subject>
        <action name="read" permission="grant"/>
      </acl>

<!-- ===================================================
  3. Manager in the personnel group can write any
     elements that are categorized as private, provided
     the access is logged.
 =================================================== -->
      <acl>
        <subject>
          <role>Manager</role>
          <group>personnel</group>
        </subject>
        <action name="write" permission="grant">
          <provisional_action timing="before" name="log"/>
        </action>
      </acl>
    </rule>
  </xacl>
</policy>

Propagation Policies

The XACL language allows users to specify how the access control rules or decisions should be propagated along the hierarchical structure of a target XML document (the object hierarchy), and the role and group hierarchies. They can be specified using <propagation_along_oh>, <propagation_along_rh>, and <propagation_along_gh> elements. For example,

• <propagation_along_oh direction="downward" permission="grant" name="or"/> means that any access decision with the grant permission propagates downward along the object hierarchy in the override ("or" in short) manner.

How to Run the Example

Basically, follow the instructions described in Simple Example 2.

1. Run the XACL Visual Test Tool.
2. Open the target XML document open_target.xml
3. Click "Start" button for each of the following access requests
• Load open_request1.xml and click the start button. The initiator Alice can read all the fields except for the privacy related fields. This decision comes from the first rule and the open policy.
• Load open_request2.xml and click the start button. Bob can read all the fields because Bob belongs to the "personnel" group. This decision comes from the first rule, second rule, and the open policy.
• Load open_request3.xml and click the start button. Bob who is authenticated to have a Manager role can write all the fields in the personnel document. This decision comes from all of the rules and the open policy.