Every so often, when you are developing long-lived applications, you will have to deal with changing security requirements – it is inevitable. For complex applications, with hundreds of interfaces and integrations, it may be challenging to enforce the new security requirements throughout the application. How can a low-code application platform help you in such a scenario?
We have previously discussed the strict global policy of Genus in a post on security concerns and priorities of your low-code platform. This post will explore a bit more into what this means for the Business Engineer and how it is an enabler of sustainable software.
We will use an imaginary application as an example to easier explain how low-code, and Genus specifically, can help you when developing and maintaining the security of your application. The example application has a data model typical of applications used in the public safety domain, and by large insurance providers. Nevertheless, the functionality and concepts discussed for securing the data applies to all types of applications and business objects.
There are several aspects when implementing the security of an application. However, in this post, we will focus on how you configure and maintain the permissions of the business objects of an application. But first, a brief introduction to the scenario.
The scenario
The imaginary application we will use is a case management system used for the investigation of financial fraud. The application is called Fraud Investigation Management System (FIMS), and it supports a group of fraud specialists within the Police.
The primary business objects of the applications are:
- Investigation case. The container of an investigation.
- Activity. To document and delegate activities in the investigation.
- Files. The reports and documents of the investigation.
- Persons. The persons involved in the investigation. Witness, suspect, etc.
The data model is as shown in the following screenshot:
The person is added to a case using a many-to-many relationship, by instances of the associative business object called Involvement. This enables the users of FIMS to add the same person to multiple investigations, which is an important feature in every investigative case management system.
Similarly, users are assigned to a case using the associative business object called Assignment. This enables users to be assigned multiple cases simultaneously.
Initial security permissions
FIMS is configured with two user groups and their permissions are as described in the following table:
| Security group | Description |
| Supervisor | Find, read and edit all cases. |
| Investigator | Find, read and edit all cases where the user is assigned. |
In Genus Studio, our low-code application development tool, you would implement the read permission of the Investigation case as shown in the following screenshot for the Supervisor security group:
For the Investigator security group, since their access to cases should be limited, you would need to express the permissions to read a case as a condition. The condition can be expressed as: An assignment to the investigation case must exist for the user.
This condition is implemented in Genus as shown in the following screenshot:
The access to instances of Activity and File are simply derived from Investigation case. This means that a user that has access to a case will also have access to all related activities and files. This can be implemented in several ways, but a particularly efficient way is to use the function to inherit permission from reference properties. In this data model, the case reference property of Activity and File should use this feature. This means that whatever security is applied to Investigation case is automatically applied to File and Activity by Genus.
This can be configured as shown in the following screenshot:
Read access to Person is slightly more complex, as its instances can be reused across cases. There is no need for the Investigator security group to access all persons, but they will need access to those involved in their cases. This means that if user A is given access to case X and this case involves a person named “Scrooge McDuck”, then user A should have access to “Scrooge McDuck”. Reversely, if “Scrooge McDuck” is not involved in any cases that user A has access to then this person is not accessible to user A. The following screenshot shows how this may be implemented:
The data of FIMS is now secure. The investigators have access to cases and the associated objects in cases they are assigned, while the supervisors can see all data.
The inevitable
For purpose of this post, lets us assume that FIMS has been in use for several years and that it has seen a steady increase in users and functionality. The customer has gradually requested new user interfaces, process automation, integrations, reports, etc.
In short, it is no longer an application used by a few specialists, for a special type of investigation. FIMS has gradually evolved into a critical core application, used nationwide, and for all types of investigations.
To better support the actual business processes of the current users and investigations handled in FIMS, you are requested to make some changes:
- The current security group called Supervisors should be renamed to National supervisors, and a new group called District supervisors should be added. Members of the District supervisor security group have been tasked to perform the same functions as National supervisors, but only in their own district.
- To be able to share information in selected cases you are requested to add a new property called Access Type. This property of a case can be set to the following values and effect on access:
- Open. Open cases should be accessible to all users.
- District. Accessible to all users in the district of the case.
- Closed. Only accessible to assigned users.
This type of change may initially seem like a high-risk and costly change. FIMS is a critical nationwide system with hundreds of user interfaces, automated processes, and integrations. How can you make sure that the new permissions are enforced everywhere?
Global strict policy to the rescue
It is in such situations a powerful low-code application development platform such as Genus shines. Genus automatically enforces the permissions defined in one place to all places where the data is accessed. This makes the implementation of changing security requirements a low-risk endeavor, even for nationwide core applications.
The requested change needs the introduction of two new business objects into FIMS:
- District. A geographical area. Every user and case belong to a district.
- Access type: Used to set the access level of the cases. Values are: Open, District, Closed
The data model of the application will now look like this:
New security permissions
The security groups of FIMS and their read permission to Investigation case is now as described in the following table:
| Security group | Description |
| Investigator | Find, read, and edit all cases where the user is assigned, or where the case type is set to Open. |
| District supervisor | Find, read, and edit all cases where the case type is set to District and the district of the case is equal to the district of the user. |
| National supervisor | Find, read, and edit all cases. |
The permissions of a District supervisor should also include the permissions of the Investigator security group. This could be achieved by duplicating the permission of Investigator for the District supervisor, but it is more elegant to use inheritance.
Simply adding the District supervisor group as a member of the Investigator security group is all that is needed. Genus automatically applies any permission granted to the Investigator security group to the District supervisor group.
The permissions of the District supervisor security group is therefore as shown in the following screenshot:
The permission of the Investigator security group is as shown in the following screenshot:
The inheritance of permissions from the Investigator security group to the District supervisor group makes the effective permissions of members of the district supervisor like the configuration in the following screenshot:
For File and Activity, there is no need to make any changes in the permission since their permissions are derived from the Investigation case reference.
Configure once, apply everywhere with low-code
Changes in security requirements are not something you normally need to handle on a daily, weekly, nor even monthly basis. However, for applications that are used for several years or decades, it is inevitable.
Low-code application platforms, such as Genus, will aid you when developing applications with complex security models. They will also enable you to quickly, and with minimal risk, adapt to changes in the security requirements of the application.
If you are responsible for a critical, enterprise application, “configure once, apply everywhere” is a must-have feature. It will empower you to always keep the permissions of the application aligned with the requirements.
Want to learn more about how low-code can help you? Feel free to book a demo or subscribe to our newsletter.
