0
0
During this post we will discuss about the “IS_GRANTED_TO_INVOKER_ROLE” access control property. It Returns TRUE if the role returned by the INVOKER_ROLE function inherits the privileges of the specified role in the argument.
is_granted_to_invoker_role( ‘<string_literal>‘ )
We will be using IS_GRANTED_TO_INVOKER_ROLE property in conjunction with Dynamic Masking. This Role function passed into a masking policy body as part of a condition. When the function evaluates to TRUE, the role in the function argument is in the INVOKER_ROLE hierarchy.
However, To get more clarity on this function, we will implement the below scenario:
For Instance, we have CUSTOMER_DATA table which stores PII information like SSN and Phone.
As part of this requirement ,PHONE should be masked using Dynamic Masking and IS_GRANTED_TO_INVOKER_ROLE SYSTEM FUNCTION.
Currently we have two Roles in system: REP and FLM. As of now there is no hierarchy among these Roles and will create Masking Policy inside the FLM.
Login to the FLM account :
CREATE OR REPLACE MASKING POLICY CUSTOMER_PII_PHONE
AS (PHN NUMBER) RETURNS NUMBER ->
CASE
when is_granted_to_invoker_role('REP1') then PHN
ELSE '0'
END;
Assign this Policy to CUSTOMER_DATA table on PHONE number column:
ALTER TABLE CUSTOMER_DATA MODIFY COLUMN PHONE SET MASKING POLICY CUSTOMER_PII_PHONE;
Login to FLM and query the table: Phone is mask for FLM.
As REP1 does not belongs to FLM hierarchy and hence Masking Policy moves into the ELSE condition.
Now Grant the Role REP1 — > FLM (via ACCOUNTADMIN)
GRANT ROLE REP1 to ROLE FLM;
Login to FLM and query the table: Phone is visible for FLM.
And if we try to query the table via ACCOUNTADMIN, Data would be masked as REP1 is not part of ACCOUNTADMIN in hierarchy.
