config.yml settings for OpenID Connect not working with nested hierarchy for roles

[NickDatLe]

Hello,

I can't seem to get roles working when the roles_key field is not a simple key-value pair. For example, this works:

              authc:
                openid_auth_domain:
                  http_enabled: true
                  transport_enabled: true
                  order: 0
                  http_authenticator:
                    type: openid
                    challenge: false
                    config:
                      subject_key: preferred_username
                      roles_key: roles
                      openid_connect_url: https://my-keycloak-server.com:8443/auth/realms/demo/.well-known/openid-configuration
                  authentication_backend:
                    type: noop

When the token looks like this, it works:

      "roles": [
        "admin"
      ]

However, when I try to restructure the roles_key to this:

              authc:
                openid_auth_domain:
                  http_enabled: true
                  transport_enabled: true
                  order: 0
                  http_authenticator:
                    type: openid
                    challenge: false
                    config:
                      subject_key: preferred_username
                      roles_key: resource_access.my-client-id.roles
                      openid_connect_url: https://my-keycloak-server.com:8443/auth/realms/demo/.well-known/openid-configuration
                  authentication_backend:
                    type: noop

and restructure my JWT to look like this:

"resource_access": {
    "my-client-id": {
      "roles": [
        "admin"
      ]
    }
  }

I think it's the way I defined the "roles_key" field. Any help is appreciated.

[weicongs-amazon]

please @vrozov @sujithvm help to take a look this issue about how to configure the security feature.

[AntonEliatra]

Issue still present in latest version of Opensearch (1.2.0) No roles are retrieved from jwt with nested roles.

[davidlago]

We are doing some "spring cleaning in the fall", and to make sure we focus our energies on the right issues and we get a better picture of the state of the repo, we are closing all issues that we are carrying over from the ODFE era (ODFE is no longer supported/maintained, see post here).

If you believe this issue should still be considered for current versions of OpenSearch, apologies! Please let us know by re-opening it.

Thanks!

[scrawfor99]

[Triage] This is being reopened as a result of https://github.com/opensearch-project/security/issues/3877. This will require investigation before we can determine the extent of the changes required for this. @scrawfor99 will add a comment.

[urpylka]

Same problem!

[scrawfor99]

Hi @urpylka and @NickDatLe, I am adding this comment to explain the current behavior and then leave some steps for someone to follow in order to add the features you both want.

Currently, when parsing the authentication configuration settings, OpenSearch expects all values to be 1:1 mapped. This means that there is no support for nested fields or values like the OIDC example above. This means that if we set roles to resource_access.my-client-id.roles the token is expected to have that whole string as its roles key.

In order to support the nested naming requested, the security plugin would need to be made to 1) be able to handle requests with nested fields in their JWTs by modifying the JWTAuthenticator code 2) properly split on a given character when doing so. Both of these changes should be pretty straightforward but challenges arise around the use of the standard splitting character. In the example above, '.' is used to show different levels. This is common and easy to understand however if we force the default interaction to be splitting on '.' we risk breaking users who have periods and do not expect splitting to occur. To handle this we would need to make the nested parsing a default-off feature which could be flipped on in the settings.

[urpylka]

Thanks for the explanation! It is helpful to understand the complexity with solving it.

I can share with my workaround with somebody else who faced with same problem.

It is possible to create additional client role mapper in default client scope roles specially for opensearch client. And use not nested opensearch_roles key. Pictures with configs below: