Securing MINT Domains

From IMSMA Wiki
Jump to: navigation, search

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.
  • 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

Use case description

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
    parent_organisation.parent
  • 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

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:

  1. Define Attribute-Value pairs on those users that should have restricted access.
  2. Define and upload a security file for the domain.


Example:

<securityDefinition xmlns="http://www.jaspersoft.com/2007/SL/XMLSchema" version="1.0" itemGroupDefaultAccess="granted">
<resourceAccessGrants>
	<!-- Row level security -->
	<!-- What access do roles/users have to the rows in the resource? -->
	<resourceAccessGrantList id="JoinTree_1_List" label="ListLabel" resourceId="JoinTree_1">
		<resourceAccessGrants>
			<!-- Row level restrictions for Organisations, e.g. Operator X only sees his own progress reports -->
			<resourceAccessGrant id="Jointree_1_row_access_grant_20">
				<principalExpression><![CDATA[authentication.principal.attributes.any{it.attrName in ['Organisation'] }]]></principalExpression>
				<filterExpression>testProfileAttribute(parent_organisation.parent,'Organisation')</filterExpression>
			</resourceAccessGrant>
		</resourceAccessGrants>
	</resourceAccessGrantList>
</resourceAccessGrants>
</securityDefinition>

Download the above example here.

Column-level security

Use case description

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

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:

  1. Define a role, e.g. called ROLE_NOVICTIMNAMES
  2. 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
  3. Define and upload a security file for the domain.


Example:

<securityDefinition xmlns="http://www.jaspersoft.com/2007/SL/XMLSchema" version="1.0" itemGroupDefaultAccess="granted">
<!-- Column level security -->
<!-- What access do roles/users have to the fields in an item group? -->
	<itemGroupAccessGrants>
		<itemGroupAccessGrantList id="grant_item_group_Victims" label="aLabel" itemGroupId="victims" defaultAccess="granted">
			<itemGroupAccessGrants>
				<!-- Column level for Victims: allow general access to ROLE_NOVICTIMNAMES, then deny access to specific fields -->
				<itemGroupAccessGrant id="Victims_item_group_access_grant" access="granted">
				<principalExpression>authentication.getPrincipal().getRoles().any{ it.getRoleName() in ['ROLE_NOVICTIMNAMES'] }</principalExpression>
				<itemAccessGrantList id="Victims_grant_item_group_items" defaultAccess="granted">
					<itemAccessGrants>
						<!-- Deny access to the name and surname of victims -->
						<itemAccessGrant id="Jointree_1_grant2_items_grant1" itemId="givenname" access="denied" />
						<itemAccessGrant id="Jointree_1_grant2_items_grant2" itemId="familyname" access="denied" />
					</itemAccessGrants>
				</itemAccessGrantList>
				</itemGroupAccessGrant>
			</itemGroupAccessGrants>
		</itemGroupAccessGrantList>
	</itemGroupAccessGrants>
</securityDefinition>

Download the above example here.

Note.jpg 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.