Page Comparison

Entitlement Policy Name: Name of the policy.

Entitlement Policy Description: A description of the policy.

The policy is going evaluate….:  to be evaluated Only when following matched: You can define; for what attribute values, this policy is going to be applied (or picked). This is similar to defining the policy target element.

Define Entitlement Rule(s): You can define rules which you want to evaluate after they are matched with above.

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.