The logout page does not seem to work, after the user logs out they can go back and still access their data.

Document ID : KB000051245
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

After logout, the user goes back to the protected webpage (via the browser history) and they can still access and change their data.

When the client chooses to end their session, they click on the "logout" link, the web agent when it processes that request from the client then deletes the SMSESSION cookie token containing the session identification.

In tracing with httpwatch, it could be seen that the logout.html page was cached in the users browser, and on the second logout attempt the logout.html page was being retrieved from the local user cache rather than from the webserver.
In that second attempt since no actual request was sent to the webserver/webagent no command was issued by the agent to delete the SMSESSION cookie.

Solution:

In this case the problem is caused by caching of the logout page.

A trace of the Problem

This configuration has a custom authentication scheme, that front-ends the real, in this case NTLM, authentication scheme.

http://sso.ca.com/ntlm/redirect.html?orignalTarget=http://portal.ca.com.

Using a trace tool, httpwatch in this instance, the login redirect sequence is as follows

  1. http://www.transpolar.com/protected/index.html

    Check for existence of SMSESSION cookie does not exist so redirects to SM auth scheme.

  2. http://www.transpolar.com/siteminderagent/login.fcc
  3. Show user login page.

  4. http://www.transpolar.com/siteminderagent/login.fcc (POST with UN/PW)
  5. (sets SMSESSION cookie)

  6. http://www.transpolar.com/protected/index.html
  7. Show user protected page.

  8. http://www.transpolar.com/unprotected/logout.html
  9. (deletes users SMSESSION cookie) and displays logout page.

  10. http://www.transpolar.com/protected/index.html

    Check for existence of SMSESSION cookie does not exist so redirects to SM auth scheme.

The problem we saw was that the page http://sso.ca.com/ntlm/redirect.html was cached. So the above worked the first time, but subsequent logons would go:

Using a trace tool, httpwatch in this instance, the login redirect sequence is as follows

  1. http://www.transpolar.com/protected/index.html
  2. Check for existence of SMSESSION cookie does not exist so redirects to SM auth scheme.

  3. http://www.transpolar.com/siteminderagent/login.fcc
  4. Show user login page.

  5. http://www.transpolar.com/siteminderagent/login.fcc (POST with UN/PW)
  6. (sets SMSESSION cookie)

  7. http://www.transpolar.com/protected/index.html

    Show user protected page.

  8. http://www.transpolar.com/unprotected/logout.html
  9. (deletes users SMSESSION cookie) and displays logout page.

  10. http://www.transpolar.com/protected/index.html

    Check for existence of SMSESSION cookie does not exist so redirects to SM auth scheme.

Since the portal page at this point does not see an SMSESSION cookie, it redirects you to the login page again and this puts the client into an endless loop.

Note: The above representation of the httpwatch trace will vary slightly, the http://sso.ca.com in this example is a slight simplification, due to another intermediate page involved in this particular custom setup.

This redirect.html page was being cached in the users browser, and subsequent re-login would use the locally cached version, redirecting the user back to the original protected page, whereas a fresh request of the redirect.html target from the webserver was needed to engage the webagent complete the SiteMinder NTLM logon and set a new SMSESSION variable.

Solution

The page : /ntlm/redirect.html needs to be set so that it is not cached by the users browser.

This is best done in the webserver, by setting:

Cache-Control:no-cache                                                    

Setting in the webserver is the best option, however if that is not under your control you can also set them as meta parameters within the page itself:

  <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">                         
  <META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">                               
                                                                              

(the pragma one is for older browsers).

Changing the cache settings for this page, note in the webserver to pragma:no-cache fixed the issue.