Assume that we have two applications A and 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.
Have a look at this:
Let me know if you have futther questions
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:
3. There is nothing as “update” cookie.
HTTP spec only allows “Set-Cookie” option which means create cookie
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?
Ok so that was incorrect. Corrected as :
I need to cross check that, but I think its last access time from webserver/webagent access perspective .
Thanks for your response again. I will mark your initial response as 'Correct' answer after your confirmation regarding ATTR_LASTSESSIONTIME.
np, I will confirm tomorrow after checking
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
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?
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.
Sorry, I didn't notice this response.
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.
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,
SMSESSION cookie has expired and will not be used to authenticate.
Unable to process SMSESSION cookie
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
Yep looks right