To implement a secure bank account search service in Mukta that masks Personally Identifiable Information (PII) in the response based on the user’s role and predefined security policies.
PII data - Branch name, Account number, IFSC
The response would be based on the config set in MDMS-V2 which masks the above fields in appropriate patterns.
Key Components
1. Masking Methodology
Masking is applied to sensitive attributes such as accountHolderName, accountNumber, and ifscCode.
A regular expression-based masking technique is used, replacing parts of the sensitive values with asterisks (*).
Example: For a pattern - (?=.{4}), the value 12345678 would be masked as ****5678.
2. Security Policy:
Role-Based Access Control (RBAC):
Defines which roles can access attributes in plain text.
Example roles: BILL_ACCOUNTANT, MUKTA_ADMIN.
Attribute Visibility Levels:
PLAIN: The attribute is fully visible.
MASKED: Attribute is partially masked.
Policy Configuration Example:
3. Masking Pattern Configuration:
Patterns define how sensitive attributes are masked.
Example configuration:
Pattern Example:
Pattern.(?=.{4}): Masks all characters except the last 4.
Pattern (?<=.{4}).(?=.{2}): Masks characters except the first 4 and last 2.
4. Implementation Details:
The service retrieves security policies and masking patterns from MDMS.
User roles are validated to determine access levels for each attribute.
Masking is applied dynamically to sensitive data if the user’s role lacks plain text access.
5. Code Highlights:
Role Access Check: Ensures attributes are visible in plain text only if the user’s role has access.
Masking Application: Masks attribute values using patterns fetched from the configuration.
Nested JSON Handling: Retrieves and updates attribute values dynamically using JSON paths
