Rules, Policies, and Policy sets

The actual expressions for granting and denying access are defined in a hierarchical structure consisting of rules, policies and policy sets.

Rules

The most fundamental element for defining the access control policies is the rule. Here is an example of a rule:

rule {
     permit
     target clause Attributes.resourceType == "document"
     condition Attributes.userClearance >= Attributes.resourceClassification
}

A rule is declared with the keyword "rule". Every rule must contain the effect of the rule, which is either "permit" or "deny". The rule may contain a target and/or a condition, and this determines whether the rule applies to the request. If the rule has no condition or target, then the rule applies to every request.

The rule declaration above does not define a name for the rule, in which case the compiler will automatically generate a unique ID for the rule.

The rule can be given an explicit name after the rule keyword in the declaration:

rule rule1 { ...

With his name you can reference the rule from policies, and the compiler will use this name when generating the XACML rule ID.

Rules may also contain obligations and advice. See the sections on obligations and advice for more details.

Policies

Policies are used to collect multiple rules. A policy is declared using the keyword "policy". Here is an example of a policy with two rules:

policy {
        target clause Attributes.resourceType == "document"
        condition Attributes.userClearance >= Attributes.resourceClassification
        apply denyOverrides
        rule {
            permit
        }
        rule {
            deny
            condition Attributes.documentStatus == "draft"
                && not(Attributes.documentAuthor == Attributes.subjectId)
        }
}

A policy may contain a target and/or a condition. These are used to determine whether the policy applies to the request. If there is no target or a condition, then the policy will apply to every request. The example policy contains both a target and a condition.

There are two rules in this policy. A policy may contain any number of rules, or it may be empty. An empty policy can be useful as a placeholder during policy development. It is also possible to reference a rule by its name. For example, if you defined a rule named "rule1", you could simply write "rule1" within the policy and the compiler would inline a copy of the rule in that position.

Since a policy may contain multiple rules, which may return different decisions, a combining algorithm is used to decide what the decision of the policy as a whole will be if there is a conflict among the rules. The combining algorithm is declared with the "apply" keyword (in the example it is the denyOverrides algorithm), so if both rules apply the decision from the policy as a whole will be deny.

The policy in the example has not been given a name, so the compiler will generate a name and an XACML identifier automatically. If you wish to define a name, it is done after they keyword "policy":

policy policy1 { ...

This name will be used to generate the XACML policy ID and can be used to reference the policy from policy sets. It is also possible to specify directly the full XACML policy ID using an equals sign after the name:

policy policy1 = "http://example.com/policies/policy1" { ...

Policies may also contain obligations and advice. See the sections on obligations and advice for more details.

Policy sets

Policy sets are collections of policies or other policy sets. A policy set is declared with the keyword "policyset". The following is an example of a policy set.

policyset topLevel {
        apply permitOverrides
        medicalPolicy
        policy printerPolicy {
            target clause Attributes.resourceType == "printer"
            apply permitOverrides
            rule {
                permit
                target
                    clause Attributes.role == "doctor"
                        or Attributes.role == "nurse"
                        or Attributes.role == "receptionist"
                    clause Attributes.userTraining = "printer-use"
            }
        }
}

A policy set may contain a target and/or a condition. The example above has a target but no condition. The target and condition determine whether the policy set applies to a request. If there is no target or condition, then the policy set applies to all requests.

A policy set can contain any number of other policies or policy sets or references to such, or can be empty. An empty policy set can be useful as a placeholder during policy development. In the example above, there is a reference to a policy called "medicalPolicy". Such  references are compiled to an XACML policy reference. The example also has an in-lined policy called "printerPolicy".

Since there may be multiple contained policies and policy sets that may return conflicting decisions, a policy set has a combining algorithm that decides which decision is from the policy set as a whole. The combining algorithm is declared with the "apply" keyword. (In the example it is "permitOverrides".)

The example gives a name "topLevel" to the policy set. Naming the policy set is optional. If a name is not specified, then the compiler will automatically generate a unique name for the policy. It is also possible to define the full XACML policy identifier explicitly by using an equals sign:

policyset topLevel = "http://example./com/policies/toplevel" {

A policy set may also contain obligations and advice. See the sections on obligations and advice for more details.

Policy hierarchies

By nesting rules, policies and policy sets, hierarchies of rules are formed. This is the manner by which complex use cases can be broken into smaller pieces and modeled into full-access control policies.

Here is an example of a somewhat more complex structure:

policyset p = "urn:axiomatics:policies:example:p" {
        target ...
        apply firstApplicable
        authzManagement
        authzExternal
        policy alwaysDeny {
            target ...
            apply denyOverrides
            rule1
            rule rule2 {
                target ...
                permit
            }
        }
}