c



c

  

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.

  c

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:
  cc  
c

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.
 Ä   c

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:

  
c   

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:
 
c
Ä Ä   

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.

    c  !" 

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.

   Ä  

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:

   !" # !" $ 

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:
c

     

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.
Ä   c

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.