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. 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.
Data Rules
A Data Rule restricts the visibility of selected series or observations in a data set to members of a specific Security Groups.
In the Data Rule example, we will look at how to restrict by reference to a dataflow’s specific series.
To start, I created a Security Group with the Id of GOT
I have restricted data for the code “SE_ADT_1524_LT_ZS” which is reported for Agency = GOT, in Dataflow = WDI_EDUCATION (V1.0), in the Component = SERIES.
In the Security Group, you will see that the Data Sets tab has been populated and shows the Dataflow, the SERIES, and the restriction.
Implications
If a user (other than an Administrator) performs a function such as Browsing or Querying the Data using Web Services, they will not be able to see any Observational Data for this specific series.
Users who have been placed in the Security Group will have full access to the Observational Data reported for this specific series.
Other Points to note
Restricting all structures
Agencies
In this example I am using the Structures from the BIS who have many Agencies and Sub Agencies. My intention here is to restrict all Structures with Agency ID of SDMX:BIS_OECD.
On the Structure Rules page, select Type ‘Agency Schemes’ and then SDMX. Double click on the Agency Scheme.
This will expand to display a list of all agencies.
Click the Agency and place it into the security Group. Note that several items in the Type and Agency column now the half padlock symbol next to them. To see exactly what has been restricted, follow the padlocks down to the ‘lowest level’.
When Restricting All Structures in your own Registry, don’t forget to check any Inheritance implications (as discussed in the relevant section above).
Sub Agencies
In this example I am using the Structures from the BIS who have many Agencies and Sub Agencies. My intention here is to restrict all sub agencies.
On the Structure Rules page, select the Type ‘Agency Schemes’, then select the Parent Agency and then Agencies.
Note: Individual Sub Agencies – this feature is not currently available but will be introduced in a future release.
