ALFA Plugin

for Eclipse
Users Guide

Disclaimer
Axiomatics AB strives to ensure all documentation is accurate and up to date. However, no warranty
of any kind is made with regard to this material, including, but not limited to, the implied warranties
of merchantability and fitness for a particular purpose. Axiomatics AB shall not be liable for errors
contained herein or for incidental or consequential damages in connection with the furnishing,
performance or use of this material.
Note: The information in this document is subject to change without notice.
Trademarks
All brand names and product names used in this book are the trademarks, registered trademarks, or
trade names of their respective holders.
Title: ALFA Plugin for Eclipse User's Guide
Document number: 1.0.2-01
Note: New versions of this document may be published on the Axiomatics Customer Support site
without further notice. Visit https://support.axiomatics.com and check the documentation download
area for later versions of this document.

Copyright 2013 by Axiomatics AB. All rights reserved.

Contents
Introduction

A simple example

A second example

Default definitions System.alfa

Typical project structure and metadata

Namespaces and scoping

10

Type declarations

12

Operator declarations

12

Operator inverses

13

Operator bag overloading

13

Operator precedence

14

Function declarations

14

Combining algorithm declarations

16

Obligation and advice declarations

17

Category declarations

17

Attribute declarations

17

Policy syntax

18

Constant values

18

Attribute designators

19

Atomic attributes and bags

19

Targets

19

The match expressions in the target

20

Conditions

21

Rules, Policies and Policy sets

22

Policies

22

Policy sets

24

Policy hierarchies

25

Policy/rule in-lining vs references

26

Obligations and Advice

26

Limitations with respect to XACML

27

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

XACML Generation
About Axiomatics

2013 Axiomatics AB
www.axiomatics.com

27
29

ALFA Plugin for Eclipse

User's Guide

Introduction
The Axiomatics Language for Authorization (ALFA) is a domain-specific language for a high-level
description of XACML policies. It is designed for ease of use by developers. In addition, it presents
domain specific information such as attribute identifiers in compact form and it can be compiled into
XACML 3.0.

A simple example
The following is an example of an XACML policy written in ALFA:
namespace documents {
policy topLevel {
target clause Attributes.resourceType == document
apply denyOverrides
rule {
permit
condition Attributes.userClearance >=
Attributes.resourceClassification
}
rule {
deny
condition Attributes.documentStatus == draft
&& not(Attributes.documentAuthor == Attributes.subjectId)
}
}
}
The first line declares a namespace in which the policies exist. All ALFA documents must start with a
namespace declaration. Namespaces are used to collect related policies under a shared name structure.

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

By default the identifiers of the policies will inherit the namespace they belong to.
The second line defines a policy with the name topLevel. Naming a policy is optional, but for top level
policies it is useful to define it since the namespace and the policy name are used to confirm the name
of the XACML XML file that is produced by the compiler. In this case, the filename will be documents.
topLevel.xml.
This policy has a target that is defined on the third line. A target is a conditional expression that
determines when a policy or a rule applies. Targets are optional in both policies and rules. In the above
example, the target matches if the request contains a resource type attribute with the value document.
Note that attributes in XACML are multi-valued, so-called bags, so any attribute in the request may
contain zero or more values, and a value may even be repeated multiple times. The expression in the
target matches if there is at least one matching value.
A target can contain a list of clauses that can be combined with and or or. In this case there is only one
expression so that structure is not visible. There is, however, another example below with a more complex
target.
Within a policy there are two rules. One of the rules may permit access and the other one may deny
access, depending on how the rules match the request. The policy applies a deny override algorithm to
decide which gets priority in the event that both rules match. In such a case, the deny decision will receive
priority.
The two rules do not contain any target; rather, they use a condition, which is another way to define how a
rule or a policy matches. A condition is not limited to a special structure, unlike a target, which is why it is
used in this instance.
The first rule will permit access to the document if the users clearance is at least as high as the
documents classification. The second rule will override this if the documents status is draft and the user
attempting access is not the author of the document.
Note that the operators ==, <, etc., can be applied to bags in the condition. If the values are not bags,
then the operator is applied between the two atomic values. However, if either operand is a bag, the
operator is applied through the XACML any-of-any function, which means that as in the target the operator
returns true if at least one combination of values causes the operator to evaluate to true. For example,
if there are three authors of the document Alice, Bob and Carol, and the subject is Alice, then the
expression Attributes.documentAuthor == Attributes.subjectId would be true.
Some operators (e.g., +) cannot operate on bags, so these will cause a syntax error that will be
highlighted in the editor. For more details on this feature, see the operator definitions in this guide.
The attributes themselves are defined in a separate file. In this case, we have the following definitions:
namespace Attributes {
import System.*

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

attribute resourceType {
id = http://example.com/xacml/attr/resource/type
type = string
category = resourceCat
}

attribute resourceClassification {
id = http://example.com/xacml/attr/resource/classification
type = integer
category = resourceCat
}

attribute userClearance {
id = http://example.com/xacml/attr/subject/clearance
type = integer
category = subjectCat
}

attribute documentStatus {
id = http://example.com/xacml/attr/resource/documentStatus
type = string
category = resourceCat
}

attribute documentAuthor {
id = http://example.com/xacml/attr/resource/documentAuthor
type = string

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

category = resourceCat
}

attribute subjectId {
id = urn:oasis:names:tc:xacml:1.0:subject:subject-id
type = string
category = subjectCat
}
}
These define how the attributes are translated into XACML attributes. For each attribute there is a short
name, which is used when writing policies in ALFA, the full XACML attribute identifier, the data type of the
attribute and the category it belongs to (subject, resource, action, environment, etc.).

A second example
The following is an example of a policy that uses some additional features of ALFA.
Let us define an advice that will be used in the example.
namespace ObligationAdvice {
advice reasonForDeny = http://example.com/advice/reasonForDeny
}
Let us also define some additional attributes concerning medical records and printers so we can write a
set of policies for a hospital.
namespace hospital {
policyset topLevel {
apply permitOverrides
medicalPolicy
printerPolicy

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

policy medicalPolicy {
target clause Attributes.resourceType == medical-record
apply denyOverrides
rule {
permit
target clause Attributes.role == doctor
}
rule {
deny
condition not(booleanOneAndOnly(Attributes.careRelationExists))
on deny {
advice ObligationAdvice.reasonForDeny {
Attributes.message = There is no care relation
}
}
}
rule {
deny
condition booleanOneAndOnly(Attributes.recordIsBlocked)
on deny {
advice ObligationAdvice.reasonForDeny {
Attributes.message = The record is blocked
}
}
}
}

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

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
}
}
}
This second example introduces a few more features of ALFA.
At the top you can see that we have defined a policyset. A policy set contains either policies or another
policy set, allowing for arbitrarily deep nesting. The contained policies or policy sets can either be in-lined
within the policy set or, as in the example, referenced by their name. In this example, the two referenced
policies become their own separate XACML XML files when the ALFA source is compiled to XACML.
Looking at these policies, we see they both concern hospital procedures. One policy refers to medical
records access. Access to medical records is permitted for doctors but is blocked if the doctor does not
have a caregiving relationship to the patient or if access to the record has been suspended for some
reason.
The conditions show an example of how to convert a bag into an atomic value. As was previously
mentioned, all attributes in XACML are bags that may contain any number of values. However, in many
cases exactly one value per attribute is expected in the request and the policy wants to operate on this
single value. The booleanOneAndOnly function converts a bag of Boolean values into an atomic value,
and checks that there is exactly one value in the bag. If there is not exactly one value, then the function
returns an XACML Indeterminate result.
Another new feature in this example is the use of an advice. An advice is an extra item in the result which
can be used to convey extra information to the PEP. The PEP may ignore the advice, however. There is
a similar feature called an obligation which may not be ignored by the PEP. There is no obligation in this
example though.

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

In this case we use an advice to return a reason for a denial of access. That may be important to tell the
doctor so he knows how he could gain access if needed. For instance, he might have forgotten to register
the patient as being treated by him.
The second policy concerns access to a printer. This policy illustrates a more complex target. In this
case, there are three different roles that have been granted access to the printer. The two different
clauses are ANDed together, with lower precedence than the OR operator, so any of the three roles will
work. In addition the user must have training in how to use the printer.
This second example concludes the introduction. The most significant features of the language have been
shown in these examples. The rest of this manual consists of reference information on ALFAs features.

Default definitions System.alfa

The ALFA plugin for Eclipse package includes a file called system.alfa. This contains declarations for the
standard data types, functions, and algorithms from XACML. In most cases, this file should be included
in your project. The System namespace that is declared in this file is always implicitly imported, so all the
files declarations are always available for use.

Typical project structure and metadata

To author XACML policies using the ALFA plugin for Eclipse, a set of metadata declarations is needed.
Typically an ALFA project will contain the following types of artifacts.
The system.alfa file providing standard declarations for:
XACML data types
Operators
Functions
Combining algorithms
Attribute categories
Attributes
Files with custom attribute declarations
Files with custom advice and obligation declarations
Files with the policies themselves

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

10

It is possible to define custom data types, operators, functions, combining algorithms and attribute
categories, but it is typically not necessary.
With regard to namespace use, there are two recommended ways to organize namespaces.
For small projects, an artifact type structure works well. A namespace called Attributes is used for
custom attribute declarations, whereas namespaces called Obligations and Advice are used for custom
obligation and advice declarations respectively. The policies can be in a namespace called Policies.
For larger projects, or if there are multiple projects, it is recommended that the namespaces are organized
according to domain. The following is an example:
Namespace User for subject attributes.
Namespace Document for attributes, obligations and advices relating to resources in document
management.
Namespace Export for attributes related to export control legislation.
Namespace PortalA for policies for the application called Portal A.

Namespaces and scoping

XACML elements like policies, policysets and rules are given abstract identifiers (names) that are collected
into namespaces. Different namespaces may reside in different files or within the same file. Namespaces
can also be nested and their names accessed using the usual dot-notation from languages like Java and
C#.
An ALFA file may contain any number of namespace declarations. All policies and policy sets and other
declarations must always be inside a namespace.
Example: The following code snippet defines policy p within namespace B, which in turn resides within
namespace A. Comments are marked using // and /*..*/ as is customary.
namespace A {
// (2)
namespace B {
// (1)
policy p {...}
}

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

11

}
/* (3) */

To refer to policy P from code point (1), we need to use its name p; from code point (2). If no import
statement is added, we would use the qualified name B.p; and A.B.p from code point (3).
Names from a namespace can be imported into another namespace to avoid having to indicate the chain
of namespaces.
For example:
namespace A {
namespace B {
policy p {...}
}
import B.p
/* (4) */
}

namespace C {
import A.B.*
/* (5) */
}
At points (4) and (5), policy p may now be referred to simply as p.
Namespaces are also used to construct default identifiers for policies, policy sets and rules.
In XACML, a policy (set) and rule are uniquely identified using a URI. When the default mapping from
qualified names to URIs is to be overridden, the syntax admits associating a URI constant to a name.
Examples:

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

12

policy p = urn:example:policy:p {...}

policyset q = urn:example:policy-set:q {...}

Type declarations
A type declaration is used to give a short name to a datatype and makes the type available in the
language. The following example declares the standard string data type.
type string = http://www.w3.org/2001/XMLSchema#string
The system.alfa file contains declarations for all the standard data types in the XACML language, so in
most cases there is no need for a user to declare any types.

Operator declarations
Operators are declared with the keyword infix, followed by the name and a table of the XACML functions
that the operator has translated. system.alfa declares operators for the standard XACML functions, so in
most cases there is no need for a user to declare operators.
The following is an example for declaring the less-than operator.
infix allowbags (<) = {
urn:oasis:names:tc:xacml:1.0:function:integer-less-than : integer
integer -> boolean
urn:oasis:names:tc:xacml:1.0:function:double-less-than : double double
-> boolean
An infix operator takes two arguments and returns one value. The data types of the inputs and the
outputs are declared after the XACML functions that implement the operator. For each operator there
may be multiple implementing XACML functions so that the operator can be too overloaded to handle
different data types. In the example above, the less-than operator will be able to work on both integers and
doubles. The compiler will automatically select the right XACML function depending on the argument data
types.
The name of the operator must consist of the following characters: *, /, %, +, @, ^, =, <, >, &, $,
_, |. In addition the operator name may begin with the minus sign -, but the minus sign may not appear
anywhere except in the first position.

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

13

There are two optional features for an operator declaration: inverses and bag overloading.

Operator inverses
An operator may declare another operator to be its inverse. An operator inverse is another operator that
has the property that by reversing the two arguments the inverse then returns the same result as the
operator.
For instance, in the example above, the inverse of the < operator is the > operator. Inverses are
needed because some constructs in XACML, like the <Match> in a target, require a particular argument
order. In XACML, the constant value in the match expression always comes before the attribute
designator. ALFA allows the user to use operators with its arguments in any order and if the user wrote
the arguments in the reverse order of the XACML language, the ALFA compiler will change the order and
replace the operator with its inverse..
Because of this, the user can write both Attributes.age < 40 and 40 > Attributes.age, although only the
latter can be directly represented in XACML. If the user writes the former, the compiler will transparently
produce the equivalent second form in the XACML output.
Some functions are commutative, that is, they always give the same result even if the order of the
arguments is reversed. One example is the == operator. An operator is declared commutative with the
comm modifier, as in the following example:
infix allowbags comm (==) = {
urn:oasis:names:tc:xacml:1.0:function:string-equal : string string ->
boolean
urn:oasis:names:tc:xacml:1.0:function:boolean-equal : boolean boolean ->
boolean
}

Operator bag overloading

XACML has two different forms of expression for writing the conditions of rules: conditions and targets.
The structure of a condition is more free form, while the target requires less XML for simple matching
against constant values.
In XACML a match in a target will look for a match with any value in the attribute bag. For instance, if
a target contains the expression doctor == Attributes.role, then the expression will be true if any of
several possible values for the role attributes is doctor. Thus, if the subject has the roles doctor and
employee, then the expression will be true.
In contrast, using the XACML string-equals function in a condition is more cumbersome. The function
expects two atomic string values, so writing an equivalent expression in a condition would require using
ALFA Plugin for Eclipse
User's Guide

2013 Axiomatics AB
www.axiomatics.com

14

the any-of function: any-of(function[stringEquals], doctor, Attributes.role).

To make this more convenient for the user, the ALFA Plugin for Eclipse can automatically translate
operators in a condition to this form. To enable this translation for an operator, use the allowbags
modifier in the operator declaration. The less-than operator in the example above makes use of this
feature.
Some operators should not do this translation--arithmetic operators, for instance. Here is an example that
declares the addition operator, which must not be overloaded to accept bags:
infix comm (+) = {
urn:oasis:names:tc:xacml:1.0:function:integer-add : integer integer ->
integer
urn:oasis:names:tc:xacml:1.0:function:double-add : double double ->
double
}

Operator precedence
Operator precedence is fixed in the ALFA grammar. The order is as follow, going from the operators that
bind the weakest to the operators that bind the strongest.
Operators starting with |. These are right associative.
Operators starting with &. These are right associative.
Operators starting with =, <, > or $. These are left associative.
Operators starting with @ or ^. These are right associative.
Operators starting with + or -. These are left associative.
Operators starting with *, / or %. These are left associative.
Parenthesis can be used to control the evaluation order of operators. For instance, you can write (2+3) *
5 to perform the addition of 2 and 3 before the multiplication by 5.

Function declarations
Function declarations give short names to XACML functions and declare their argument types so the
compiler can perform type checking and type inference for operator overloading. System.alfa contains
declarations for all the standard functions, so in most cases users do not need to declare any functions.

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

15

Here is an example of a function declaration:

function stringEqual = urn:oasis:names:tc:xacml:1.0:function:string-equal

: string string -> boolean

The declaration consists of the short name, the full XACML identifier and the number and types of the
arguments and the type of the return value.
The possible argument types are
An atomic type that has been declared somewhere
Example: string
A bag of a type that has been declared somewhere
Example: bag[string]
Any atomic type
anyAtomic
A bag of any type
bag[anyAtomic]
Any atomic or bag type
anyAtomicOrBag
A function identifier reference
function
In addition, the last argument may be marked with a * to indicate that it may appear as a zero or any
number of times.
Here is a more complex example of a function declaration:
function anyOf = urn:oasis:names:tc:xacml:1.0:function:any-of
: function anyAtomic bag[anyAtomic] -> boolean
This defines the standard anyOf function from XACML 1.0. It takes three arguments, the first one being
a function reference, the second any atomic value and the third any bag value. Use of this function could
look like the following:
any-of(function[stringEquals], doctor, Attributes.role)

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

16

Note that the type declaration is unable to express that for anyOf, as the argument types of the input
function (stringEquals) must match the types of the two other arguments. This limitation is there in order
to keep the function declaration syntax reasonably simple.
Here is another example:
function anyOfAny3 = urn:oasis:names:tc:xacml:3.0:function:any-of-any
: function anyAtomicOrBag anyAtomicOrBag* -> boolean
This is the XACML 3.0 generalized any-of-any function. It accepts a wider range of arguments than the
1.0 version. The first argument is a function reference and then there must be at least one more argument
for any atomic or bag type.
The possible return value declarations are:
An atomic type that has been declared somewhere
Example: string
A bag of a type that has been declared somewhere
Example: bag[string]
Any atomic type
anyAtomic
A bag of any type
bag[anyAtomic]
Note that in contrast to the input arguments, the function reference and any atomic or bag type are not
allowed.

Combining algorithm declarations

Combining algorithm declarations provides short names and makes the declared algorithms available for
use. Here are examples of rule and policy combining algorithm declarations:
ruleCombinator permitUnlessDeny =
urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unlessdeny
policyCombinator denyOverrides =

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

17

urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
The system.alfa file contains declarations for all the standard algorithms from the XACML specification,
so users do not typically need to declare any algorithms.

Obligation and advice declarations

Advice and obligation declarations provide short names for advice and obligation identifiers and make
them available for use. Here are examples of obligation and advice declarations:
obligation myObligation1 = http://example.com/obligation/my-obligation-1
advice myAdvice1 = http://example.com/advice/my-advice-1

Category declarations
Declarations of attribute categories provide short names for them and make the categories available for
use in attribute declarations. Users typically do not need to declare their own categories since system.alfa
declares the four standard attribute categories, as follows:
category subjectCat
subject

= urn:oasis:names:tc:xacml:1.0:subject-category:access-

category resourceCat = urn:oasis:names:tc:xacml:3.0:attributecategory:resource

category actionCat = urn:oasis:names:tc:xacml:3.0:attribute-category:action
category environmentCat = urn:oasis:names:tc:xacml:3.0:attributecategory:environment

Attribute declarations
Attributes need to be declared to associate a short name with the URI ID, the attribute type and the
category. Notice that the type is identified using its short name.

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

18

Example:
attribute subjectId {
id = urn:oasis:names:tc:xacml:1.0:subject:subject-id
type = string
category = subjectCat
}
The system.alfa file contains declarations for standard XACML attributes. Users would typically define
their required attributes in their own namespace.

Policy syntax
The following sections describe the syntax for writing the policies themselves.

Constant values
Constant values can appear in the policy expressions. The parser recognizes strings, integers, doubles
and Booleans directly. Strings are quoted with single or double quotes. Integers consist of a number
and optionally a minus sign. Double consists of a number with a decimal dot and optionally a minus sign.
Booleans consist of the value true and false, without quotes.
Other datatypes are represented using a string followed by a colon and the name of the datatype, as
defined in the data type declaration. Examples of valid parameters are:
integer: 18, 20, -34
double: 30.5, -95.899
Boolean: true, false
string: hello, A sunny day
ipAddress: 127.0.0.1:ipAddress, 10.0.0.1:ipAddress

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

19

Attribute designators
AttributeDesignators in policies refer to the attribute declarations for translation to the full XACML syntax.
They are referred to using the short name given for the attribute. The MustBePresent and Issuer attribute
can be defined with the AttributeDesignator.
Some valid AttributeDesignators are:
role[mustbepresent]
role[mustbepresent issuer=Axiomatics]
role[issuer=Axiomatics]
role
The attribute designators can then be used in expressions using operators and functions. For instance
the following target uses the Attributes.resourceType attribute designator to match the value document.
target clause Attributes.resourceType == document

Atomic attributes and bags

All attribute designators return bag values. Some functions require atomic values. To convert the attribute
designator to an atomic value, use the appropriate one-and-only function. For instance, the following
example concerts the subjects age into an atomic value so it can be used in arithmetic operators.
integerOneAndOnly(Attributes.age) + integerOneAndOnly(Attributes.
trainingPeriod) < 50
This assumes that the attributes age and training period contain exactly one value. If there are no values
or multiple values, then the one-and-only function will return an Indeterminate result.

Targets
Targets in policies, policysets and rules are specified using the keyword target. If the target is empty, it
can be omitted.
Example:

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

20

target clause Attributes.resourceType == document

and Attributes.documentStatus == approved
and stringRegexpMatch(aaa.*, Attributes.subjectId)
clause Attributes.actionId == read or Attributes.actionId == write
The structure of the target follows the structure of the XACML standard. At the top level, there are clauses
which are ANDed together; that is, all clauses must be true for the target to match.
Within a clause there are expressions that are ORed; that is, at least one of these expressions separated
by the ORs must be true for the clause to be true.
Each OR contains expressions that are ANDed together; that is, all of those expressions must be true for
the OR to be true.
The expressions that are ANDed consist of XACML match expressions, which are expressed in ALFA as
either operators or function calls.
To summarize the structure:
Target
Clause
OR
Attributes.resourceType == document
AND
stringRegexpMatch(aaa.*, Attributes.subjectId)
Unless there are several expressions, the and and or need not be written out; rather, the ALFA Plugin
for Eclipse will fill in the appropriate XACML elements automatically during compile time. The clause,
however, always needs to be written out.

The match expressions in the target

The XACML 3.0 standard requires the Match element to contain an AttributeValue followed by an
AttributeDesignator or AttributeSelector. ALFA makes it possible to ignore the order if the match function
is commutative, or if there exists an inverse function to the match function. See the function declaration
section for a detailed explanation of how this works. The standard functions are declared with inverses in
system.alfa so the user typically does not need to worry about the order.
If the function is neither commutative nor has inverse function, then the order should be maintained in the
match element, or an error will be shown by the compiler.

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

21

Conditions
Conditions are another way to write expressions in XACML and are more expressive than targets, which
are limited to matching attributes against constant values. With conditions, you can match attributes
against other attributes, manipulate attribute values, perform arithmetic, and more.
Conditions can appear in rules, policies or policy sets. Note that the XACML standard allows conditions
only in rules, not in policies or policy sets. However, if the compiler encounters a condition in a policy
or policy set, it will automatically generate a rule to contain the condition and a couple of extra policies
with particular combining algorithms. This produces the same effect as if the condition had been written
directly in the policy or policy set, which greatly simplifies the modeling of certain use cases since
conditions are much more expressive than targets.
A condition is written with the keyword condition followed by an expression that must return a Boolean
value. Expressions in turn can consist of any operators of function calls.
Here is an example of a simple condition:
condition Attributes.userClearance >= Attributes.resourceClassification
In this case, the expression consists of only a single operator to check whether at least one value of
the user clearance attribute is greater than or equal to at least one value of the resource classification
attribute.
XACML has a large set of functions to operate on attribute values. To call a function, use the function
name that has been declared (in system.alfa typically) followed by the arguments in parenthesis. Here is
an example of a condition that uses function calls:
condition
allOf(function[stringRegexpMatch], .*fishing.*, Attributes.
clubMembership)
&& Attributes.age

> 25

This example checks that all club memberships of the subject contain the word fishing and that the age
of the subject is greater than 25.
The function that is being called is allOf. It takes another function as an argument, which is done with the
function[] syntax. The second parameter is a string and the third parameter is a bag of strings. The allOf
function will apply the provided function, stringRegexpMatch, with the second argument and each value of
the bag in the third argument in turn. If the stringRegexpMatch function returns true for each combination
like this, then the allOf function returns true.

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

22

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:

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

23

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 { ...

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

24

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
2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

25

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

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

26

Policy/rule in-lining vs references

In ALFA, policies/rules combined within a policyset/policy are identified by their names. The compiler
always in-lines the rules inside the rule-combining block of the policy. A Policy or PolicySet is in-lined if it
is defined inside the policy-combining block. If it is referenced, the corresponding references are added.
ALFA allows the Rules to be defined as separate elements. Hence, they can be reused inside many
policies by references. But the compiler always in-lines them in the output xml file.

Obligations and Advice

Obligations and advice appears as expressions in rules, policies or policy sets. Here is a rule with some
obligations and advice.
rule {
deny
condition not(booleanOneAndOnly(Attributes.careRelationExists))
on permit {
obligation ObligationAdvice.notifyPatient {

Attributes.message = Your record was accessed

Attributes.notificationRecipient = Attributes.patientId

}
obligation ObligationAdvice.logAccess
}
on deny {
advice ObligationAdvice.reasonForDeny {
Attributes.message = There is no care relation
}
}
}
2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

27

Advice and obligations apply either to Deny or Permit decisions. This is indicated by on deny and on
permit respectively. An obligation is defined with the obligation keyword and an advice is defined with
the advice keyword. The keyword is followed with the name of the obligation or advice. The name has
to have been declared somewhere. See the section on obligation and advice declarations for details.
An obligation or advice may optionally contain attribute assignments. In the example above, the
logAccess obligation does not contain an attribute assignment, while the other examples do. An
attribute assignment consists of an attribute that is assigned a value from an expression. The attribute
assignment can in this manner be used to provide parameters to the obligation. In the above example,
the reasonForDeny advice contains a message explaining the reason for the denied access. If access
had been permitted, a notification would be sent to the patient, and the obligation would include the ID of
the patient to receive the notification and the message contained in the notification.

Limitations with respect to XACML

ALFA does not support combiner parameters or variable definition/declarations. The representation of
constant values for attributes is not rich enough to be able to express the XPath data type.

XACML Generation
XACML files are generated and stored in the src-gen folder in the project home folder.
Each policyset and policy that appears directly under a namespace is translated to a separate XACML file.
If the policyset or policy is in-lined inside a policyset, a new file is not generated.
If the policyset or policy has an explicit URI specified, then PolicySetId or PolicyId is assigned the URI
value. Otherwise, the fully qualified name of the PolicySet or Policy is assigned as PolicySetId and
PolicyId, respectively.
namespace A{
policyset policySet = urn:example:com:policyset1 {
...
}
namespace B {
policy p {

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

28

...
}
}
}
For the above sample code, two files (A.policySet.xml and A.B.p.xml) are generated and PolicySetId is
assigned urn:example:com:policyset1 and PolicyId is assigned http://axiomatics.com/alfa/identifier/
A.B.p.
Rules are always in-lined inside the XACML file, though the rules are allowed to be defined as separate
elements in ALFA. A Rule cannot have an URI. The RuleId is assigned with the fully qualified name of the
Rule.

2013 Axiomatics AB
www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

29

About Axiomatics

About Axiomatics
Axiomatics, located in Stockholm, Sweden, is the leading provider of fine-grained and attribute-based
authorization solutions based on the XACML standard. The company has a global customer base within
the health, government and finance sectors.
The Axiomatics Policy Server (APS) protects systems against unauthorized use while enabling secure
sharing of information within and across enterprise borders. Axiomatics actively contributes to the
development of the XACML standard and has editorial responsibilities within the OASIS Technical
Committee.
http://www.axiomatics.com

ALFA Plugin for Eclipse

User's Guide

2013 Axiomatics AB
www.axiomatics.com

30

2013 Axiomatics AB
www.axiomatics.com

About Axiomatics

ALFA Plugin for Eclipse

User's Guide

AXIOMATICS AB

info@axiomatics.com
www.axiomatics.com