Kibana embeded

[sam3546 (Sam)]

I have a kibana instance embedded in an iframe for ease of use in an secondary application but everytime my users log in they get a popup saying "Unable to update the UI setting" "the server requires a client certificate".

The user can log in with their credentials (tied to an ldap realm) or with a pki but either method seems to give this popup. I have certificate authentication ssl.client_authentication: optional set to this for http and transport so the user should not have to provide a cert.

I do not get this message for native user accounts, only accounts authenticated via ldap, I also no longer get this message when in full screen on safari but does randomly come back again?

What am i missing?

[rashmi (kulkarni)]

cc @oleg might know more and will answer when he gets a chance.
Thanks
Rashmi

[sam3546 (Sam)]

I have since noticed in the console whenever loading the page i get

Failed to load resource: The server “localhost” requires a client certificate

For clarification i didn't mention in my first post on this issue incase it wasnt inferred, im testing locally running kibana and my ui on localhost different ports, so that's what the "localhost" is referring to.

[sam3546 (Sam)]

So i believe i've solved this, seems to be a combination of 2 things but based on permissions.

1. the default index needs to be set "defaultIndex":{"userValue":"index"} at api/kibana/settings but the role used by the users does not give them access. This can be solved by using a superuser to navigate to the dashboards page, its set and should not need to be done again unless kibana is redeployed.

2. Saved objects, the role didn't allow read on saved objects so would cause part of the error getting a 401 get/savedObjects in the dev console. Giving users "feature_saved_objects.read", "feature_savedObjectsManagement.read" solves this issue, they can view all saved objects but not delete or modify.

While i dont like giving the role more permissions in 7.8 which i'm using there is no way of preventing the user access to stack management anyway, even if they can't modify anything they still shouldn't have access. This is allowed in newer version but we will not be upgrading.

Seems to solve both issues, enjoy.