Attribute based authorizations using Policy
In this blog post, you will learn how to handle context-based authorizations in Field Masking scenarios through Policies which are introduced in the product UI Data Protection Masking for S/4 HANA. A basic overview of Policy and its various components is provided in this Blog.
Q) Why Policy?
Ans) Policies are a user-friendly way of implementing authorization rules. To implement a basic Policy the user is not required to have technical knowledge of BAdIs. So for a user unfamiliar with BAdIs, he/she can use Policies to execute field masking.
Q) What is a Policy?
Ans) A Policy is a combination of rules and actions which are defined in one or more blocks. The actions are executed on a sensitive entity (field to be protected) which has to be assigned to a Policy. The conditions are based on contextual attributes that help derive the context. Every Policy has a default result that needs to maintain.
Q) What is a Block?
Ans) A block is the basic building ‘block’ of a Policy. A policy can have one or more blocks that define the conditions which need to evaluated and the actions which need to be performed according to the conditions.
Each block comprises of 2 parts :
- Rule (Mandatory) –
1. Pre – Condition
The pre-condition allows you to define a condition that will decide if the statement(s) maintained in the Rule will be evaluated or not. If the pre-condition holds true, only then will the Rule be evaluated. When a pre-condition is left blank it is assumed to be true. If the pre-condition fails (returns False), the current Block will be bypassed and the next block will be evaluated.
If a user wishes to execute a Policy only when the Transaction Code is SE16 OR SE16N, the following pre-condition should be maintained :
SY-TCODE = ‘SE16’ OR SY-TCODE = ‘SE16N’. (1)
This implies that the subsequent Rule defined by the user in the Policy should only be implemented if the transaction code is SE16 or SE16N. Here SY-TCODE acts as the contextual attribute.
Rule is a combination of conditions and actions. Here, you can define the condition(s) and action (mask, hide, clear, etc.) which will be evaluated and executed on the sensitive entity assigned to the policy. If all the conditions defined in a rule fail (returns False), no action will be executed, and the Default Result will be executed. All the subsequent blocks (if any) will be bypassed once a rule condition evaluated.
- If a user wishes to mask the annual salary of an employee only if his Personnel number(PERNR) is ‘69’, the following Rule should be maintained in the respective Block.
PERNR = ‘69’ (2)
THEN RESULT = ‘MASK’.
The result specifies the action which is executed on the assigned sensitive entity. If PERNR is not 69 then the default result will be executed on the sensitive entity. Here, PERNR acts as the contextual attribute.
3. Default Result of Policy
The default result of the Policy is executed if a scenario is not handled by the conditions specified in all the rules in the policy.
DEFAULT RESULT = ‘CLEAR’ (3)
If the Rule of a block fails, the sensitive entity/entities linked to the Policy will be cleared by default.
Statements (1), (2) and (3) when combined make a block which implicitly executes the following conditional logic:
If Transaction Code is SE16 or SE16N *Pre-Condition
If Personnel Number is 69 *Rule
Mask (the sensitive entity)
Else, Clear (the sensitive entity) *Default Result
Else Move to Next Block.
Q) How do I create a Policy?
Ans) The Policy Builder provides an environment to develop Policies. The Policy Builder provides a list of pre-defined contextual attributes, actions and miscellaneous features that the user can use to protect a sensitive entity. The user can also create user-defined contextual attributes that can be used through the Policy Builder. Before defining a Policy, the user must ensure that a sensitive entity is assigned to the Policy.
For more details on UI Data Protection Masking and Policies, please refer to the blog series by Amit Kumar Singh