Symantec Access Management

Our web app users occasionally get redirected to out SiteMinder cookie provider. There is no discernible pattern at this point as to why they are being redirected. We see the error message "Unable to decode SMSESSION cookie" in the web agent trace log. I have attached an anonymized snippet of the log with this error message. This is a particular issue for our application, which is a single page JS app, since most traffic is XMLHttpRequest traffic and we get a CORS error when the redirection happens because the cookie provider is in a different domain than our application. To get around the CORS issue, we rely on the initial HTTP GET request that loads the app to go through the process of obtaining a cookie and all XMLHttpRquests subsequent to that initial request should have a valid SMSESSION, however, users occasionally get redirected before the session should have expired and we are trying to determine the cause. We are also looking for ways to allow the XMLHttpRequests to obtain a new SMSESSION without encountering a CORS error. One though is to proxy to the cookie provider though our Apache agents. Wondering if this is a practical approach?

If I understand this correctly, I see two questions here :

1. Why cookie provider agent is unable to decode the SMSESSION cookie ?

This could happen if the Agent keys used by cookie provider and the target agents are different.

For this I will look at clearing the duplicate agent keys (if any).

Knowledge Base Articles 

2. How to avoid cookie provider redirection for Ajax request (XMLHttpRequest).

For this you can refer to following discussion thread where I have provided couple of soluiton :

Skip CookieProvider redirect based on XMLHttpRequest 

Regards,

Ujwol Shrestha

Regarding the possibility that there is an issue with the agent keys, I think our symptoms argue against this being the case with our agent keys since the failure to decode the SMSESSION cookie happens on a small fraction of our total requests. I'm guessing less than 1%. Please let me know if my analysis seems wrong.

Regarding the second suggestion to exclude requests from cookie provider redirection, how does this approach allow reestablishment of a session that has failed due to the inability to decode the SMSESSION cookie? Does using a setting like the ones discussed in the link you supplied (e.g. OverlookSessionForMethodsUri) essentially exclude that URL from protection by Siteminder. If so, that does not seem tenable for our use case. If this approach does not exclude the URL from protection, how does this prevent the error decoding the SMSESSION?

1. It is worth checking for duplicates agent keys by doing smkeyexport just to rule this out.

Are you using FCCCompatmode = yes ACO ? There was another known issue with that setting and Cookiprovider failing to decode cookie.

2. No, these setting doesn't prevent SM protection it just prevents redirection to Cookie Provider.

If the URLs that have been prevented from redirecting to the Cookie Provider are still protected, what happens when a request is made to that URL with a SMSESSION cookie that cannot be decoded (i.e. an invalid cookie)? Is the request just denied? If so, the effect would seem to be the same for our application. We can't proceed without API support and with all APIs blocked we have to reload.

This will need a bit more looking at logs.

Please open support case for further troubleshooting.

Cheers,

Ujwol