OBIEE “Act As” vs “Impersonate”

http://www.rittmanmead.com/2013/10/obiee-act-as-vs-impersonate/


Grupie BIAdministratoras należy dodać polisę :oracle.bi.server.impersonateUsers
ORACLE DOC http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/install.htm#CIHJEIEG

There will come a point in the lifecycle of an OBIEE deployment when one user will need to access another user’s account. This may be to cover whilst a colleague is on leave, or a support staff trying to reproduce a reported error.

Password sharing aside (it’s zero-config! but a really really bad idea), OBIEE supports two methods for one user to access the system as if they were another: Impersonation and Act As.

This blog article is not an explanation of how to set these up (there are plenty of blogs and rip-off blogs detailing this already), but to explain the difference between the two options.

First, a quick look at what they actually are.

Impersonation

Impersonation is where a “superuser” (one with oracle.bi.server.impersonateUser application policy grant) can login to OBIEE as another user, without needing their password. It is achieved in the front end by constructing a URL, specifying:

• The superuser’s login name and password (NQUser and NQPasword)
• The login ID of the user to impersonate (Impersonate)

For example:

http://server:port/analytics/saw.dll?Logon&NQUser=weblogic&NQPassword=Password01&Impersonate=FSmith_FundY

The server will return a blank page to this request, but you can then submit another URL to OBIEE (eg the OBIEE catalog page or home page) and will already be authenticated as the Impersonate user – without having specified their password.

From here you can view the system as they would, and carry out whatever support or troubleshooting tasks are required.

Caution :  Impersonation is disabled by default, even for the weblogic Administrator user, and it is a good idea to leave it that way. If you do decide to enable it, make sure that the user to whom you grant it has a secure password that is not shared or known by anyone other than the account owner. Also, you will see from the illustration above that the password is submitted in plain text which is not good from a security point of view. It could be “sniffed” along the way, or more easily, extracted from the browser history.

Act As

Whilst Act As is a very similar concept to Impersonation (allow one user to access OBIEE as if they were another), Act As is much more controlled in how it grants the rights. Act As requires you to specify a list of users who may use the functionality (“Proxy users”), and for each of the proxy users, a list of users (“Target users”) who they may access OBIEE as.

Act As functionality is accessed from the user dropdown menu :

From where a list of users that the logged-in user (“proxy user”) has been configured to be able to access is shown :

Selecting a user switches straight to it:

In addition to this fine grained specification of user:user relationships, you can specify the level of access a Proxy user gets – full, or read-only. Target users (those others can Act As) can see from their account page who exactly has access to their account, and what level of access.

So what’s the difference?

Here’s a comparison I’ve drawn up

Here are a couple of examples to illustrate the point:

Based on this, my guidelines for use would be :

• As an OBIEE sysadmin, you may want to use Impersonate to be able to test and troubleshoot issues. However, it is functionality much more intended for systems integration than front-end user consumption. It doesn’t offer anything that Act As doesn’t, except fewer configuration steps. It is less secure that Act As, and could even be seen as a “backdoor” option. Particularly at companies where audit/traceability is important should be left disabled.
• Act As is generally the better choice in all scenarios of an OBIEE user needing the ability to access another’s account, whether between colleagues, L1/L2 support staff, or administrators. 
  Compared to Impersonation, it is more secure, more flexible, and more granular in whose accounts can be accessed by whom. It is also fully integrated into the user interface as standard functionality of the tool.

Reference

• Act As: Enabling Users to Act for Others
• Impersonate: How to use OBIEE Impersonate parameter for quick checks

Thanks to Christian Berg, Gianni Ceresa and Gianni Ceresa for reading drafts of this article and providing valuable feedback

Tags: act as, impersonate, obiee