Kibana user session switches to Kibana server

Hi,

we are using readonlyrest 1.16.33 on ES 6.5.4, with an LDAP backend, and have noticed an odd behavior where the user’s Kibana session suddenly switches to that of the Kibana server user, under certain conditions. For example:

  1. ldap user logs on to Kibana
  2. chooses the Monitoring tab on the left hand pane
  3. he then chooses a different role via the multi-tenancy drop-down at the top left; note that the chosen role has no access to the Monitoring tab - it is hidden
    4.the user’s Kibana session is then switched to the Kibana server session

We have since tried upgrading to 1.16.34 in the hope that would fix the issue. It did not.

How can we solve the issue?

Thanks!

Hi @Robert!

Now that you describe the issue in the details, I think I know what’s going on. What happens when after point 4, the user clicks on another app, like for example timelion?

Hi @sscarduzio,

after step 4, the user can access all the apps (timelion, monitoring etc) that the Kibana server user has access to.

Thanks,
Robert.

This is resolved for 6.6.x master branch. Would you like to test the pre release?

We see this issue on an install of 5.6.9. Is there an updated release for that please?

Working on this right now. The 6.6.x got the priority because it was much easier to fix there, and it’s newer. Previous versions need a bit more attention.

The pre-6.6.0 branch has this fixed too now! Will hand you a build soon, @atownsend.

Hi @sscarduzio,

can you please confirm, if there is a fix out for 6.5.4? Sounds like that is the case, just looking for a confirmation before we request and install the updated plugin.

Thanks,
Robert.

Yes it is, we’re releasing tonight a new version.

Hi @sscarduzio,

we have tested version 1.17.4_6.5.4, and are still seeing the problem.

Thanks,
Robert.

I tried to reproduce this again, with no success using ROR Enterprise 1.17.4 for Kibana 6.5.4.
I also opened the zip file to see if the fix was in place. and it is.

Is the test case above still valid or do you do now something different?

Hi @sscarduzio,

yes, the above test case is still valid. For example we have user1, which is an ldap user that is part of both administrators and developers groups, as below.

- username: user1
  groups: ["administrators", "developers"]
  ldap_authentication:
    name: ldapserver1
    cache_ttl_in_sec: 600
- name: administrators
  indices: ["default-index", ".monitoring*", ".kibana*", "ls-*", "mbeat-*"]
  kibana_access: admin
  kibana_index: ".kibana"
  groups: ["administrators"]
- name: developers
 indices: [".kibana_app_developers", "default-index", "ls-app-*"]
 kibana_access: rw
 kibana_hide_apps: ["readonlyrest_kbn", "timelion", "kibana:dev_tools", "monitoring", "apm", "infra:home", "infra:logs"]
 kibana_index: ".kibana_app_developers"
 groups: ["developers"]

Plugin version (ES/Kibana 6.5.4):

GET _cat/plugins
10.10.10.10 readonlyrest 1.17.4

To reproduce, we do the following:

  1. user1 logs on to Kibana, multi-tenancy defaults to the administrators role
  2. user1 then goes to the Monitoring tab (correct username is reflected at bottom right)
  3. user1 then chooses the developers role from the multi-tenancy drop-down (to which the role has no access to)
  4. at this point the session is switched to the user context of kibana server, which is reflected at the bottom left corner. The session remains this way until the user is logged off.

I did test all the other tabs, and it appears this only happens with the Monitoring tab. For all the other tabs that are hidden from the developers role, the user is just taken to the main Kibana landing page without the session being switched.

From the Kibana directory, can you run this?

$ grep version plugins/readonlyrest_kbn/package.json 

I tried your test case with no luck even outside the dev environemnt. I just downloaded Kibana 6.5.4 from the website, the 1.17.4 Enterprise plugin, login, I’m in role administrators, go to monitoring, change to developers and I’m redirected to Kibana home and all is normal.

Another way to check if the fix is not there for some reason:

cat plugins/readonlyrest_kbn/server/routes/lib/postAuth.js | tr ';' '\n'|grep monitoring

should contain

f((!g||!g.authHeaders)&&a.url.path.startsWith('/api/monitoring')

Interesting…Please see below:

grep version plugins/readonlyrest_kbn/package.json 
  "version": "1.17.4",
    "version": "6.5.4"

cat plugins/readonlyrest_kbn/server/routes/lib/postAuth.js | tr ‘;’ ‘\n’|grep monitoring
return n.redirect(f),n}}}try{if((!g||!g.authHeaders)&&a.url.path.startsWith(‘/api/monitoring’)){const j=c.config().get(‘elasticsearch.username’),k=c.config().get(‘elasticsearch.password’)

the code looks fine, the version too. I replicate your environment even closer now and still nothing. Would you mind if we get in a screen share?

Sorry for the delay, sure, we can set up a screen share. I’ll reach out via email.

Thanks,
Robert.

1 Like