SAW-OBAW SSO integration with Siteminder


The basic idea of this thread is to show how Siebel Analytics Web i.e Oracle BI Analytics Web interact with with SSO products, such as Microsoft IIS’ Windows Authentication, and CA’s eTrust SiteMinder (previously Netegrity SiteMinder) .

Prerequisites
The SSO system must be able to provide one of the following:
1. An HTTP header containing the end-user’s username. In this case the header can be any valid HTTP header name.
2. One of the following server side options:
a. When using the SAW ISAPI plug-in on a Windows/IIS solution, populate IIS’ REMOTE_USER server variable end-user’s username. Note this is a server variable queried through the use of the ISAPI Extension API GetServerVariable.
b. When operating in a J2EE environment using the SAW servlet, SAW will make use of the javax.servlet.http.HttpServletRequest.getRemoteUser API. In this case the SSO solution must be integrate with the J2EE environment of choice and setup the framework such that this method returns the end-user’s username.

SAW will assume that any incoming requests have already been authenticated and will use its (SAW’s) credentials connection with the SAS (OBAS) on behalf of the end-user. User personalization and access controls such as data level security maintained in this environment. Certain steps are required on the SAS side to ensure that SAW can successfully use impersonation feature to create the connection to SAS on behalf of the authenticated end-user.

Configuration Steps

Select/create SAS user for impersonation
1. Create a special user for this purpose, say Impersonator and assign this user a password, say secret created in the SAS repository.
2. Make this user a member of the group Administrators.

Generate an obfuscated version of the impersonator’s password

1. Open a web browser and point it to the machine where SAW is installed and running (in non SSO mode).
2. Login as an administrative user and issue the following URL:http://server/analytics/saw.dll?encryptString&string=secret, where secret was the password assigned Impersonator.
3. This page will result in a string which will be required when configuring SAW for SSO. Save this in a conveniently location.
4. Note that this URL is only accessible by Analytics administrators and will result in an empty page for all other when generating this obfuscated string, ensure that HTTP server logging is disabled so that the password does logged by the HTTP server.

Configure SAW for SSO
1. Ensure SAW is not running on the machine where you wish to setup SSO.
2. You need to create several configuration settings. These are listed below:
o Auth/Impersonator: Should be set to analytics user who can impersonate others. In this case Impersonator
o Auth/I\mpersonatorPassword: Obfuscated password generated earlier.
o Auth/SSOEnabled: yes or y.
o Auth/SSOServerVariable: Set to REMOTE_USER if:
a. The SSO scheme will populate IIS’ REMOTE_USER HTTP server variable; or
b. The SAW deployment is using the J2EE servlet option to connect from the HTTP server. In this case, servlet will use the javax.servlet.http.HttpServletRequest.getRemoteUser method to determine login name.
c. If neither of the above options is being used, this setting should be removed.
o Auth/SSOClientHeader: Set to name of the HTTP header present in the request if SSO scheme populates/HTTP header. If an HTTP request header is not being used remove this setting.
o Auth/SSOStripWindowsDomain: If set to yes or y, SAW will look for a backslash (\) in the username and characters upto and including the backslash.
o RPC/PermittedClientList: A comma separated list of IP addresses. These will be the only hosts that are allowed directly to SAW server over SAW server’s TCP/IP listening port. In particular, the IP addresses of all Scheduler instances and HTTP plugins (ISAPI and/or Servlet) will need to be added here. If the scheduler or HTTP plugin located on the same machine as the SAW server, then 127.0.0.1 must be added to this list as well. This NOT control end-user browser IP addresses.
3. These settings must be placed in the instanceconfig.xml file in <WebConfig><ServerInstance>…</ServerInstance></WebConfig>.

Example Config Files

Using a server side authentication option

<?xml version=”1.0″?>
<WebConfig>
<ServerInstance>
<!– other settings … –>
<RPC>
<PermittedClientList>127.0.0.1, 192.168.1.100, 192.168.1.101, 192.168.1.102</PermittedClientList>
<!– other settings … –>
</RPC>
<!– other settings … –>
<Auth>
<Impersonator>Impersonator</Impersonator>
<ImpersonatorPassword>12hjsdf</ImpersonatorPassword>
<SSOEnabled>y</SSOEnabled>
<SSOServerVariable>REMOTE_USER</SSOServerVariable>
<SSOStripWindowsDomain>y</SSOStripWindowsDomain>
</Auth>
<!– other settings … –>
3 of 3
</ServerInstance>
</WebConfig>

Using an HTTP header

<?xml version=”1.0″?>
<WebConfig>
<ServerInstance>
<!– other settings … –>
<RPC>
<PermittedClientList>127.0.0.1, 192.168.1.100, 192.168.1.101, 192.168.1.102</PermittedClientList>
<!– other settings … –>
</RPC>
<!– other settings … –>
<Auth>
<Impersonator>Impersonator</Impersonator>
<ImpersonatorPassword>12hjsdf</ImpersonatorPassword>
<SSOEnabled>y</SSOEnabled>
<SSOClientHeader>FOO_SSO_SYSTEM_USERID</SSOClientHeader>
<SSOStripWindowsDomain>n</SSOStripWindowsDomain>
</Auth>
<!– other settings … –>
</ServerInstance>
</WebConfig>

Integration with SWE

o Symbolic URLs for CRM-Analytics integration are configured to support nQUser/nQPassword authentication out-Changes are required if you wish to use SSO authentication. Namely removal of nQUser and nQPassword from
o An IFRAME Symbolic URL should work in most SSO environments once the nQUser and nQPassword is removed URL arguments for the Symbolic URL. These arguments must be removed from every Symbolic URL that will access Analytics site using SSO authentication. Because the IFRAME Symbolic URL is processed by the user’s browser, end-user’s credentials should be passed automatically.
o An Inline Symbolic URL is not expected to work in an SSO environment. An Inline Symbolic URL is run by the Siebel and it does not attempt to impersonate an SSO user. Inlines may be converted to IFRAME however. You may Symbolic URL “dimensions” command to control the IFRAME dimensions on Siebel Home Pages.

So in brief ……

1) Siteminder agent should be installed in OBAW server so that it can handshake with Web server either IIS or OC4J .

2) When calling the analytics page SSO agent will lookup to LDAP server to perform the authentication and  pass  HTTP_<useridentificationvar> header variable from SSO policy server to BI server .

3) BI server authenticate it and  impersonation should be done on BI repository and user should be assigned into groups to perform authorisation and thus group specific report access is managed . 

4) Retrieval of user information like Display name and Email address can be performed against SSO Policy/LDAP server .

N.B : -Below depicts some useful info about how Siteminder works .

Siteminder SSO - SAW

The steps that a user would go through when attempting to access a protected resource or applications with a SiteMinder enabled system are as follows:

o User attempts to request access to a protected resource such as a web page or application.
o The request is received by a web server and intercepted by a SiteMinder Agent.  The Agent determines, via the Policy Server, whether or not the resource is protected.
o If resource is protected, and if the user is not know, the user is challenged to present authentication credentials, which are passed to the Policy Server for authentication.
o The Policy Server authenticates the user against a user store. The Policy Server evaluates whether the authenticated user is authorised to access the resource based on rules and policies contained in the Policy Store. 
o If authorisation is successful, the Web Agent grants access to resource.  Any information requested for application customisation (e.g. user details) is passed to the application.

SSO via RSA – Siebel Analytics – OBIEE


RSA is a third party agent which can be configured and integrated with Siebel Analytics aka OBIEE so that it act as a Single Sign On (SSO) interface and passed through the integrated security mechanism .

RSA Access Manager can be configured to protect Siebel Analytics URIs, thus providing web access management and web single sign on to Siebel users. When a user tries to access a protected Analytics application via a web browser, the RSA Access Manager Web Server Agent intercepts the request, and redirects the user to the Access Manager logon page. After the user has been authenticated, the web server plug-in writes the authenticated username to an HTTP Header variable. The Siebel Analytics Web (SAW) ISAPI plug-in is configured to trust this variable’s value and use it to create a session.
Before continue with this it has been assumed that RSA agent has been installed and configured RSA Access Manager with User ids for all existing Siebel users. If the products’ UIDs don’t match, the integration will not work.

So lets follow the steps :

Create an Analytics Server user for impersonation
Login to Admintool and Select Manage and then Security .Create new user who will be a member of group Administrators .In the example username is : Impersonator and Password is Secret .

RSA-SSO

RSA-SSO2

 Generating a Encrypted Password

Log into Siebel Analytics Web as an administrator, and issue the following URL: http://HostServer/analytics/saw.dll?encryptString&string=secret where secret is the password for the impersonator user created .

The encrypted password will be displayed in the browser. Copy the string and save it to a temporary file.

RSA-SSO3

Configure SAW
Shut Siebel Analytics Web down.
o Open %SiebelAnalyticsDataHOME%\Web\configinstanceconfig.xml and add the following entries inside the <WebConfig><ServerInstance> tag:
a) RPC/PermittedClientList – A comma separated list all of the client IP addresses that will be allowed to communicate directly with SAW
b) Auth/Impersonator – the user created for impersonation in step 1
c) Auth/ImpersonatorPassword – the encrypted password created in step 2
d) Auth/SSOEnabled – y to enable SSO and n to disable it
e) Auth/SSOServerVariable – the name of the HTTP header variable that will contain the Access Manager –authenticated username. REMOTE_USER, for example.
f) Auth/SSOStripWindowsDomain- y to strip out a \ and the preceding domain name from the username and n otherwise .

<?xml version=”1.0”?>
<WebConfig>
<ServerInstance>
<RPC>
<PermittedClientList>127.0.0.1</PermittedClientList>
</RPC>
<Auth>
<Impersonator>Impersonator</Impersonator>
<ImpersonatorPassword>040337e52e23e468d41aca107207e051106c </ImpersonatorPassword>
<SSOEnabled>y</SSOEnabled>
<SSOServerVariable>REMOTE_USER</SSOServerVariable>
<SSOStripWindowsDomain>N</SSOStripWindowsDomain>
</Auth>
</ServerInstance>
</WebConfig> 

End User Login

The user opens a browser and types in a protected Siebel resource (/Analytics in this case).
The user is redirected to the RSA Access Manager login page.(Note that the user should exist in both RSA manager and analytics environment) .

RSA-SSO4

Now the user details should be authenticated and verified against the RSA manager and once that has been passed user would be redirected automatically to the actual Siebel Analytics / OBIEE screen .

IIS and SAW in two Different Server – OBIEE


So far what we observed is that in typical environment we have both IIS and Siebel Analytics Web (SAW) in the same machine ,if we at all consider that SAS could be at different server .

We have had a typical requirement where we need to segregate both IIS and SAW into two different servers .Its not a big challenge but believe me the configuration to achieve this could not possible if you dont know how to tweak this across windows settings and possibly others using non-windows environment .

So lets assume I have two host : aphbit05 and aphbit06 .My IIS at aphbit05 and my SAS and SAW up and running at aphbit06 .

I have setup a virtual directory at aphbit05 IIS so that it will point to … \\aphbit06\web\app (please see the Virtual directory setup process put into my previous threads) .

Here it has been assumed that the web folder has been shared into network on host aphbit06 keeping in mind that the OS , Network and IIS permission allow the access .

I have had Siteminder in both servers so lets make sure that the Siteminder agent is turned off in both by tuning the parameter as per attached .

Siteminder Off

Change the Windows registry settings of  aphbit05 server as below :

[HKEY_LOCAL_MACHINE\SOFTWARE\Siebel Systems, Inc.\Siebel Analytics\Web\7.8\ISAPI]

“ServerConnectString”=”sawtcp://<IP of aphbit06>:9710″@=””

(Though the host name works but sometime I prefer to use the IP ) It looks like the below changes . Note that 9710 port is default for IIS to communicate with SAW.

Registry ISAPI change

 

Be careful about the below settings in instanceconfig.xml file at aphbit06 (if your have different skin across 2 servers and if you have SAW also at host aphbit05 but disabled )

<DefaultStyle> </DefaultStyle>
<DefaultSkin> </DefaultSkin>

Use below tag at instanceconfig.xml file to specify the local directory resource you are trying to access (considerin web/app/res is at C-drive)

<URL>
<ResourcePhysicalPath>c:\SiebelAnalytics\Web\App\Res</ResourcePhysicalPath>   
</URL>

Also ensure that the Windows user running the IIS and SAW server process has full permissions on this directory.Now lets restart the IIS at aphbit05 and SAS – SAW at aphbit06 .

Its seem that the blue moon Siebel Analytics login page appears while trying to access the URL .

http://aphbit05/analytics/saw.dll?dashboard 

So all Web server related request will be load balanced by aphbit05 while aphbit06 will be engaged to perform its analytical processing business .

N.B : The above configuration and settings works on Siebel Platform version 7.8.5 but not tested on latest OBIEE 10.1.3.4 release . Also how the process valid on non-windows OC4J env is not tested .