OBIEE With Essbase as a Data Source Using SSO

There are various ways to integrate OBIEE and Essbase when using SSO, each with their own security specifics and implementation difficulty. The three main ways of SSO authentication between OBIEE and Essbase are:

1. Username and password pass-through – this passes the user name and user password through to the Essbase server with each request. This will not work with some OBIEE Authentication methods such as SAML SSO Authentication due to the fact that the OBIEE server never knows the user password.
2. CSS Token authentication – This is not recommended any more due to the difficulty in setting it up. This process differers depending on the version of Essbase used.
3. User Impersonation – this uses an Essbase Admin user (or user with the required permission) for the connection between OBIEE and Essbase however when data is requested, the username is passed to the Essbase server as part of the EssLoginAs function. This function is similar to using su – username in Linux as it assumes the username‘s status despite who initially connected.

Option 1 doesn’t work in all scenarios, such as when OBIEE authentication is done using SAML SSO – so that rules out option 1. Oracle no longer recommends using the CSS Token method due to the complexity involved in setting it up – so that removes option 2 from the pool.

Option 3 is the new, recommended method of connecting OBIEE to an Essbase data source using single sign on. The client authenticates with OBIEE using the Authentication Provider, in this case Active Directory, and then sends the username to the Essbase server to run all further commands (such as ‘give me some data’) as if it were the user running them.

Setting this up is very easy. You need an Essbase user that has permission to run EssLoginAs , such as any admin user. Once you have that, enter that users credentials into the Connection Pool’s User name and Password fields under Shared logon and tick the SSO check box.  And that’s it – you’re good to go!

It’s worth noting that if you look at Sessions in the EAS Console you’ll only see the Admin user name and not the user being impersonated. It can be a bit misleading, but you’ll see something similar to the below in the Essbase logs:

[Thu Jun 18 20:18:12 2015]Local/ESSBASE0///Info(1051529)
Logging in user [essbaseadmin] with security privileges of user [james]

This shows the initial user that is in your Connection Pool, essbaseadmin, and the user being impersonated, james.