SAML2 session timeout settings overwritten

[sychan]

I am trying to customize the session timeouts per the description here:

http://wiki.service-now.com/index.php?title=Installation_Exits

The appropriate place seemed to be the Process handler in the SAML2 login script. I've added in the code to set the session timeout based on source IP address, and it all seems to run without issues. But the timeouts are not being honored. What I see in the logs is that the original session is being destroyed and a new one replaces it, and at that time another session timeout is applied (apparently from the glide.ui.session_timeout property).

03/07/12 09:35:52 (082) 2D569FBA00AC2000545B40D65BDAC928 *** Script: Here is where we would set the session duration for client IP 128.55.19.238
03/07/12 09:35:52 (085) 2D569FBA00AC2000545B40D65BDAC928 *** Script: IP Address matches 128.55.* - setting 10 hour session duration
03/07/12 09:35:52 (095) 2D569FBA00AC2000545B40D65BDAC928 Session destroyed: 2D569FBA00AC2000545B40D65BDAC928, (not logged in), created Wed Mar 07 09:35:38 PST 2012
03/07/12 09:35:52 (095) 2D569FBA00AC2000545B40D65BDAC928 Inactivity time changed from 1800 seconds to 7200 seconds

Is there a way to propagate the desired session timeout past this session recreation? I tried setting the glide.ui.session_timeout property from within the login script, but it doesn't seem to be honored.

Thanks,
Steve

[john_andersen]

I recommend you use the property you mentioned: glide.ui.session_timeout as explained here:
http://wiki.service-now.com/index.php?title=Modifying_Session_Timeout

After setting that value, you will likely have to clear the ServiceNow cache:
http://www.john-james-andersen.com/blog/service-now/flush-that-cache.html

[Ravish Shetty]

Hi John,

We have a property change to be made in production.

How long does it take for property change to reflect?

Is a manual cache flush necessary?

[sychan]

John,

Thanks for the suggestion. In fact, we implemented the glide.ui.session_timeout change months ago, so we're well aware of it.

The requirement is to have a programmatic session timeout that can be set based on details of the specific login session. The glide.ui.session_timeout is a fixed timeout for all users and is too simple. In fact, what is happening is that glide.ui.session_timeout overrides anything we set in the external login handler.

Is there more to the solution that you are recommending?

Steve

[john_andersen]

Sorry, I was confused by one line in your post that made me think you wanted a global timeout.

It sounds like you are using SAML 2.0 as well, is this correct.

If this is the case, can you verify that the IdP is not just reauthenticating you when the ServiceNow session times out for that user? You may want to do a fiddler/httpfox trace to verify. If your IdP session timeout is longer than your ServiceNow timeout, then when your SN session expires, the browser will redirect to the IdP. Since the IdP session is still valid, the browser is quickly just routed back to SN and a new user session is created. It often happens quickly and the user doesn't realize that this transaction took place.