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.