This action might not be possible to undo. Are you sure you want to continue?
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:
that BI Publisher is only certified to work with Oracle SSO. using Oracle SSO as an example: . and CA eTrust Siteminder v6. at present). The following diagram illustrates in a simplified manner how diversionary SSO works. (note.Oracle SSO 10g.0.0. IBM Tivoli v6.
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. During subsequent requests the Oracle Single Sign-On server uses the session cookie to determine whether or not the user is authenticated. ³mod_osso´. without further modification. but the request is redirected by ³mod_osso´ to the Oracle Single Sign-On server. . This module acts as a sole partner application as far as SSO is concerned. When the user responds with a valid user name and password. and confirms to the Oracle Single Sign-On server that the user is authenticated. preventing unauthorised servers from gaining access. The Oracle Single Sign-On server sends a sign-on page to the user. and then used by it to restrict the data to which the user has access. The impersonating user name and its password are defined in the BI Server repository. to the HTTP server that acts as a front-end to OBIEE. the Oracle Single Sign-On Server passes this information to the Oracle Internet Directory server. would present a security loophole. and The Oracle Single Sign-On server passes the user name to the BI Presentation Services via ³mod_osso´. To ensure that this is possible a user with administrative level privileges is used to impersonate the user who is logging on. and they are also stored in the configuration files read by the BI Presentation Services at start up. The Oracle Single Sign-On server places a session cookie in the user¶s browser cache.Diversionary SSO with Oracle Single Sign-On The starting point for SSO is the addition of a module. However. This method of authentication. The Oracle Internet Directory server validates the user name and password. The initial connection sequence is as follows: A user tries to access the BI Presentation Services. An additional complication arises because all requests must be authenticated by the BI Server. 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. The user name (together with any other information returned by the Oracle Internet Directory) is passed to the BI Server.
The only problem with this arrangement is that the user first has to sign-on to the OLTP application.Reflexive SSO Let¶s suppose you have an OLTP application and you¶d like to use OBIEE as a reporting backend. With an external configuration the BI Presentation Services can accept external parameters by means of cookies or URL parameters. and then when he clicks on the link. you add a link in some screen of the OLTP application to transfer the application user to an OBIEE dashboard. passed to stored procedures that are run against the same database as the OLTP application). based on the role allocated to the user by the OLTP application. The BI Server supports the concept of a connection script which. the BI Server will still need to authenticate the request it receives from the BI Presentation Services. Reflexive SSO is a way of eliminating this second sign-on. in which it doesn¶t send a logon screen to the user requesting logon details. which it passes to the end user¶s browser. So. in turn. in turn. allows these parameters to be passed back to the OLTP application (or. 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. The following diagram illustrates the circular flow. Authentication works on a ³round-robin´ basis in which the EBS generates signature data. and OBIEE. The BI Presentation Services can be configured to support an external logon. not into OBIEE ± so that from an end user perspective OBIEE appears to be fully integrated within the EBS application. the end user¶s browser passes this signature data to OBIEE. Now. and can assign the values of these parameters to session variables which are then passed on to the BI Server. passes it back to EBS: . he has to sign-on to OBIEE. more precisely. and it will need some means of restricting the data that the user has access to. 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).
When the end user clicks on a link corresponding to an OBIEE dashboard (step 2). This table is used to retain the state of the session.EBS . with the session identifier acting as the primary key. EBS: . An entry for the session is created in table ICX_SESSIONS.OBIEE Round Robin Authentication First the end user logs on to EBS in the usual manner (step 1).
authentication fails. and by looking up the session state in table ICX_SESSIONS. . obtains certain external data items that are to be used as proxies. if not. So EBS can verify that the parameters it has received correspond to parameters it has sent. 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. instead. The URL is used by the web browser to access the BI Presentation Services. The BI Server will use the values of these session variables to restrict the data it displays based on the user¶s EBS responsibilities. EBS can determine the EBS responsibilities of the user. which has been configured to support external authentication.ACF´ as parameters to the connection script. but. To this URL is added. The BI Presentation Services extracts the value of parameter ³acf´ from the URL and assigns it to session variable ³NQ_SESSION. The URL that is passed to the web browser contains the address of the relevant OBIEE dashboard. In the present case. OBIEE passes to EBS the values of session variables ³NQ_SESSION. In particular.ICX_SESSION_COOKIE´ and ³NQ_SESSION. Then the BI Presentation Services process assigns the value of the cookie ± the encrypted session identifier ± to OBIEE session variable "NQ_SESSION. OBIEE does not ask for a user name and password. However. Configuring the Profile Option Name Navigate to the EBS administration screen used for managing profile options: ³Home Page => System Administrator => Profile => System´. OBIEE also supports the concept of an ³Execute on Connect´ script: if this script succeeds the user is authenticated.ICX_SESSION_COOKIE´.ACF´. 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). The cookie that is sent to the web browser contains an encrypted version of the session identifier.Puts a cookie in the web browser¶s cache. With this mode of authentication. 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. ³acf´. by decrypting the session identifier. the proxy data items are the encrypted session identifier and the ³acf´ parameter value. an additional parameter. and Passes a specially constructed URL to the web browser. consisting of a ten digit number generated by EBS. The values of these session variables are passed to the BI Server process. 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 Presentation Services will have to be restarted for these changes to take effect.ICX_SESSION_COOKIE" source="cookie" nameInSource="<cookie name>"/> <Param name="NQ_SESSION. navigate to the BI Presentation Services logon screen: ³Start => All Programs => Oracle Business Intelligence => Presentation Services´. Open the EBS repository online: ³File => Open => Online´.com:9704 Configuring External Authentication Navigate to directory ³<OracleBIData Home>\web\config´ and use a standard text editor to edit file ³instanceconfig. Configuring the EBS Repository Start the Administration Tool: ³Start => All Programs => Oracle Business Intelligence => Administration´. After the ³DSN´ tag pair. add the following text: <Auth> <ExternalLogon enabled="true"> <ParamList> <Param name="NQ_SESSION. Then navigate to an OBIEE dashboard link within EBS. .myorg.dll?Dashboard then the base address would be http://myobiee. 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. For example. To determine the cookie name delete all existing cookies using the facility built into your web browser.xml´. The value of ³<cookie name>´ must match that of the cookie sent by EBS to the end user¶s web browser.To determine the base address.com:9704/analytics/saw.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. The portion of the web address in the browser¶s address bar up to and including the port number is the base address.myorg. using a cookie and a parameter named ³acf´ that is added to the URL used to access OBIEE. if the address bar showed: http://myobiee. and press ³Open´ when the pop-up window appears (³Administrator´ is a predefined repository user and it has no password).
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.Select ³Manage => Variables´ from the menu. under ³Variables´ and ³Repository´ in the left-hand pane. The Data Source Name should correspond to the EBS connection name found in file ³tnsnames. Edit the values of these variables by double-clicking on each in turn. Click on the ³Static´ node.ora´. Expand the node in the Physical layer (the pane on the right): . Variable ³Static_USER_ID´ represents the Oracle user name used to connect to EBS. The user name should be one that has sufficient privileges to see all the DBI data needed for the OBIEE reports and dashboards.
Physical Layer showing Connection Pools Bring up the ³EBS_Query_Pool´ and ³EBS_Authentication_Pool´ in turn by double clicking on the nodes: .
. and press ³OK´ when asked if you wish to check-in the changes.OBIEE . select ³File => Save´ from the menu. When all changes are complete.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.
As with diversionary SSO.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. . 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.
This identifier can then be passed around the loop (typically as the identifier of a session cookie). However. thereby authenticating the user. 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. . this information would allow any other network server to gain access to the same data by spoofing the URL.At first sight. using the identifier as part of the session initialization procedure. Then the BI Server can query the database. 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. which could then restrict access to data based on its value.