Understanding the Nesstar ACU Policies

Introduction to generic policy structure

Nesstar preloaded ACU policies

Introduction to generic policy structure

A policy defines the access control to data and operations made available by the server. The policy file is written in a rule-based formal programming language. The elements in the policy file are organized in various sections and structured as hierarchies.

Policy Hierarchies

Hierarchies are defined for the following subjects:

All the subjects [Users, Actions, Objects, Purposes] need to be declared in the corresponding hierarchy before they are used in a rule. Refer to the appendix for more details on the  ACU language structure.

Policy Rules

There are two types of access control policy rules - permissions and restrictions:

Users [of aProject project] CAN use anObject [for aPurpose purpose] [IF condition].

Users [of aProject project] CAN use anObject [for aPurpose purpose] ONLY IF condition.

A set of rules on an object is interpreted by the access control unit in the following way:

  1. All the permissions are connected by OR
  2. All the restrictions are connected by AND
  3. Restrictions and permissions are combined by AND

An example of a permission:

authorisedUser can access objects.
This permission states that all authorized users can access any objects in the server. The action 'access' is defined in the use hierarchy.
fullauthorisedUser can download objects.
This one states that full authorized users can download objects (or part of them).

Restrictions are used in particular cases when an extra degree of security is needed on a particular set of data.

An example of a restriction:

user CAN admin objects ONLY IF user = administrator.

 This one restricts admin operations only to users who have administrator role assigned.


Nesstar preloaded ACU policies

The preloaded user roles available in Nesstar server are:

Note: These roles cannot be deleted.

The Nesstar server comes preloaded with 4 policies:

  1. Restricted Data - Default Policy
  2. Restricted Data And Catalogs
  3. Restricted Data And Metadata
  4. Restricted Publishing Only

The policies RestrictedDataAndCatalogs and RestrictedDataAndMetadata are based on the RestrictedData_DefaultPolicy and are slightly modified to meet specific requirements.

Restricted Data - Default Policy

On installation the server applies the Restricted Data - Default Policy. The policy provides a basic access control which constitutes a significant level of security. The Restricted Data - Default Policy provides access control only on statistical operations and downloading of data while allowing anonymous users to freely browse the metadata.  In most cases this policy will be enough to meet your requirements. A copy of the policy can be opened here.

The Restricted Data - Default Policy defines the previliges for each user role as following :

  • anonymousUser : users that are not logged in can browse and search metadata on the server.
  • guestUsers: users have the same rights as anonymous users.
  • authorisedUsers: users can perform statistical operations on studies and cubes; and can create, use and delete derived variables.
  • fullauthorisedUsers: such users can download data or a subset of data.
  • publisher: users can publish metadata and data.
  • administrator: can perform any operation on the server.

The Restricted Data - Default Policy structure:

 users hierarchy:

HIERARCHY USERS
guestuser.
authorisedUser.
fullauthorisedUser EXTENDS authorisedUser.
publisher EXTENDS fullauthorisedUser.
administrator EXTENDS publisher.
END
All the users defined in this description, by default, inherit the rights from the category they extend.

objects hierarchy:

HIERARCHY OBJECTS
common.Server.
common.Statement.
faster.Catalog.
faster.Cube.
faster.Study.
faster.Variable.
END

use hierarchy:

HIERARCHY USE
access.
analize EXTENDS access.
Breakdown EXTENDS analize.
Correlation EXTENDS analize.
...
GetDerivedVariable EXTENDS analize.
GetDerivedVariables EXTENDS GetDerivedVariable.
browse EXTENDS access.
FindDDIVariables EXTENDS browse.
GetBackVersionClient EXTENDS browse.
...
retrieve EXTENDS browse.
toRDF EXTENDS retrieve.
see EXTENDS retrieve.
basicObjRDF EXTENDS see.
search EXTENDS access.
FastQuery EXTENDS search.
...
admin.
Reboot EXTENDS admin.
...
download.
Subset EXTENDS download.

modify.
GetOrphans EXTENDS modify.
Import EXTENDS modify.
ImportBy EXTENDS modify.
publish EXTENDS modify.
AddDataFile EXTENDS publish.
AddDataFileBy EXTENDS publish.
...
Delete EXTENDS modify.
Remove EXTENDS Delete.
RemoveStatement EXTENDS Delete.

GetReport.

GetFile.
END

rules :

RULES
administrator CAN use objects.
publisher CAN use objects UNLESS action=admin.

/* users can search catalogs and studies */
users CAN search faster.Catalog.
users CAN search faster.Study.
users CAN PathsTo common.Server.

/* users can browse metadata */
users CAN browse objects.

/* authorised users can access (analyze) objects */
authorisedUser CAN access objects.

/* full authorised users can download objects or part of them*/
fullauthorisedUser CAN download objects.

/* users can use objects created by themselves */
users CAN use objects IF objects/creator = user/id.

Restricted Data And Catalogs

Studies are organised in the Nesstar server using catalogs (in a similar way to how files are organised using folders). This policy, in addition to restricting access to data ( similar to Restricted Data - Default Policy) provides option to restrict particular catalogs and their contents from being accessed by unauthorised users. Using this policy, it is possible to hide catalogs from generic users. When users try to access a list containing the restricted catalog, a challenge will be issued. If users can access the catalog, this will appear in the list, if not, only the accessible catalog(s) will be in the list. If the catalog is listed at the root level (top level of the tree view), a challenge will be issued as soon as server is accessed. If the catalog is listed as a child of an unrestricted catalog, the users will receive a challenge as soon as they try to access this catalog. In this way, the users are free to browse the normal catalogs as in the default policy. A copy of the policy can be opened here.

users hierarchy:

HIERARCHY USERS
guestuser.
authorisedUser.
specialUser EXTENDS authorisedUser.
fullauthorisedUser EXTENDS authorisedUser.
publisher EXTENDS fullauthorisedUser, specialUser.
administrator EXTENDS publisher.
END

A new user role specialUser which extends authorisedUser is defined in this policy. Only this user role will have access to the restricted catalogs. In the hierarchy above, the category “publisher” extends the specialUser because, users with publisher rights needs to have access to any object in the server.

Details about the catalogs need to be added to the policy to make them restricted under the objects heirarchy.

objects hierarchy:

HIERARCHY OBJECTS
common.Server.
common.Statement.
faster.Catalog.
faster.Cube.
faster.Study.
faster.Variable.
restrictedObjects.

/* The next line when uncommented will restrict access to the catalog with id "Catalog1" */
/* "Catalog1" is faster.Catalog, restrictedObjects. */
END
The “catalog1” declared in the hierarchy is the actual id of the catalog that we want to protect. In this example just one catalog is defined, but you can declare as many catalogs as you need.
use hierarchy:
It is same as the Restricted Data - Default Policy.

rules:

This policy contains an extra rule that defines access permission to the restricted objects to specialUser only.

   /* only specialUser can use objects of type restrictedObjects **/
users CAN use restrictedObjects ONLY IF user = specialUser.
This rule states that restricted objects can be accessed in any operation by, and only by, users that are declared as special users. The use of the declaration ONLY IF guarantees that the rules are always fired and not overridden by other more permissive ones. For a better explanation of this, please refer to the appendix.

Restricted Data And Metadata

Datasets in the server are a combination of metadata and data files. Metadata refers to the description, on various levels, of the dataset. Data files are the actual statistical data used in the analysis process. The RestrictedDataAndMetadata policy provides access control not just on the statistical content of your data, but also on their metadata. This policy provides just a basic protection on metadata: it denies unauthorised users the browsing of full metadata description of the objects. In order to do that, it slightly modifies the Restricted Data - Default Policy. A copy of the policy can be opened here.

The modifications made in order to restrict access to the full metadata description and allow only a reduced set of metadata to be accessible are as below:

rules:

/* users can browse metadata */
users CAN browse objects.
becomes
/* users can only see objects */
users CAN see objects.

users CAN browse common.Server.
The action “see” returns only the basic description for metadata. The action “browse” returns the full metadata description, plus some more basic operations on the server.  Changing just this single rule will achieve the undesired result of restricting basic operations that are defined on the server itself (for example, the login will be restricted). Hence, the next rule is added to allow users full access to the server.

Restricted Publishing Only

This policy makes the metadata, datasets, cube and other resources on the server to be freely avaialble for viewing, performing statistical operations and downloading. However, the publishing and administrative actions are restricted to ensure server integrity. This is the simplest policy and enables open data dessimination. Any user can view, analyze or download data while a publisher can publish and remove objects and administrator can do any operation. A copy of the policy can be opened here.

 users hierarchy:

HIERARCHY USERS
publisher.
administrator EXTENDS publisher.
END
Only two user roles are defined in the users hierarchy.

objects hierarchy:

HIERARCHY OBJECTS

END

Since there are no specific objects based permissions defined in the rules, the objects hierarchy is empty.

use hierarchy:

HIERARCHY USE

admin.
Reboot EXTENDS admin.
SaveFile EXTENDS admin.
SaveWebFile EXTENDS admin.
Shutdown EXTENDS admin.
Update EXTENDS admin.

modify.
GetOrphans EXTENDS modify.
Import EXTENDS modify.
ImportBy EXTENDS modify.
publish EXTENDS modify.
AddDataFile EXTENDS publish.
AddDataFileBy EXTENDS publish.
AddDataset EXTENDS publish.
ModifySchedule EXTENDS publish.
PublishFile EXTENDS publish.
addCube EXTENDS publish.
addStudy EXTENDS publish.
create EXTENDS publish.
setAccessConditions EXTENDS publish.
setDocAuthEntity EXTENDS publish.
Delete EXTENDS modify.
Remove EXTENDS Delete.
RemoveStatement EXTENDS Delete.

END
Since there are no restrictions on accessing and downloading objects these are not defined in the use hierarchy. Only the admin and modify actions are defined.

rules :

RULES
   /* Only the administrator can do admin operations
  user CAN admin objects ONLY IF user = administrator.

   /* Only publisher can modify objects */
   users CAN modify objects ONLY IF user = publisher.

   /* Gives access for all users to all operations not defined as admin or modify */
   users CAN use objects.