Session timeout

[Max Caines]

Hi

I have set up SAML authentication for Kibana and Elasticsearch, and set the cookie lifetime and session timeout to 36000000 msec (10 hours). However, what I'm finding is that after an hour of inactivity, my Kibana session stops working and I get two error messages:

Request timeout after 30000ms

Visualize: Request timeout after 30000ms

If I do a reload of that tab, I get the SAML logon page. I've checked the cookies in the browser, and I the Searchguard cookie is present and has the correct lifetime. 

At the time of the error, I get the following in kibana.log

{"type":"error","@timestamp":"2018-09-10T10:45:53+01:00","tags":["warning","process"],"pid":1349,"level":"error","error":{"message":"Unhandled

promise rejection (rejection id: 204): Error: Cannot provide statusCode or

message with boom

error","name":"UnhandledPromiseRejectionWarning","stack":"Error: Cannot

provide statusCode or message with boom error\n at Object.exports.assert

(/usr/share/kibana/plugins/searchguard/node_modules/hoek/lib/index.js:740:11)\n

at Object.exports.wrap

(/usr/share/kibana/plugins/searchguard/node_modules/boom/lib/index.js:96:10)\n

at Object.internals.create

(/usr/share/kibana/plugins/searchguard/node_modules/boom/lib/index.js:115:24)\n

at Object.exports.forbidden

(/usr/share/kibana/plugins/searchguard/node_modules/boom/lib/index.js:272:22)\n

at /usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:179:47\n

at next (native)\n at step

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:191)\n

at /usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:437\n

at /usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:99\n

at server.auth.test

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:160:17)\n

at transfer (/usr/share/kibana/node_modules/hapi/lib/auth.js:92:16)\n at

Function.wrapped (/usr/share/kibana/node_modules/hoek/lib/index.js:875:20)\n

at Function.internals.response

(/usr/share/kibana/node_modules/hapi/lib/reply.js:138:14)\n at reply

(/usr/share/kibana/node_modules/hapi/lib/reply.js:70:22)\n at

unauthenticated

(/usr/share/kibana/plugins/searchguard/node_modules/hapi-auth-cookie/lib/index.js:169:28)\n

at

/usr/share/kibana/plugins/searchguard/node_modules/hapi-auth-cookie/lib/index.js:142:32\n

at Object.<anonymous>

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:233:24)\n

at next (native)\n at step

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:191)\n

at /usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:437\n

at Object.<anonymous>

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:23:99)\n

at Object.validate [as validateFunc]

(/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:211:13)"},"message":"Unhandled

promise rejection (rejection id: 204): Error: Cannot provide statusCode or

message with boom error"}

Any idea what this might be?

* Search Guard and Elasticsearch version: ES 6.2.4, SearchGuard 6.2.4-23-14

* Installed and used enterprise modules, if any: SAML

* JVM version and operating system version: Ubuntu 14.04.3 LTS. Oracle Java 1.8.0_60-b27

* Search Guard configuration files: kibana.yml attached

* Elasticsearch log messages on debug level

* Other installed Elasticsearch or Kibana plugins, if any: x-pack

Regards

Max

[Jochen Kressin]

Hi Max,

thanks for reporting, we're looking into it. Seems like a timeout problem with Ajax-requests. I guess it's correlated with the JSON web token. 

When you say that you are getting redirected to the IdP login page, do you mean you have to re-authenticate?

[maxca...@gmail.com]

Hi Jochen

Well, to be exact what happens is that I click "reload" in the browser, and it takes me to the Kibana "defaultAppId" page. It was my assumption that because I'm using ADFS, and I'm logged into our Windows domain, ADFS was bypassing the logon page because my Kerberos ticket is still valid, and that if I didn't have that Kerberos ticket, I would get the ADFS logon page. But I've just tried using an "incognito" window in Chrome, and although that takes me to the ADFS logon page when I make the first access to Kibana, when I click "reload" after the timeouts, it also goes back to the defaultAppId page just the same as window with my domain credentials.

I've had a look at at bits of the code. I know that following SAML authentication, the plugin issues a JWT token which controls the session. Is it possible that the expiry time set in that is always 1 hour (the default)? It looks (in Saml.js) like that takes precedence over the expiry time in the config file.Just my speculation

Regards

Max

[maxca...@gmail.com]

Hi Jochen

It looks to me very likely that the problem is the JWT token that is issued by Elasticsearch following the SAML authentication. I set ES to DEBUG logging, and thus got the JWT token. I used an online converter to get the content of the token, and got this:

.{

 "jti": "7f38b3af-53ff-4d65-a2eb-9ef5b021a8f9",

 "iat": 1536745488,

 "exp": 1536749088

}

The "exp" date comes out as one hour after the "iat" date. As the "exp" date in the token takes precedence over the expiry date set in the session record (in AuthType.js), the session gets terminated after one hour, whatever session limit you set in Kibana. I guess the problem is that ES doesn't read the Kibana config file, so doesn't know that the limit there is longer. As far as I can see, the limit set in KIbana is only used if the JWT token doesn't contain an "exp" attribute

Regards

Max

On Monday, 10 September 2018 11:56:22 UTC+1, Max Caines wrote:

[Knut Lauer]

Hi Max,

the options from the Kibana config file are indeed not the right options to control the time of SAML sessions. The one hour of session validity you are observing is indeed the SearchGuard default.

You have two choices:

- Configure your IdP to include a SessionNotOnOrAfter attribute in the SAML responses. This attribute will be honored by SearchGuard. Note that not all IdP support setting this attribute.

- Modify your SAML configuration in sg_config.yml. Inside the saml.config section, you can use the attribute jwt.expiry to set the time after which the JWT token will get invalidated. Use as value now + <number_of_minutes> to invalidate after the given time.

It should look like that:

saml:
   ...
   http_authenticator:
      type: 'saml'
      challenge: true
      config:
        ...
        jwt:
          expiry: now + 120

Hope, this helps you out ...

- Knut

[Max Caines]

Hi Knut

That’s exactly what I was looking for! Thanks very much!

Max

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f93c0283-162d-4b60-b4a1-dbf218cb770f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.