"Your session has timed out. Please log in again." immediately after login if xpack.security.session.idleTimeout is set to (for example) 180d

[archon810]

Kibana version:
7.6.2-1

Elasticsearch version:
7.6.2-1

Server OS version:
OpenSUSE 15.1

Browser version:
Chrome stable 81

Browser OS version:
Windows 10 64

Original install method (e.g. download page, yum, from source, etc.):
zypper

Describe the bug:
I set up a 4-cluster ES today. It's working well.

Then, I installed Kibana and pointed it to the cluster. When I log into Kibana, it goes through, reaches the dashboard where it offers to import sample data, then immediately redirects to http://:5601/login?msg=SESSION_EXPIRED&next=%2Fapp%2Fkibana%23%2Fhome&provider=basic with this message: "Your session has timed out. Please log in again."

It took me hours of tinkering to figure out that if xpack.security.session.idleTimeout is not specified or is "1Y", then everything works. But I set this value to "180d" at the beginning, and it kept logging me out.

Is there a bug here? Why would "180d" idleTimeout log me out immediately, but "1Y" work?

Steps to reproduce:

1. xpack.security.session.idleTimeout: "180d"
2. Log in.

Expected behavior:
I'm not logged out.

Screenshots (if relevant):

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[azasypkin]

Hey @archon810,

How many Kibana instances do you have (e.g. if you use load balancer or something along these lines)? If more than one then you need to explicitly set xpack.security.encryptionKey to the same value for every Kibana node.

[jportner]

I'm a bit surprised, it never occurred to me that someone might want to use such a high value for an idle timeout. It's much more common to see something in the order of minutes or hours, not days.

I tested this and was able to reproduce the issue locally -- "180d" immediately results in a timeout, while "1Y" doesn't.

I did a bit of digging and I'm pretty sure our problem is in the client-side portion of the timeouts:

kibana/x-pack/plugins/security/public/session/session_timeout.tsx

Lines 149 to 152 in e3442b1

	this.expirationTimer = window.setTimeout(
	() => this.sessionExpired.logout(),
	Math.max(timeout - GRACE_PERIOD_MS, 0)
	);

When you load the page, this module will call an API to get its current session expiration timestamp, and use setTimeout to ensure that the user's browser logs itself out if that expiration is reached. We also invalidate the session on the server side when this expiration is reached, but the client-side code is necessary to ensure that a Kibana screen doesn't stay up indefinitely (if, for instance, network connectivity is broken).

It appears that 180 days (15,552,000,000 ms) is too large for setTimeout to handle. Major browsers only support a 32-bit signed integer for setTimeout, which translates to a maximum of about 24 days. Anything larger than that will result in an overflow. Reference: setTimeout | MDN

180 days overflows to a negative number, which triggers the timeout immediately. It just happens that a value of 1 year overflows to a positive number, so you don't see the same result with that configuration.

---

With regards to the solution: I think the idle timeout as a security measure has diminished value if it doesn't work on the client side. So I believe the correct way to fix this is to validate the session timeout configuration and disallow values larger than 24 days. We'll have to deprecate this in Kibana 7.x and make a breaking change when 8.0 is released. In the meantime, we can add a band-aid on the client side to artificially limit the value that's passed in to setTimeout to a maximum of 2,147,483,647 ms.

Edit: by the same token, we should set minimum session timeout values. Currently, you can set the idleTimeout value to 1 ms, which will also immediately time out user sessions. Perhaps the minimum should be 1 minute; that's still extremely low and probably completely unrealistic, but at least it would allow users to log in and see the timeout toast message.

[legrego]

Hi @archon810, thanks for the bug report.

This appears to be a duplicate of #22374, so I'll close this in order to consolidate the discussion.