Difference between revisions of "Security Configuration"
(→Authorization) |
|||
| Line 22: | Line 22: | ||
== 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 | + | 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]] | # 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 | + | 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 | + | 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 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. | ||
| + | |||
| + | 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. | ||
Revision as of 10:22, 28 April 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 via LDAP
- 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
Fusion Security
Active Directory
Certificate
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 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.
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.
