Closed elasticmachine closed 3 years ago
Original comment by @kobelb:
@azasypkin created a proof of concept for this, but it ended up being more complicated than he anticipated. The need to hide additional UI elements in this scenario, for example because the user is unable to log-out, and the interaction with the other authorization providers became problematic and need to be addressed when we look into implementing this again.
I think this is a much needed feature 👍 !
A workaround that thanks to @thomasneirynck and @tsullivan I was able to put in place, will not work for all cases: https://discuss.elastic.co/t/auto-authenticating-to-iframe-embedded-kibana-dashboard/46091
In my case, our organization's visualizations would be part of a public site, conveying information freely. I cannot expect users to enter credentials 5 times for 5 sample visualizations or even once, for a single dashboard. This is popular feature among many other visualization platforms (tableau, powerbi, google studio, qlik and more). Please provide us with an assessment of what it would take to implement this feature, I am more than happy to contribute in any way possible!
Thank you in advance, George
We need this, too.
Use case: The Refugee Datathon Munich Dashboard, running on elastic cloud. https://refugee-datathon-muc.org/english-pages/welcome-to-our-dashboard/. We definitely need our data protected. Our dashboard is on the web.
We prepared a read only role + user for our web visitors, but we have to provide them with a username and a password, and they still have to log in. Web visitors don't like that much, and this means much less usage of our beautiful dashboard. It's possible to give username and password in the browser link to the dashboard, but then their browser will warn them that there's something fishy going on, and it feels even weirder.
We need something similar, we'd like to be able to embed a dashboard without a login page. We have seen the workarounds using a proxy but are after a solution like '?embed=true&anonymous=true' in the iframe src url. The embedded dashboard does not need any UI elements hidden as it only contains visualisations we've selected and is read-only.
We looked at the new Kibana Spaces hoping for a solution but were unable to have an anonymous Space.
An example use case is visible at https://www.communityinformationexchange.com.au/.
Update: We got around this with a simple ASP.Net Core Proxy project available at https://github.com/aspnet/AspLabs/tree/master/src/Proxy (not ours)
We used the sample project with the following changes to the Startup.cs:
public void ConfigureServices(IServiceCollection services)
{
services.AddProxy(options =>
{
options.PrepareRequest = (originalRequest, message) =>
{
message.Headers.Add("X-Forwarded-Host", originalRequest.Host.Host);
message.Headers.Add("X-Found-Cluster", "<your-cluster-id>");
message.Headers.Add("Authorization", "Basic <base64_encoded_username:password>");
return Task.FromResult(0);
};
});
}
We then deployed this to a subdomain (e.g. kibanaproxy.yourdomain.com) and changed our iframe src domain from https://clusterid.blah.found.io:5601 to https://kibanaproxy.yourdomain.com, leaving the rest of the url the same. Viewing the use case link above now works without signing in.
This is definitely a very important feature. It is not uncommon for Admins to need to be able to grant read only access to Dashboards, and creating a xpack security disabled Kibana that allows users to create visualizations but not be able to save them isn't a great solution.
From a usability perspective, we really only need to mimic the behavior of creating a read only account that has limited access to specific indices. The only difference being that it is the anonymous user. Then as described, add a configuration item for Kibana of something like xpack.security.anonymous.enable
that can be set to true
.
The setup for usage would be this:
xpack.security.anonymous.enable
to true
in KibanaThis is how I see the implementation of this to behave for the users:
kibana.defaultAppId
I hope this feature gets revisited and prioritized soon.
This is how I see the implementation of this to behave for the users:
Yes, exactly like this. We really need this also. Currently we need to have two Kibana instances:
It would be great if we could avoid this and just use the same instance where users are anonymous until they log in.
We need this too, currently there are certain dashboards in my company that we would encourage everyone to use them freely, but a login requirement will sometime make users annoyed since they don't know where to get user name and password.
Hello, I need it, my proposition:
Thanks
@antoineberthelin the approach that you've outlined is similar to what I'd like to see us implement to enable "anonymous authentication" in iframes. The one change is that I'd prefer we don't put the raw ES token directly in the URL. Instead, I'd recommend that we store the ES token in the .kibana
index using encrypted saved object attributes, and then include our own "authentication token" which corresponds to the token saved object. This way we aren't disclosing tokens for accessing ES directly to end-users.
We recently landed a feature (#51557) that allows an admin to display a custom message on the login page. The APM team uses this internally on their test/QA deployments to list which users the dev can log in with. Could this also be used as a workaround for anonymous access?
Could this also be used as a workaround for anonymous access?
Yup, absolutely. It's a good short-term workaround for various situations.
Any news on this?
@carlosvega we are still very interested in working on this, but we don't have a firm timeline for when this will be implemented.
+1
me too
+1
+1 as it will simplify the complexity of solutions
+1 Why not simply enable CORS for api/security/v1/login ? This would allow you to obtain the authentication cookie from pretty much anywhere, and enable you to bypass the kibana login page when showing your dashboard. I'm using Kibana on elastic cloud, so the reverse proxy workaround is not a great option for me.
It would be cool if there is something to solve this issue, I have a site with my own access control/authentification and I would like to not have to authentificate again on an embed dashboard.
My superior dont really want to use a proxy and he suggested instead to create an SAML authentification between my site and our kibana instance. Do you guys know if this can work ?
Thanks,
My superior dont really want to use a proxy and he suggested instead to create an SAML authentification between my site and our kibana instance. Do you guys know if this can work ?
Yes, SSO authentication mechanisms like SAML or OpenID Connect are supposed to solve that exact problem.
+1
I too have use cases where I'd like to share dashboards with anonymous users. This would especially come in handy with the interface allowing you to generate a URL that disables certain parts of the interface (Share>Embed Code).
Do we have an ETA on implementation of this?
Do we have an ETA on implementation of this?
No, we don't. And usually we don't provide ETA for enhancements like this. But I can say that it's on our top priority list for sure.
Any idea how long it will probably take until this PR arrives in elastic cloud ?
Any idea how long it will probably take until this PR arrives in elastic cloud ?
Usually there is no considerable delay between a new Elastic Stack minor/major release that would include a particular feature and the moment when this feature is available in Elastic Cloud. The only question here is when this PR lands and for what release, we don't know that yet. But now you can track the progress :slightly_smiling_face:
This thread is for Kibana anonymous access.
In case someone wondering about Elasticsearch anonymous access, then try this - https://www.elastic.co/guide/en/elasticsearch/reference/7.x/anonymous-access.html ?
Original comment by @jguay:
Kibana version: 6.0.0 Elasticsearch version: 6.0.0 Description of the problem including expected versus actual behavior: Customer would like to use kibana with anonymous user but using new "kibana_dashboard_only_user" role's restricted UI Steps to reproduce:
Describe the feature: Feature would be to have new setting for kibana like "xpack.security.anonymous.enable" which when set to true would remove the login page and go straight in using anonymous user against ES After this user gets logged in, the logout button should be removed. Or even better allow option to replaced by "login" button if another option xpack.security.anonymous.redirecturl is set (so that user is redirected to another kibana instance using standard security)