Sometimes, autologin in a TCP Web HTML SSO service stops working.
The symptom is that it stays in the login phase for a long time until finally giving a timeout with no screen presented.
Launching the PAM client in debug may result in showing the login screen but no credentials being injected, so that the browser stays there waiting until finally timing out
CA PAM all supported versions
There may be many different root causes for the behaviour observed. In the present article we will be dealing with one of such possible reasons: An invalid redirectURL mapping from the Learn mode.
To determine if this is the case, please set the CA PAM Applet in debug by changing the Diagnostic Log Level for Applet to Debug in Configuration --> Diagnostics --> Log Levels ---> Applet Log Level (and start the CA PAM Client in debug if possible). Reproducing the problem after this, one may observe the following entries in the CA PAM Client log file, logs.log
2024-06-14 15:25:51 DEBUG - WebSSO check login URL: currentUrl = https://198.51.100.1/webui, expectedUrl = https://198.51.100.1/webui/SSO/login.asp, paramURL = https://198.51.100.1:443/webui, redirectUrl = https://198.51.100.1/webui/SSO/login.asp com.ca.xsuite.app.xbrowser.LogonManager.debug [Browser Thread: 569cbd52-edf7-4c1a-a7ec-0dae7cd5ec63]
In the debug message, the meaning of the different url parameters displayed is the following:
currentUrl: the web portal is navigating to this URL and loading the page content
paramURL: the login URL that is defined in the web portal service in the PAM UI
redirectUrl: the URL from the Learn mode that was used to mark the credential and submit fields
expectedUrl: this is set to the redirectUrl. If the redirectUrl is NULL, then this is set to paramURL
When the web portal is launched, it navigates to the login page. For some web portals, this URL may redirect to one or more pages or post back to itself.
The web portal tries to determine if the page navigation has reached the login page by comparing the currentUrl and expectedUrl. If they match, then the web portal will inject the credentials and submit the page. If they don't match, the auto login process will wait forever until the applet times out, giving rise to this issue
Rerun the learning mode for Web HTML SSO. This may set up the correct parameters and enable SSO login to proceed