OBIEE “Act As Proxy” Feature

Right ! I am back with a article of  OBIEE 10g  feature called “Proxy User” .Also known as “Act As Proxy” .

So here we will learn about the usage of  Web Catalog Privileges option as below :

The background of this utility is ,using this feature One user can act a proxy user and can give a proxy on behalf of other user here called Target user ,such a way that Proxy user can edit ,manipulate the request created by Target user . Being a Administrator ,he has to assign the Proxy permission to the group of people who will act as Proxy User.Thus Administrator will be delegating the permissions .Which proxy user will access which Target user report could be determined by the mapping defined under back-end table. So whatever the Report and Dashboard the Target user have access would be visualized by the Proxy User .

Sometime Global Administrator user want to see the reports of the target users for debugging purpose.In this scenario he/she might be interested for acting as Proxy User and assign the Act As Proxy for him/her . This is a typical scenario where this feature is suitable.

Below specifies the Proxy feature in step by step approach :

1) For my case I have build a repository using the SCOTT schema ‘EMP’ and ‘DEPT’ table .Apart from that I have created a PROXY_TABLE to maintain a relationship between Proxy and Target user list as below.Added that table in my repository .

So here ACCESS_TYPE is a column which takes 2 values — full or restricted. If full access is provided, then the Proxyuser list would have edit/read privileges of the Target user Dashboards/Pages/Reports (N.B :- Proxyuser himself should have those read/edit privileges). If restricted access is provided, then the Proxyuser would only have read privileges (provided the proxy user himself has those privileges).

2)  My RPD configuration as below :  I have also created the  6 users  in RPD  appeared above  among  which ‘proxyuser1′ , ‘proxyuser2′ , ‘proxyuser3′ have been added under user group ‘Proxy_User_Groups’ . This user group I  have to create in Web Catalog as well  so that  Act As Proxy can  only be given to that group .

3) Now we have to create the list of Session Initialisation Block and Variable to fetch the target user list based on the logged in Proxy user .

Hence I create Init Block ‘Set_RUNAS’ which will populate a Non-System Session variable RUNAS defined later in sqltemplate file and it is acting as a parameter to that custom Logon template(see point 7 XML code) file .Since we will pass this variable in next Init block hence lets populate it using a dummy SQL as :

SELECT ‘SOMETHING’ FROM DUAL

4) Lets initialize a System Session Variable ‘PROXY’ using the query below and set the proper execution precedence.

SELECT TARGET_USER FROM PROXY_TABLE
WHERE TARGET_USER = ‘VALUEOF(NQ_SESSION.RUNAS)’
AND PROXY_USER = ‘:USER’

5) Initialize Proxy Level variable as Non-System Session variable  to define the access type using below SQL :

SELECT ACCESS_TYPE FROM PROXY_TABLE
WHERE TARGET_USER=’VALUEOF(NQ_SESSION.RUNAS)’ AND PROXY_USER = ‘:USER’
6) Now lets put a instanceconfig.xml entry below just before tag </ServerInstance>

<LogonParam>
<TemplateMessageName>ProxyLogonParamTemplate</TemplateMessageName>
<MaxValues>200</MaxValues>
</LogonParam>
This will ensure that a new message template can be called where template name is “ProxyLogonParamTemplate” and the Max Value specifies maximum how many user can be defined as “Act As” .

7) We need to define the custom message template as below and save the file as “ProxyUser.xml’ under “..\OracleBI\web\msgdb\customMessages” .

This custom message template for the proxy functionality contains the SQL to get the list of target users that a proxy user can Act As. This list appears in the User box in the Act As dialog box.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<WebMessageTables xmlns:sawm=”com.siebel.analytics.web.messageSystem”>
<WebMessageTable system=”SecurityTemplates” table=”Messages” translate=”no”>
<WebMessage name=”ProxyLogonParamTemplate”>
<XML>
<logonParam name=”RUNAS“>
<getValues>EXECUTE PHYSICAL CONNECTION POOL oradeba.Proxy_Conn
select TARGET_USER from PROXY_TABLE where PROXY_USER=’@{USERID}’</getValues>
<verifyValue> EXECUTE PHYSICAL CONNECTION POOL oradeba.Proxy_Conn
select TARGET_USER from PROXY_TABLE where PROXY_USER=’@{USERID}’ and TARGET_USER=’@{VALUE}’</verifyValue>
<getDelegateUsers>EXECUTE PHYSICAL CONNECTION POOL oradeba.Proxy_Conn
select PROXY_USER, ACCESS_TYPE from PROXY_TABLE where TARGET_USER=’@{USERID}’
</getDelegateUsers>
</logonParam>
</XML>
</WebMessage>
</WebMessageTable>
</WebMessageTables>

8 ) Now Restart BI server and Presentation server .

9) Using targetuser1 , targetuser2 I have developed two reports .So that when proxyuser1 logged in he/she would be able to Act as targetuser1 and can see the reports developed by targetuser1.Similarly targetuser2 report is also delegated to proxyuser2 .proxyuser1 could edit/change the targetuser1 reports but proxyuser2 would not be able to modify targetuser2 reports .

10)  Using Administrator login Goto Manage Privileges and under “Act As Proxy” set the Proxy user group .For my case, I have Granted the privileges to ” Proxy_User_Groups ” .

11) I have logged in as proxyuser1 and landed to below reports which is proxyuser1′s own report not targetuser1 report. Now click on “Set As” under Settings link and you will get a small window open which will be populated using ‘targetuser1′ .As much as targetuser defined it will be get populated in this drop down list .

12) Now clicked “ok” and landed to the report developed by ‘targetuser1′ in his/her own dashboard .As the ‘Edit Dashboard’ option is enabled hence you can do any modification here and save the report. Next time when ‘targetuser1′ will log into system he/she can easily find the changes done by someone ! here by its Proxy .

13) Now logout from ‘proxyuser1′ and logged in as ‘proxyuser2′ . Go to Settings and clicked on “Set As” .After that ‘targetuser2′ should be selected .Click “ok” .Now you can see ‘targetuser2′ dashboard reports .Also ‘Edit option’ is disabled since “proxyuser2″ has “restricted” access level defined under PROXY_TABLE .

14) So thats all about OBIEE Proxy user feature ! So small but so robust …