In this entry I will explain how to set up Single Sign-On for OBIEE in IIS environment. For those unfamiliar with the terminology, I'll start with just a quick overview to explain what IIS and OC4J are:
OBI is by default deployed on OC4J (Oracle Containers for Java) web application server. What does it actually mean? It simply means that the core OBI application will run on OC4J platform. This application by default is called “analytics” and the default port for OC4J is 9704 (as in http://hostname:9704/analytics).
Apart from the default installation we have other deployment options. One of the most popular being the IIS deployment – using Microsoft’s Internet Information Services instead of OC4J. Again we will have application called analytics, but the default IIS port will be 80 (as in http://hostname:80/analytics or simply http://hostname/analytics as 80 is the default HTTP port).
It is worth mentioning that from the user's perspective there is virtually no difference – OBI will work and look the same on IIS as on OC4J.
The discussion on advantages and disadvantages of both solutions could easily be material for an additional post, but for now you may be interested in checking out an interesting discussion I started on the Oracle forum some time ago.
Summing it up quickly, it all really comes down to the client’s environment – if the environment is totally based on IIS and Active Directory authentication (Windows Native Authentication – using Windows login to seamlessly access other applications), IIS may be the best choice. This is due to the compatibility with other systems and the relative simplicity of SSO implementation, which I will explain in more detail below.
In order to run SSO on IIS, first we need OBIEE itself installed on IIS. There is an option with “Basic” installation type of OBI that indicates IIS.
One thing worth mentioning is that if you start from scratch and install OBI straight on IIS, you need to have IIS already installed on the machine hosting OBI Presentation Server. If you don’t, the installation wizard will simply not give you an option to use IIS (which may give you quite a headache).
Another option is to move an existing OBI installation on OC4J to IIS. A great blog entries from John Minkjan explains the process in good detail:
http://obiee101.blogspot.com/2008/11/obiee-presentation-server-on-iis.html
As soon as OBI is working on IIS, you’ll need OBI Presentation Services configured to work in the Single Sign-On environment. Good step-by-step guidelines can be found in the documentation (chapter 8 of the Deployment Guide). We’ll use the “Server Variable” method for IIS web application server. There are a number of steps to perform (creating Impersonator user, modifying credential store, modifying instanceconfig.xml file, etc.), but they should be quite straightforward when following the documentation.
You should also have your OBI authentication based on the existing Active Directory. That should be quite a natural choice for users’ authentication in IIS/AD dominated environment.
Now, the interesting part is how easy it is to actually enable the Single Sign-On when all the components are in place. We will only need to change the authentication method of our IIS instance hosting analytics application.
Edit properties of your “analytics” application (Virtual Folder in IIS)
Go to Directory Security tab and edit “Authentication and access control” section. Disable anonymous access and enable “Integrated Windows Authentication”.
And that should be it! Just access http://hostname/analytics and you should be automatically logged in.
It should look like this:
<Auth>
<SSO enabled="true">
<ParamList>
<Param name="IMPERSONATE" source="serverVariable" nameInSource="REMOTE_USER" stripWindowsDomain="true" />
</ParamList>
Also make sure you use serverVariable as a source for SSO authentication – that will indicate using the REMOTE_USER native IIS variable that is populated when a user logs in to a domain.
A common problem may be that the variable will come together with a domain name (i.e. MY_DOMAIN\MY_USER) – this can be overcome by using stripWindowsDomain="true" tag (as shown above).
The process described in this post is really straightforward,which may be considered quite an advantage when comparing it with Windows Native Authentication process for OC4J (or wider for Oracle AS).
We also gain an advantage here as “analytics” application comes with an IIS version by default (you have a choice of an IIS installation while installing OBI). That means “analytics” can be seamlessly run in an IIS environment and no complicated configuration process is needed.
In a future post I will explain how to configure other OBI applications (i.e. BI Publisher, MS Office plug-in) to work with Single Sign-On on IIS platform. In the meantime, feel free to leave comments and questions if you want to know more.
OBI is by default deployed on OC4J (Oracle Containers for Java) web application server. What does it actually mean? It simply means that the core OBI application will run on OC4J platform. This application by default is called “analytics” and the default port for OC4J is 9704 (as in http://hostname:9704/analytics).
Apart from the default installation we have other deployment options. One of the most popular being the IIS deployment – using Microsoft’s Internet Information Services instead of OC4J. Again we will have application called analytics, but the default IIS port will be 80 (as in http://hostname:80/analytics or simply http://hostname/analytics as 80 is the default HTTP port).
It is worth mentioning that from the user's perspective there is virtually no difference – OBI will work and look the same on IIS as on OC4J.
The discussion on advantages and disadvantages of both solutions could easily be material for an additional post, but for now you may be interested in checking out an interesting discussion I started on the Oracle forum some time ago.
Summing it up quickly, it all really comes down to the client’s environment – if the environment is totally based on IIS and Active Directory authentication (Windows Native Authentication – using Windows login to seamlessly access other applications), IIS may be the best choice. This is due to the compatibility with other systems and the relative simplicity of SSO implementation, which I will explain in more detail below.
In order to run SSO on IIS, first we need OBIEE itself installed on IIS. There is an option with “Basic” installation type of OBI that indicates IIS.
One thing worth mentioning is that if you start from scratch and install OBI straight on IIS, you need to have IIS already installed on the machine hosting OBI Presentation Server. If you don’t, the installation wizard will simply not give you an option to use IIS (which may give you quite a headache).
Another option is to move an existing OBI installation on OC4J to IIS. A great blog entries from John Minkjan explains the process in good detail:
http://obiee101.blogspot.com/2008/11/obiee-presentation-server-on-iis.html
As soon as OBI is working on IIS, you’ll need OBI Presentation Services configured to work in the Single Sign-On environment. Good step-by-step guidelines can be found in the documentation (chapter 8 of the Deployment Guide). We’ll use the “Server Variable” method for IIS web application server. There are a number of steps to perform (creating Impersonator user, modifying credential store, modifying instanceconfig.xml file, etc.), but they should be quite straightforward when following the documentation.
You should also have your OBI authentication based on the existing Active Directory. That should be quite a natural choice for users’ authentication in IIS/AD dominated environment.
Now, the interesting part is how easy it is to actually enable the Single Sign-On when all the components are in place. We will only need to change the authentication method of our IIS instance hosting analytics application.
Edit properties of your “analytics” application (Virtual Folder in IIS)
Go to Directory Security tab and edit “Authentication and access control” section. Disable anonymous access and enable “Integrated Windows Authentication”.
And that should be it! Just access http://hostname/analytics and you should be automatically logged in.
Troubleshooting Tips
Just make sure you have your instanceconfig.xml file configured correctly.It should look like this:
<Auth>
<SSO enabled="true">
<ParamList>
<Param name="IMPERSONATE" source="serverVariable" nameInSource="REMOTE_USER" stripWindowsDomain="true" />
</ParamList>
Also make sure you use serverVariable as a source for SSO authentication – that will indicate using the REMOTE_USER native IIS variable that is populated when a user logs in to a domain.
A common problem may be that the variable will come together with a domain name (i.e. MY_DOMAIN\MY_USER) – this can be overcome by using stripWindowsDomain="true" tag (as shown above).
The process described in this post is really straightforward,which may be considered quite an advantage when comparing it with Windows Native Authentication process for OC4J (or wider for Oracle AS).
We also gain an advantage here as “analytics” application comes with an IIS version by default (you have a choice of an IIS installation while installing OBI). That means “analytics” can be seamlessly run in an IIS environment and no complicated configuration process is needed.
In a future post I will explain how to configure other OBI applications (i.e. BI Publisher, MS Office plug-in) to work with Single Sign-On on IIS platform. In the meantime, feel free to leave comments and questions if you want to know more.
Posts
