Security Configuration

Security is split into two distinct functions: User Authentication and User Authorisation. Authentication is the process of ensuing the provided user credentials match up against a valid user account. Authorisation is the process of ensuring a user is allowed to perform the action they are trying to perform.

The Fusion Metadata Registry only provides Authentication services for two types of user; the Fusion Metadata Registry Root user. Authentication for other users are provided by either:

• Fusion Security Web Server
• Active Directory using the LDAP protocol
• Apache Tomcat via Certificate Authentication

Once a user is Authenticated, the relevant User Account is loaded into the session, and the Fusion Registry uses its security model and rules to authorise the user is allowed to access the resource.

Authentication

An Authentication Service is required to verify the provided credentials and to provide the Fusion Metadata Registry with information about the user. There are two ways a user can provide credentials to the Fusion Metadata Registry, username and password using Basic Authentication, or Certificate Authentication.

Username and Password authentication requires an authentication service to be running which can be used to verify the credentials. This external authentication service may be Fusion Security or Active Directory, the two authentication services are mutually exclusive - the Fusion Metadata Registry can only be configured to use one of these services.

After the Authentication process, the Fusion Metadata Registry must Authorise the user to access the resources. This is achieved by the Fusion Metadata Registry linking the user's account to one or more Organisations, this link is achieved in different ways depending on the Authentication mechanism.

Fusion Security

If the Authentication Service is Fusion Security, then the Fusion Security server will verify the user credentials and return the user account details to the Fusion Metadata Registry, including which Organisations the user belongs to. No additional configuration is required in the Fusion Metadata Registry.

Active Directory

If Active Directory is used as an Authentication server, then the Common Name (CN) is used to authenticate with the server. The CN is mapped in the Fusion Metadata Registry to one or more Organisations. To learn more about how to map users to Active Directory, please refer to this article.

Certificate

If Certificate Authentication is used, then the Common Name (CN) of the certificate mapped in the Fusion Metadata Registry to one or more Organisations.

Authorisation

To understand Authorisation, it is important to understand the security model for the Fusion Registry. Each user account links to zero or more Organisations maintained in the Fusion Registry. The Organisation a user account can be linked to falls into one of three categories:

1. An Agency
2. A Data Provider
3. A Data Consumer

A user account may have administrative privileges, which allows the user unrestricted access to any information in the product, including access to the configuration settings of the product.

A Agency user is able to create, maintain, and delete structures that belong to the Agency, or any of its sub-agencies. An Agency can also see any data which has been provided to any of the Dataflows the Agency maintains.

A Data Provider user is able to Registry, or publish data for any datasets the Data Provider has been set up to provide data for via a Provision Agreement. The Fusion Registry can be locked down to only allow Data Providers to see the data they have provided, in this instance data access will be private, restricted to only Admin, Agency, and Data Provider users.

A Data Consumer user has no special privileges provided by default, however they are able to access the Fusion Registry if the product has been set up to enforce login, and the organisation may be given access to restricted structures or data if specific security rules have been defined.

By default all structures and data in the Fusion Registry are public. However specific security rules can be defined to restrict access to specific structures, datasets, and data points. Security rules introduce two new security structures, a Security Group and a Security Rule.

A Security Group is a container to which Organisations are assigned, a Security Group can include zero to many Organisations.

A Security Rule links a Security Group to a Structure. This may be any Identifiable structure in the Fusion Registry, and may be in the context of a particular [[Dataflow] in which case the rule exists to restrict access to specific data points.

As soon as a Security Rule is linked to a Structure, the structure becomes private and will no longer be accessible to unauthenticated users. A user is only able to view a private structure if their linked Organisation is a member of the Security Group to which the Structure has been linked to. When a Security Rule is linked to a Structure, the rule also propagates to any Ancestors, for example linking a Codelist to the Security Group 'PRIVATE' will cause any Data Structure Definition which reference the Codelist to become a member of the group PRIVATE, and then in turn any Dataflows which reference the Data Structure will also become a member of the Security Group PRIVATE, and so on up the tree.

If a Security Rule is linked to an Item in an Item Scheme, then the Item Scheme will remain publicly accessible, but the Item will become private, and therefore will not be visible, via both the User Interface or Web Services, to an unauthenticated user. If the Item is a Code in a Codelist, then any data which uses the Code will become private, if the Code is used at the Series level then the entire series will become private, if the Code is used at the Observation level, as an Observation Attribute, then the Observation will become private.

Security rules can also be defined at higher levels to achieve the following:

• Make a Structure Type private for a particular Agency
• Make a Structure Type private for all Agencies

Security rule's can be defined in the context of a Dataflow, in this case the rule is applied to a Code in the context of a Dataflow. For example a Security Rule can be set up against the Code United Kingdom in the Reporting Country Dimension of Dataflow for National Accounts. In this instance the Code is still available to see in the Codelist, however any data reported against National Accounts with the reported value United Kingdom in the Reporting Country Dimension will become private, and therefore will not be included in any dataset obtained by users who do not belong to the Security Group that the Security Rule defines.

Root User

Fusion Registry provides a single root user account, where the credentials are stored locally (not in an external authentication service). The Fusion Registry authenticates the root user, and as such the root user is always able to log into the product should the external authentication service become inaccessible.

It is not a requirement to set up an external authentication service, or use certificate authentication, it is perfectly valid to run the Fusion Registry with only a root user account. Root user has unrestricted access to the product, and as such security rules do not apply to the root user.