I have configured SSO for 3 applications, configuration as below
Installed web agent on Apache web server and configured reverse proxy on Apache.
I had created on page, logout/logoff.html, on apche web server and in each application logoff button I had given this logoff page url(http://fqdn/logout/logoff.html)
In ACO, logoffURI parameter is set as logout/logoff.html.
problem i am facing is:
after clicking logoff i am getting redirected to logoff page. but session is not getting terminated SMSESSION cookie still exists in browser.
I had added below code in html page for preventing cache. but, sometimes session getting terminating and sometimes not.
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, no-store, must-revalidate">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
Please help me to resolve this issue
Do you have:
Notice the / in the second. from what you've written that might be missing and i believe to be important.
Thanks Josh for your replay.
It's my mistake in earlier post actual logoffURI as below.
From my experience, the LogOffURI is not a complete solution. All LogOffURI does is set the SMSESSION to LOGGEDOFF.
With a tool like HTTPWatch, you can still see the value of SMSESSION last sent by the browser before the LOGGEDOFF value was pushed down to the browser.
To re-use this previous SMSESSION, just copy and paste it to a URL: http://yourapp.domain.com?SMSESSION=KR+yLnsypOoHelRY/wXtfbTbLhPxE8RHI6B8bR5fXYJguvuBLhzgHQmJEmd...
and you are in.
Agree to a certain degree, as any one having access to machine could replay OR man-in-middle could sniff the cookie value to inject / replay.
I believe this is true for any cookie based solution, wouldn't it? not just siteminder.
It also means the Cookies are not being transferred securely and the client machine where the browser is running is either Shared machine (helpdesk agents who work in shifts round the clock, which mandates logging off User Desktop Login) OR not adequately enforced by machine lockouts on idling.
Nevertheless believe this could be mitigated by using a Session Store. However there are downsides to using Session Store in terms of performance.
What Tool is being used to view the Cookie? The reason being we could be easily carried away by the representation of the tool of displaying SMSession Cookies from multiple domains.
Have you checked when you logged in how many SMSession Cookies were present in the Browser?
Also are you sure SMSession Cookie does not have a gibberish value (because even after logout SMSession would be still present in Browser with the value set to LOGGEDOFF).
I would also check if the logoff request is handled by a WebAgent on which the logoffuri parameter is configured in the ACO. I do see peers making the mistake of sending the logoff request to a different WebAgent on which the logoffuri is not configured (e.g. when we use Common Login Page Infrastructure).
Try capturing the HTTP Header trace and check if the SMSESSION cookie is set to the value LOGGEDOFF upon logout. If there are multiple SMSESSION cookies (associate with different cookie domain) in the session, the custom logout page should handle the comprehensive logout with hyperlink to the Logoff URI of each cookie domain in the SSO environment.
I am checking cookies in browser. I have configured only one domain, so there is no chance of multiple domains
Only one SMSESSION cookie present after logged in.
Problem is after clicking log out link, redirected to logoffURI page(http://fqdn/logout/logoff.html) . But SMSESSION value is not set to LOGGEDOFF, valid session still present in SMSESSION cookie.
If I refresh/reload the page (http://fqdn/logout/logoff.html) . Then SMSESSION cookie is set to LOGGEDOFF.
I suspect, it is issue with cache.
That is correct, http://FQDN/logout/logout.html needs to reach the Server. If it is served out from cache, then SMSession would not be logged out as the request never reached the server to allow WebAgent to process the request.
Here's a trick always make the URI look unique by appending gibberish query parameter e.g. http://FQDN/logout/logout.html?sdsdsd
A small piece of code to generate random gibberish values and append that to the logout.html - this would make the URI look unique to the Browser and it would generate a call to the Server instead of serving from Cache.
This definitely looks like to be the case of caching.
What browser are you testing with ? Based on my experience different browser behaves differently with those meta tags.
Can you try adding all the following meta tag and see if it works ?
<meta http-equiv="cache-control" content="max-age=0" /><meta http-equiv="cache-control" content="no-cache" /><meta http-equiv="expires" content="0" /><meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" /><meta http-equiv="pragma" content="no-cache" />
Reference : html - Using <meta> tags to turn off caching in all browsers? - Stack Overflow
If you would like to confirm that the issue is indeed due to caching then you can do so by running a fiddler and capturing
the browser trace. If the request is served by browser cache, the request will not reach the fiddler (which is actually a proxy)
and hence not recorded in the fiddler capture
Hubert, Thanks for the tip. I will try this method.
Ujwol, I tried this approach but there is inconsistency while testing. some times working fine some times not