Siteminder Users are getting logged out after IdleTimeOut eventhough they are active

[SatyendraSingh]

For a siteminder protected application in our infra, users are getting logged out after 1 hour even though they active.

MaxIdleTimeOut = 1hr

 

Has anybody faced this issue or any idea about it?

[Ashok kumar Muthu]

Hi Satyendra,

 

That should be the expected behavior with Max Idle Timeout setting. Please refer the below document link for further details. 

 

Realm Dialog Reference - CA Single Sign-On - 12.7 - CA Technologies Documentation 

 

• Maximum Timeout
  If enabled, determines the maximum amount of time a user session can be active before the Agent challenges the user to re-authenticate.

  Note: You can override this setting by using the WebAgent-OnAuthAccept-Session-Max-Timeout response attribute.

  This setting is enabled by default. To specify no maximum session length, clear the checkbox. The default maximum session length is two hours.

  • Hours
    Specifies the hours value for the maximum session length.

  • Minutes
    Specifies the minutes value for the maximum session length.
    To use this feature with the Basic authentication scheme, your Web Agent must be configured to Require Cookies.

• Idle Timeout
  If enabled, determines the amount of time that an authorized user session can remain inactive before the Agent terminates the session. If you are concerned about users leaving their workstations after accessing a protected resource, set the idle timeout to a shorter period of time. If the session times out, users must re-authenticate before accessing the resources in the realm.
  This setting is enabled by default. To specify no session idle timeout, clear the checkbox.The default session idle timeout is one hour.

  Note: The session actually expires within a certain maintenance time period after the specified idle timeout value. The extra time period is determined by the number of seconds specified in the following registry key:HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\SessionServer\MaintenancePeriod

  
  Default: 60 seconds.
  For example, if the you set the idle timeout at 10 minutes, and you use the default value of the MaintenancePeriod registry setting, the longest time period before a session will timeout due to inactivity is 11 minutes (specified timeout + maintenance period).
  To use this feature with the Basic authentication scheme, your Web Agent must be configured to Require Cookies.

  Note: Be aware of the following:

  • For persistent sessions, the Idle Timeout must be enabled and set to a value higher than that specified for the Validation Period.
  • You can override this global setting by using the WebAgent-OnAuthAccept-Session-Idle-Timeout response attribute. A value of zero indicates that the session will not end because of inactivity.
  • Hours
    Specifies the hours value for the idle timeout period.
  • Minutes
    Specifies the minutes value for the idle timeout period.

[SatyendraSingh]

Thanks Ashok for the reply.

However if a user is active then he shouldn't be logged out after idle timeout, isn't it?

[Ujwol]

Can you please share fiddler? We would need to check if the SMSESSION cookie is being updated everytime user refreshes/access new page.

 

Sent from my iPhone

[SatyendraSingh]

I will surely try to share it.

however, what exactly we should try looking into smsession cookie?

[Ujwol]

The cookie value needs to change everytime the page is refereshed or the user visits different page.

This is required to keep track of the "ATTR_LASTSESSIONTIME" which is embedded within the SMSESSION cookie.

This is needed to enforce idle/max time out related restrictions by web agent.

 

More on SMSESSION cookie : Tech Tip : CA Single Sign-On ::What information is stored in the SMSESSION Cookie 

[SatyendraSingh]

Ujwol, you were spot on.

value of smsession cookie is not changing and i checked in Session Cookie Management - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation to see if any ACO parameter is stopping the smsession cookie update, but that is not the case.

So, smsession is getting logged off despite being active

[Ujwol]

SessionGracePeriod 

Specifies the number of seconds the agent waits from the last accessed time of the received session cookie before it generates a new session cookie. Set the SessionGracePeriod to 0 to disable the setting. If the setting is disabled, the agent updates session cookies for every request instead of skipping updates.

Note: The specified session grace period must be at least half of the configured idle timeout. If the session grace period is less than half of the idle timeout, the agent generates a new session cookie according to the following formula: 

IdleTimeout - (SessionGracePeriod * 2)

For example, if your session grace period is 25 minutes and the idle timeout is 60 minutes, the agent regenerates a session cookie after 10 minutes (because 60-(25*2)=10).

Modify the Session Update Period

You can specify how often the Web Agent redirects a request to the Cookie Provider to set a new cookie using the SessionUpdatePeriod parameter.

This parameter specifies how often (in seconds) a Web Agent redirects a request to the Cookie Provider to set a new cookie. Refreshing the master cookie decreases the possibility that it will expire due to an idle time-out of the session. The default is 60 seconds.

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/web-agent-configuration/session-protection/session-grace-period-and-update-period-settings

Look into above two settings.

[SatyendraSingh]

thanks for quick response, I see SessionGracePeriod=30 and SessionUpdatePeriod=60 in our ACO.

Are both the SessionGracePeriod and SessionUpdatePeriod in seconds?

[Ujwol]

Yes they are in seconds. Can u check ur web agent trace logs if it says “Generated SMSESSION cookie”?

If it says that, it means web agent is creating cookie.

If it’s still doesn’t refresh on browser then the could be cached at webserver. What is your webserver? If IIS, try disabling Output ans User cache.

[Legacy User]

Hi Ujwol,

 

I am facing similar issue, any suggestions?... My configuration for Session in ACO is as below:

SessionGracePeriod	30
SessionUpdatePeriod	60

even the session is "Generated SMSESSION cookie." still the agent says "User 'cn=test4john,ou=people,ou=internet,o=teds' is not authorized by Policy Server.]" and the reason is as below from SMPS logs

 

AzReject xtvlap1138 [19/Dec/2018:08:28:06 -0800] "10.61.186.49 " "test4-web-tfs GET /myaccounts/w/js/app/views/statement_view.js" [0000000000000000000000008ed43d0a-39bf
-5c1a7196-90fa7700-6cc02c94d157] [4] Session has expired [] []

 

Although the idle timeout is 16 mins and max is 2 hrs and none of them has been exhausted, this happens just between 4-5 mins of inactivity

 

Thanks

Harsh

[punyashloka.swain]

Hi Ujwol,

 

SM SESSION cookie are generated as per logs and not reaching server.We are using IIS. Please suggest what are the options to resolve the issue as application times out after 30 mins even if user is active.

 

Thanks

[Ashok kumar Muthu]

It will be very difficult to troubleshoot these kind of issues on the communities without sufficient information. I would suggest to open a support ticket with necessary logs to investigate and troubleshoot it further.

[Naresh Garg]

I am also facing the same kind of issue. My IdleTimeout is 50 mins and MaxTimeout is 4 hours. User is still active after 52 mins. I can see below in my agent trace logs. 

[01/20/2019][07:12:24][4832][1276][CSmHttpPlugin.cpp:1622][CSmHttpPlugin::CreateSession][000000000000000000000000cc0c610a-12e0-5c4473b7-04fc-028718be][*10.87.233.11][][archer_ext_uat_agent][/rsaarcher/][GRC1483944][Generated SMSESSION cookie.]
[01/20/2019][07:40:19][4832][5832][CSmHttpPlugin.cpp:1622][CSmHttpPlugin::CreateSession][000000000000000000000000cc0c610a-12e0-5c447a43-16c8-01f70732][*10.87.233.11][][archer_ext_uat_agent][/RSAarcher/api/internal/sessiontimeout/GetSessionExpirationTime][GRC1483944][Generated SMSESSION cookie.]
[01/20/2019][08:04:34][4832][6800][CSmHttpPlugin.cpp:1622][CSmHttpPlugin::CreateSession][000000000000000000000000cc0c610a-12e0-5c447ff2-1a90-03ba4d06][*10.87.233.11][][archer_ext_uat_agent][/RSAarcher/foundation/WorkspaceDashboard.aspx][GRC1483944][Generated SMSESSION cookie.]

Policy server logs. 

AuthAccept dlgsasam2plcy01.r1-core.r1.aig.net [20/Jan/2019:07:12:23 -0600] "10.87.233.11 CN=grc1483944,ou=users,o=xxxx" "archer_ext_uat_agent GET /rsaarcher/" [idletime=3000;maxtime=14400;authlevel=5;] [0]  [] []

 

Please find attached fiddler trace as well. 

Attachment(s)

archer.saz.zip   2.05 MB 1 version