Symantec Access Management

Dear SiteMinder Experts,

We have a .aspx script to delete the cookies. We use IIS to host our web app.
When I track what is happening with Google Chrome Developer tools I can see clearly that the cookies

dissapear or are overwritten. However if I revisit my URL the SMSESSION Cookie gets magically repopulated with a cryptic session ID and I am back logged in as if I never logged out.

Does someone have an idea if SiteMinder would cache certain sessions?
When I clear my cache and start a new browser session I have to login as normal but that can't be a serious solution.

SiteMinder logs show that the correct logoff.aspx is executed and AuthLogout is done but after that...it is a mystery.
Could it be that the session does not terminate?

Many thanks for any clues.

Please provide a trace of the logoff and logon.

What authentication scheme are you using to protect the site?

Is the URL you are testing with protected or unprotected in the configuration?

When we login did we check (using a cookie editor) the following for SMSESSION Cookie ...

Cookie Name. (just to be sure we are not using SSOZoneName).

Cookie Domain.

Secure Flags

HTTPOnly Flags

Looking at the code, it simply is issuing a new Cookie called SMSESSION. This does not ensure 100% that the SMSESSION Cookie is being overwritten. Example, when you are logging in, if the WebAgent is setting a SMSESSION cookie for .abc.com and your code sets a SMSESSION=LOGGEDOFF cookie for .test.abc.com; well that is no good. Because now the browser has two SMSESSION Cookie, one for .abc.com with the gibberish string (Session) and one for .test.abc.com which the value as LOGGEDOFF. Also we could be playing with SecureCookies e.g. the cookie from your code seems to be unsecure, but Cookie that WebAgent is setting may be secure and thus secure cookie gets transmitted over https.

Thus one needs to investigate using a cookie editor and see what cookies are being set during login.

Additionally we should be using the LogOffURI feature in CA SSO Agent Configuration Object to logout the SMSESSION Cookie.

We'd really need to review your logout solution to see what fits best.

Hi Philip,

It looks like you are implementing your own customized log off logic.

Why not go with the OOTB logout configuration ?

Comprehensive Log Out - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

Configure Full Logoff

The full log-out feature uses a custom log-out page that you create with the following parameter:

LogOffUri

Enables the full log-out function by specifying the URI of a custom web page. This custom web page appears to users after they are successfully logged off. Configure this page so that it cannot be stored in a browser cache. Otherwise, a browser could possibly display a log-out page from its cache without logging the user off. If this situation happens, unauthorized users could possibly have an opportunity to assume control of a session.

Default: (all agents except the CA Single Sign-on Agent for SharePoint r12.0.3.0) No default

Limits: Multiple URI values permitted.Do not use a fully qualified URL.Use a relative URI.

Example:(all agents except the CA Single Sign-on Agent for SharePoint r12.0.3.0) /Web pages/logoff.html

Follow these steps:

1. Create a custom HTTP application that logs the user off. For example, add an Exit or Sign Off button that redirects the user to a URL you specify.

2. Set up the log-out page so it cannot be cached in web browsers. This setting increases security because the page is always served from the web server, and not the cache of the browser. For example, for HTML pages, you can add the following meta tags to the page:

   < META HTTP-EQUIV="Pragma" CONTENT="no-cache">
   < META HTTP-EQUIV="Expires" CONTENT="-1">

   Important! Some web browsers do not support meta tags. Use a cache-control HTTP header instead.
3. Configure the LogOffUri parameter with the following steps:
   1. Delete the pound sign (#), if necessary.
   2. Enter the URI of the custom HTTP file that will log the user off. Do not usea fully qualified URL.
      Example: /logoff.htm

The full log-out feature is configured.

If that still doesn't work , we will need to look at :

- HTTP Header trace (fiddler log Fiddler - Free Web Debugging Proxy - Telerik )

- web agent trace log

Regards,

Ujwol

Hello,

many thanks for the replies.

1. we do not use secure cookies (UseSecureCookies: no)

2. we protect everything from root onwards / also the logout.aspx but the destination after logout is not protected but a different site on our intranet

3. @Hubert Dennis, what do you propose we do with the cookie instead outdating cookie SMSESSION?
   Should I delete it?   

4. @Ujwol Thanks for the information about comprehensive logout but I dont get it
   We use Cognos 11 with SiteMinder. All I can do it give Cognos 11 a link to a IIS logout html/aspx page
   and on that page I do my cookie work.                        

Please get us a fiddler trace of the login, logoff and re-access flow (all included in the same trace). If we are to debug on the same approach, we need to see what cookies are being set & when. Since it is a fiddler trace and potentially of a customer ENV, I'd suggest raise a support case and upload the logs to the case. Share the support Case#.

There's a lot to take into account regarding SMSESSION cookie behavior - especially when using a custom logoff page.  Opening a support case would be best, in order for all of the needed details to be gathered and fully assessed.

Kirk