Securing MINT Domains - Revision history

Alnaucler at 19:10, 20 February 2020

2020-02-20T19:10:49Z

← Older revision		Revision as of 21:10, 20 February 2020
Line 77:		Line 77:
	{{Note \| security example provided, the default is that all users should access all the attributes, and then certain attributes are denied for a certain role. However, the opposite is also possible, i.e. restrict the access by default, and grant it to a specific role only. Before implementing column-based security, it is recommended to gather all known requirements for restricting attributes. Then it can be decided how to best and easiest translate those requirements into a column-based security concept.}}		{{Note \| security example provided, the default is that all users should access all the attributes, and then certain attributes are denied for a certain role. However, the opposite is also possible, i.e. restrict the access by default, and grant it to a specific role only. Before implementing column-based security, it is recommended to gather all known requirements for restricting attributes. Then it can be decided how to best and easiest translate those requirements into a column-based security concept.}}

	{{NavBox ~~Business Intelligence~~}}		{{NavBox Hub}}
	[[Category:~~VIE~~]]		[[Category:NoPublic]]

Evinek: Evinek moved page Securing Domains to Securing MINT Domains: Renaming for better keyword search

2014-10-07T09:37:13Z

Evinek moved page Securing Domains to Securing MINT Domains: Renaming for better keyword search

← Older revision	Revision as of 11:37, 7 October 2014
(No difference)

Evinek at 09:43, 6 October 2014

2014-10-06T09:43:59Z

← Older revision		Revision as of 11:43, 6 October 2014
Line 1:		Line 1:
	{{TOC right}}		{{TOC right}}
	~~{{Under construction\| This page is under construction}}~~
	MINT allows restricting access to domains to specific roles and users. Concretely, access can be restricted on the row-level and on the column-level. Typical use cases are the following:		MINT allows restricting access to domains to specific roles and users. Concretely, access can be restricted on the row-level and on the column-level. Typical use cases are the following:
	* '''Row-level security''': when querying progress report data (activities), the National Mine Action Centre (NMAC) should see all data, but users from each operator should only see data/reports submitted by them. The definition of row-level access is implemented on the level of '''users'''.		* '''Row-level security''': when querying progress report data (activities), the National Mine Action Centre (NMAC) should see all data, but users from each operator should only see data/reports submitted by them. The definition of row-level access is implemented on the level of '''users'''.

Evinek at 09:43, 6 October 2014

2014-10-06T09:43:51Z

← Older revision		Revision as of 11:43, 6 October 2014
Line 76:		Line 76:
	Download the above example [[Media:Column_level_security_example.zip\|here]].		Download the above example [[Media:Column_level_security_example.zip\|here]].

	{{Note \| ~~In the column-based~~ security example provided, the default is that all users should access all the attributes ~~(in the XML: defaultAccess="granted")~~, and then certain attributes are denied for a certain role. However, the opposite is also possible, i.e. restrict the access by default, and grant it to a specific role only. Before implementing column-based security, it is recommended to gather all known requirements for restricting attributes. Then it can be decided how to best and easiest translate those requirements into a column-based security concept.}}		{{Note \| security example provided, the default is that all users should access all the attributes, and then certain attributes are denied for a certain role. However, the opposite is also possible, i.e. restrict the access by default, and grant it to a specific role only. Before implementing column-based security, it is recommended to gather all known requirements for restricting attributes. Then it can be decided how to best and easiest translate those requirements into a column-based security concept.}}

	{{NavBox Business Intelligence}}		{{NavBox Business Intelligence}}
	[[Category:VIE]]		[[Category:VIE]]

Evinek at 09:42, 6 October 2014

2014-10-06T09:42:28Z

← Older revision		Revision as of 11:42, 6 October 2014
Line 75:		Line 75:

	Download the above example [[Media:Column_level_security_example.zip\|here]].		Download the above example [[Media:Column_level_security_example.zip\|here]].

			{{Note \| In the column-based security example provided, the default is that all users should access all the attributes (in the XML: defaultAccess="granted"), and then certain attributes are denied for a certain role. However, the opposite is also possible, i.e. restrict the access by default, and grant it to a specific role only. Before implementing column-based security, it is recommended to gather all known requirements for restricting attributes. Then it can be decided how to best and easiest translate those requirements into a column-based security concept.}}

	{{NavBox Business Intelligence}}		{{NavBox Business Intelligence}}
	[[Category:VIE]]		[[Category:VIE]]

Evinek at 09:35, 6 October 2014

2014-10-06T09:35:56Z

← Older revision		Revision as of 11:35, 6 October 2014
Line 7:		Line 7:
	=== Use case description ===__NOEDITSECTION__		=== Use case description ===__NOEDITSECTION__
	Let's assume the following:		Let's assume the following:
	* A simple domain on the activity (hazard reduction) object in the staging area has been implemented in MINT. An activity, such as a progress report, usually includes information on the organisation that has carried out the activity. An organisation can be a sub-organisation, so it is important to get the name of the parent organisation via a SQL query. Let's assume the derived table containing the parent organisation name is called ''parent_organisation'' and the attribute containing the name of the parent organisation is called ''parent''. Therefore, the full qualifier for this attribute is <pre>parent_organisation.parent</pre>.		* A simple domain on the activity (hazard reduction) object in the staging area has been implemented in MINT. An activity, such as a progress report, usually includes information on the organisation that has carried out the activity. An organisation can be a sub-organisation, so it is important to get the name of the parent organisation via a SQL query. Let's assume the derived table containing the parent organisation name is called ''parent_organisation'' and the attribute containing the name of the parent organisation is called ''parent''. Therefore, the full qualifier for this attribute is <pre>parent_organisation.parent</pre>
	* The NMAC staff should be able to access all the data in the domain, i.e. all the activities carried out by all organisations.		* The NMAC staff should be able to access all the data in the domain, i.e. all the activities carried out by all organisations.
	* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.		* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.

Evinek at 09:35, 6 October 2014

2014-10-06T09:35:23Z

← Older revision		Revision as of 11:35, 6 October 2014
Line 11:		Line 11:
	* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.		* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.
	=== Implementation ===__NOEDITSECTION__		=== Implementation ===__NOEDITSECTION__
	In order to implement the above-mentioned use case, it is sufficient to define one single domain and configure the security accordingly. Two steps are required for this:		In order to implement the above-mentioned use case, it is sufficient to define one single domain and configure the security (row-level) accordingly. Two steps are required for this:
	# Define Attribute-Value pairs on those users that should have restricted access.		# Define Attribute-Value pairs on those users that should have restricted access.
	# Define and upload a security file for the domain.		# Define and upload a security file for the domain.
Line 38:		Line 38:
	== Column-level security ==__NOEDITSECTION__		== Column-level security ==__NOEDITSECTION__
	=== Use case description ===__NOEDITSECTION__		=== Use case description ===__NOEDITSECTION__
			Let's assume the following:
			* A simple domain on the victim object in the staging area has been implemented in MINT.
			* Some users should be able to access all the attributes of a victim.
			* However, other users should not be able to access victim names, because they have been classified as sensitive data.

	=== Implementation ===__NOEDITSECTION__		=== Implementation ===__NOEDITSECTION__
			In order to implement the above-mentioned use case, it is sufficient to define one single domain and configure the security (column-level) accordingly. Two steps are required for this:
			# Define a role, e.g. called '''ROLE_NOVICTIMNAMES'''
			# Assign this role to all the users who are concerned - in this case, to all the users who should not be able to access the victim names
			# Define and upload a security file for the domain.

	<br />Example:		<br />Example:

Evinek at 09:29, 6 October 2014

2014-10-06T09:29:48Z

← Older revision		Revision as of 11:29, 6 October 2014
Line 34:		Line 34:
	</pre>		</pre>

	~~=== Example download ===__NOEDITSECTION__~~		Download the above example [[Media:Row_level_security_example.zip\|here]].

	== Column-level security ==__NOEDITSECTION__		== Column-level security ==__NOEDITSECTION__
Line 65:		Line 65:
	</pre>		</pre>

	~~=== Example download ===__NOEDITSECTION__~~		Download the above example [[Media:Column_level_security_example.zip\|here]].
	{{NavBox Business Intelligence}}		{{NavBox Business Intelligence}}
	[[Category:VIE]]		[[Category:VIE]]

Evinek at 14:50, 23 September 2014

2014-09-23T14:50:54Z

← Older revision		Revision as of 16:50, 23 September 2014
Line 2:		Line 2:
	{{Under construction\| This page is under construction}}		{{Under construction\| This page is under construction}}
	MINT allows restricting access to domains to specific roles and users. Concretely, access can be restricted on the row-level and on the column-level. Typical use cases are the following:		MINT allows restricting access to domains to specific roles and users. Concretely, access can be restricted on the row-level and on the column-level. Typical use cases are the following:
	* '''Row-level security''': when querying progress report data (activities), the National Mine Action Centre (NMAC) should see all data, but users from each operator should only see data/reports submitted by them.		* '''Row-level security''': when querying progress report data (activities), the National Mine Action Centre (NMAC) should see all data, but users from each operator should only see data/reports submitted by them. The definition of row-level access is implemented on the level of '''users'''.
	* '''Column-level security''': when querying victim data, certain groups of users should not be able to view victim names.		* '''Column-level security''': when querying victim data, certain groups of users should not be able to view victim names. The definition of column-level access is implemented on the level of '''roles'''.
	== Row-level security ==__NOEDITSECTION__		== Row-level security ==__NOEDITSECTION__
	=== Use case description ===__NOEDITSECTION__		=== Use case description ===__NOEDITSECTION__
Line 11:		Line 11:
	* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.		* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.
	=== Implementation ===__NOEDITSECTION__		=== Implementation ===__NOEDITSECTION__
	~~The definition of row~~-~~level access~~ is ~~implemented~~ on the ~~level of '''users'''~~.		In order to implement the above-mentioned use case, it is sufficient to define one single domain and configure the security accordingly. Two steps are required for this:
			# Define Attribute-Value pairs on those users that should have restricted access.
			# Define and upload a security file for the domain.

	<br />Example:		<br />Example:
	<pre>		<pre>
Line 36:		Line 39:
	=== Use case description ===__NOEDITSECTION__		=== Use case description ===__NOEDITSECTION__
	=== Implementation ===__NOEDITSECTION__		=== Implementation ===__NOEDITSECTION__
	~~The definition of row-level access is implemented on the level of '''roles'''.~~
	<br />Example:		<br />Example:
	<pre>		<pre>

Evinek at 14:47, 23 September 2014

2014-09-23T14:47:50Z

← Older revision		Revision as of 16:47, 23 September 2014
Line 6:		Line 6:
	== Row-level security ==__NOEDITSECTION__		== Row-level security ==__NOEDITSECTION__
	=== Use case description ===__NOEDITSECTION__		=== Use case description ===__NOEDITSECTION__
			Let's assume the following:
			* A simple domain on the activity (hazard reduction) object in the staging area has been implemented in MINT. An activity, such as a progress report, usually includes information on the organisation that has carried out the activity. An organisation can be a sub-organisation, so it is important to get the name of the parent organisation via a SQL query. Let's assume the derived table containing the parent organisation name is called ''parent_organisation'' and the attribute containing the name of the parent organisation is called ''parent''. Therefore, the full qualifier for this attribute is <pre>parent_organisation.parent</pre>.
			* The NMAC staff should be able to access all the data in the domain, i.e. all the activities carried out by all organisations.
			* There are two operators who are given access to MINT in general and this domain in particular: ''Operator1'' and ''Operator2''. However, there is the restriction that Operator1 should only see rows of activities carried out by Operator1. Similarly, Operator2 should only see rows of activities carried out by Operator2.
	=== Implementation ===__NOEDITSECTION__		=== Implementation ===__NOEDITSECTION__
	The definition of row-level access is implemented on the level of '''users'''.		The definition of row-level access is implemented on the level of '''users'''.