Our company using ROR for kibana multitenancy support,
first of all, am new to this ROR plugin but I tried to understand how they have implemented this.
First, they are loading the users in the drop-down based on the selected user they generating the jwt token in that token in claims (user: -userid-***, roles , writer) and the generated token is passed as (Deep linking with JWT) http://kibana:5601/login?jwt=&nextUrl=urlEncode()
based on the user and the selected index pattern indices are filtered and data is displayed.
But the issue we are facing now is when we are using two tabs in the same browser.
In tab one we are selecting user1 and the data is displayed for that user1
In tab two we are selecting user2 and the data is displayed for that user2
now again we came to tab one just changed the index for user1 but the results are showing for the user2 instead of user1. I don’t know what to do, please help.
Hi @Kaarthick,
I really didn’t understand the context (i.e. who’s they?) And the drop down you refer to is something custom “they” built around ROR or you refer to the ROR tenancy selector? Maybe a screenshot?
Anyway as far as I could understand about the tabs problem: if you are using the same browser, you are using the same cookie. And in the cookie we keep the session state. So even if you have two tabs open, for the server it’s always the same user agent and the server will receive the very same cookie. For example, when you logout in one tab, you logout in all the tabs.
Maybe can you describe better what behaviour are you looking for, and an example of another web app that behaves like this?
Thanks for the quick response.
They mean the people in our company who have implemented the ROR plugin with kibana. We are rendering the kibana discovery on our page with the iframe. We are not using the ROR tenancy selector instead of that we are loading our users in that drop-down, please refer to the screenshot which I have attached.
Based on the selected tenant or user the jwt token is generated and passed it with the kibana url as query param and results are displayed only for that selected user.
Let me try to explain to you clearly,
We are creating daily indices for the users and with different index prefix as index1,index2, etc. Eg: index1-userid(1)-2020-06-02, index2-1-2020-06-02, index1-2-2020-06-02, index2-2-2020-06-02.
And the index patterns which are created in kibana are index1-, index2-.
In a browser, two tabs are opened and loaded with kibana.
In tab 1, user1 is selected for that user1 with userid as 1 and the indices for this user in ES will look like index1-1-2020-06-02, index1-1-2020-06-01, etc.
In tab 2, user2 is selected for that user2 with userid as 2 and the indices for this user in ES will look like index1-2-2020-06-02, index1-2-2020-06-01, etc.
for these two users, we are setting the user and writer in jwt token as (user: “* * * *-1- * * ", user: " * * * -2- * * *”),
Now if I try to select the other index pattern in tab1 now it’s loading the user2 data in tab1, but in tab1 the selected user is user1.
Yes as you said, the cookie is a browser specific and value is stored in the cookie is the same for all the tabs in that browser.
I want to know whether the user value is stored in rorCookie in the cookie and I also need clarification whether ROR filters the indices if yes means then indices are filtered based on the combination of index pattern, user and selected time frame.
All ReadonlyREST Kibana plugins save an encrypted cookie in the browser, when the browser’s HTTP requests arrive to Kibana, our plugin decyphers the cookie, extracts a session ID, and looks it up in a server-side cache to retrieve the identity object where (among other things) username and ES credentials (in your case, the JWT token) are stored. Now our Kibana plugin attaches the JWT token to the Authorization header of the request, so when it’s forwarded to Elasticsearch, it can be authenticated.
Once the request reaches Elasticsearch, it’s authenticated and associated to a set of permissions (i.e. can read only index1-*) according to the matched ACL block.
So to answer your question in short: yes, the cookie is a temporary session token that is associated to a JWT token used to reach Elasticsearch on behalf of a single user.
I don’t know your ACL, you never shared it.
But index patterns are configuration objects that live in the “.kibana” index. It can be that in your ACL you have associated user1 and user2 to distinct kibana indices (i.e. at least one of the blocks that represents user1 or user2 has a “kibana_index” rule), then they won’t see the same index pattern.
