🚀External (i.e. LDAP) groups mapping (ROR >= 1.30.0)

Easy group mapping

We are excited to present you a simple solution to what has previously been quite difficult, and hacky to do with ReadonlyREST. All is done minimally extending the same basic and straight forward configuration structure we had in place for for years to define local groups.

Group mapping is really useful in ReadonlyREST Enterprise, because of the semantic overlap between the concepts of group and Kibana tenancy.

So as a matter of fact, now it’s possible to associate users from multiple LDAP groups to the same Kibana tenancy.

Sorry for the terrible drawing :pencil2:

Requirements

  • ReadonlyREST >= 1.30.0 for Elasticsearch (any version)
  • ReadonlyREST Enterprise >= 1.30.0 for Kibana (any version)
  • An LDAP server configured as an LDAP connector in readonlyrest.yml.
  • Multiple LDAP groups (with users associated)

Example

Imagine your company has three teams: developers, operations an marketing. In the LDAP server, they belong to three groups accordingly to the team they belong to.

  1. Team-dev
  2. Team-ops
  3. Team-marketing

However, they all collaborate to a project “ProjectX”, and they all need to see the usage analytics dashboards.

readonlyrest:
  access_control_rules:
  - name: "ProjectX analytics tenancy"
    groups: ["ProjectX_analytics"]
    kibana_index: ".kibana_projectx"
    indices: [".kibana_projectx", "logtash-projectx-*"]

  users:
  - username: "*"
    groups: ["ProjectX_analytics"]
    ldap_auth:
      name: ldap1
      groups: ["Team-dev", "Team-ops", "Team-marketing"]

  ldaps:
  - name: ldap1
    hosts:
    - "ldaps://ldapserver.com:636"
   [....]

Using the above configuration, we are stating the following:

"Any valid ldap1 user belonging to either “Team-dev”,“Team-ops”,“Team-marketing” teams has access to the “ProjectX analytics tenancy”.

For more information about this, see the dedicated documentation page.

Please comment for questions or just to share your opinions :slight_smile:

Simone