Appendix:An Introduction to Nesstar ACU language

Elements of the Access Control Rule

Hierarchies

Conditions

Rules

Elements of the Access Control Rule

Subject

This element describes the entity which is performing the operation, a composition of user type, user purpose and user project, defined below:

  • User: Human entity that can connect to the system and make requests; each user has an associated identifier (usually the user's login name),by which the user is referred to in the system.
  • Purpose: Reason for the request and use of the data. Users may have more than one purpose.
  • Project: Named activity registered at the server, to which different users can subscribe. Users may have more than one project.

We have assumed user and project profiles to be referenced by their own identifiers, i.e. corresponding users and projects. Single properties within those profiles are referenced by path expressions denoting the path from the root to the property. For instance, Project/sponsor indicates the sponsor of the project. Similarly, user/affiliation indicates the property "affiliation" within the profile of the user whose request is being processed.

The following are examples of subject expressions:

  • user/citizenship=EC AND (project/sponsor=EC OR purpose IN research)
    denoting requests made by users who are European citizens and intend to use the data for research purposes or within an EC funded project
  • user IN NonCommercial-users AND purpose IN research
    denoting requests made by users belonging to group NonCommercial-users that intend to use the data for research purposes
  • user IN NonCommercial-users AND purpose IN research AND project/sponsor="EC"
    denoting requests made by users belonging to group NonCommercial-users that intend to use the data for research purposes within an EC funded project

Actions

Actions define the actual operation performed on the object. They can be classified on the basis of their behaviour, and as such, a static classification is not possible, as it depends on the application requirements and on the needs.

Some of the operations defined in the default policy are classified in the following categories:

  • modify:indicates all the actions that will change the objects on which they are applied.
  • access: for accessing the structure or the information about the objects stored in the server; as a rule of thumb, all actions that don't modify the objects, can be regarded as access ones.
  • search: for searching metadata of all resources on the server.
  • browse: for visualizing and querying the metadata associated with objects. Through the browse facility, users can browse through the metadata in order to choose the actual dataset in which they are interested.
  • analyze: for online analysis of the data (tabulation, regression, etc.).
  • download: for downloading data from the server. It allows users to transfer datasets (or subsets of datasets) onto their local machine to perform off-line analysis.
  • publish: for publishing data to the server or modifying the catalog structure.
  • admin: for performing all server management activities.

An action not explicitly declared in the hierarchy will be handled as a fully restricted action; in the default policy, it will be accessible only to administrators

Objects

This field is an expression that identifies the object or set of objects to which the rule applies.

Element objects have the form

objecttype [ WITH conditional-object-expression]
where:
objecttype is the identifier of the object or set of objects
conditional-object-expression is a Boolean formula of conditions that can evaluate membership of the object in categories, values of properties on metadata and so on.

For example:

/* all datasets in the Free_Datasets class the producer of which is ACME; */
Free_Datasets WITH dataset/producer=”ACME”

Hierarchies

The elements of the ACU Language's rules are structured as hierarchies. We can think of groups in the hierarchy as security levels, as we can define rules that apply to them in a sort of multi-level security system: rules created for a particular security level will be inherited by the levels below. There are five types of hierarchies available in the policy:

hierarchy users: it describes the hierarchy of user types.
hierarchy purposes: it describes the hierarchy of purposes users can have.
hierarchy projects: it describes the hierarchy of project types.
hierarchy use: it describes the hierarchy of actions users can perform on the server.
hierarchy objects: it describes the hierarchy of the objects available on the server.

Syntactically, a hierarchy has the following structure:

hierarchy hierarchyName

elementName.
...
childElementName1 EXTENDS parentElementName1[,parentElementName2[,...]]

childElementName2 ARE parentElementName3[,parentElementName4[,...]]

instansceId IS parentElementName5[,parentElementName6[,...]]

...
end
Reserved words ARE and EXTENDS are equivalent, the word ARE is used for historical reason. The reserved word IS denotes declaration of instances.

An example of a hierarchy for the objects is given below.

objectsHierarchy

 
 

    objectsHierarchy

            

           hierarchy objects
                common.Server.
                faster.Catalog.
                faster.Study.
                freeObjects.
                freeServer extends common.Server,freeObjects.
                publicStudy extends faster.Study.
                freeStudy extends faster.Study,freeObjects.
                restrictedStudy are faster.Study.

                “2569” is restrictedStudy.
                “data-archive.essex.ac.uk.2568” is publicStudy.
                “com.nesstar.2981” is freeStudy.
                “nesstar.essex.ac.uk.256778” is freeObjects.

            end

A hierarchy must have the following constraints:

Conditions

These elements define the conditions that must be satisfied for access to be granted.

Conditions can be static and dynamic.

Conditions can be expressed using a set of operators or by invoking methods defined on the objects to handle special conditions.

Using predefined methods instead of the provided operators can change the behaviour of the system. For example, granting access on the base of the purpose of users can be done using three different rules:

The first two rules are equivalent even if written in two different ways; their meaning is that users will be granted access to objects if they have at least one purpose that is, or depends on, the “authorized” purpose described in the hierarchy. The third rule is more complex as the users now are granted access if they have selected for the current session a purpose that depends on the declared one. If the users have such a purpose in the list of purposes assigned to them but they have not selected one for the current session, a challenge will be issued.

Conditions can be combined using the usual boolean operators NOT, AND and OR.

Operators

The server allows the following operators:

Example predicate usage:

user/id="jduke": tests that the user has id 'jduke'.
user/id LIKE "jduke": tests that the user's id contains 'jduke'.
user/id MATCH "j{.*}": tests that the user's id matches a 'j' followed by any number of characters (for example “gwjduke” will match but not “gwlduke”).
project/sponsor!="commercial": test that the project for which the user is accessing a resource has a sponsor not commercial.
object/source="UK Archive" : test that the resource accessed by the user has UK Archive as source.
object/distributionDate>26/05/1969: test that the resource accessed has a distribution date after the given date.

USER IN guest(USER=guest):tests that the user is guest;
PURPOSE IN guest(PURPOSE=guest): tests that the user is accessing the resource with purpose guest;
PROJECT IN non_commercial(PROJECT=non_commercial): tests that the project for which the user is accessing a resource is not commercial;
OBJECT IN restricted(OBJECT=restricted): tests that the resource accessed by the user is restricted.

Rules

Rules are what define our actual policy and are created using the elements described above. Rules can be restriction rules and authorization rules.

Restrictions rules specify the requirements that must be satisfied for access to be granted. If any requirement is not satisfied, access will not be granted. Syntactically, restrictions have the following form:

<subjects> CAN <actions> <objects> ONLY IF <conditions>.

Authorizations specify the permissions for access. Access is granted if at least one of the permissions that apply to the given request is satisfied and no restriction is violated. Syntactically, authorizations have the following form:

<subjects> CAN <actions> <objects> [ IF <conditions> ].

where <subjects>, <actions> and <objects> have the same syntax and semantics as described before, and <conditions> is a boolean expression of conditions that must be satisfied for access to be authorised.

Unlike restrictions, authorizations whose conditions are not satisfied are simply ignored. It does not imply the access will be denied, though. In particular, access is granted if there is at least one of the authorizations for which the conditions are satisfied.

A request is granted if: