Fusion Security Manager (FR V11)

Overview

The Security model in Fusion Registry 11 was enhanced to reflect the need to support more complex use cases around securing information in the Registry.

Authorization permissions are now maintained in a separate web User Interface called Fusion Security Manager. This User Interface enables the creations of Groups, and the creation of authorization rules which explicitly permit or deny a security group access to a resource.

The default behaviour of Fusion Registry 11 is to make everything private. In order to make structures and data public, specific security rules must be defined to grant access.

The following topics discuss each aspect of security in Fusion Registry 11.

Security Groups

The Fusion Security Manager enables Groups to be defined. Fusion Registry no longer supports assigning users to Groups, instead it will get the Group information from the Authentication service, for example Active Directory supports assigning Groups to users, and the Fusion Registry will map any Group that the AD User belongs to, with it's own Groups. In short, if the AD Group ID matches a Group ID in the Fusion Security Manager, then the Fusion Registry user assumes that Group. The user can belong to one or more Groups.

By default there is a Group called 'Public'. This Group can not be deleted, and all users belong to the Public Group, even if they are not logged into the system. The Public Group provides a mechanism for granting unrestricted access to resources.

When security rules are defined, they either grant an Allow permission, or a Deny permission. It is important to note that a Deny permission implicitly allows all other Groups. When rules are checked against a specific user, the user will be granted access if they belong to at least one Group that has permission

The following table describes this behaviour with specific examples:

User Group(s)	Security Rule(s)	Outcome
Public	- none defined -	The user can not see the resource as the default behaviour is to deny access
Public	Allow Public	The user can see the resource
Public, G1	Deny Public	The user can see the resource. Deny Public implicitly allows all other Groups, the user belongs to Group G1 which grants them access
Public, G1	Deny G1	The user can see the resource. Deny G1 implicitly allows all other Groups, the user belongs to Group Public which grants them access
Public, G1	Allow G1	The user can see the resource as they belong to one of the Groups that has been given permission to the resource
Public	Allow G1	The user can not see the resource as they do not belong to the Group which is allowed to see the resource
Public, G1	Allow G1, Deny Public	The user can see the resource as belong to the Group G1 which is allowed to see the resource

Security Admin

The Security Admin page of Fusion Security Manager enables a user to be granted specific permissions for administering parts of the Fusion Registry.

The Admin functions are as follows:

Admin Function	Access Rights
Audit Manager	Ability to query for audit and log information via the Audit web service
Data Manager	Unrestricted access to view, publish, and delete data
Error Subscriber	Ability to view, add, and delete subscriptions to error conditions
Kafka Manager	Ability to view, add. and remove Kafka connections
Portal Manager	Ability to use Fusion Portal for automating the synchronization of datasets from external web services
Reference Metadata Admin	Unrestricted access to view, add, and delete SDMX Reference Metadata
Server Admin	Unrestricted access to server administration functions
Structure Admin	Unrestricted access to view, add, and delete SDMX Structural Metadata. Ability to add, delete, and run Environment Synchronisation Ability to view structure transaction details, and to roll back to a transaction
User Admin	Ability to perform all functions in the Fusion Security Manager

Structure Security

Read Rules

TODO

Example #1:

Allow public visibility of all structural metadata except for one particular agency ("ACY1")

In Fusion Security Manager, under "Structure Read" set up 2 rules:

1. Structure Type: Any, Agency: *, ID: *, Version: *, Groups: PUBLIC
2. Structure Type: Any, Agency: ACY1, ID: *, Version: *, Groups: <The Group>

Write Rules

TODO

Reference Metadata Security

Read Rules

TODO 

Write Rules

TODO

Data Security

Dataset Read Rules

Allowing Group DEMO_METATECH the ability to read data for any Dataflow maintained by METATECH

Rule Description

Allows access to query for data that matches the rule definition. When a user has access to a Dataset, it will be visible in any User Interface which supports the querying of data, including the web service page, Fusion Data Browser, Tableau, Excel, and so on.

Rule Information

The Dataset Read Rule can be applied to a Dataflow, Data Provider, or Provision Agreement. All values in the form are optional and as such it acts as a filter. If no values are provided, the rule will be applied to all Datasets in the system. If values are provided, the structures in the Fusion Registry (Dataflow, Data Provider, or Provision Agreement) will be filtered based on the value(s) provided to determine which datasets the rule applies to.

Rule Behaviour

If the rule is an Allow rule and the user belongs to at least one of the Groups, they will be able to see the Dataset. If the rule is a Deny rule and the user belongs to ALL Deny Groups, the user will not be able to see the Dataset.

If multiple rules match then the most specific rule will apply. Rules are ordered by the following criteria:

1. Non empty Agency, Id, and Version takes priority
2. A non-empty Agency ID takes priority over a rule with an empty Agency ID
3. A non-empty ID takes priority over a rule with an empty ID
4. A non-empty Version ID takes priority over a rule with an empty Version

For example:

• Rule: Agency=BIS, ID=BOP, Version=1.0 will take priority over Rule: Agency=BIS, Version=1.0
• Rule: Agency=BIS will take priority over Rule: ID=BOP

Dataset Write Rules

See the description for Dataset Read Rule. The dataset write rule follows the same behaviour, but is applicable when authorising a data publication, as opposed to a data read.

Note: A user who has Dataset Write access does not automatically get Dataset Read access, the two access types are separate and have to be managed as separate rules.

Data Point Read Rules

Rule Description

Datapoint Read Rule denying access to OBS_CONF=C

When a user has been granted permission to read a dataset using the Dataset Read rules, the behaviour is for the user to have unrestricted access to the Dataset. The Datapoint Read Rules enable filters to be placed on the Dataset which restrict access to subsets of data. The rules are based on the reported Dimension or Attribute (collectively termed Component) values. For example COUNTRY=UK would be a rule that matches on all Series/Observations where the reported value for COUNTRY is UK,

Rule Information

The Data Point Read Rule requires the Component ID (this refers to either the Attribute ID or Dimension ID) and the Component Value (the reported value to Deny or Allow access to). An example of a restriction is: Component ID=OBS_CONF, Component Value=C. This rule would match any Series or Observation which is reporting OBS_CONF="C".

Other optional values on this rule are the Dataflow Agency, Id, and Version which this rule is applicable for. If the rule is applicable for all Dataflows, these values do not need to be reported. The Agency, Id, and Version act as a filter on Dataflows, for example it is possible to just fill in the Agency ID, which would ensure the rule was only applicable for data reported against Dataflows whose Agency matches the value defined in the rule.

Rule Behaviour

The behaviour of the rule is as follows:

• If the rule matches on a Series Attribute or Dimension - the rule is applicable to all observations in the series. For example, if the rule is a Deny rule, the user will not be able to see the Series or any of its Observations.
• If the rule matches on an Observation Attribute - the rule is applicable to the single observations. For example, if the rule is a Deny rule, the user will not be able to see the Observation in the Series.
• If the Attribute has no value in the Series or Observation (i.e. it is an optional Attribute) - the rule will not apply and the user will be able to see the Series or Observation to which the attribute relates

Data Attribute Read Rules

Restricting access to an Attribute with ID SYSTEM_ID

Rule Description

The rules for Data Attributes do not filter data, like the Datapoint Read rules, instead they remove the Attributes from the output. This is useful if there are some data attributes which are used for internal purposes and not intended to be seen or used by external parties.

Rule Information

The Datapoint Read Rule requires the Attribute ID. An example of a restriction is: Attribute ID=SYSTEM_PROCESS_ID. This rule would match any any Attribute with this ID.

Other optional values on this rule are the Dataflow Agency, Id, and Version which this rule is applicable for. If the rule is applicable for all Dataflows, these values do not need to be reported. The Agency, Id, and Version act as a filter on Dataflows, for example it is possible to just fill in the Agency ID, which would ensure the rule was only applicable for data reported against Dataflows whose Agency matches the value defined in the rule.

Rule Behaviour

When writing the Dataset to the user, if the Series Attribute or Observation Attribute matches the rule, and the user does not have permission to read it, the Attribute will not be included in the output dataset.

Fusion Data Browser

In order to use Fusion Data Browser (FDB) you must configure Fusion Security Manager appropriately otherwise even users logging on to FDB as the Root user will not be able to see any data in Fusion Data Browser.