15 Steps to migrate 10g SSO to 11g SSO

OBIEE 10g SSO Integration with OAM 11g


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 deployment guide states that it can be implemented with any SSO solution that uses cookies, http header variables or JavaEE container server variables. That’s true indeed, and most of the configuration is actually performed on the OBIEE side.

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.

And what you’re about to follow has been implemented in a Windows XP box for demonstration purposes.
The exact product versions used were:
Oracle Business Intelligence Enterprise Edition 10.1.3.4.1
Oracle Identity and Access Management 11.1.1.3.0
Oracle Access Manager WebGates 11.1.1.3.0
Oracle Identity Management 11.1.1.3.0
Oracle WebTier Utilities 11.1.1.2.0
Oracle Weblogic Server 10.3.4
Oracle Containers For Java (OC4J) 10.1.3.5.0

Fasten your seat belts! Here we go....
1 - Install OBIEE 10g

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.

2 - Deploy the analytics.war application in WebLogic
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.


3 - Install Oracle HTTP Server (OHS)

OHS front-ends Weblogic server. A mod weblogic routing rule will forward requests to the analytics application running in Weblogic.


4 - Create routing rule in OHS mod weblogic for /analytics URL

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:

1:
 2: WebLogicHost
 3: WebLogicPort
4: Debug ON
5: WLLogFile /tmp/weblogic.log
 6:
 7: 8:
9: SetHandler weblogic-handler
10:
Make sure to replace the values in between
The OHS instance home config folder is typically located at $ORACLE_HOME/instances//config/OHS/ohs1
Restart OHS.

Checkpoint 1: at this point we should be able to submit requests to OHS and have them directed to Weblogic.

5 - Install OAM 11g

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.

6 - Install OAM 11g WebGate in OHS
The WebGate checks whether the executing user is authenticated before letting it access the analytics application.

7 – Register the WebGate in OAM Console



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/ to the WebGate’s instance config folder, which is typically located at OHS’ $ORACLE_HOME/instances//config/OHS/ohs1/webgate/config.
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.

8 - Create Impersonator user for the BI Server
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.

9 - Add Impersonator user to BI Presentation Services credential store (credentialstore.xml)
Navigate to BI’s home web/bin folder and type:

> cryptotools credstore–add–infile /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.

10 - Configure instanceconfig.xml
instanceconfig.xml is also located at /web/config.
In my case, 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 element:


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 element as well:





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.

11 - Define a new OID identity store in OAM

This step assumes OID has been previously installed. In this exercise, OID version is the one packaged in Oracle Identity Management 11.1.1.3.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.

12 - Create an LDAP server in BI Server (the same OID identity store above)
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.

13 - Create a USER session variable in BI Server.

* 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…

14 - Create an LDAP Initialization Block for authenticating users in OID.
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.

15 – Implementing authorizations for BI using groups defined in an external LDAP server.

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.

References:-

OBIEE 10g Documentation Library

OAM 11g Administration Guide

Thank You,