Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Follow the instructions below to create an XACML policy.

...

Following is the screenshot of simple policy editor with defined rules. Here, "foo" can be the main resource and the other resource “foo/wso2″ can be the child resource. If you have further resources to add you can add them as child resources.


Basic Policy Editor

  • This editor is based on four categories which we are mostly talking in access control rules. i.e Subject, Resource, Action and Environment.
  • You can define a target and multiple rules in the policy. Rules can be ordered.
  • You can plug any attribute value sources and select those attribute values when creating the policy; rather than filling text boxes by your own. By default, WSO2 registry resources, Roles of the underline user store and some pre-defined actions are the attribute value sources for the resource, subject and action attributes respectively. There are extension points that you can use to extend and bring more attribute values on to the policy editor UI.

...

  • This access control policy is written for the patient records of New Medi Hospital. Patient records are stored in a location under “/patient/” directory. Therefore we are defining access control rules for “/patient/” directory.
  • Users can only access patient records from 09.00pm to 04.00pm.
  • Patient records can be created, deleted by users in MedAdminstrator role.
  • Patient records can be updated and read by users in MediStaff role.
  • All other access request to patient records must be denied.

...

Note
titleNote

There are several policies Combining Algorithms that we support in WSO2 Identity Server XACML Advanced Policy Editor.

  • Deny Overrides:
    This combining algorithm combines decisions in such a way that if any decision is a Deny, then that decision wins.
    Deny overrides is one of the safest combining algorithms since it favors a Deny decision. However, if none of the children return a Deny decision, then the combining algorithm will never produce a Deny.

  • Permit Overrides:

This combining algorithm combines decisions in such a way that if any decision is a Permit, then that decision wins.

The permit overrides combining algorithm can be interesting when:


At least one child must return a Permit for access to be granted overall regardless of restrictions.

One wants to return all the reasons why access is being denied. This is what one could call a “greedy deny overrides”. Forinstanceif the reason for not being able to view aresourceisthat (a) you are not the owner and (b) you are in the wrong department, then we could rework the previous example as follows. When any of the deny reason triggers, the response wouldbe denywith all the applicable reasons for access being denied:

    • Policy Set (deny overrides): role==manager AND action==view AND resourceType==resource
      • Policy 1 (permit overrides)
        • Rule 1: deny if resourceOwner != userId + Advice(“you are not the owner of the resource”)
        • Rule 2: deny if rsourceDepartment != userDepartment+ Advice(“you are not in the same department as the resource)
      • Policy 2
        • Rule 1: permit


  • First Applicable:
    This combining algorithm combines decisions in such a way that the final decision returned is the first one produced either of Permit or Deny.

    First applicable is useful to shortcut policy evaluation. For instance, if a policy set contains a long series of not applicable policies and one applicable policy which returns either of Permit or Deny, then if that policy comes first and does produce Permit or Deny, the PDP will stop there and not process the other siblings.


  • Deny Unless Permit | Permit Unless Deny:

    In XACML there are 4 possible decisions: Permit, Deny, NotApplicable, and Indeterminate. Sometimes, it is desirable to hide the NotApplicable and Indeterminate decisions to only allow for Permit or Deny. It makes the PEP logic potentially simpler.


  • Only One Applicable:

This combining algorithm exists only for policy sets to combine policy sets and policies. It cannot be used to combine rules. With this combining algorithm, in order for either of a Permit or Deny to be returned, then only one of the children must produce a valid decision – whether Deny or Permit.

  • Ordered Deny Overrides | Ordered Permit Overrides:

The ordered combining algorithms combine decisions in the same way as their (unordered) cousins. In, addition they bring the guarantee that policies, policy sets, and rules are considered in the order in which they are defined. The need to define an ordered combining algorithm stems from the fact the XACML specification does not specify whether order matters in the deny-overrides and permit-overrides combining algorithms.




Policy Set Editor

When you want to create a set of policies to evaluate at one time, you can create a Policy Set. You can add policies as shown in the figure and Click finish to create the policy set.

...