User is suddenly unauthorized to see the current dashboard and returned to the dashboards list page

OpenSearch Dashboards
1

Versions
Opensearch/Opensearch-dashboards v2.13.0, OS: Oracle Linux Server release 8.5, multiple broswers

Describe the issue:
While working on any dashboards, after about 5 minutes the user gets redirected to the Dashboards list page (i.e. to https://myopensearch/app/dashboards). This happens as soon as the user interacts with the dashboard, typically when the “refresh” or “update” button of the time interval is hit, or when the browser is reloaded manually. As long as there is no interaction with the page though, no reload happens.

In reality the matter appears to happen on many (all) the apps of opensearch-dashboards, not just the dashboards component.
For example, if the user stays on the dashboards list page for 5 minutes, and then select one of the dashboards, the user gets redirected to the dashboards list page. It is then possible to select and access the desired dashboard.
Another case is the Reporting component: also there, if the user is navigating in one of the reports, after about 5 minutes any action lead to a redirection to app/reports-dashboards.

The normal info log doesn’t show anything that appears to be related to such redirection. I then set the root.loglevel to debug, but the amount of data is then massive, and I’m not sure whether there is anything relevant there.

I also enabled and checked the opensearch-dashboards log, and there I could observe the following unauthorized error being reported in the moment of the redirection:

statusCode":401,“req”:{“url”:“/api/saved_objects/_find?default_search_operator=AND&has_reference=%7B%22type%22%3A%22visualization%22%2C%22id%22%3A%2269fadd30-eb1d-11ec-b55e-315f31c8d686%22%7D&page=1&per_page=100&search_fields=title%5E3&search_fields=description&type=augment-vis”

…followed by the actual redirection to /app/dashboards

statusCode":302,“req”:{“url”:“/app/dashboards”…

This seems to indicate that the user is not authorized to access the current page anymore, and therefore returned to e.g. the list of dashboards (or basically to the home page of the specific component). The user can however access again the previous dashboard. So the authorization issue (if that is really the case) is only temporary.
The authentication is OIDC based. The user is not logged out though, just redirected to the parent component.

To give it a try, I have already tried to work with the following parameters:

opensearch_security.cookie.ttl = (set to some very big value)
opensearch_security.session.ttl = (set to some very big value)
opensearch_security.session.keepalive = true

…but it didn’t help.

Any suggestion would be very appreciated. It would be already very good to have some hint about which single component to be set to debug loglevel.

Thx!

configuration
OIDC authentication. Multitenancy disabled.

2

Hi @rockhard,

Do you have anything set as plugins.security.cache.ttl_minutes:?
Would you mind sharing your opensearch.yml and opensearch_dashboards.yml files (please blank any sensitive information)?

Thanks,
mj

3

Thank you for your reply @Mantas !

In the last days, having excluded everything else, I started to consider the access token lifetime of Keycloak. For the client that I set up there, there has been always a “never expires” in place, which was overriding the Realm defaults (5 minutes).
I then changed the access token lifetime of the client in Keycloak to i.e. some hours, I didn’t change anything in Opensearch, and the problem was not observable anymore.

I have never had the plugins.security.cache.ttl_minutes set, so I assume it was defaulting to 60 minutes. However I considered that maybe with 2.13, the default got erroneously set to 5 minutes.

So, today I tried to revert the access token lifetime to “never expires” and I set the plugins.security.cache.ttl_minutes to 0. I restarted the Opensearch (and dashboard) services and the problem didn’t show up (at least not after 30 minutes).

I then removed the plugins.security.cache.ttl_minutes again, restarted the services. At this point I went back to the initial state, where I was getting the issue, but still the problem didn’t show up.

Basically, after having changed and then reverted the access token lifetime of my client in Keycloak, I cannot reproduce anymore the issue.

I can only imagine that after the upgrade to 2.13, somehow the access toke ttl got stuck cached at 5 minutes. And after having switched to a different value, the cache got updated and now it is working as expected.

1 Like
4

@rockhard, Thanks for sharing your detailed summary, this is very helpful for the community!

Best,
mj