Everything Oracle

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:

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.

You’ll find details of how reflexive SSO is used with the E-Business Suite here.

Everything Oracle

Home

Everything Oracle