Do not allow a user to log in if they do not have sufficient privileges

[elasticmachine]

Original comment by @skearns64:

A user who doesn't have at least read access to the currently configured Kibana index (and the other permissions necessary for Kibana to function) should not be allowed to log in.

Our users have seen this when they get role mapping wrong, or do role mapping based on AD/LDAP user properties - some users may not get roles, because they're not in the proper AD groups. The current behavior is that they can successfully log in, but everything is broken.

I propose that we block login, and the error message we show on the login screen should make it clear that they don't have the proper permissions to use Kibana.

[elasticmachine]

Original comment by @skearns64:

Thanks to LINK REDACTED , we now have an API to check a users permissions, so this should now be possible.

[elasticmachine]

Original comment by @epixa:

We should experiment with different role combinations before we go through with this. If someone's just using Kibana for monitoring, for example, then how would Kibana behave right now?

[elasticmachine]

Original comment by @skearns64:

Agree we should think it through, but in the short term, I would vote to simplify the problem space by defining the minimum permissions to access Kibana today as "a read-only version of the current kibana_user role."

For example, to use Monitoring today, you need the kibana_user (or a read-only version of it) and monitoring_user, and that hasn't been a problem.

We know that eventually, we're going to need a way to define more granular access to individual Kibana apps and features (LINK REDACTED), and I think that's the right time to revisit the various modes of usage that we expect (e.g. monitoring-only, monitoring + management only, monitoring + management + data visualization, data vis only, etc), and ensure the security mechanism we create is sufficiently flexible to meet the needs.

[elasticmachine]

Original comment by @bczifra:

Has there been any movement towards providing at least a short-term solution in the direction that @skearns64 mentioned above?

[elasticmachine]

Original comment by @epixa:

@bczifra There hasn't been any work on this yet

[joshbressers]

It would make sense to change the functionality of this a little bit. Kibana in version 7 will be using application privileges to manage who can access Kibana data and features. We could deny login or present users with a nice warning screen that explains they don't have Kibana access if they don't have any Kibana application privileges assigned.

[marbin]

I am also struggling with the case where users may be authenticated, but dont belong to any of the proper LDAP group mapped to elastic/kibana roles. They are still presented with an unresponsive UI.
Would be great with an option to lock out users without any mapped roles.

[e-mars]

@skearns64 .

How are we doing on this request?

we were able to do a search filter for just username and [email protected].

However, i could not figure out a filter for domain\username for AD and we eventually expect negative user feedback from the customer.

user filters in my lab:

          user_search:
            filter: "(&(|(sAMAccountName={0})(sAMAccountName=marsnet\\{0}))(memberOf=cn=ESAdmins,ou=Groups,ou=Elasticsearch,dc=marsnet,dc=local))"
            upn_filter: "(&(userPrincipalName={1})(memberOf=cn=ESAdmins,ou=Groups,ou=Elasticsearch,dc=marsnet,dc=local))"

cc: @Ca2Patton

thanks,
marcelo

[Erni]

How are we doing on this? We have users complaining about users being able to login successfully despite not being in an AD group mapped to Elasticsearch.

[kobelb]

When we're looking at addressing this, we should consider exposing the roles that the authenticated user is assigned. This is particularly helpful if a role-mapping isn't working correctly and the user is utilizing SSO.

[watson]

A big chunk of this issue was addressed in #75538 and will land in 7.10. There's still some small details that might not be that important for the end user that means we'll keep this issue open for now, specifically that we don't check the users privileges prior to logging them in. That means we'll still log them in and forward them to the main system, which only then discovers that they do not have the proper access. It is here we then show them a nice new screen which allows them to log out and try again. For this issue to be fully resolved we'd have to check this in advance and not even log them in in the first place.

However, since the user now have a way out of the situation by means of the new "reset session" screen, this issue is no longer that important and have for now been moved to the backlog.

[legrego]

We do not have any more planned work for this, so I am going to close this as completed via #75538.