Context based masking scenarios for Field Masking for SAP GUI

In this blog post you will learn how to handle Context (Attribute) based masking scenarios in Field Masking for SAP GUI. The scenarios are implemented using “BAdI: UI Masking and Field Access Trace”.
Sample coding with explanation of each scenario is provided here.

Use Case 1

An object (e.g. a salary) is masked to a subject (e.g. a user) that is attempting to see the object. If the object (e.g. salary) is masked only for some values (e.g. the CEO’s salary but not everybody else) this is known as Attribute-based masking (ABM).

The solution is achieved in UI Masking with below steps –

**The importing data contains the table name. Read the table name into a variable

DATA(lv_tabname) = cs_mask_data-tabname.

** Set the context field on which logic is based. In the use case we need to know the employee number of the object

 lv_context_field = ‘PERNR’.

** Read the program name of the User Interface

DATA(lv_program) = /uim/cl_dynp_msk=>sv_in_prog.

** get the employee number of the object (salary)

 CONCATENATE ‘(‘ lv_program ‘)’ lv_tabname ‘-‘ lv_context_field INTO lv_oid.

ASSIGN (lv_oid) TO <fs_context>.

IF sy-subrc NE 0.

** the table doesn’t contain the employee number field. Implement some logic to get the employee number (e.g. reading through the program stack)

RETURN.

ENDIF.

** Check whether object is to be masked from the subject. As an example, this can be done by maintaining the employee of the object in a user table. Additionally, a whitelist role for the employee should be maintained in this table.

SELECT SINGLE whitelistrole FROM <ztable> INTO @lv_role

WHERE pernr = @<fs_context>.

** if entry is not found in the table, masking happens in standard manner

IF sy-subrc NE 0.

RETURN.

ENDIF.

** Check if the subject viewing the object has the whitelisted role. if no whitelist role is maintained for the employee this means object should be masked from all users

ASSIGN cs_mask_data-masked_val->* TO <fs_mask_val>.

IF lv_role IS INITIAL.

cs_mask_data-auth_flag = abap_false.

<fs_mask_val> = ‘****’.  “Choose masking pattern of your choice

RETURN.

ENDIF.

*** If whitelisted role is maintained in user table, check if the subject viewing the information has the role

SELECT SINGLE agr_name

FROM agr_users

INTO lv_auth

BYPASSING BUFFER

WHERE uname EQ sy-uname

AND agr_name = lv_role

AND from_dat <= sy-datum

AND to_dat >= sy-datum.

** if subject is unauthorized to view the object, mask the object else display original value

IF sy-subrc EQ 0.

cs_mask_data-auth_flag = abap_true.

ELSE.

cs_mask_data-auth_flag = abap_false.

<fs_mask_val> = ‘****’.

ENDIF.

Conclusion –

With the above peice of code in BADI implementation sensitive data (e.g. CEO Salary or any other sensitive information) will be masked from the organization and accessible only to those who have the whitelisted role.

Use Case 2

Employees (subject) shall only be able to see employee data (object) of their own department or of those that are additionally permitted via PFCG roles (whitelisting roles).

This is a case of Level based masking where depending on the Hierarchy-level of the subject (e.g. a user) the object (e.g. salary) is masked. 

The solution is achieved in UI Masking with below steps –

**The importing data contains the table name. Read the table name into a variable

DATA(lv_tabname) = cs_mask_data-tabname.

** Set the context field on which logic is based. In the use case we need to know the employee number of the object

lv_context_field = ‘PERNR’.

** Read the program name of the User Interface

DATA(lv_program) = /uim/cl_dynp_msk=>sv_in_prog.

** get the employee number of the object (salary)

CONCATENATE ‘(‘ lv_program ‘)’ lv_tabname ‘-‘ lv_context_field INTO lv_oid.

ASSIGN (lv_oid) TO <fs_context>.

IF sy-subrc NE 0.

** the table doesn’t contain the employee number field. Implement some logic to get the employee number (e.g. reading through the program stack)

RETURN.

ENDIF.

** Get the department of the employee (object).

SELECT SINGLE werks FROM pa0001

INTO @lv_o_did

WHERE pernr EQ @<fs_context>.

 ** Get the employee number of the subject

    SELECT SINGLE pernr FROM pa0105

INTO @lv_pernr_subject

WHERE usrid EQ @sy-uname.

** Get the department of the subject

    SELECT SINGLE werks FROM pa0001

INTO @lv_s_did

WHERE pernr EQ @lv_pernr_subject.

** If the subject and the object belong to the same department, do not mask provided he/she is allowed through the PFCG role.

IF lv_s_did EQ lv_o_did.

RETURN.

ENDIF.

** If the subject and the object belong to different departments then ideally the subject is not permitted to see the object data. As a special case a subject can see the object if he has a whitelisted role. This can be done by maintaining the object’s employee in a user table. Maintain a whitelist role for the employee in this table.

SELECT SINGLE whitelistrole FROM <ztable> INTO @lv_role

WHERE pernr = @<fs_context>.

** if entry is not found in the table, masking happens in standard manner

IF sy-subrc NE 0.

RETURN.

ENDIF.

** Check if the subject viewing the object has the whitelisted role. if no whitelist role is maintained for the employee this means object should be masked from all users

ASSIGN cs_mask_data-masked_val->* TO <fs_mask_val>.

IF lv_role IS INITIAL.

cs_mask_data-auth_flag = abap_false.

<fs_mask_val> = ‘****’.   “Choose masking pattern of your choice

RETURN.

ENDIF.

*** If whitelisted role is maintained in user table, check if the subject viewing the information has the role

SELECT SINGLE agr_name

FROM agr_users

INTO lv_auth

BYPASSING BUFFER

WHERE uname EQ sy-uname

AND agr_name = lv_role

AND from_dat <= sy-datum

AND to_dat >= sy-datum.

** if subject is unauthorized to view the object, mask the object else display original value

IF sy-subrc EQ 0.

cs_mask_data-auth_flag = abap_true.

ELSE.

cs_mask_data-auth_flag = abap_false.

<fs_mask_val> = ‘****’.

ENDIF.

Conclusion –

With the above peice of code in BADI implementation Level based authorization is achieved (e.g. Sales data is visible only to the Sales department). The users who are not part of the same department or doesn’t have the whitelisted role has the Sales data masked from them.