RoR Pro: Understanding permissions with groups and and LDAP authentication

1

According to this section of the documentation: https://readonlyrest.com/documentation/index.html#Users_and_Groups--Local_users_and_groups

It reads that user bob is a member of team2 and team4. I would assume then, that bob would have access to index2 index3 and indices defined by team4.

Based on my implementation, I’m not seeing that as a result. Index access is limited to one of the groups they are added to. I want to configure access based on ldap group membership (ldap_authorization) But need to get this to work first.

Any ideas? I’m open to the fact that I might be approaching this all wrong. It’s just not how it works.

Here’s what I’ve got configured:

readonlyrest:
  audit_collector: 'true'
  prompt_for_basic_auth: 'false'
  ldaps:
    -
      search_user_base_DN: 'cn=users,dc=example,dc=com'
      port: '636'
      search_groups_base_DN: 'cn=groups,dc=example,dc=com'
      host: ldapserver.example.com
      name: ldap1
      unique_member_attribute: Member
      ssl_trust_all_certs: 'true'
  access_control_rules:
### SERVICE ACCOUNTS
    -
      name: '::KIBANA-SRV::'
      auth_key: 'kibana:kibana'
      verbosity: error
    -
      name: '::ADMIN::'
      auth_key: 'admin:admin'
### GROUPS      
    -
      name: "::KIBANA_GRP::"
      groups: ["KIBANA Access"]
      kibana_access: rw
      kibana_hide_apps: ["readonlyrest_kbn", "kibana:management", "timelion"]
    -
      name: "General Access"
      groups: ["General Access"]
      indices: ["shakespeare", "consumer_data"]
      kibana_hide_apps: ["readonlyrest_kbn", "kibana:management", "timelion"]
    -
      name: "Financial Access"
      groups: ["Financials Access"]
      indices: ["fin-*"]
      kibana_hide_apps: ["readonlyrest_kbn", "kibana:management", "timelion"]
    -
      name: "::ADMIN_GRP::"
      groups: ["ROR (admin)"]
### USERS
  users:
    -
      username: "superuser"
      ldap_authentication:
        name: "ldap1" 
      groups: ["ROR (admin)"]
    -
      username: "user1"
      ldap_authentication:
        name: "ldap1" 
      groups: ["KIBANA Access", "General Access"]
    -
      username: "finuser2"
      ldap_authentication:
        name: "ldap1" 
      groups: ["KIBANA Access", "General Access", "Financials Access"]
2

Hi @mching,

This is a known limitation (and a terrible example ended up in the docs, sorry). The ACL nature of ReadonlyREST (first block that matches is taken in consideration) makes it so that a user with two groups is actually interpreted as belonging to the first group alone.

We opted for leaving this behaviour as it currently is, because the rules associated to two groups could potentially be contradictory, and of non-obvious reconciliation.

With the Enterprise Kibana plugin this gets better because a user with multiple groups receives a drop down menu on the top left, where to select what group to belong for the current session.

3

@sscarduzio A dropdown option in Kibana might work for kibana users. But for purely Elasticsearch users, this is a serious limitation as the user might satisfy for example both readonly rule and a readwrite rule. Just because the readonly rule was positioned first in the config file, it doesn’t make sense to apply only the readonly rule, when user actually has write access also. Can you please look at improving this functionality to consider the more broader access?

To your point of rules being contradictory - let say due to bad setup, ROR should always take the rule that gives broader access, irrespective of where the rule was positioned in the config file. Atleast that is how most of the security software works generally.

Thanks!