Previous Next JavaScript must be enabled to correctly display this content

## 3.1 Indirect Object Reference Implementation

i. What it means

It is a good security practice to hide sensitive data objects from the end user. Although the system needs to play around with sensitive data objects, it is recommended to refer to these sensitive data objects via pointers – tokens that temporarily point to the sensitive data objects but themselves do not contain any sensitive data.

For example consider a credit card application on the web which offers the following 2 transactions:

- Credit Cards Summary – Displays a list of all credit cards the user owns.
- Credit Card Details – Displays the details of one specific Credit Card that the user selects

The Credit Cards Summary page will typically list all credit card numbers in a masked format. Let’s assume that the end user holds 2 Credit Cards C1 and C2. When the end user hits the Summary link, the server returns back the following in its response:

1. Masked Credit Card Number C1 (visible to the user)
2. Masked Credit Card Number C2 (visible to the user)
3. Token T1 (not visible to the user)
4. Token T2 (not visible to the user)

T1 and T2 are random tokens – difficult to guess – which the server has generated as proxies for C1 and C2 respectively. The server has internally stored this mapping of C1-T1 and C2-T2 somewhere. Please note that T1 and T2 are tied to the current session. The moment the session expires, T1 and T2 get discarded. Next time the user logs in, the server generates different tokens T1x and T2x for C1 and C2 respectively.

Whenever the user clicks on say Credit Card Details for C1, the client sends T1 to the server instead of C1, as a request parameter. The server internally figures out that the request is actually for C1 and processes the request accordingly.

Thus we refer to sensitive data indirectly via tokens that are generated with different values for every session.

ii. How OBAPI supports it

To implement the above mechanism the framework offers interception of both the request and the response. The recommendation is to apply indirect referencing to sensitive data fields like Personally Identifiable Information fields aka PII data.

For the interception to work automatically, the sensitive fields holding the PII data must be defined as a Java type, which extends the abstract class

`com.ofss.digx.datatype.complex.MaskedIndirectedObject`.

The abstract class exposes 2 data fields, namely value and displayValue. The `value` field holds the indirect reference value, which is used during data transmission from the client to the server. The `displayValue` field holds the masked value of the data.

The following data types are supported out-of-box:

1. `com.ofss.digx.datatype.complex.Account` - Account number
2. `com.ofss.digx.datatype.complex.Applicant` – The unique identifier to identify an applicant. Typically a party ID.
3. `com.ofss.digx.datatype.complex.ApplicationId` – The unique identifier of an application for account opening.
4. `com.ofss.digx.datatype.complex.ContentId` – The unique identifier for content such as documents for a party.
5. `com.ofss.digx.datatype.complex.CreditCard` – Credit Card Number
6. `com.ofss.digx.datatype.complex.DebitCard` – Debit Card Number
7. `com.ofss.digx.datatype.complex.Email` – Email ID
8. `com.ofss.digx.datatype.complex.Party` – The unique identifier for a party.
9. `com.ofss.digx.datatype.complex.PhoneNumber` – Phone Number
10. `com.ofss.digx.datatype.complex.SSN` – Social Security Number
11. `com.ofss.digx.datatype.complex.SubmissionId` – The unique identifier for a submission containing 1 or more applications for account opening.

To modify the existing/base product-masking pattern for any of the above data types, the following entries need to be copied/cloned from the table `DIGX_FW_CONFIG_ALL_B` to the table `DIGX_FW_CONFIG_ALL_O` and then modified as required in `DIGX_FW_CONFIG_ALL_O`.

Note:

Please DO NOT MODIFY these entries in `DIGX_FW_CONFIG_ALL_B`.

Data Type | Category ID / Preference Name | Property ID
--- | --- | ---
Account | MaskingPattern | AccountNumberMasking
Applicant | MaskingPattern | ApplicantIdMasking
ApplicationId | MaskingPattern | ApplicationIdIdMasking
ContentId | MaskingPattern | ContentIdMaskingPattern
CreditCard | MaskingPattern | CreditCardNumberMasking
DebitCard | MaskingPattern | DebitCardNumberMasking
Email | MaskingPattern | EmailIdMasking
Party | MaskingPattern | PartyIdMasking
PhoneNumber | MaskingPattern | PhoneNumberMasking
SSN | MaskingPattern | SSNMasking
SubmissionId | MaskingPattern | SubmissionIdMaskingPattern

The characters allowed in the making pattern are as below:

N – Keeps the character transparent. Does not mask.

Any other character – Replaces the character at the location with the character specified.

For example: XXXXXNNNN will keep the last 4 characters in clear text and mask the first 5 characters using the character ‘X’.

Parent topic: Guidance for Implementation Teams