OBIEE     Single     Sign-On

Introduction

 Most applications require a user to provide credentials by way of a user name and password, or perhaps by way of a smart card, in order to sign-on and gain access.  When applications multiply within an organization and when users frequently move from one application to another, then the process of providing credentials becomes tedious and time wasting.  And where the user has different passwords for different applications, help desk requests to reset forgotten passwords become all too common.  In this environment, the idea of single sign-on (SSO) – in which the user by signing-on to any one application gains access to all applications for which he is authorized – becomes attractive.

 SSO does, however, introduce its own challenges.  Firstly, there is the complexity of interfacing all applications to the SSO server.

 Secondly, there is the issue of resilience: if the single sign-on process fails then no one in the organization will have access to any application; so SSO installations need a backup, preferably at a remote location, so that they can fail-over gracefully.

 And, finally, SSO introduces a security risk: if someone can view a user signing-on in any context, then he will have complete access to all applications that that user is authorised to access; SSO represents a considerable security risk when it is deployed in a mobile environment, where anyone with a video-enabled mobile phone can casually video a user signing-on, and then reconstruct the password by playing back the footage, frame by frame.

As far as OBIEE is concerned there are two different solutions to implementing SSO:

  Diversionary, and

  Reflexive.

The diversionary solution makes use of a single sign-on server and a database, and it authenticates the user from scratch – it’s expensive to set up, but once it’s in place it can be made to serve any compliant application.  The reflexive solution relies on the fact that the user has already been authenticated by signing-on to one application, and it then uses that application’s credentials to sign-on to the OBIEE by way of a proxy – it costs very little to set up, but its scope is restricted to the application for which OBIEE is acting as a reporting back-end.

Diversionary SSO

 In principle, OBIEE will work with any SSO product that propagates the user name by means of the HTTP or HTTPS protocols.  It is certified to work with the following SSO software:

 

  Oracle SSO 10g,

  IBM Tivoli v6.0, and

  CA eTrust Siteminder v6.0.

 (note, that BI Publisher is only certified to work with Oracle SSO, at present).

 The following diagram illustrates in a simplified manner how diversionary SSO works, using Oracle SSO as an example:

Diversionary SSO with Oracle Single Sign-On  

The starting point for SSO is the addition of a module, “mod_osso”, to the HTTP server that acts as a front-end to OBIEE.  This module acts as a sole partner application as far as SSO is concerned.  The initial connection sequence is as follows:

    A user tries to access the BI Presentation Services, but the request is redirected by “mod_osso” to the Oracle Single Sign-On server;

    The Oracle Single Sign-On server sends a sign-on page to the user;

    When the user responds with a valid user name and password, the Oracle Single Sign-On Server passes this information to the Oracle Internet Directory server;

    The Oracle Internet Directory server validates the user name and password, and confirms to the Oracle Single Sign-On server that the user is authenticated;

    The Oracle Single Sign-On server places a session cookie in the user’s browser cache; and

    The Oracle Single Sign-On server passes the user name to the BI Presentation Services via “mod_osso”.

 During subsequent requests the Oracle Single Sign-On server uses the session cookie to determine whether or not the user is authenticated.

 The BI Presentation Services must be set up to work in “SSO mode” by making appropriate changes to its configuration file – the BI Presentation Services needs to be told how it will receive the name of the user who is signing-on.  An additional complication arises because all requests must be authenticated by the BI Server.  To ensure that this is possible a user with administrative level privileges is used to impersonate the user who is logging on.  The impersonating user name and its password are defined in the BI Server repository, and they are also stored in the configuration files read by the BI Presentation Services at start up.  The user name (together with any other information returned by the Oracle Internet Directory) is passed to the BI Server, and then used by it to restrict the data to which the user has access.

 This method of authentication, without further modification, would present a security loophole.  However, a firewall section added to the BI Presentation Services configuration file explicitly lists those servers that are allowed to communicate with the BI Presentation Services, preventing unauthorised servers from gaining access.

  Reflexive SSO

 Let’s suppose you have an OLTP application and you’d like to use OBIEE as a reporting back-end.  So, you add a link in some screen of the OLTP application to transfer the application user to an OBIEE dashboard.  The only problem with this arrangement is that the user first has to sign-on to the OLTP application, and then when he clicks on the link, he has to sign-on to OBIEE.

 Reflexive SSO is a way of eliminating this second sign-on.  The BI Presentation Services can be configured to support an external logon, in which it doesn’t send a logon screen to the user requesting logon details.  Now, the BI Server will still need to authenticate the request it receives from the BI Presentation Services, and it will need some means of restricting the data that the user has access to, based on the role allocated to the user by the OLTP application.

 With an external configuration the BI Presentation Services can accept external parameters by means of cookies or URL parameters, and can assign the values of these parameters to session variables which are then passed on to the BI Server.  The BI Server supports the concept of a connection script which, in turn, allows these parameters to be passed back to the OLTP application (or, more precisely, passed to stored procedures that are run against the same database as the OLTP application).  The following diagram illustrates the circular flow, in which parameter values are “reflected” back to the application that issues them:

How Single Sign-On Authentication Works

 OBIEE reports and dashboards can only be accessed from within the E-Business Suite (EBS).  The authentication mechanism used to validate OBIEE users has been designed to facilitate a single sign-on – the end user logs in once to EBS, not into OBIEE – so that from an end user perspective OBIEE appears to be fully integrated within the EBS application.

 Authentication works on a “round-robin” basis in which the EBS generates signature data, which it passes to the end user’s browser; the end user’s browser passes this signature data to OBIEE, and OBIEE, in turn, passes it back to EBS:

EBS - OBIEE Round Robin Authentication  

First the end user logs on to EBS in the usual manner (step 1).  An entry for the session is created in table ICX_SESSIONS, with the session identifier acting as the primary key.  This table is used to retain the state of the session.  

When the end user clicks on a link corresponding to an OBIEE dashboard (step 2), EBS:

    Puts a cookie in the web browser’s cache, and

  Passes a specially constructed URL to the web browser.

 The cookie that is sent to the web browser contains an encrypted version of the session identifier.  The URL that is passed to the web browser contains the address of the relevant OBIEE dashboard.  To this URL is added, an additional parameter, “acf”, consisting of a ten digit number generated by EBS.

 The URL is used by the web browser to access the BI Presentation Services, which has been configured to support external authentication.  With this mode of authentication, OBIEE does not ask for a user name and password, but, instead, obtains certain external data items that are to be used as proxies.  In the present case, the proxy data items are the encrypted session identifier and the “acf” parameter value.

 The the BI Presentation Services process retrieves the cookie from the web browser (in order for this to be possible both EBS and OBIEE must belong to the same network domain).  Then the BI Presentation Services process assigns the value of the cookie – the encrypted session identifier – to OBIEE session variable "NQ_SESSION.ICX_SESSION_COOKIE”.  The BI Presentation Services extracts the value of parameter “acf” from the URL and assigns it to session variable “NQ_SESSION.ACF”.

The values of these session variables are passed to the BI Server process.  The BI Server process connects to the DBI component of EBS using a shared logon which gives it full access to all the DBI data.  However, OBIEE also supports the concept of an “Execute on Connect” script: if this script succeeds the user is authenticated; if not, authentication fails.  OBIEE passes to EBS the values of session variables “NQ_SESSION.ICX_SESSION_COOKIE” and “NQ_SESSION.ACF” as parameters to the connection script.  So EBS can verify that the parameters it has received correspond to parameters it has sent.  In particular, by decrypting the session identifier, and by looking up the session state in table ICX_SESSIONS, EBS can determine the EBS responsibilities of the user.  This information can then be passed back to the BI Server as part of the session initialization process to establish values for additional session variables.  The BI Server will use the values of these session variables to restrict the data it displays based on the user’s EBS responsibilities.

  

Configuring the Profile Option Name

Navigate to the EBS administration screen used for managing profile options: “Home Page => System Administrator => Profile => System”.  Assign to profile option name “FND: Oracle Business Intelligence Suite EE Base URL” the base address used to communicate with the BI Answers and BI Dashboards components of OBIEE.

 

To determine the base address, navigate to the BI Presentation Services logon screen: “Start => All Programs => Oracle Business Intelligence => Presentation Services”.  The portion of the web address in the browser’s address bar up to and including the port number is the base address.  For example, if the address bar showed:  

  http://myobiee.myorg.com:9704/analytics/saw.dll?Dashboard

 then the base address would be  

  http://myobiee.myorg.com:9704  

  Configuring External Authentication

Navigate to directory “<OracleBIData Home>\web\config” and use a standard text editor to edit file “instanceconfig.xml”.  After the “DSN” tag pair, add the following text:

 <Auth>   <ExternalLogon enabled="true">      <ParamList>         <Param name="NQ_SESSION.ICX_SESSION_COOKIE"            source="cookie" nameInSource="<cookie name>"/>         <Param name="NQ_SESSION.ACF" source="url"            nameInSource="acf"/>      </ParamList>   </ExternalLogon></Auth>

 The element ‘ExternalLogon enabled="true"’ tells the BI Presentation Services process that authentication will take place via externally supplied information – in this case, using a cookie and a parameter named “acf” that is added to the URL used to access OBIEE.

 The value of “<cookie name>” must match that of the cookie sent by EBS to the end user’s web browser.  To determine the cookie name delete all existing cookies using the facility built into your web browser.  Then navigate to an OBIEE dashboard link within EBS.  Examine the cookie list using your web browser or the file system to determine the cookie name that has just been added to the cookie cache.  

The BI Presentation Services will have to be restarted for these changes to take effect.

  Configuring the EBS Repository

 Start the Administration Tool: “Start => All Programs => Oracle Business Intelligence => Administration”.  Open the EBS repository online: “File => Open => Online”, and press “Open” when the pop-up window appears (“Administrator” is a predefined repository user and it has no password).

 

Select “Manage => Variables” from the menu.  Click on the “Static” node, under “Variables” and “Repository” in the left-hand pane.  The screen display should be as follows:

EBS Data Source Name and User Name Variables  

Variable “Static_DSN_OLTP” represents the Data Source Name used to connect to EBS.  Variable “Static_USER_ID” represents the Oracle user name used to connect to EBS.  Edit the values of these variables by double-clicking on each in turn.  The Data Source Name should correspond to the EBS connection name found in file “tnsnames.ora”.  The user name should be one that has sufficient privileges to see all the DBI data needed for the OBIEE reports and dashboards.  

Expand the node in the Physical layer (the pane on the right):

Physical Layer showing Connection Pools

 

Bring up the “EBS_Query_Pool” and “EBS_Authentication_Pool” in turn by double clicking on the nodes:

OBIEE - EBS Connection Pool

 In the “General” tab for each connection pool change the value of the “Password” field to match that of the user name you assigned to variable “Static_USER_ID”.  Click “OK” to exit the editor.

 When all changes are complete, select “File => Save” from the menu, and press “OK” when asked if you wish to check-in the changes.

Reflexive SSO

 There are various ways in which you can use this mechanism to implement reflexive SSO.  The main considerations are (1) to utilize the existing role assignments of users that have been set up in the OLTP application; and (2) to provide some security mechanism to ensure that no application other than OBIEE can draw data from the database used by the OLTP application.

 As with diversionary SSO, impersonation can be used to allow the BI Server to validate an administrative level user from information stored in the BI Presentation Server configuration files.

 

At first sight, a simple solution to restricting data access would be to pass the user’s role as a parameter around the loop to the BI Server, which could then restrict access to data based on its value.  However, this information would allow any other network server to gain access to the same data by spoofing the URL.  A better approach is for the OLTP application to allocate a unique identifier in the form of a large number to the user and store it in the database used by the OLTP application.  This identifier can then be passed around the loop (typically as the identifier of a session cookie).  Then the BI Server can query the database, using the identifier as part of the session initialization procedure, thereby authenticating the user.