Difference between revisions of "Security Configuration"

From FMR Knowledge Base
Jump to navigation Jump to search
(→‎Security Overview)
(→‎Active Directory)
 
(47 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
== Security Overview ==
+
[[Category:Installation_and_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.
+
[[Category:FMR Configuration Reference]]
 +
==Overview==
  
−
The Fusion Registry only provides Authentication services for two types of user; the [[Fusion Registry Root]] user, and [[Fusion Reporting Node]] users. Authentication for other users are provided by either:
+
The Security function is available to logged-in users and found on the Main menu.
  
−
* [[Fusion Security]] Web Server
+
Security is split into two distinct functions: User '''Authentication''' and User '''Authorisation'''.  Authentication is the process of ensuring 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.
−
* [[Active Directory]] using the [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol 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.
+
The Fusion Metadata Registry only provides Authentication services for one user; the Fusion Metadata Registry Root user.  Authentication for other users are provided by either:
 +
 
 +
* Fusion Security web application
 +
* [https://en.wikipedia.org/wiki/Active_Directory Active Directory] using the [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP] protocol
 +
* [https://en.wikipedia.org/wiki/OpenLDAP OpenLDAP]
 +
 
 +
Once a user is Authenticated, the relevant User Account is loaded into the session, and the Registry uses its security model and rules to '''authorise''' the user is allowed to access the resource. The example below shown as example for Active Directory. You can read more [[Active_Directory_-_Set_up_Role_Mappings| about Active Directory in this article]].
 +
 
 +
[[File:VMSS0.PNG|Authentication Set-up|800px]]
  
 
== Authentication ==
 
== Authentication ==
 +
An Authentication Service is required to verify the provided credentials and to supply the Registry with information about the user.
 +
 +
Fusion Metadata Registry's web services support [https://en.wikipedia.org/wiki/Basic_access_authentication HTTP Basic 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  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 ===
 
=== 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 ===
 
=== Active Directory ===
 +
For detail on the various settings in FMR for Active Directory, please refer to [[Authentication_Service |this article]].
  
−
 
+
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, [[Active_Directory_-_Role_Mapping | please refer to this article]].
−
=== Certificate ===
 
  
 
== Authorisation ==
 
== 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:
+
To understand Authorisation, it is important to understand the security model for the Fusion Metadata Registry.  Each user account links to zero or more [[Organisations]] maintained in the Fusion Metadata Registry.  The Organisation a user account can be linked to falls into one of three categories:
−
# An [[Agency]]
+
# An Agency
−
# A [[Data Provider]]
+
# A Data Provider
−
# A [[Data Consumer]]
+
# 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 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 '''Agency''' user is able to create, maintain, and delete structures that belong to the Agency, or any of its sub-agencies.
 +
 
 +
A '''Data Provider''' user is able to validate and convert datasets the Data Provider has been set up to provide data for via a [[Provision Agreement]]. 
 +
 
 +
A '''Data Consumer''' user has no special privileges provided by default, however they are able to access the Registry if the product has been set up to enforce login.
 +
 
 +
== Root User ==
 +
Fusion Metadata 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 - Fusion Metadata Registry can be run in ''single user mode'' using the built-in '''root''' superuser account.  Root user has unrestricted access to the product, and as such security rules do not apply to the root user.
 +
 
 +
==Reporting Template==
 +
===Restrict Access===
  
−
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.  
+
Fusion Metadata Registry's default security ensures that generating an Excel workbook from a Report Template is a restricted action. Only users with certain access permission can generate an Excel workbook. The rules are:
  
−
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.
+
{| class="wikitable"
 +
|-
 +
! User Type !! Permission
 +
|-
 +
| Admin || Can download Excel Report Workbooks for any Data Provider
 +
|-
 +
| Agency || Can download Excel Report Workbooks for any Data Provider which is maintained by the Agency
 +
|-
 +
| Data Provider || Can download Excel Report Workbooks for which they can report data
 +
|-
 +
| Data Consumer || Can not download any Excel Report Workbooks
 +
|-
 +
| Anonymous || Can not download any Excel Report Workbooks
  
−
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.
+
To disable theses default settings, you can use the Enable / Disable button but note it is either all ON or all OFF.
  
−
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.
+
===Worksheet Passwords===
−
 
+
When a password is applied, when Fusion Metadata Registry generates an Excel workbook from a Report Template definition, it will ensure non-observation cells are locked and can not be edited unless a password is supplied to unlock the worksheet.  
−
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 Structures]], 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.
+
This will help prevent the data reporter editing the workbook in such a way to make it unreadable by the Registry.  
  
−
Security rules can also be defined at higher levels to achieve the following:
+
Passwords are set per Agency and can be changed at any time. If no password is set, the Excel workbook will not be locked.
−
*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.
+
It is strongly recommended to ensure each agency has a password set to ensure the workbooks are locked.

Latest revision as of 07:26, 10 May 2024

Overview

The Security function is available to logged-in users and found on the Main menu.

Security is split into two distinct functions: User Authentication and User Authorisation. Authentication is the process of ensuring 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 one user; the Fusion Metadata Registry Root user. Authentication for other users are provided by either:

Once a user is Authenticated, the relevant User Account is loaded into the session, and the Registry uses its security model and rules to authorise the user is allowed to access the resource. The example below shown as example for Active Directory. You can read more about Active Directory in this article.

Authentication Set-up

Authentication

An Authentication Service is required to verify the provided credentials and to supply the Registry with information about the user.

Fusion Metadata Registry's web services support HTTP Basic 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 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

For detail on the various settings in FMR for Active Directory, please refer to this article.

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.

Authorisation

To understand Authorisation, it is important to understand the security model for the Fusion Metadata Registry. Each user account links to zero or more Organisations maintained in the Fusion Metadata 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.

A Data Provider user is able to validate and convert datasets the Data Provider has been set up to provide data for via a Provision Agreement.

A Data Consumer user has no special privileges provided by default, however they are able to access the Registry if the product has been set up to enforce login.

Root User

Fusion Metadata 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 - Fusion Metadata Registry can be run in single user mode using the built-in root superuser account. Root user has unrestricted access to the product, and as such security rules do not apply to the root user.

Reporting Template

Restrict Access

Fusion Metadata Registry's default security ensures that generating an Excel workbook from a Report Template is a restricted action. Only users with certain access permission can generate an Excel workbook. The rules are:

User Type Permission
Admin Can download Excel Report Workbooks for any Data Provider
Agency Can download Excel Report Workbooks for any Data Provider which is maintained by the Agency
Data Provider Can download Excel Report Workbooks for which they can report data
Data Consumer Can not download any Excel Report Workbooks
Anonymous Can not download any Excel Report Workbooks

To disable theses default settings, you can use the Enable / Disable button but note it is either all ON or all OFF.

Worksheet Passwords

When a password is applied, when Fusion Metadata Registry generates an Excel workbook from a Report Template definition, it will ensure non-observation cells are locked and can not be edited unless a password is supplied to unlock the worksheet.

This will help prevent the data reporter editing the workbook in such a way to make it unreadable by the Registry.

Passwords are set per Agency and can be changed at any time. If no password is set, the Excel workbook will not be locked.

It is strongly recommended to ensure each agency has a password set to ensure the workbooks are locked.

Retrieved from "https://fmrwiki.sdmxcloud.org/index.php?title=Security_Configuration&oldid=7671"