Difference between revisions of "Security Configuration"
(→Authentication) |
|||
| Line 3: | Line 3: | ||
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. | 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 Registry only provides Authentication services for two types of user; the | + | 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: |
* [[Fusion Security]] Web Server | * [[Fusion Security]] Web Server | ||
| Line 19: | Line 19: | ||
=== 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 Registry, including which Organisations the user belongs to. No additional configuration is required in the Fusion Registry. | + | 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 Registry, including which [[Organisations]] the user belongs to. No additional configuration is required in the Fusion Registry. |
=== Active Directory === | === 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 Registry to one or more Organisations. | + | 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 Registry to one or more [[Organisations]]. |
=== Certificate === | === Certificate === | ||
| − | If Certificate Authentication is used, then the Common Name (CN) of the certificate mapped in the Fusion Registry to one or more Organisations. | + | If Certificate Authentication is used, then the Common Name (CN) of the certificate mapped in the Fusion Registry to one or more [[Organisations]]. |
== Authorisation == | == Authorisation == | ||
| Line 37: | Line 37: | ||
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. 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 | + | 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 Provider]]s 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. | 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, | + | 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, [[dataset]]s, 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 Group''' is a container to which '''Organisations''' are assigned, a Security Group can include zero to many Organisations. | ||
| Line 47: | Line 47: | ||
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. | 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 [[SDMX:Parent_Ancestor|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 | + | 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 [[SDMX:Parent_Ancestor|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 [[Dataflow]]s 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. | + | 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: | Security rules can also be defined at higher levels to achieve the following: | ||
| Line 56: | Line 56: | ||
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. | 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. | ||
| + | |||
| + | |||
| + | == Reporting Node User == | ||
| + | [[Fusion Reporting Node]] is a web application, hosted for a [[Data Provider]] who is responsible for reporting data to a [[Fusion Registry]] which is acting as a central Hub. The [[Fusion Reporting Node]] provides a Web User Interface for managing and publishing [[Dataset]]s. The [[Fusion Reporting Node]] manages the reporting of the published [[Dataset]]s upstream to the [[Fusion Registry]] central Hub. | ||
| + | |||
| + | In order for the [[Fusion Reporting Node]] to be able to report to the parent [[Fusion Registry]] it must authenticate itself. In the installation of the [[Fusion Reporting Node]] a license file is required, which is generated by an administrator of the [[Fusion Registry]] Hub server. The [[Fusion Registry]] generates an encrypted license file, which includes inside it very strong, computer generated, user credentials which are to be used by the [[Fusion Reporting Node]] to authenticate with the [[Fusion Registry]]. | ||
| + | |||
| + | The [[Fusion Registry]] therefore does not need access to any external authentication service for authentication of [[Fusion Reporting Node]] users, this is controlled locally. | ||
Revision as of 13:34, 3 May 2019
Contents
Security Overview
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 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:
- 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 Registry with information about the user. There are two ways a user can provide credentials to the Fusion 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 Registry can only be configured to use one of these services.
After the Authentication process, the Fusion Registry must Authorise the user to access the resources. This is achieved by the Fusion 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 Registry, including which Organisations the user belongs to. No additional configuration is required in the Fusion 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 Registry to one or more Organisations.
Certificate
If Certificate Authentication is used, then the Common Name (CN) of the certificate mapped in the Fusion 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:
- An Agency
- A Data Provider
- 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.
Reporting Node User
Fusion Reporting Node is a web application, hosted for a Data Provider who is responsible for reporting data to a Fusion Registry which is acting as a central Hub. The Fusion Reporting Node provides a Web User Interface for managing and publishing Datasets. The Fusion Reporting Node manages the reporting of the published Datasets upstream to the Fusion Registry central Hub.
In order for the Fusion Reporting Node to be able to report to the parent Fusion Registry it must authenticate itself. In the installation of the Fusion Reporting Node a license file is required, which is generated by an administrator of the Fusion Registry Hub server. The Fusion Registry generates an encrypted license file, which includes inside it very strong, computer generated, user credentials which are to be used by the Fusion Reporting Node to authenticate with the Fusion Registry.
The Fusion Registry therefore does not need access to any external authentication service for authentication of Fusion Reporting Node users, this is controlled locally.
