The Simplified Policy Language

The simplified policy language allows for authoring authorization policies without the need to know anything about XACML.

A policy is a permit or deny rule permitting or denying a subject to perform an action on a resource. The subject is described by a set of attributes which can be, for example, FQANs, DNs, CAs, etc. The syntax of the simplified policy language is:

resource <value> {
    action <value> {
        rule <permit|deny> {
            <id>=<value>
            ...
        }
        ...
    }
    ...
}
...

Curly brackets are always required and there are no other characters used to structure the definition of policies (e.g. spaces or tabs can be both used for indentation, new lines are not required therefore a one-line definition is correct, etc.).

A rule is applied when it matches the request, therefore when the resource and action values (they are regular expressions) and the rule attributes (with the given values) are found in the request. List of attributes inside a rule are ANDed, list of attributes of different rules are ORed.

Only one rule is applied at a time, that is the first matching rule. That means that order matters.

That's all, check the Examples section to learn from some practical examples.

Supported Attributes

List of supported attribute identifiers:

• subject a Distinguished Name, the format is described in RFC2253 (example: subject="CN=Mario Rossi,L=TEST,OU=Personal Certificate,O=TEST,C=IT")
• fqan (example: fqan=/vo_test/analysis)
• pfqan (example: fqan=/vo_test/Role=administrator)
• ca

Examples

Ban policies

Typically a ban policy is needed in order to deny a subject who may have permit policies somewhere. Therefore a ban policies should be placed at the top and defined for any action on all the resources.

resource ".*" {
    action ".*" {
        rule deny { subject = "CN=Alberto Forti,L=CNAF,OU=Personal Certificate,O=INFN,C=IT" }
        rule deny { fqan = /dteam/test }
    }
}