OBIEE “Act As” (ActAs) vs “Impersonate”

October 16th, 2013 by

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 is where a “superuser” (one with 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:


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.


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

Tags: , ,


  1. Scott Powell Says:

    Hi Robin, quick question on both Impersonate and Act As – we’ve configured OBIEE with single sign on and we’re using database tables to hold the OBIEE roles a user gets. With either Impersonate or Act As, are the appropriate queries fired to pull back the right roles? i.e. if I choose to “Act As” user ABC, will the SQL still get fired to grant me the roles user ABC would normally have?


  2. Robin Moffatt Says:

    Hi Scott, I’m afraid I’ve never tried that particular configuration, so wouldn’t know the answer without trying it :-)

  3. Scott Powell Says:

    Ok, I’ll give it a try and post back here what we find out. I’m suspecting that the roles will not be refreshed properly, but maybe I’ll be surprised.


  4. Robin Moffatt Says:

    In case you’ve not seen them, I noticed a few articles on MOS regarding SSO and Act As / Impersonate which may be relevant.
    Let me know how you get on.

  5. Jayesh Rao Says:

    @Scott: I believe it will work fine, it will fatch the roles from database for the users. Because once you login as another user, USER session variable will have appropriate value and that shall give you the roles associated with user. I am assuming you are using USER session variable in Init block to fatch user roles.

    I have done the same successfully in OBIEE 10g release. We were having SSO authentication and authorization was from databse table. It worked fine.

  6. Jayesh Rao Says:

    Hello Robin,

    You mentioned ” Impersonation is disabled by default, even for the weblogic Administrator user”. Do you mean to say the impersonation policy is not added in BI Administrator role?

    By the way, as you rightly said that impersonation is primary a concept for systems integration. And as OBIEE 11g provides integration with BI Scheduler, so this application policy is already added for “BI System” application role.


  7. Robin Moffatt Says:


    You mentioned ”Impersonation is disabled by default, even for the weblogic Administrator user”. Do you mean to say the impersonation policy is not added in BI Administrator role?

    Yes – on a vanilla install I had to grant the application policy explicitly even to the BI Administrator role.

  8. Jayesh Rao Says:

    Yes. I instead used BISystem user for impersonation as this user by default has access on this poliy (via BI System application role).


  9. Scott Powell Says:


    we are not using init block functionality, we’re using the ReadOnlySQLAuthenticator through weblogic, which is the “proper” way to do it in 11g. But I’m thinking it also means that Act As isn’t going to work properly.

    I’ll try it out and post a comment here after I have a chance to play with it.


  10. Amrutha Says:


    Thats a good article. When developers use impersonation for testing purpose in Production instances, it significantly effects the Usage Tracking right.

    Is there a way that Impersonation can be indicated as some flag which can be seen in Usage Tracking report?


  11. Robin Moffatt Says:


    Good question. I just checked this and both Act As and Impersonate will log the authenticated user (“proxy user” / superuser) in the IMPERSONATOR_USER_NAME column of S_NQ_ACCT, whilst the user being impersonated or acted as will be shown in USER_NAME.

  12. Asis Panda Says:


    I had logged in with the credentials of weblogic, but I am unable to get the drop-down list which contains ‘My account and Act As’.
    Does it require any configuration?

  13. Robin Moffatt Says:

    Yes, Act As requires extensive configuration. See the link above under “References” for more information.

Website Design & Build: