CA SSO : Query regarding SMSESSION cookie

[Dhilip kumar Mari]

Hi,

 

Assume that we have two applications A and B.

• For both the applications, Protection Level is same and SessionGracePeriod is 30 seconds.
• But, the Idle Timeout of application A is 1 hour whereas the Idle Timeout of application B is 5 minutes.

 

• At 10:00 AM, we are logging into application A and SMSESSION cookie is getting generated.
• At 10:05 AM, we are logging into application B in the same browser, (we are not prompted for credentials and existing session has been used).
• We are not performing any activity till 10:15 AM.
• Now, if we refresh application B at 10.15 AM, it is not prompting for credentials, meaning session is not getting expired (due to Idle Timeout) for application B.

 

I presume it is because SMSESSION has been created with Application A and the value of ATTR_IDLESESSIONTIMEOUT in SMSESSION will be 1 hour. Please correct me if I am wrong.

 

1. Now, how to overcome this behavior? Do we have any parameter in ACO to control this?
2. Also, if the SMSESSION cookie will not be updated with Idle Timeout of Application B, why am I getting the "Generated SMSESSION cookie" in Webagent trace log while launching application B? Has cookie been re-generated using the same values?
3. First of all, on launching application B (after the SessionGracePeriod period), will webagent request the webserver to create a new SMSESSION cookie as I could see the Cookie Created time (in chrome browser) is getting updated? If yes, is there any specific reason for creating new cookie instead of updating the value of same/old cookie (in encrypted format)?

 

Thanks,

Dhilip

[Ujwol]

Have a look at this:

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/web-agent-configuration/session-protection/enforce-timeouts-across-multiple-realms

Let me know if you have futther questions

[Ujwol]

2. It means cookie has been recreated. Most of the originals value is retained. The cookie is recreated basically to update the last access time.

Full list of info contained in smsession cookie:

https://communities.ca.com/community/ca-security/ca-single-sign-on/blog/2016/08/16/tech-tip-ca-single-sign-on-what-information-is-stored-in-the-smsession-cookie

3. There is nothing as “update” cookie.

HTTP spec only allows “Set-Cookie” option which means create cookie

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

[Dhilip kumar Mari]

Hi Ujwol,

 

Thanks for your quick reply.  

 

Regarding the second point, I could see below lines in the shared article.

<<

ATTR_LASTSESSIONTIME. The time that the Policy Sever was last accessed within the session.

>>

 

So, I hope this attribute will be updated only if webagent makes call to Policy Server.

 

But, I could see "Generated SMSESSION cookie" line even for the following case.

Resource is protected from cache.

User '<user>' is authenticated from cache.

 

Am I missing something?

 

Thanks,

Dhilip

 

[Ujwol]

Ok so that was incorrect. Corrected as :

• ATTR_LASTSESSIONTIME. The time the current session was last accessed.

[Ujwol]

I need to cross check that, but I think its last access time from webserver/webagent access perspective .

[Dhilip kumar Mari]

Hi Ujwol,

 

Thanks for your response again. I will mark your initial response as 'Correct' answer after your confirmation regarding ATTR_LASTSESSIONTIME.

 

Regards,

Dhilip

[Ujwol]

np, I will confirm tomorrow after checking

[Dhilip kumar Mari]

Hi Ujwol,

 

Also, I am curious to know how enforce timeout across multiple realm has been implemented. Where the response of WebAgent-OnAuthAccept-Session-Max-Timeout will be stored?

 

I hope it will not be stored/stored only in

• SMSESSION cookie (as it will affect other realms).
• Session ticket (as webagent cannot decrypt this).

 

As a result, I thought it will be stored (on webagent side) in Agent User/Resource Cache. But, if I remove these caches (after establishing a session) and trying to login after the idle timeout, session is getting terminated (even before connecting to policy server). Do we have any additional parameters in SMSESSION cookie? Could you please explain in detail?

 

Thanks,

Dhilip

[Ujwol]

The session timeout information (both idle/max) for a particular realm & sessionID combination is stored in Web Agent SessionCache.

 

When navigating between multiple realm, the SMSESSION cookie will also be updated to reflect the time out applicable for that realm.

[Dhilip kumar Mari]

Thanks Ujwol,

 

Sorry, I didn't notice this response.

[Dhilip kumar Mari]

Hi Ujwol,

 

Thanks for your confirmation regarding ATTR_LASTSESSIONTIME. Did some analysis and I guess I figured out the answer for my previous query.

 

1) ATTR_IDLESESSIONTIMEOUT of SMSESSION cookie will always be updated with Idle timeout of the last accessed realm. There are two cases here.

• If there is no WebAgent-OnAuthAccept-Session-Idle-Timeout response,  Session timeout in Realm section will be used.
• If there is WebAgent-OnAuthAccept-Session-Idle-Timeout response, corresponding Idle Timeout value will be used.

 

2) Idle Timeout details of the realm will also be stored in webagent cache (not sure if Agent Resource Cache or Agent Session Cache will be used)

 

Now, whenever the user hit any URL,

 

• While creating a session ATTR_IDLESESSIONTIMEOUT of SMSESSION cookie will be checked, if the difference between ATTR_LASTSESSIONTIME and the current time is greater than ATTR_IDLESESSIONTIMEOUT, session will not be created and we will get following line in the logs.

      <<

      SMSESSION cookie has expired and will not be used to authenticate.

      Unable to process SMSESSION cookie

      >>

 

• In case, if the session is not expired, webagent will successfully decode the SMSESSION cookie. It will check if the resource is protected. After that while validating the session using the 'Session ID' in the corresponding zone, webagent will verify if idle timeout of this session(ATTR_LASTSESSIONTIME - current time) is greater than idle timeout of the corresponding realm (from the cache). If the session has already timed out, we will get following line in the logs.

      <<

      realm has timeeout, session expired. Check next valid session

      >>

 

Please confirm if my understanding is correct. I will definitely close this thread after your confirmation

 

Thanks,

Dhilip

[Ujwol]

Yep looks right