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

[sychan]

Our IdP sessions are currently set for a 10 minute inactivity timeout, and I have tested this aspect of the system thoroughly and it is unrelated to the issue. The SN session expires long after the IdP session, and we are interested in extending the SN session, not the IdP session.
The problem at hand is that ServiceNow is not honoring the call to request.getSession().setMaxInactiveInterval(). The logs indicate that during SAML2 authentication we set MaxInactiveInterval, but it then gets plowed over when a new session is created. Here are the relevant log entries:

Our code in the login handler examines the client IP address and performs a request.getSession().setMaxInactiveInterval() to 10 hours (to cover a full workday)

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

Something else in SN seems to say that it is destroying the session we modified

03/07/12 09:35:52 (095) 2D569FBA00AC2000545B40D65BDAC928 Session destroyed: 2D569FBA00AC2000545B40D65BDAC928, (not logged in), created Wed Mar 07 09:35:38 PST 2012

ServiceNow then sets an inactivity timeout based on the glide.ui.session_timeout property and totally wipes out the results of our call to request.getSession().setMaxInactiveInterval()

03/07/12 09:35:52 (095) 2D569FBA00AC2000545B40D65BDAC928 Inactivity time changed from 1800 seconds to 7200 seconds

We are definitely seeing the sessions timeout at the time that the final log message states, so something is clearly forcing down the session timeout value. The question I would like to have answered is How do we set an inactivity timeout in the SAML2 handler that propagates through properly through the rest of the loin process?

[john_andersen]

Ok, I gave the following a try on one of my local instances and it seems to work great.

Here are the steps:

1) Open the SAML2SingleSignon Installation Exit script
2) Browse to the "process" function
3) make the following change:

 process : function() {
    var saml_passed = true;

    ....

    //Add the following line right before the return statement
    request.getSession().setMaxInactiveInterval(30);
    return this.loginUser(nameId);
  },

Of course you could put any logic you want around the setMaxInactiveInterval call, but just make sure it gets called right before that final "return" statement.

[sychan]

John,
It turns out that we are doing pretty much exactly what you describe, and it executes, however the timeout is not being honored. Here is the code we have been running:

  process : function() {
    var saml_passed = true;

[snip]
    // pass these values to Logout script
    request.getSession().setAttribute("glide.saml2.session_index", sessionIndex);
    request.getSession().setAttribute("glide.saml2.session_id", nameId);

    var clientIP = gs.getSession().getClientIP().toString();
    gs.log("Here is where we would set the session duration for client IP " +
        clientIP);
    if ( clientIP.match(/^128\.55\./)) {
        gs.log("IP Address matches 128.55.* - setting 10 hour session duration");
        request.getSession().setMaxInactiveInterval(60 * 60 * 10);
    } else {
        gs.log("IP Address not in NERSC nets, default session duration");
    }
   
    return this.loginUser(nameId);

Have you verified that the timeout you set is being honored? We found that in testing, the the setMaxInactiveInterval() call was not being honored - as described in the previous message in this thread. Can you verify that your timeout is actually being set?

[john_andersen]

Yes, I set my timeout to 30 seconds. As soon as I logged in as that user, my timeout because 30 seconds. I did close all of my browser windows, etc to ensure there were no lingering sessions. After 30 seconds I traced it going back to my IdP and reauthenticating. I also killed my SAML session to verify that as well and after 30 seconds when I tried to access a link it redirected me to login with my IdP.

I noticed the termination of the original session and the creation of the new in the logs, just as you had described, but the new session received the timeout.

Good luck in you efforts.

[sychan]

Do you know if there is a maximum timeout value, beyond which it doesn't matter if you set it any higher?

Steve