User Impersonation

This section describes how to impersonate a user in the Oracle database protector. The user impersonation feature enables you to perform operations and access resources on behalf of another user. Service users leverage this feature to impersonate individual users. However, to supply user context to execute a query, upper applications provide the CLIENT_IDENTIFIER. Set the impersonation parameter to YES in the config.ini file, to use the CLIENT_IDENTIFIER parameter of the inbuilt USERENV application context SYS_CONTEXT provided by the Oracle database.

To impersonate a user:

1. Log in to the node where the Oracle database is installed.

2. Navigate to the /opt/protegrity/databaseprotector/oracle/data/ directory.

3. To open the config.ini file, run the following command:

   vi config.ini
   

4. Press ENTER.

   The command opens the config.ini file.

   ###############################################################################
   # Protector configuration
   ###############################################################################
   [protector]
   
   # Cadence determines how often the protector connects with ESA / proxy to fetch the policy updates in background.
   # Default is 60 seconds. So by default, every 60 seconds protector tries to fetch the policy updates.
   # If the cadence is set to "0", then the protector will get the policy only once.
   #
   # Default 60.
   cadence = 60
   
   
   ###############################################################################
   # Log Provider Config
   ###############################################################################
   [log]
   
   # In case that connection to fluent-bit is lost, set how audits/logs are handled
   #
   # drop  : (default) Protector throws logs away if connection to the fluentbit is lost
   # error : Protector returns error without protecting/unprotecting
   #         data if connection to the fluentbit is lost
   mode = drop
   
   # Host/IP to fluent-bit where audits/logs will be forwarded from the protector
   #
   # Default localhost
   host = localhost
   

5. To include the impersonation parameter and set the value to YES, add the following code:

   [userimpersonation]
   impersonation = yes/no or YES/NO
   

   The default value of the impersonation parameter is set to NO or no.

6. Assign 644 permissions to the config.ini file. This is required only tf the ownership of the config.ini file is not set to the oracle user and the oinstall group.

7. Connect to the database session using the service account. For example, USER1.

8. To set the CLIENT_IDENTIFIER, execute the following query:

   EXEC DBMS_SESSION.SET_IDENTIFIER ('USER2');
   

9. Press ENTER. The query returns the name of the user for whom you set the CLIENT_IDENTIFIER parameter.

   USER2
   

10. To verify the value that is set for the CLIENT_IDENTIFIER parameter, execute the following query: SQL> select sys_context('USERENV','CLIENT_IDENTIFIER') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')

11. Press ENTER. The query returns the name of the user for whom you set the CLIENT_IDENTIFIER parameter.

    USER2
    

    Warning: When you set the value of the impersonation parameter to yes/YES, then set a value for the the CLIENT_IDENTIFIER parameter. The protect/unprotect UDFs will run only after the value for the CLIENT_IDENTIFIER parameter is set. If you set the value of the impersonation parameter to yes/YES, and fail to set the value for the CLIENT_IDENTIFIER parameter, then the PTY.WHOAMI() UDF will return the username as <no_user>. This will cause the protect/unprotect operations to fail with the Failed to retrieve user error message.

12. To verify the user who is logged into the database session, execute the following query:

    select pty.whoami() from dual;
    

13. Press ENTER. The query returns the name of the user that is logged into the current database session.

    USER2
    

14. To clear the value set for the CLIENT_IDENTIFIER parameter, execute the following query:

    EXEC DBMS_SESSION.CLEAR_IDENTIFIER;