Versions Compared

Key

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

At the root of all XACML policies is a Policy or a PolicySet. A Policy represents a single access control policy, expressed through a set of rules. A PolicySet is a container that can hold other Policies or PolicySets, as well as references to policies found in remote locations. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. Because a Policy or PolicySet may contain multiple policies or Rules, each of which may evaluate to different access control decisions, XACML needs some way of reconciling the decisions each makes. This is done through a collection of Combining Algorithms. Each algorithm represents a different way of combining multiple decisions into a single decision.

...

  • Some predefined commonly used XACML Policy template samples where you can use by editing according to your use case.

    Info
    titleNote

     To get more details on available XACML templates. Read me.

  • A set of UI editors to create an XACML policy using UI configurations.

Here, in this documentation, we will mainly focus on how to The following steps lists how you can create an XACML policy using UI of our the management console of WSO2 IS. Please follow the below steps in management console,

...

  1. Log in to Management Console by entering your username and password to log on to the Management Console. 
  2. Navigate to the Main menu to access the Entitlement menu. Click Policy Administration under PAP.
  3. Click Add New Entitlement Policy.

The Add New Policy page appears which gives the 6 ways of writing an XACML 3.0 policy. You can select one out of six methods to create the policy using UI according to your preference as follows.

Table of Contents
maxLevel4
minLevel4
includeSimple Policy Editor|Basic Policy Editor|Standard Policy Editor|Policy Set Editor|Import Existing Policy|Write Policy in XML

Simple Policy Editor

  • This simple editor provides you the opportunity to create XACML 3.0 policies without any knowledge of XACML policy language. You can define your rules in a simpler manner and create an XACML 3.0 policy out of them. However, you need to have some knowledge about access control rules.

This editor is based on four categories which we are mostly talking about access control rules. i.e User, Resource, Action, and Environment where  User is the person who is going to access the resource,  Resource is an entity that we are trying to protect with access control rules,  Action is, what user is going to perform on Resource and Environment is the time, domain or any other factors that could cause to control the user’s access.

...

  • The standard policy editor is little similar to Basic Policy Editor. But it is basically designed for creating XACML 3.0 policy rules. Because there are several improvements with Obligation in XACML 3.0 when compare to 2.0. In XACML 2.0, obligations can only be added to policies and policy sets. But with XACML 3.0, rules can also contain Obligations. Therefore, if you want to get details of the obligations after the policy evaluated, It is good to use Standard Policy Editor. 

  • As in Basic Policy Editor, there is a place to define the conditions which make the rules evaluated as "The policy is evaluated only when following are matched" and a place to define entitlement rules.

  • Advice is a newly introduced feature with XACML 3.0 which is similar to Obligations. But only different, when compared to Obligations, PEPs do not have to comply with advice statements. PEPs can consider or discard the statement. Common A common use case is to explain why something was denied. “User bob Bob is denied Because he denied because he has not a valid email”

  • Here the attribute "Define Policy Obligation or Advice" is not mandatory.

...

Excerpt
Note
titleNote

There are Policy Combining Algorithms which are used by Policy Sets and Rule Combining Algorithms which are used by Policies. Each of the algorithms mentioned below has its Policy Combining algorithm and its Rule Combining algorithms as follows:

  • Standard combining algorithms defined in XACML 3.0:
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides
    • urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable
    • urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable
    • urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-deny-overrides
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-deny-overrides
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-permit-overrides
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-permit-overrides
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit
    • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-deny
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit
    • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny

These algorithms are explained in detail as follows,

  • 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”.Forinstanceifthe reason for not being able to view a resource is that(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 would be denied with 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 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.

...