Content Security

Overview

The Content Security module is available from the Administration menu which is available to users with Administrator and Agency access rights. The module allows you to decide who, inside and outside your organisation, can view Structures and Data.

The module is simple and straight forward to use however before you embark on any implementation it is recommended that you spend some time planning out what you want to achieve before you start.

Principles of Operation

Depending on the setting specified in the Administration area, Security Settings, General, all structures are public by default. This means that you do not need to give specific access to any structures or data if you are using the Content Security module. The Security Module is to prevent access to the many by giving access to the few.

Key Concepts

• Content Security provides control over who can view structural metadata and observational data content.
• It does not control who can create and maintain structural metadata – this is managed by granting users membership of SDMX Agency organisations.
• It does not control who can submit, amend, or revise data – this is managed by granting users membership of SDMX Data Provider organisations.
• All structures and data are visible to all users unless Content Security rules are applied.
• The Server Security setting controls whether anonymous users are allowed in addition to authenticated users: Public – anonymous users are allowed, Private – only authenticated users.
• A Structure Rule restricts the visibility of a structure to members of specific Security Groups.
• Rules placed on a structure are inherited by any structures or data sets than depend on it.
• A Data Rule restricts the visibility of selected series or observations in a data set to members of a specific Security Groups.

Server Security Setting

Below is an example of the Security Settings for a Registry which is fully ‘public’.

The options explained

Setting	Usage / Impact if Content Security Implemented
Server Security	Public: Anonymous users can view structural metadata and data content in addition to authenticated users. Private: Anonymous users are not allowed – all users must be authenticated before any content can be viewed. Applying Content Security rules further restricts what structural metadata and data users that do have access are able to see. This setting will be impacted by rules set up in Content Security as what users will see could be restricted due to the Security Groups and restrictions applied.
Data Validation	This setting relates to validating data loaded into Fusion Registry. It can be set to Private or restricted to via URL load only. This setting is not impacted by Content Security.
Data Reporting	This setting means that any one can view data published into the Registry. If set to Private, the Provision Agreements and related data can only be viewed by the Data Provider to which the Provision Agreement is assigned. Agency users can view all Provision Agreements assigned to their Agency and Administration users can view all Provision Agreements.

Click here to read more about Authentication and Authorisation.

Security Groups

Content Security rules restrict the right to view selected structures and / or data (series or observations) to members of specific Security Groups.

Security Groups contain zero or more SDMX organisations, specifically Agencies, Data Providers or Data Consumers.

Since a typical authenticated user has membership of one or more SDMX organisations, Fusion Registry’s Content Security system can establish to which Security Groups they belong, and by extension what Security rules apply.

Who can create Security Groups?

Role Type	What they can do
Administrator	Add and modify Security Groups, create Data and Structure Rules.
Agency	Modify Security Groups, create Data and Structure Rules for their own Agency and their Sub-Agencies.
Sub Agency	Modify Security Groups, create Data and Structure Rules for their own Agency.
Data Provider	Unable to access Content Security.
Data Consumer	Unable to access Content Security.
Anonymous User	Unable to access Content Security.

Inheritance of Structure Rules

One other important thing to be aware of is the concept of Inheritance. In the example below a Security Group has been created ECB_STRUCTURES which restricts a Data Structure, all Codelists and a Concept scheme, all are owned by the Agency ECB. This means that any Organisation who has not been placed in that Security Group will be unable to view the Structures.

Care must therefore be taken to avoid unintended consequences. For instance, restricting access to a Codelist will result in the same restrictions being applied to all DSDs, Dataflows and datasets that use it.

If we look at the page which shows the Structure Rules, you will see from the example below that as well as the Data Structure etc restrictions, the Dataflow has been restricted. This is because the Dataflow is attached to the Data Structure thus a dependency exists. This is shown the Inherited Groups area as shown below.

To understand the relationship between structures in the registry you can make use of the Structure References option which is available from the Home menu as shown below.

In the example above, Data Structures and Agency ECB has been selected, The right hand panel shows details of References (these are items which have been used in the Data Structure) and under Referenced by, you can see the Dataflow which has a dependency on the Data Structure.

Before you start

Planning

The best way to approach this is to be sure of what exactly you want to achieve. We also recommend that you make a note of what you want to restrict and who you want to restrict it to as you may need to refer back to it to check the implications of your restrictions.

We recommend that you consider all the options discussed in the following sections.

Server Security settings

Review your Server Security Settings and decide if the Registry should be in Public or Private mode.

Organisations

Review your SDMX organisational structure to make sure that the Agencies, Sub Agencies, Data Providers and Consumers are set up in the Registry.

User access

Authentication Service Review/implement your Authentication service and settings. In AD or LDAP, review the Groups and Roles (Users) creating any additional Groups and Users if required.

The example below shows settings used for Active Directory here at Metadata Technology.

Role Mappings Having reviewed AD/LDAP the next step is to map the Organisations. In the example below I have mapped my Organisations to Active Directory Groups (as shown in the AD/LDAP Role column).

Security Groups

Define your Security Groups by deciding:

• Which Organisations each group will contain?
• What Structures and Data rules will be applied?

Remember, when a Group is created the rules will restrict those organisations NOT placed in a group.

There is no need to create a group for a ‘no restriction’ scenario.

Set up process

A suggested workflow is outlined below.

To check for Inheritance implications, please refer to the Inheritance section of this user guide and using the legend above to check the effect of each rule.

Building Content Security

Overview

The Content Security modules is split into three areas, Groups, Structure Rules and Data Rules.

Security Groups

To start, create a Group using the Add button.

The usual restrictions apply to the ID field and you can enter a Name of up to 30 characters. Note: that currently there is no edit facility on the Security Groups so chose the Name and Id wisely.

Once the Group has been created, select the Organisations (Agencies, Data Providers and Data Consumers) who will be able to access restricted Structures and Data.

Next, from the Content Security menu, select either Structure or Data Rules as required.

Structure Rules

A Structure Rule restricts the visibility of a structure to members of specific Security Groups.

Remember that rules placed on a structure are inherited by any structures or data sets than depend on it. This means that rules restricting a Codelist, for instance, will also be applied to any DSDs, Dataflows and data sets that use it.

In the example Group below, the intention is to restrict access to code AUS which the Agency WB use for Australia.

The Structure Rules page will display all the Structures, in this example you will see that I have selected the Type = Codelist, for the Agency = GOT and the Codelist CL_REF-AREA_WDI (V1.0).

To access the individual codes on the Codelist, double click the Codelist to expand it as shown below.

The next step is to select the Security Group into which the restriction will be placed. This means that only users in that Group will be able to access this code. To do that, select the Group as shown below.

Note that a red padlock symbol appears next to the code AUS and red half-padlock symbols appear next to the Type and Agency. These symbols are used to identify when Structures have had either full restrictions or inherited restrictions placed upon them.

In the Security Group, you will now see that the Structures tab has been populated and shows the Codelist and the restricted code.

Implications If a user (other than an Administrator) performs a function such as Browsing or Querying the Data using Web Services or viewing the codelist they will not be able to see anything for the code AUS. Users who have been placed in the Security Group will have full access to the code and the Observational Data. Note: Inherited restrictions do not appear in the Structure Tab. Please refer to the Inheritance section to see how Inherited restrictions can be viewed.