Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anonymous access #18331

Closed
elasticmachine opened this issue Nov 16, 2017 · 26 comments · Fixed by #79985
Closed

Anonymous access #18331

elasticmachine opened this issue Nov 16, 2017 · 26 comments · Fixed by #79985
Assignees
Labels
enhancement New value added to drive a business result ReleaseStatus Item of high enough importance that it should be called out in release status meetings Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@elasticmachine
Copy link
Contributor

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
Copy link
Contributor Author

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.

@elasticmachine elasticmachine added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Apr 25, 2018
@georgezoto
Copy link

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

@kobelb kobelb changed the title [security] Allow anonymous access for version 6.x [security] Allow anonymous access Jul 10, 2018
@ynux
Copy link

ynux commented Sep 8, 2018

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
Copy link

leightonb commented Jan 8, 2019

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
Copy link

Ralnoc commented May 26, 2019

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.
  4. 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.
  5. When someone clicks on Login it takes them to the login page and they can log in to use it as a normal user.
  6. When they click Logout it switches them over to the anonymous access again.

I hope this feature gets revisited and prioritized soon.

@kobelb kobelb changed the title [security] Allow anonymous access Anonymous access Jun 19, 2019
@tomhe
Copy link

tomhe commented Jun 25, 2019

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:

  • one without security enabled where users have read access to dashboards
  • one with security enabled with role-based write access to authenticated users

It would be great if we could avoid this and just use the same instance where users are anonymous until they log in.

@siben168
Copy link

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
Copy link

antoineberthelin commented Jul 29, 2019

Hello, I need it, my proposition:

  • In front side, we are able to get bearer for the user using our backend (with /_security/oauth2/token xpack functionality) and include dashboard iframe with bearer
  • You could allow the bearer in dashboard iframe URI to avoid proxy on our side ?
    What do you think ?

Thanks

@kobelb
Copy link
Contributor

kobelb commented Jul 29, 2019

@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
Copy link
Contributor

watson commented Jan 27, 2020

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
Copy link
Contributor

kobelb commented Jan 27, 2020

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

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

@carlosvega
Copy link

Any news on this?

@legrego
Copy link
Member

legrego commented Mar 18, 2020

@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
Copy link

+1

@fidelis
Copy link

fidelis commented May 2, 2020

me too

@cristiprg
Copy link

cristiprg commented May 16, 2020

+1

@dtakis
Copy link

dtakis commented May 20, 2020

+1 as it will simplify the complexity of solutions

@snava10
Copy link

snava10 commented May 26, 2020

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

@legrego legrego self-assigned this Jun 24, 2020
@Quentin2B
Copy link

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
Copy link
Member

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
Copy link

+1

@stacey-gammon stacey-gammon added the ReleaseStatus Item of high enough importance that it should be called out in release status meetings label Sep 17, 2020
@Grunticus03
Copy link

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
Copy link
Member

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
Copy link

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

@azasypkin
Copy link
Member

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 🙂

@deepakprasad119
Copy link

deepakprasad119 commented Nov 6, 2020

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result ReleaseStatus Item of high enough importance that it should be called out in release status meetings Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging a pull request may close this issue.