Users get blank page using formfill to single sign on to Siebel

  • 7015916
  • 24-Nov-2014
  • 24-Nov-2014

Environment

NetIQ Access Manager 4.0
NetIQ Access Manager 4.0 Support Pack 1 applied
NetIQ Access Manager 4.0 Access Gateway Appliance or Service


Situation

Access Manager setup and working well. Users can single sign on (SSO) to protected applications behind Access Gateway proxy after successfully authenticating to the Identity (IDP) server. Administrator wanted to role out a new Siebel based application where users logged in via HTML form, and created a supporting formfill policy to do this. Users accessing this application would appear to SSO to Siebel using formfill but would then see a spinning logo for 30 seconds followed by a blank white page.

Fiddler traces confirmed that the data being POSTed by formfill matched that sent by the browser when logging in directly.

Resolution

Create custom rewriter policy to search and replace references to the internal Siebel application TCP port to the external Access Gateway published TCP port.

From the Fiddler trace, one could confirm that the browser successfully POSTed the Siebel credentials. After that, some supporting objects were retrieved and looks like all loaded fine from Siebel side but a 30 second gap was visible between the last two requests for Siebel objects. There are a lot of javascript (JS) files downloaded in between. More importantly, a scan of the HTTP payload being sent back to the browser indicated a possible rewriter issue.

One of the main requests is for "GET https://siebel.ag.vcpoc.local/ecommunications_enu/start.swe?SWECmd=Login&SWEPL=1&SRN=BBVmAqaNUMQngpcf6KLtuYpVbdyEHT0Tmht29FyL35wb&SWETS=1416513212395". The Fiddler trace shows the response coming back references the following URL:
 
src="http://siebel.ag.poc.local:7777/ecommunications_enu/start.swe?

Adding a char based rewriter profile that ..
 
search for  - src="http://siebel.ag.poc.local:7777/ecommunications_enu/start.swe
replace with - src="https://siebel.ag.poc.local/ecommunications_enu/start.swe

allowed the correct page to be rendered without any delays. The delays were caused by TCP connections trying to go to 7777 and eventually timing out.