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

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

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.

 

Environment

Release:
Component: SMPLC

Cause

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.example.com/ntlm/redirect.html?orignalTarget=http://portal.example.com.

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

1. http://www.example.org/protected/index.html
   

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

2. http://www.example.org/siteminderagent/login.fcc

Show user login page.

1. http://www.example.org/siteminderagent/login.fcc (POST with UN/PW)

(sets SMSESSION cookie)

1. http://www.example.org/protected/index.html

Show user protected page.

1. http://www.example.org/unprotected/logout.html

(deletes users SMSESSION cookie) and displays logout page.

1. http://www.example.org/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.example.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.example.org/protected/index.html

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

1. http://www.example.org/siteminderagent/login.fcc

Show user login page.

1. http://www.example.org/siteminderagent/login.fcc (POST with UN/PW)

(sets SMSESSION cookie)

1. http://www.example.org/protected/index.html

   Show user protected page.

2. http://www.example.org/unprotected/logout.html

(deletes users SMSESSION cookie) and displays logout page.

1. http://www.example.org/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.example.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.

 

Resolution

 

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.