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)
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:
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.
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”:
makes sense at the root level
makes sense with block with type: forbid
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.
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”
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
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.
Sorry, I was on a long vacation and couldn’t answer you.
Can you tell me what was added?
I checked authorization with the wrong password and with the user banned. The error is the same.
I tried using not_groups and response_if_req_forbidden in blocks. But ROR doesn’t know these parameters.
P.S.
My bosses are asking me to clarify the ETA of this problem. Because they often encounter these errors.
Do you have any timeframe for solving this problem?
The second one is being reviewed. It means I will be able to provide you a pre-build with this change this week. And it will be released with ROR 1.63.0
ad 2) we’re planning to improve the error message under the login form, so we will take this into consideration. At the moment, the message set in the ROR ACL hasn’t been propagated to this place.
