Environment
Novell Access Manager 3
Novell Access manager 3.0.4
Novell Access Manager 3.1
Novell Access Manager 3.1.1
Novell Access manager 3.0.4
Novell Access Manager 3.1
Novell Access Manager 3.1.1
Situation
- Novell Access Manager has been configured to protect a Siebel application server
- If a Novell Access Manager authenticated user session has been timed out a user might see garbled characters rendered by the browser client after re-authentication has been processed on the NIDP server
- The problem will only show up if the user tries to run a HTTP POST request to the Siebel application server exactly at the time the user session had been expired
Resolution
- Make use of the non redirected login function on the protected resource servicing the Siebel application server
- Update you Novell Access Manager system to service pack 2
This will provide a new option to configure an "Authentication Timeout" for each configured Authentication Contract (which can be assigned to a protected resource). Choose an Authentication Timeout value much bigger than the Siebel application timeout itself.
Additional Information
The user session timeout setting configured on the NIDP server is a global setting and therefore valid for any protected resources. With Novell Access manager 3.0.4 and 3.1.1 there is no direct communication between the LAG and the NIDP server about user activity. There are basically two timeout events (softtimeout / hardtimeout) on which the LAG will re-route a given user back to the NIDP server in order to update the NIDP session timer (on a soft timeout event) or require the user to re-authenticate (hard timeout event) by using HTTP 302 redirect messages.
The problem comes only come up if the browser runs a POST request at the time the session hard timeout process kicks in in order to re-validate the user session. As either thr 302 HTTP redirect nor the alternative Java Script Redirection (if the touchfile ".alwaysUseJSFor302") will store more than just the URI which the browser was requesting the browser client will run a "GET" instead of a "POST" (after successfully re-validating the session). All data which was included in the "POST" request will get lost. in order to avoid the loss the LAG will park the POST request until the client returns back. As soon as the client will return back (now running a GET request due to the 302 redirects) the parked POST request will get processed. Application like Ajax (as stated in the Novell Access manager admin guide) might not be able to handle this (application lost its context). Therefore the browser just renders the received data returned on the POST request which might end up looking like a page with garbled characters.
The problem comes only come up if the browser runs a POST request at the time the session hard timeout process kicks in in order to re-validate the user session. As either thr 302 HTTP redirect nor the alternative Java Script Redirection (if the touchfile ".alwaysUseJSFor302") will store more than just the URI which the browser was requesting the browser client will run a "GET" instead of a "POST" (after successfully re-validating the session). All data which was included in the "POST" request will get lost. in order to avoid the loss the LAG will park the POST request until the client returns back. As soon as the client will return back (now running a GET request due to the 302 redirects) the parked POST request will get processed. Application like Ajax (as stated in the Novell Access manager admin guide) might not be able to handle this (application lost its context). Therefore the browser just renders the received data returned on the POST request which might end up looking like a page with garbled characters.