Permission management

Table of Content

• Introduction
• List of available permissions
  • Granular permissions
  • Standard roles
• List of available SDMX artefact types
• Visibility of permissions

Introduction

The the Authorisation-Management web service allows retrieving, inserting, updating and deleting user permissions. We provide here more detailed information on the permission definitions as well as on the usage and parameters of this API. A Demo version of the Authorisation-Management web service is available here: https://authz-demo.siscc.org/swagger/index.html.

Access permissions can be defined individually for the following contexts:

• per user (e-mail, e.g. user@domain.org), group of users (Project_Team) or any user (*)
• per data space (e.g. Dissemination) or for all spaces managed within an instance (*)
• per SDMX artefact type (e.g. Dsd, Dataflow) or any type (0)
• per SDMX artefact maintenance agency (e.g. SDMX, MY_ORG) or any agency (*)
• per SDMX artefact ID (e.g. DATAFLOW_ID) or any ID (*)
• per SDMX artefact version (e.g. 1.0) or any version (*)
• permission type (e.g. 3)

For the list of available Permission types and SDMX artefact types, please see below.

In order to be able to use the Authorisation-Management web service, the user needs to be authenticated and to provide a valid access token.

List of available permissions

Granular permissions

The granular permissions listed below are permissions associated to a single and specific action.

Note that since release .NET 6.0.0, permission id:0 is no longer supported in .Stat Suite.

Note that since August 24, 2023 release .NET ’elote’, permission id:64 works as expected also in .Stat Suite.

Standard roles

Standard roles are combinations of several granular permissions as described in the table above, obtained by addition. For example, adding together CanReadStructuralMetadata [1] and CanReadData [2] to get 3, will create a standard role that has the ability to read both structural metadata and data.
Below is a table of pre-defined standard roles, but others are possible.

List of available SDMX artefact types

Visibility of permissions

Using the AuthorizationRules method of the Authorisation-Management web service:

• A user without any CanModifyStoreSettings[64] permission (or member of a group without any CanModifyStoreSettings[64] permission) can only see all those permissions that grant this user with a permission.
• An user with a CanModifyStoreSettings[64] permission (or member of a group with a CanModifyStoreSettings[64] permission) can see all permissions defined on those spaces on which that user has those permissions.

When a user is individually granted with a specific permission, and this user also belongs to a group which has its own permissions, then the user permissions are cumulative with its individual permissions and the group permissions he belongs to.
User permissions are also cumulative with the generic user permission ("*") if any.

It is important to check that the NSI web service configuration parameters (Authentication, Allow anonymous, Authorisation) correspond to one of the following tryptics, knowing that if they match with one of the bold tryptics, then the specific authorisations won’t be taken into consideration.

Example:

Consider the following fictive users:

Considering the following fictive authorization rules (one per line), the visibility of these rules to each user would be as follow: