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 title Note Note For more details on available XACML templates. Read me.
- A set of UI editors to create an XACML policy using UI configurations.
...
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 | ||||||
|---|---|---|---|---|---|---|
|
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.
| Info | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Entitlement Policy Name: Name of the policy. Entitlement Policy Description: A description of the policy. This policy is based on: Define based on what entity, that you are going to write this policy.
You can define multiple permit rules: As an example, “Only users in admin role can do GET” This rule can be defined as follows. You need to select “Role” attribute id for “User” and fill the text box with the role name (admin) and then fill the text box of near “Action” with action name (GET) Deny rule is automatically created as the final rule. Permitted rules are evaluated from top to blow.
|
...
- Rule1: Resources under “foo” collection can be read, written, edited and deleted by the users in the admin role.
- Rule 2: Resources under “foo/wso2″ collection can be read by only the users in the WSO2 (whose email address is wso2is wso2.com domaincom domain) regex for email (^([a-zA-Z0-9_.-])+@wso2@wso2.com)between 9.00am and 4.00pm (09:00:00+05:00, 16:00:00+05:00)
- All other access requests to “foo” resource must be denied.
...
- This access control policy is written for the patient records of 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 requests to patient records must be denied.
Lets Let's implement this sample policy using Basic Policy Editor,
...
Step 5: You can do a search for attributes values.
Step 6: Select only the “MediAdminstrator” role from the attribute source.
...
Step 7: You can see, the text box has been filled with the selected “MediAdminstrator” role name. Now let define actions. Here let us make the function name as “at-least-one”. Then this rule would be satisfied even when at least one action is going to perform. Finally, let us add this rule in to the rule into the policy
Step 8: Let's define the 3rd rule. Which allows “MediStaff” roles to access the resource with action read and edit. You can follow same steps 4, 5, 6, 7. Then finally, add this rule into the policy.
...
Step 9: Finally define the rule to deny all other access, as followingas follows:
Step 10: We have defined the target and rules. Now it is time to define the rule-combining algorithm. Let select is as “first applicable”. Then rule effect of the 1st rule that is evaluated properly, would be the final result of the policy. You You can click on “finish” and finish policy creation.
...
- 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 the 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. A common use case is to explain why something was denied. “User Bob Alex is denied because he has not a valid email”
- Here the attribute "Define Policy Obligation or Advice" is not mandatory.
...
| Excerpt | |||||
|---|---|---|---|---|---|
|
...