As I mentioned in the part one of this article Configuring OC4J Applications (i.e. BI Publisher) to work in Single Sign-On (SSO) Environment on IIS, we may need to use applications like BI Publisher on web application servers other than OC4J.
In this scenario we will see how to set up BI Publisher with Windows Native Authentication for Internet Information Services (IIS).
The way to make BI Publisher work in the SSO environment shown in this document is only one of the multiple possible solutions. Other deployment options (including for example SSO cookie or Oracle Application Server integration) can be implemented but considering your client infrustructure (i.e. IIS used all over) the Oracle Proxy integration may be the only choice.
Why Oracle Proxy?
The reason for implementing additional component is simple: BI publisher application (xmlpserver) will not run natively as an IIS application (for more information on that you can refer to the OBI 10.1.3.3.2 Release Notes document
In order to enable communication between analytics (IIS) and xmlpserver (OC4J) within IIS web application server, we will use the oracle_proxy plug-in.
Internal IIS communication is necessary because user credentials have to be passed across application. Using this approach, xmlpserver will still run on OC4J but will be accessible through IIS (and its 80 port instead of 9704)
The following components have to be in place before proceeding with implementation steps:
-> BI Publisher
-> OBIEE analytics application deployed on IIS Web Application Server AND on OC4J in parallel
-> SSO for analytics application enabled in IIS
-> BI Publisher/BI Presentation Services should be installed on the same physical server as IIS instance
Please note that in the scenario described in this article, OBI Server and OBI Presentation Server are on different physical servers. All considerations are anyway still valid if they are on the same server.
BI Publisher is installed along with OBIEE and integrated with it (i.e. available from OBI using 'More Products' -> 'BI Publisher' option). The need to use both IIS and OC4J is due to the fact that the application will work natively on OC4J, but will communicate with IIS for SSO purposes. On this subject, in this example authentication is based on user's Active Directory credentials - username/password of user's Windows login (Windows Native Authentication).
For further information regarding enablement of SSO for analytics in IIS, please refer to my previous article.
In this example, OBIEE has been installed as a default OC4J installation and then deployed also on IIS.
Now, let's desbribe the implementation steps.
There are two main tasks to perform:
-> Oracle Proxy Configuration
-> IIS Configuration
1. Oracle Proxy Configuration
a. Copy oracle_proxy.dll
The first step is to copy the tool to our environment.
Go to OBI Installation folder (the one that OBI was installed from – not installed to!) and localise oracle_proxy.dll file in Server\Oracle_Business_Intelligence\oc4jproxy\
b. Create proxy.conf and oproxy.log files
The following step is to create appropriate control files for our solution. Start with creating an empty file and save it as oproxy.log. After that, create a proxy.conf file with the following lines:
· # Server names that the proxy plug-in will recognize.
· # Hostname to use when communicating with a specific server.
· # Port to use when communicating with a specific server.
· # Description of URL(s) that will be redirected to this server.
Fig 1: Proxy.conf file example (easy to get lost here!)
Fig 2: What the oproxy folder should look like
c. Modify registry entries for Oracle Proxy to work
The third step is to modify our Windows registry.
Open a regedit session on you OBI machine as per Fig. 3 below:
Fig 3: Regedit in Windows
Now add a new Key in My Computer -> HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE registry
Call the new Key “IIS Proxy Adapter”
Fig. 4: New key in the Registry
Then add three new String Values in the key created and assign values as shown below
Fig. 5: New values for the new registry key
All done? Good! That is all on the proxy side.
Now it's time to configure IIS.
2. IIS Configuration
a. Create a Virtual Directory in IIS instance
First of all create a Virtual Directory in the IIS. This should run BI Publisher application and runs analytics application and navigate to the website that stores analytics Virtual Directory. When prompted, specify the path to the oproxy folder.
Also assign the Read/Run/Execute permisions for the new Virtual Directory as per following figure:
Fig. 6: Permissions for the new Virtual Directory
b. Configure a ISAPI Filter for IIS Website
The next step is to add an ISAPI filter as follows:
Right-click on the Website storing oproxy Virtual Directory then Properties -> ISAPI Filters -> Add and specify the name (oproxy) and the path to the oracle_proxy.dll file (e.g. E:\OracleBI\oproxy\oracle_proxy.dll)
Fig. 7: Creation of the ISAPI Filter
c. Configure a Web Service Extension in IIS
The final step is to configure a Web Service Extension.
NOTE: This step is not mentioned in any documentation, but trust us - it is necessary! In the IIS instance go to Web Service Extensions, then click on Add new Web Service Extension.
Fig. 8: Web Service Extension workspace
Now specify the extension name (oproxy) and the required files (E:\OracleBI\oproxy\oracle_proxy.dll). Make sure to check the “Set extention status to Allowed”
Now it’s time to test if all the steps were properly implemented.
Restart your IIS instante. After restarting make sure oproxy ISAPI Filter is running (green arrow pointing up). If it is not running, another IIS restart may be needed
Fig. 9: Checking the filter status
Try the following link and make sure the requested website opens: http://NQhost/xmlpserver/login.jsp (it should open a BI Publisher login website without redirecting to port 9704)
Fig. 10: BI Publisher login page
Now let’s test BI Publisher access from OBI environment as per following figure:
If all steps have been followed properly, the automated login process should provide access to BI Publisher by passing the login page as follows:
As stated earlier, this is one of the many possible ways to implement BI Publisher on IIS. We chose this one as it's industry-standard, widely used and proven. Also, the main principles of the process described above can be replicated for any OC4J native apps to be deployed on IIS - which definitely simplify a configurator's life in environments where IIS is the only web application platform and using OC4J directly is not an option.