Overview
Today I will be talking about the "Data Filtration" plugin (com.glide.data_filtration), which allows to define an extra layer of security an organisation can add on top of ACLs to prevent users seeing records they shouldn't. This plugin has a dependency on another plugin I already talked about, Adaptive Authentication given it uses the filter criteria records from that plugin to define who can read data from a given table.
Data to be filtered
Let's say, we have a custom CI table called "Turnstile" that registers the turnstiles we have in all the buildings in our organisation. In this case, we want that only "Satefy Teams" can see these if they are located in our HQ at "3 Whitehall Court, London". Also we are ignoring the fact that other teams like maintenance teams should also be able to see them, but this could be achieved by defining another use case for them. Here is the aspect of such table without being filtered:
Data filtration records
Once the plugin is installed, we can go to "Data Filtration" and see the types of records that are added with it. As you can see we can filter the records above based on IP Addresses, Roles or Groups, as we could filter access in the Adaptive Authentication plugin. In our example we will use a "Group Filter Criteria".
Configuring the records
Prior to do anything, we need to elevate our "security_admin" role, since Data Filtration Records, like ACLs, require it.
Once this is done we need to define a "Group Filter Criteria" after selecting the right module above. This criteria will contain all the teams which will have visibility granted over those records.
Having done this, we can then define a "Subject Criteria". This will link the incumbent subjects (Safety Team) and the condition that will apply to this team. This means, whether they can or cannot see the records, allowing us to blacklist or whitelist teams.
When the "Subject Criteria" is created we will see two tabs called "Criteria Inputs" (the incumbent subjects mentioned above) and "Criteria Conditions" (if they can or cannot see the records). Bear in mind conditions may be complex, including groups, IP addresses and roles.
Under the "Subject Criteria" we click on "New" and create the following record, selecting the Subject Criteria we created before (Group Filter Criteria)
Then we go back to the "Subject Criteria" and click on the "Criteria Conditions" tab and then on "New" to create a new record. This will be a "Subject Criteria Condition" record, that should look as below to allow the groups to read. The condition means "If the user belongs to any of the Safety Teams then". We will see how to define the "then" part.
This is the aspect of the Subject Criteria once both records are created:
Now let's talk about what to do when such condition is true. To do so, we create a "Data Filtration" record, selecting the table we want to filter, the subject condition, which defines who will be given access to it and then defining a "Data Condition" that defines the filter itself. In this case, The data must be filtered if the location is "3 Whitehall Court, London", the HQ of this made up organisation we are representing in this use case.
It is important to mention that the "Security Attribute Condition" allows us to use other "ad hoc" (if local) or existing conditions, such as "Has Admin Role" or "Logged In";
Also, if we create a "Security Attribute" we could even do our own scripted version if needed, similar to an ACL:
Showing the results
If the "Data Filtration" record above is active and the user doesn't belong to any of the "Security Teams", this will be what they will see:
If this blog article was useful to you, please click on “Helpful” and share it!
9 Comments
