Follow the instructions below to create an XACML policy.
...
- Resources under “foo” collection can be read, written, edited and deleted by the users in the admin role.
- Resources under “foo/wso2″ collection can be read by only the users in the WSO2 (whose email address is wso2.com domain) regex for email (^([a-zA-Z0-9_.-])+@wso2.com)between 9.00am and 4.00pm (09:00:00+05:00, 16:00:00+05:00)
- Allother access requestto “foo” resource must be denied.
Following is the screenshot of simple policy editor with defined rulesYou can build the above-mentioned policy example using Simple Policy Editor as shown below. 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 by clicking on icon.
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.
...
Note | ||
---|---|---|
| ||
There are several policies Combining Algorithms that we support in WSO2 Identity Server XACML Advanced Policy Editor.
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:
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.
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.
...