How to access nested JWT claims in role DLS

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser): 3.2.0

Describe the issue:

My JWTs contain a nested claim that contains the tenant ID of the user:

{
  ...
  "active_tenant": {
    "tenant_id": "<tenant-id>",
    ...
  },
  ...
}

I would like to use this nested claim in a role DLS (document level security), e.g. something like this:

"dls": "{\"bool\":{\"must\":{\"term\":{\"owner\":\"${attr.jwt.active_tenant.tenant_id\"}}}}"

However, this doesn’t seem to be working, the filter always filters everything away. How can I make this nested attribute available in a way so that I can use it in a DLS filter? The filter works fine if I use a constant value instead of a variable. I guess it also works if a top-level claim is used.

Accessing /_plugins/_security/authinfo, I can see that indeed the nested attribute is not listed among the attr.jwt.* attributes, only top-level attributes are listed. I see “attr.jwt.active_tenant” listed, but not “attr.jwt.active_tenant.tenant_id”. Can I somehow map the nested attribute to a top-level attribute and then access it?

@thomas.schuerger The jwt claims only support top level attributes, as you see using authinfo.

You have 2 options to get this working:

  1. You can use mappers in JWT provider (IDP) to convert it to top level attribute.
  2. You can add this to the roles section, since roles supports nested attributes, (You might find this case useful)
  1. Ok, that is obviously a solution, but TBH not a good one. This could be a temporary solution until OpenSearch has a better solution available.
  2. I’m not sure I understand this part. I’m already using the array syntax for roles_key that is supported since version 3.1.0 (because the roles are also a nested attribute inside the active_tenant, that works fine). But how would this help me extracting the tenant_id attribute for the DLS?

How about also making nested attributes available as attr.jwt.*?

Regarding the second point, if this is included in the roles claim, you could then create DLS based on the roles received.

Regarding nested attributes for attr.jwt, I would recommend to raise a feature request here