The Simplified Policy Language

As already explained here, Argus policies contain collections of rules that state which actions can be performed on which resources by which users. XACML, the language used internally by Argus to define policies, provides great expressiveness and flexibility but it's very hard to read and author for uman beings. For this reason, Argus provides a Simplified Policy Language (SPL) to hide the complexity of XACML while providing much of its flexibility.

As an example, the following policy denies access to all the resources (under Argus control) to the members of the ATLAS VO:

resource ".*" { 
   action ".*" {
      rule deny { vo = "atlas" }
   }
}

The SPL syntax

resource <value> {
   
   action <value> {

      rule <permit|deny> {

         <attributeId>=<attributeValue>
         ...
      }
      ...
   }
   ...
}
...

The SPL defines three stanza types: resource, action and rule. It's possible to define multple resouce stanzas that can contain multiple action stanzas that can contain multiple rules stanzas.

The resource stanza is used to target a resource (or set of resources, if wildcards are used) under the control of Argus authorization.

The action stanza (always defined in the context of an enclosing resource) is used to target an action (or set of actions, if wildcards are used) that has to be authorized by Argus on the resource identified by the enclosing resource stanza.

The rule stanza defines who is authorized (in case of a permit rule) or not authorized (in case of a deny rule) to perform the action on the resource identified by the enclosing action and resource stanzas.

Identifying actions and resources

Actions and resources are identified by unique identifiers that are assigned to them. This identifiers are usually URIs, but any string that is unique in your deployment may work.

You can also use wildcards in your SPL policies to target group of resources or actions, like in the following example:

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action ".*" {

      rule permit { vo = "cms" }

   }
}

This policy authorizes users from the CMS vo to perform any action on the resource http://cnaf.infn.it/cream-ce-01.

Identifying subjects

In Argus policies, the users (or software agents) that need to be authorized to execute an action on a specific resource are identified using a set of attributes, like:

• the subject of the user's X509 certificate;
• the CA that issued the user's x509 certificate;
• the VO the user belongs to;
• whether the use has a specific FQAN in its bag of VOMS attributes;
• whether the user has a specific FQAN as his primary FQAN.

The table below specifies the supported attributes for Argus 1.1:

subject ="CN=Andrea Ceccanti,L=CNAF,OU=Personal Certificate,O=INFN,C=IT"

subject-issuer = "CN=INFN CA,O=INFN,C=IT"

vo = "atlas"

fqan="/dteam/Role=VO-Admin"

pfqan="/atlas/Role=pilot"

The contents of the rule stanza

As already pointed out, the rule stanza defines who is authorized to perform a specific action on a specific resource. A subject can be identified using the attributes defined in the previous section.

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action "submit-pilot-job" {

      rule permit { pfqan="/atlas/Role=pilot" }

   }
}

In the above policy, only subjects that have the /atlas/Role=pilot fqan as their primary fqan are authorized (since the rule is permit rule) to perform the action submit-pilot-job on the resource http://cnaf.infn.it/cream-ce-01. To prevent users from LHCB VO the execution of the same action, one would write the following policy:

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action "submit-pilot-job" {

      rule deny { vo = "lhcb" }

   }
}

Multiple attributes inside the rule stanza

It is possibile to define multiple attributes inside a rule stanza. All the attributes defined in the rule stanza need to match with the subject attributes present in the authorization request for the rule to be applied. This can be explained more clearly using an example:

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action "submit-job" {

      rule permit { 
         vo = "cms"
         subject-issuer = "CN=INFN CA,O=INFN,C=IT"
      }
   }
}

The meaning of the above policy is that only members from the VO CMS that have a certificate signed by the CN=INFN CA,O=INFN,C=IT CA will be authorized to perform the action submit-job on resource http://cnaf.infn.it/cream-ce-01. CMS members with certificates signed by the CERN CA, for instance, will not be authorized.

Since all the attributes defined in a rule must be "matched" in the request for the rule to be applied, one can think about multiple attributes inside a rule stanza as conditions that are ANDed to select who will be authorized to perform the action the rule is about.

How policies are evaluated

The first applicable policy (and only that one) that matches the authorization request is the one that is applied by Argus. This means that order matters. An example will help in understanding this concept.

Suppose we want to grant access to our CE to all members of VO CMS but not those that have /cms/Role=pilot as their primary FQAN. We would write a policy like this:

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action ".*" {

      rule deny{ pfqan = "/cms/Role=pilot"}
      rule permit { vo = "cms" }

   }
}

Since the deny rule precedes the permit rule in the above policy, we are able to deny access only to CMS users with the pilot role, but grant access to other members of CMS. This is due to the fact that the first deny rule will not match to CMS users that do not have the pilot role, so the following permit rule will be applied. On the contrary, if we reversed the order of the two rules like in the following policy:

resource "http://cnaf.infn.it/cream-ce-01" {
   
   action ".*" {

      rule permit { vo = "cms" }
      rule deny{ pfqan = "/cms/Role=pilot" }
   }
}

the deny rule would be useless, since the permit rule that precedes it would always match any CMS member.

The obligation stanza

Starting with Argus version 1.1, the SPL supports obligation stanzas. The syntax of the obligation stanza is as follows:

obligation "obligationId" {
   [attributeId = attributeValue]*
}

Oligation stanzas can be placed either in the resource or action context and are used to define a set operations that must be performed by the Argus PEP in conjuction with an authorization decision. An obligation stanza can define 0..N attribute definitions, that are passed as parameters to the PEP for the fulfillment of the obligation.

An example of policy with an obligation is the following:

resource "http://cnaf.infn.it/wn"{
   
   obligation "http://glite.org/xacml/obligation/local-environment-map" {}

   action "http://glite.org/xacml/action/execute"{
      rule permit { vo = "dteam" }
   }
}

The Argus PEP currently supports only the map-to-local-enviroment obligation.

The map-to-local-environment obligation

The map-to-local-environment obligation, identified by the following id:

http://glite.org/xacml/obligation/local-environment-map

is used within a policy to signify that a mapping to a local posix account will be produced by the Argus server as a result of a permit policy.

The use of this obligation is mandatory for the policies that authorize the execution and mapping of pilot jobs on the worker node.

Examples

Ban policies

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

Glexec on the WN policies

resource "http://cnaf.infn.it/wn"{
   
   obligation "http://glite.org/xacml/obligation/local-environment-map" {}

   action "http://glite.org/xacml/action/execute"{
      rule permit { vo = "dteam" }
      rule permit { pfqan = "/atlas/Role=pilot" }
      rule permit { pfqan = "/ops/Role=pilot" }
   }
}

The above policy authorizes the execution of jobs on the WN by:

• people from the dteam VO,
• people that have /atlas/Role=pilot as the primary fqan
• people that have /ops/Role=pilot as the primary fqan