Edit

Water & Sewerage Privacy Changes

Backend technical documentation

Overview

This document highlights the changes that need to be done in a Water and Sewerage module to support the privacy feature.

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. The following models have been used for W&S in the SecurityPolicy.json file:

{
      "model": "WnSConnection",
      "uniqueIdentifier": {
        "name": "uuid",
        "jsonPath": "/connectionHolders/0/uuid"
      },
      "attributes": [
        {
          "name": "ownerType",
          "jsonPath": "connectionHolders/*/ownerType",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "relationship",
          "jsonPath": "connectionHolders/*/relationship",
          "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"],
          "attributeAccessList": [          
            {
              "attribute": "ownerType",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "relationship",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        },
        {
          "roles": ["REINDEXING_ROLE"],
          "attributeAccessList": [
            {
              "attribute": "ownerType",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "relationship",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        }
      ]
    },
    {
      "model": "WnSConnectionOwner",
      "uniqueIdentifier": {
        "name": "uuid",
        "jsonPath": "/uuid"
      },
      "attributes": [
      
        {
          "name": "connectionHoldersMobileNumber",
          "jsonPath": "mobileNumber",
          "patternId": "001",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "fatherOrHusbandName",
          "jsonPath": "fatherOrHusbandName",
          "patternId": "002",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "gender",
          "jsonPath": "gender",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "correspondenceAddress",
          "jsonPath": "correspondenceAddress",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "ownerType",
          "jsonPath": "connectionHolders/*/ownerType",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "plumberInfoMobileNumber",
          "jsonPath": "plumberInfo/*/mobileNumber",
          "patternId": "001",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "assigneeMobileNumber",
          "jsonPath": "assignes/*/mobileNumber",
          "patternId": "001",
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "relationship",
          "jsonPath": "connectionHolders/*/relationship",
          "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"],
          "attributeAccessList": [
            {
              "attribute": "connectionHoldersMobileNumber",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "gender",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "fatherOrHusbandName",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "ownerType",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "correspondenceAddress",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "relationship",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "plumberInfoMobileNumber",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "assigneeMobileNumber",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        },
        {
          "roles": ["REINDEXING_ROLE"],
          "attributeAccessList": [
            {
              "attribute": "connectionHoldersMobileNumber",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "gender",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "fatherOrHusbandName",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "ownerType",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "correspondenceAddress",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "relationship",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "plumberInfoMobileNumber",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            },
            {
              "attribute": "assigneeMobileNumber",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        }
      ]
    },
    {
      "model": "WnSConnectionDecrypDisabled",
      "uniqueIdentifier": {
        "name": "uuid",
        "jsonPath": "/connectionHolders/0/uuid"
      },
      "attributes": [
        {
          "name": "ownerType",
          "jsonPath": "connectionHolders/*/ownerType",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "relationship",
          "jsonPath": "connectionHolders/*/relationship",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        }
      ],
      "roleBasedDecryptionPolicy": []
    },
    {
      "model": "WnSConnectionOwnerDecrypDisabled",
      "uniqueIdentifier": {
        "name": "uuid",
        "jsonPath": "/uuid"
      },
      "attributes": [
        {
          "name": "connectionHoldersMobileNumber",
          "jsonPath": "mobileNumber",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "fatherOrHusbandName",
          "jsonPath": "fatherOrHusbandName",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "gender",
          "jsonPath": "gender",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "correspondenceAddress",
          "jsonPath": "correspondenceAddress",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "ownerType",
          "jsonPath": "connectionHolders/*/ownerType",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "plumberInfoMobileNumber",
          "jsonPath": "plumberInfo/*/mobileNumber",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "assigneeMobileNumber",
          "jsonPath": "assignes/*/mobileNumber",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        },
        {
          "name": "relationship",
          "jsonPath": "connectionHolders/*/relationship",
          "patternId": "005",
          "defaultVisibility": "PLAIN"
        }
      ],
      "roleBasedDecryptionPolicy": []
    },
    {
      "model": "WnSConnectionPlumber",
      "uniqueIdentifier": {
        "name": "applicationNo",
        "jsonPath": "/applicationNo"
      },
      "attributes": [  
        {
          "name": "plumberInfoMobileNumber",
          "jsonPath": "plumberInfo/*/mobileNumber",
          "patternId": "001",
          "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"],
          "attributeAccessList": [
           {
              "attribute": "plumberInfoMobileNumber",
              "firstLevelVisibility": "MASKED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        },
        {
          "roles": ["REINDEXING_ROLE"],
          "attributeAccessList": [
            {
              "attribute": "plumberInfoMobileNumber",
              "firstLevelVisibility": "ENCRYPTED",
              "secondLevelVisibility": "PLAIN"
            }
          ]
        }
      ]
    },
    {
      "model": "WnSConnectionPlumberDecrypDisabled",
      "uniqueIdentifier": {
        "name": "applicationNo",
        "jsonPath": "/applicationNo"
      },
      "attributes": [
        {
          "name": "plumberInfoMobileNumber",
          "jsonPath": "plumberInfo/*/mobileNumber",
          "patternId": null,
          "defaultVisibility": "PLAIN"
        }
      ],
      "roleBasedDecryptionPolicy": []
    }

Also, add the following under roleBasedDecryptionPolicy of User model(already existing):

Refer to 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 models User which is used when a user tries to search other user data. The PII data will be available in masked, plain or encrypted form depending on the visibility set for an attribute in the MDMS. The other model is UserSelf which is used when a user tries to search their own data. The data is available 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 W&S we have 2 models -WnSConnection and WnSConnectionOwner which are meant for ConnectionHolderDetails. 2 different models for connectionHolder data are required since some data for connectionHolder comes from the W&S tables and the remaining is fetched from the User table. So to maintain consistency we had to have 2 different models.

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

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

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

  1. 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 W&S. If PII data is for connectionholder and is coming from WnS tables directly, then with the Proper name and path of the object we can add a new Property in existing model WnSConnection. The 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 only new attributes and hit the _encryptOldData API. Once old data encryption is done, we can put back all the required attributes (old and +new) in the model. Also, before starting the encryption of old data, we will have to check the latest record of the table eg_ws_enc_audit / eg_sw_enc_audit / eg_pt_enc_audit(for PT) . 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 a current timestamp in millis in utc.

  2. Any data other than that of connectionHolder would need a new model to be created and changes at the code level as well. For old data encryption of new property other than that of connectionHolder, we will have to have code changes as well.

For further info about adding models refer here.

Backend Service Changes

Update the pom.xml file

  • Upgrade services-common library version.

  • Upgrade the tracer library version.

  • Add enc-client library

Application Properties Changes

In ws-services encryption and decryption endpoints should be declared as follows:

In sw-services encryption and decryption endpoints should be declared as follows:

EncryptionDecryptionUtil.java

We need an interfacing file for handling the encryption and decryption of attributes and for interacting with the 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 the Owner from the User service. This file also contains a method that swaps the PlumberInfo in a similar manner.

For reference follow the below code snippet:

You may find the file here in the repo.

Important Methods To Add

Method to encrypt the water/sewerage requestBody data:

The following method is added in WaterServiceImpl.java for encrypting the entire data

Method to decrypt the water/sewerage data:

The following method is added in WaterServiceImpl.java for decrypting the entire data

_search API Changes

During the search call the PII data needs to be masked in the response received. For this, the searchCriteria needs to be encrypted before fetching details and eventually the data retrieved needs to be decrypted and then returned to the user.

Following changes need to be made in WaterServiceImpl.java

You may find the file here in the repo.

If you want to get all the PII data in the plain format then in the search request add the search param “isInternalCall“ 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 : 1. recordId which will take the uuid of the user as an input for which PII data has to be unmasked, and 2. plainRequestFields will take an array of attributes that need to be unmasked. These attributes should comply with the attributes used in the Mdms SecurityPolicy.json’s models created.

For unmasking PlumberInfoMobileNumber, recordId will take the applicationno as value.

_create and _update API Changes

In _create and _update API calls the data needs to be encrypted before the data for application/connection is pushed to respective topics.

A sample code line for encrypting data in these calls is as follows:

A sample code line for decrypting data in these calls is as follows:

The entire method for create call can be found here: create method

and update call can be found here: update method

Encrypting Old Data In The DB

Before using the privacy feature in any environment, 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 encryption happens for all the tenants. However, if the tenantId is specified, then the encryption happens only for that tenantId.

The following method is added to execute the oldDataEncryption

In WaterController.java

n WaterEncryptionService.java This service is solely for old data encryption and can be referred from here: https://github.com/egovernments/DIGIT-Dev/blob/8ec8592b73470c6dcdb1508caa1e6b1cf8ebb2ca/municipal-services/ws-services/src/main/java/org/egov/waterconnection/service/WaterEncryptionService.java A new persister file needs to be added for keeping track of progress of oldDataEncryption. Refer this ws-enc-audit-persister.yml and sw-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 Old Data In The Base Indexes

There is no need to re-index the base indexes(viz. water-services/ sewerage-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.

There are some changes in the Indexer file that need to be made for W&S to get the encrypted data from the external service like Property-service.

So, in the URL mentioned above in apiRequest, change the role from EMPLOYEE to REINDEXING_ROLE. Reference for changes : [UM-4382]- Updated indexer for water service by hinamakhija-eGov · Pull Request #2342 · egovernments/configs [UM-4382]-Updated indexer for sewerage by hinamakhija-eGov · Pull Request #2345 · egovernments/configs This role is a newly defined role in MDMS as already mentioned in the changes at the top. This Role helps in getting the Encrypted data in accordance to firstLevelVisibilty defined for it. For W&S, we need encrypted MobileNumber in the index because W&S inbox uses Elastic search and we require mobileNumber search for the same hence owner MobileNumber has to be there mandatorily in the index for search. The changes need to be made in all the topics for W&S indexes. For more details find the changes here.

Enabling / Disabling Privacy

To enable or disable decryption in privacy, we need to make changes to only the privacy variable present in the environment file in DevOps.

For enabling, its value should be “true” else “false”.

For water-services variable is as follows:

For sewerage-services:

For user-service:

The variable can be found in the file here.

Note: Privacy decryption means: For any new application creation/ old application updation Internal data will be stored in the encrypted form itself, just that during decryption disabled it would give PLAIN text rather than masked one.

All the above changes need to be done for sw-services as well.

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

PreviousWorkflow Config-Replacement DataNextW&S - Steps To Configure Privacy

Last updated

Was this helpful?