Skip to main content

Rules, policies, policy sets

The core components of access control policies in ALFA are defined within a hierarchical structure consisting of rules, policies, and policy sets. These elements work together to establish refined and comprehensive access control rules.

Rules​

Rules represent the fundamental building blocks of ALFA policies. They specify the actions to be taken (permit or deny) and the conditions that must be met for the rule to apply. A rule can have a target clause to further refine its scope, limiting its applicability to specific resources, subjects, or actions. If the rule has no condition or target, then the rule applies to every request.

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

Rules can be defined with or without explicit names. If a name is not provided, as in the example above, the compiler will automatically generate a unique identifier.

You can add a name to the rule right after the rule keyword in the declaration:

rule rule123 { ...

This name allows you to reference the rule from within policies. For instance, you can simply refer to the rule above as "rule123" within the policy, and the compiler will embed a copy of the rule at that location.

Finally, rules can also contain obligations and advice, which are additional instructions to be executed upon a successful or denied decision, respectively. See the Obligations and advice section for more details.

Policies​

Policies serve as containers for organizing and managing multiple rules, providing a hierarchical structure.

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)
        }
}

Policies may contain a target and/or a condition. The target expression identifies the entities (subject, resource, and action) to which the policy applies. It also determines whether the policy should be considered for a particular access request. If a policy does not specify a target, it applies to all requests. The condition expression defines specific criteria that must be met for the policy to apply. It evaluates attributes associated with the access request and determines whether the policy should be considered. If no condition is specified, the policy applies unconditionally.

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. Since a policy may contain multiple rules, a combining algorithm is used to resolve conflicts arising from multiple rules within the same policy. You can declare the combining algorithm using the apply keyword.

As mentioned previously, it is also possible to reference a rule by its name. For instance, if you have a rule named "rule123", you can simply refer to it as "rule123" within the policy, and the compiler will embed a copy of the rule at that location.

Policy names​

Policy names are optional but can be useful for identifying and referencing policies. If a policy is not explicitly named, the compiler will generate a unique name for it. If you wish to define a policy name, it is done after they keyword policy:

policy policy123 { ...

This name will be used to generate the XACML policy ID and can be utilized to reference the policy within policy sets. For instance, you can simply refer to the policy above as "policy123" within the policy set, and the compiler will embed a copy of the policy at that location.

Alternatively, you can specify a full XACML policy ID using an equals sign after the policy name:

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

Optionally, policies can include obligations and advice. Obligations are mandatory actions that must be performed if the policy applies. Advice is optional guidance that can be provided when the policy applies. See the Obligations and advice section for more details.

Policy sets​

Policy sets are hierarchical structures that group multiple policies or policy sets together. They enable the organization and management of complex access control rules in a modular fashion. You can declare a policy set using the policyset keyword.

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"
            }
        }
}

Policy sets may contain a target and/or a condition. The target expression identifies the entities (subject, resource, and action) to which the policy applies. It determines whether the policy should be considered for a particular access request. If no target is specified, the policy applies to all requests. The condition expression defines specific criteria that must be met for the policy to apply. It evaluates attributes associated with the access request and determines whether the policy should be considered. If no condition is specified, the policy applies unconditionally.

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.

To address potential conflicting decisions from multiple policies or policy sets, a combining algorithm is employed to resolve discrepancies deriving from multiple rules within the same policy. You can declare the combining algorithm using the apply keyword. In the example above, it is permitOverrides.

Policy sets names​

Naming policy sets is optional. The example above explicitly names the policy set "topLevel". If no name is provided, the compiler will automatically assign a unique identifier to the policy set. It is also possible to define the full XACML policy set identifier by using an equals sign:

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

A policy set may also contain obligations and advice. See the Obligations and advice section for more details.

Policy hierarchy​

ALFA's hierarchical structure allows for the organization and management of rules, policies, and policy sets. This approach promotes modularity, simplifies policy development, and facilitates the creation of comprehensive access control policies.

Here is an example of a 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
            }
        }
}