In this post I share the necessary steps in order to integrate OBIEE 10g into OAM 11g Single Sign On with the little caveat that OBIEE Analytics application is deployed in Weblogic server.
OBIEE 10g has two installation modes: basic and advanced. For SSO integration, you must pick adavanced mode. And Oracle Application Server version 10.1.3.1.0 or later is required.
OBIEE 10g implements SSO through the concept of impersonation. It retrieves the end user identity through one of the mechanisms mentioned above and uses an impersonator user to establish a session to the OBIEE server on behalf of the end user.
This post by no means intends to discuss OBIEE architecture or go into the details of OAM 11g. As a matter of fact, the latter is extensively discussed in this blog by my colleagues in the Oracle Access Manager Academy series. Reading strongly recommended. Fantastic material.
And what you’re about to follow has been implemented in a Windows XP box for demonstration purposes.
The exact product versions used were:
Fasten your seat belts! Here we go.
When you install OBIEE 10g, you get a set of standalone component processes, some admin UIs and a front-end web application running on top of OC4J.
For the purposes of this post, we’re interested in the BI Server, BI Presentation Services and the BI Presentation Services Plug-in components. The BI Server is a standalone process that maintains the BI data model and connects to data stores. BI Presentation Services is another standalone process that present information worked by BI Server to clients via ODBC. BI Presentation Services Plug-in allows web clients to interact with BI Presentation Services. In JavaEE application servers, it is a servlet component delivered via the analytics.war web application.
Once OBIEE is installed, find the analytics.war file under $BI_HOME/web folder.
Shut down OC4J in case it's running. We don't need it.
Simply use Weblogic console to deploy the analytics.war application. There really is nothing special here. Click click click and you should get the analytics application up and running in Weblogic.
OHS front-ends Weblogic server. A mod weblogic routing rule will forward requests to the analytics application running in Weblogic.
This step can also be accomplished via Enterprise Manager.
Open mod_wl_ohs.conf located under your OHS instance home config folder and type in the following:
<IfModule weblogic_module> WebLogicHost <!--weblogic-server-running-analytics-application--> WebLogicPort <!--weblogic-port--> Debug ON WLLogFile /tmp/weblogic.log </IfModule> <Location /analytics> SetHandler weblogic-handler </Location>
Make sure to replace the values in between <!-- -->
The OHS instance home config folder is typically located at $ORACLE_HOME/instances/<instance-name>/config/OHS/ohs1
Checkpoint 1: at this point we should be able to submit requests to OHS and have them directed to Weblogic.
Nothing special here. Just follow OAM 11g install guide. It is a good idea to create one Weblogic domain along with one managed server for the OAM server.
The WebGate checks whether the executing user is authenticated before letting it access the analytics application.
Simply follow OAM Administration Guide Instructions.
Here’s my WebGate definition:
On registration, by default, you get an application domain and Authentication and Authorization policies automatically configured for the patterns / and /…/*. You don’t need those policies. Remove them and add the /analytics/…/* as a protected resource to the set of Authentication and Authorization policies.
And make sure you copy the generated ObAccessConfig.xml and cwallet.sso from the OAM’s $DOMAIN_HOME/output/<agent-name> to the WebGate’s instance config folder, which is typically located at OHS’ $ORACLE_HOME/instances/<instance-name>/config/OHS/ohs1/webgate/config.
<agent-name> is the name you gave to your WebGate when you registered it in the OAM Console.
Restart both OAM access server and the WebGate.
Checkpoint 2: At this point we should be able to have the WebGate intercepting calls to /analytics URL running in WebLogic and asking for credentials. Upon entering them, the user would be re-challenged by BI login screen.
Connect to the BI Administrator tool and select Manage –> Security.
Select User, right click on the panel’s right side, select New User… and type in the user name. For this exercise, I am calling it Impersonator. Make sure it is a member of the Administrators group.
Navigate to BI’s home web/bin folder and type:
> cryptotools credstore–add–infile <OracleBIData>/web/config/credentialstore.xml
You are prompted for some information. Make sure the Credential Alias is impersonation (literally). Username and password should obviously match those you just provided in the previous step. Encrypt the password and give it a passphrase.
instanceconfig.xml is also located at <OracleBIData>/web/config.
In my case, <OracleBIData> is C:\OracleBIData.
In order to allow BI Presentation Services connecting to BI Server using the Impersonator user, add the following snippet as a child of <ServerInstance> element:
<CredentialStore> <CredentialStorage type="file" path="C:\OracleBIData\web\config\credentialstore.xml" passphrase="welcome1"/> </CredentialStore>
Make sure to enter the passphrase you chose previously.
In order to allow BI Presentation Services consuming the end user identity authenticated by OAM, add the following as a child of <ServerInstance> element as well:
<Auth> <SSO enabled="true"> <ParamList> <Param name="IMPERSONATE" source="httpHeader" nameInSource="OAM_REMOTE_USER"/> </ParamList> </SSO> </Auth>
Here we’re instructing BI Presentation Services to use the OAM_REMOTE_USER http header value as the “impersonatee” user. OMA_REMOTE_USER is always put in the HTTP header by OAM upon successful authentication. BI will simply trust that. Dangerous? Oh yes.
Don NOT go to production without implementing a trusting mechanism between Weblogic and OHS. Weblogic should only accept requests from OHS. And the solutions to the rescue are 2-way SSL or some firewalling protecting Weblogic. Don’t let anyone sending requests directly to Weblogic!
Restart BI Server and BI Presentation Services processes.
Checkpoint 3: At this point SSO should work for /analytics. After getting challenged by OAM on accessing /analytics/saw.dll?Dashboard, you should be let in without any further authentication challenge by BI.
Notice that we still have two user repositories. OAM is looking at the Weblogic embedded LDAP server while BI is looking at its internal repository. That assumes the user is defined in both identity stores.
OBIEE 10g has the option of importing users and groups to its internal repository from external systems. That’s certainly an option, but it involves synchronization, which I am not a great fan of. Import and synchronization are available in the BI Administration tool.
If you seek a single identity store, keep reading.
This step assumes OID has been previously installed. In this exercise, OID version is the one packaged in Oracle Identity Management 188.8.131.52.0.
The application policy domain created when we registered our WebGate uses Weblogic embedded LDAP server as the identity store by default.
We need to change it, by pointing it to an external LDAP server. OID being the choice here.
This is done in OAM console. On the System Configuration tab, expand the Data Sources node and select User Identity Stores. Click the New button on the tool bar. Here’s my definition:
Then associate this identity store to the authentication scheme that is associated with the authentication policy protecting the /analytics/…/* pattern. This is done under Authentication Modules node on the System Configuration tab:
LDAP is the authentication module defined for the authentication scheme protecting our /analytics/…/* pattern.
Restart OAM server.
Using BI Administration tool, define the LDAP server. Go to Manage –> Security –> New… –> LDAP Server
Click the Advanced tab and inform uid as the User name attribute type. uid is the attribute that univocally identifies the user in OID.
Defining a USER session variable tells BI Server to authenticate users in an external repository. But in case of conflicting usernames, users defined in the BI repository takes precedence.
Using the BI Administration tool, go to Manage –> Variables. On the left side panel, under Session, select System. Right click on the right side and pick New USER…
Initialization blocks are the means by which external repository data is communicated to BI server.
Again, using BI Administration tool, go to Manage –> Variables. Click Session. Right click on the right side and pick New Initialization Block… Give it a name, like Authentication Block.
Under Data Source, click Edit Data Source… button, pick LDAP as the type, click Browse button and pick the LDAP server you’ve defined previously.
Under Variable Target, pick the USER variable you’ve created. Inform uid as the LDAP Variable value.
You should end up with something like this:
Restart BI Server.
Checkpoint 4: at this point, you should be able to login with a user defined in OID and access the BI analytics application in SSO mode, but you’ll notice that the privileges within BI analytics look wrong.
Unfortunately, OBIEE 10g does not retrieve group memberships directly from LDAP. But it is possible to implement it indirectly, by creating a virtual table in the Oracle database populated with LDAP user/group information (that can be done with DBMS_LDAP package).
Another option would be writing a SQL query directly against OID tables, but that’s too invasive and could break at any time due to changes in the OID schema, which is private.
Once you populate a table using DBMS_LDAP package, you can query it via a second Initialization Block and retrieve the group names for a given user, populating the GROUP session variable. This block should refer the Authentication initialization block we’ve defined earlier as a predecessor so that the USER variable is properly initialized with the authenticated user.
I am not done with this part yet. As time permits, I will come back with the virtual table definition as well as the initialization block.
But I guess there's already plenty to do in case you want to try this out. Let me know about your experiences.
Refer to product documentation.
OBIEE 10g Documentation Library (Deployment Guide has most of the information presented here).