Undefined roles which was refered in demo configuration

Hi Team,

As I have noted that the roles_mapping_resolution is default to MAPPING_ONLY. but in the sg_roles_mapping.yml, there are roles mapping like:

  readonly: true
    - admin

    - kibanauser

  readonly: true
    - snapshotrestore

but i also noted that the backend roles admin, kibanauser, snapshotrestore have not been defined in the sg_roles.yml. and also sg_internal_users.yml use those undefined roles. do those roles has been predefined by SG?



i eventually found the roles used by internal user database do not necessarily be defined in the roles. only those in the results of internal user database * roles mapping should be defined in the roles if using internal user database as the backend.

it is something trickly…


The mapping step is there to being able to map any users and backend roles to SG roles, regardless where they are coming from. Think of backend roles as roles that come from any of the configured auth/auth backends. For example, backend roles can be:

  • LDAP groups
  • JWT claims
  • SAML assertions

It is best explained by using the LDAP case: We first authenticate the user via an LDAP search, then fetch the user’s LDAP roles, and then map the user to one or more SG role:

So in that sense the configured backend roles for the internal users behave exactly like LDAP groups. After the user is authenticated, we take the username and the backend roles and map them to SG roles.

The default mappings are there to make it easier to assign users to standard roles, like a Kibana user, snapshot/restore or an admin user. If you want to give an internal user access to Kibana, you would just assign the kibanauser backend role to the account in sg_internal_users.yml, and the default mapping takes care of assigning the user to the sg_kibana_user SG role.

1 Like

it is easy wrongly think the roles refered in the sg_internal_users as sg roles. indeed they are backend roles. and only those roles defined in the sg_roles.yml configuration are sg roles.


I know this can be confusing, but we definitely need the role mapping step when working with LDAP, JWT etc. If you have an idea about how to make that concept easier / explain it better / make it more obvious I’d really like to hear! Thx!

it maybe more straight forward if we take roles_mapping_resolution and sg_roles_mapping defined for each backend instead of take them as global configurations.

I actually like the idea. I’ve created a ticket in our backlog for internal discussion. Thanks!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.