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.
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.
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 followingURL: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.
2. Login as an administrative user and issue the followingURL: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>.
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>
<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>
<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.
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 .
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
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
Posts
