Appendix:An Introduction to Nesstar ACU language

Elements of the Access Control Rule

Subject

Actions

Objects

Hierarchies

Conditions

Operators

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



           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:

The hierarchies have to be defined before the rules.

All element used in the rules have to be declared in the corresponding hierarchy.

Multiple inheritance is allowed.

Parent elements must be declared before the child elements.

Actual server objects, such as 'server', 'study', must be defined in the hierarchy if a rule is required for them. Their name in the hierarchy is given by the full name of the class that defines the object, for example nesstar.ejbean.common.Server. The name can be cut after the first two elements of the package path, for example, as in fig.1 common.Server.

instances should have a server object and only one in their ascendants. The last declaration in the fig.1 is wrong as category freeObject does not extend any object. The correct declarition would be : “nesstar.essex.ac.uk.256778” is freeObjects, faster.Study.

Element names containing special characters, such as hyphen (-), period (.), undercore (_) or similar and element names starting with number should be inserted as String, between double quotes, as “data-archive.essex.ac.uk.2568”.

Conditions

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

Conditions can be static and dynamic.

Static: this type evaluates class or property membership of subjects and objects in their profiles and associated metadata.

Dynamic: conditions of this type are satisfied during runtime processing of the request. Dynamic conditions require the existence of a procedure that allows the user to engage in a dialogue with the access control unit (a challenge).

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:

users can access objects FOR authorized PURPOSES.

users can access objects IF PURPOSE=authorized.

users can access objects IF USERS.HasPurpose( “authorized” ,SESSION).

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:

IN used for checking hierarchies

LIKE for string checks if a string contains a given substring

MATCH for string searches for regular expression

equal to (=) (it can be used in place of IN operator)

not equal to (!=)

with numbers or dates (in the dd/mm/yyyy format), these additional predicate types are available:

greater than (>)

greater than or equal to (>=)

less than (<)

less than or equal to (<=)

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:

there is at least one authorization allowing the request (authorizations are considered as combined by a logical OR)

AND all restrictions are satisfied (restrictions are considered as combined by a logical AND)

NSD

Appendix:An Introduction to Nesstar ACU language

Elements of the Access Control Rule

Subject

Actions

Objects

Hierarchies

Conditions

Operators

Rules