[SUPPORT|kbn_ent] Managing forbidden messages

Enterprise Support
1

We have a large number of groups and users.
Many people do not understand why they cannot access the indexes and write to support.

I want to add the ability to add the response_if_req_forbidden function to each ACL.

To get a message when accessing the index “support”,
error:

you need the “support” role in ldap

To get a message when accessing the index “prod”,
error:

you need the “prod” role in ldap

Now the person gets an error, the password is incorrect and does not understand what to do to gain access to the role.

Or maybe you already have a solution to my problem?

{“customer_id”: “6c4a385b-2ae8-4f02-a9cd-ef24addfb5b3”, “subscription_id”: “32d4073f-dc2f-4056-a868-842727c637cd”}

2

Hi @driveirk

Where do you want to see this message? Somewhere in Kibana UI or do you refer to response from ES API only?

3

Hi
In both cases.
But most often the problem occurs in Kibana, because people visit there more often.

4

The API case is simple. Assuming that we are talking about the custom forbidden message in the “forbid” type blocks only.

But I don’t think I understand how you would like to see it in Kibana. Could you please show me some example? (ROR ACL + Kibana screenshot of how it looks now)

5
  1. the password is incorrect.
    image
    image998×630 34.3 KB

    This is good.

2)the password is correct, But access is denied.
I want to replace “Wrong credentials” with my own text

    - name: "check pass"
      type: allow
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
 #Maybe use "not_groups"? and type: forbid
        groups: ["basic", "admin", "support"] 
     response_if_req_forbidden: "You must be in one of the groups basic, admin, support"

3)1) the password is correct, but there are restrictions on access to the index:

image
image1990×660 90.2 KB

This error is from Elasticsearch, so you can leave it like this and do nothing in Kibana, but if you make a beautiful conclusion, it will be cool.

    - name: "group a access"
      indices: ["*kibana*" ]
      kibana_access: rw
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        groups: ["a"]

    - name: "group a"
      type: forbid
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
 #Maybe use "not_groups"? and  groups: ["b"]
        groups: ["a"]
      response_if_req_forbidden: "You must be in one of the groups b"

Adding not_groups would help too.
not_groups - The user does not have any of the listed groups.

6

A user won’t be allowed to enter Kibana when no block is matched. All blocks mismatched, means: FORBIDDEN.

So, analyzing the 2nd point, I’d say that the block won’t be matched (assuming that the user has none of the listed groups), and the next block will be evaluated. Because the “check pass” block was not matched, the “response_if_req_forbidden” message won’t be chosen anyway.

When there is a possibility to change the block type to “forbid” and use “not_groups”, the “response_if_req_forbidden” might make sense. The block will be matched, ACL result is defined by this block and we can get the message and return to Kibana.

So, as you see - the “response_if_req_forbidden”:

  1. makes sense at the root level
  2. makes sense with block with type: forbid
  3. makes no sense with block with type: allow

BTW: high in our backlog, we have a task to improve the error messages shown by Kibana when user’s request is rejected by ROR ES ACL.

1 Like
7

What if we use this option? Continuation of point 2

- name: "group a"
      type: forbid
      ldap_authentication:
        name: "ldap"
      ldap_authorization:
        name: "ldap"
        not_groups: ["a"]
      response_if_req_forbidden: "You must be in one of the groups a"

user is not a member of any of the groups “a”
So that when authorizing with the correct user password, instead of
“Wrong credentials”
there will be
“You must be in one of the groups a”

Can this be added?

8

“not_groups” in “ldap_authorization” won’t be so simple to add (e.g. I’m not sure if it’s going to work with server_side_groups_filtering enabled).

But it seems we can try to implement this.

9

Can I ask why?
not_groups and groups search for groups in the same way.
Differences:

                            groups => skip
                         /
search group => if false 
                         \
                           not_groups => use

                            groups => use
                         /
search group => if true 
                         \
                           not_groups => skip

The only difference is the behavior after the search is completed.

10

LDAP connector has two modes:

  1. Server side groups filtering is disabled (default) - ROR asks for all ldap groups for a given user and then on the ROR side there is a check if user belongs to the configured groups. The new subrule is going to check if the user DOESNT belong to the configured groups. This is simple
  2. Server side groups filtering is enabled - ROR asks LDAP to return only the groups that matches a given query (the ldap query is created using the configured groups). I’m not sure if this will be possible with the new subrule. This requires some deeper analysis.