Overview

As digitisation is increasing, privacy has become one of the major requirements in the digital world. Masking the PII data is one such ways to achieve privacy.

This document highlights the changes need to be done in a Property module to support the privacy feature which will mask the PII data during search and updates at different levels.

Pre-requisites

Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot.
MDMS Service
Encryption Service

MDMS changes

Update the SecurityPolicy.json file.

The Security Policy mdms file, must have the model configuration for fields to be encrypted/decrypted.
Following models have been used for W&S in SecurityPolicy.json file:

    {
      "model": "Property",
      "uniqueIdentifier": {
        "name": "uuid",
        "jsonPath": "/owners/0/uuid"
      },
      "attributes": [
        {
          "name": "street",
          "jsonPath": "address/street",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "doorNo",
          "jsonPath": "address/doorNo",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "landmark",
          "jsonPath": "address/landmark",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        }
      ],
      "roleBasedDecryptionPolicy": [
        {
          "roles": ["WS_CEMP","WS_DOC_VERIFIER","WS_FIELD_INSPECTOR","WS_APPROVER","WS_CLERK","SW_CEMP","SW_DOC_VERIFIER","SW_FIELD_INSPECTOR","SW_APPROVER","SW_CLERK","PT_APPROVER", "PT_CEMP", "PT_COLLECTION_EMP", "PT_FIELD_INSPECTOR", "PT_DOC_VERIFIER"],
          "attributeAccessList": [
            {
              "attribute": "street",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "doorNo",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "landmark",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        },
        {
          "roles": ["REINDEXING_ROLE"],
          "attributeAccessList": [
            {
              "attribute": "street",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "doorNo",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "landmark",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        }
      ]
    },
    {
      "model": "PropertyDecrypDisabled",
      "uniqueIdentifier": {
        "name": "propertyId",
        "jsonPath": "/propertyId"
      },
      "attributes": [
        {
          "name": "street",
          "jsonPath": "address/street",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "doorNo",
          "jsonPath": "address/doorNo",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "landmark",
          "jsonPath": "address/landmark",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        }
      ],
      "roleBasedDecryptionPolicy": []
    },

Also add following(if not already there) under roleBasedDecryptionPolicy of User model(already existing):

"roleBasedDecryptionPolicy": [
        {
          "roles": ["REINDEXING_ROLE"],
          "attributeAccessList": [
            {
              "attribute": "mobileNumber",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        },
        {
          "roles": ["WS_CEMP","WS_DOC_VERIFIER","WS_FIELD_INSPECTOR","WS_APPROVER","WS_CLERK","SW_CEMP","SW_DOC_VERIFIER","SW_FIELD_INSPECTOR","SW_APPROVER","SW_CLERK"
          ],
          "attributeAccessList": [
            {
              "attribute": "mobileNumber",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "fatherOrHusbandName",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "correspondenceAddress",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "name",
              "firstLevelVisibility": "PLAIN",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "emailId",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "permanentAddress",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "guardian",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        }
     ]

Refer the SecurityPolicy.json file for full reference.

For modules, there is no such hard rule or pattern for naming the model, but it should be related to that service.
ex: 1.) For user service we have two security policy model User which is used when a user tries to search other user data and he/she will get the PII data in masked, plain or encrypted form depending on the visibility sets for an attribute in the mdms.
And another model is UserSelf which is used when a user tries to search its own data and he/she will get the data as per the configuration set there. For report and searcher config the model name should be similar to the value that we are setting in the field decryptionPathId. ex:- Employee Report. Employee Report Security Model

2.) For Property we have model Property which is for Address fields like street,doorNo,landmark encryption and decryption.

For an attribute where its firstLevelVisibility is set as "Masked" and whenever the respective search API is called without the plain Access Request then in the API response for that attribute we will get the masked value
for ex:- if for mobile number attribute’s firstLevelVisibility is masked and its plain value is 9089243280 then in response, we will get value as ******3280 and the masking pattern is defined in the MaskingPattern mdms file and the pattern is picked up based on patternId. Similarly, if firstLevelVisibility is set as "ENCRYPTED" we will get the encrypted value of that plain data (which is present in DB) in the response.

NOTE: For adding of new attribute for encryption, following things need to be kept in mind:

We do not have a direct approach to it, but a workaround as follows:

We need to make sure which property has to be encrypted and what is the path of the property in the Request/Response object of Property. We can add a new property in existing model Property.
Inclusion of any new attribute here would need encryption of the old data for this new property.
For that, in MDMS, we will have to replace the existing model attributes with the only new attributes and hit the _encryptOldData api. Once old data encryption is done, we can put back all the required attributes (old +new) in the model.
Also, before starting the encryption of old data, we will have to check the latest record of table eg_pt_enc_audit . If the latest record has offset and record count value other than 0 then insert a random record with offset and record count as 0 and createdtime and encryptiontime as current timestamp in millis in utc.

Backend service changes

Update the pom.xml file.

Upgrade services-common library version.
<dependency> <groupId>org.egov.services</groupId> <artifactId>services-common</artifactId> <version>1.1.0-SNAPSHOT</version> </dependency>
Upgrade tracer library version.

Add enc-client library

Application Properties changes:

In property-services encryption and decryption end points should be declared as follows:

Also update the following existing property in application-properties:
property.es.index=pt-fuzzy-search-index

EncryptionDecryptionUtil.java:

We need an interfacing file for handling the encryption and decryption of attributes and for interacting with enc-client library directly.

For reference follow the below code snippet

You may find the file here in the repo.

UnmaskingUtil.java:

UnmaskingUtil.java file helps in extracting the plain data of Owner from the User service.

For reference follow the below code snippet

You may find the file here in the repo.

Important methods to be added in service:

If you want to get all the PII data in plain format then in the search request add the search param “isSearchInternal“ as “true”

If the user wants only specific fields to be unmasked then add the plainAccessRequest in the RequestBody in the following format:

plainAccessRequest contains :

recordId which will take uuid of the user as an input for which PII data has to be unmasked, and
plainRequestFields will take and array of attributes that need to be unmasked. These arrtributes should comply with the attributes used in the Mdms SecurityPolicy.json’s models created.

Encryption of Old Data in the dB :

Before using the privacy feature in any environment, first the encryption of existing data in the dB should be done.

An api for the same is written in the service and needs to be triggered by port-forwarding the respective service pod.

The data encryption api uses the existing plainSearch method and the encryption shall take place tenantId-wise. If tenantId is not specified then all the tenants are picked from the mdms repository and the encyption happens for all the tenants. However, if the tenantId is specified, then the encryption happens only for that tenantId.

Following method is added to execute the oldDataEncryption

In PropertyController.java

In PropertyEncryptionService.java
This service is solely for old data encryption and can be referred from here:
PropertyEncryptionService.java

A new persister file needs to be added for keeping track of progress of oldDataEncryption.
Refer this pt-enc-audit-persister.yml for the same.

Here is the Postman collection for all property, water and sewerage services for old Data encryption :
https://www.getpostman.com/collections/b3858ec2020462a6407d

Re-indexing of Old Data in the base indexes:

There is NO need of re-indexing the base indexes(viz. property-services) once the api for old data encryption is executed as this will happen during the api execution itself.
For any new data getting created, the new data will get saved in the encrypted format only in the indexes.

When talking about privacy changes, we would need 2 additional indexes to be added.
both of them would be the copy of existing indexes.
1. A fuzzy index : Copy of index config under existing save topic

Reference: https://github.com/egovernments/configs/commit/5399adb0afae6e646550ca5c4c269632b6aac630

2. An index for Old data encryption: Copy of index config under existing update topic
Reference: https://github.com/egovernments/configs/pull/2516

Enabling / Disabling Privacy:

To enable or disable decryption in privacy, we need to make change only privacy variable present in the environment file in DevOps.
For enabling, its value should be “true” else “false”.

For property-services :

For user-service:

The variable can be found in the file here

For detailed steps to configure the above changes refer document: Detailed Steps to configure privacy in Property module

eGov Knowledge Base

Property : Privacy Changes Backend Technical Documentation