elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.62k stars 8.22k forks source link

Anonymous access #18331

Closed elasticmachine closed 3 years ago

elasticmachine commented 6 years ago

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:

  1. Define anonymous_user in elasticsearch with role kibana_dashboard_only_user
  2. Kibana displays a login page so it's not possible to use the anonymous user
  3. xpack.security.enable: false in kibana.yml will partially workaround if user also has cluster/monitor privilege. However user will have unrestricted UI (hence be able to create any dangerous vizualisation and get errors when trying to save them to .kibana)

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)

elasticmachine commented 6 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.

georgezoto commented 6 years ago

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

ynux commented 6 years ago

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.

leightonb commented 5 years ago

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.

Ralnoc commented 5 years ago

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:

  1. Enable the anonymous user in Elasticsearch
  2. Assign anonymous user to the roles that grant read access to the indices & spaces you want everyone to be able to view data from.
  3. Set xpack.security.anonymous.enable to true in Kibana

This is how I see the implementation of this to behave for the users:

  1. When a user lands on Kibana, they are immediately routed to the kibana.defaultAppId
  2. The profile button in the top right corner is instead a Login button.
  3. User can navigate to anything as they would as a normal logged in user with limited read access, only as the anonymous user.
    1. Caveat to this, it would obviously be preferred if the Anonymous users only had the option to switch spaces if they had access and go to the Dashboards section. All other app interfaces would be disabled.
  4. When someone clicks on Login it takes them to the login page and they can log in to use it as a normal user.
  5. When they click Logout it switches them over to the anonymous access again.

I hope this feature gets revisited and prioritized soon.

tomhe commented 5 years ago

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.

siben168 commented 5 years ago

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.

antoineberthelin commented 5 years ago

Hello, I need it, my proposition:

Thanks

kobelb commented 5 years ago

@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.

watson commented 4 years ago

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?

kobelb commented 4 years ago

Could this also be used as a workaround for anonymous access?

Yup, absolutely. It's a good short-term workaround for various situations.

carlosvega commented 4 years ago

Any news on this?

legrego commented 4 years ago

@carlosvega we are still very interested in working on this, but we don't have a firm timeline for when this will be implemented.

mgoritzk commented 4 years ago

+1

fidelis commented 4 years ago

me too

cristiprg commented 4 years ago

+1

dtakis commented 4 years ago

+1 as it will simplify the complexity of solutions

snava10 commented 4 years ago

+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.

Quentin2B commented 4 years ago

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,

azasypkin commented 4 years ago

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.

aniruddhaopseco commented 4 years ago

+1

Grunticus03 commented 4 years ago

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?

azasypkin commented 4 years ago

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.

ManuelKugelmann commented 4 years ago

Any idea how long it will probably take until this PR arrives in elastic cloud ?

azasypkin commented 4 years ago

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:

deepakprasad119 commented 4 years ago

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 ?