Document-Layer Security with parameter substitution from JWT token claims doesn't seem to work

Security
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
Opensearch v2.7

Describe the issue:
Hello there,

I’ve been trying to define DLS with parameter substitution for days, to no avail…

The overall setup works just fine : SSO via Keycloak / Openid Connect working fine, users do access Dashboards with the proper roles (so, getting the backend roles from the JWT access token and mapping them to Opensearch roles is working as intented)

Now, my DLS clause works as long as I use a static term. As soon as I try to use a dynamic parameter such as “${attr.jwt.my_custom_attribute_claim}”, I will get no documents/hits at all.
Does seem like parameter substitution doesn’t occur at all.

The JWT token does contain the targeted claim/info, but it does not seem to be “seen” or propagated (in Dashboards, at least). This is true everywhere: dev tools, discover, visualize.

After many tries, and a lot of doc/posts reading, I have no clue.

I was wondering: Opensearch has both “jwt” and “openid” as http_authenticator types. Here, I do use “openid” (with Keyckoak as the IDP), and I though that was maybe the reason why “${attr.jwt.xxx}” params were not available? I thought of that while reading a post here about pretty much the same situation but with SAML auth - and there are, obviously, no such thing as “${attr.openid.xxx}” parameters…

Does anyone know anything about that?

Assuming that my issue does relate to Openid Connect vs JWT auth, does anyone know how to approach this (maybe there are some settings, somewhere…)? I don’t think that using the http_authenticator type “jwt” will work with Keycloak (can just have Openid Connect or SAML clients there), but maybe there’s a solution.

Otherwise, could it be related to some issue in the Dashboards UI/features? I do set my roles/permissions via the security panel in Dashboards (not via yml config files). How can I check that nothing weird is happening when my DLS query is submitted? (I mean, maybe there’s some issue with the ${} notation when using the UI, and that would require some escaping/encoding?)

EDIT:

I’ve just checked via the dev tools (GET _plugins/_security/api/roles/) and I have the following data for the role I configured DLS on:

“index_permissions”: [
{
“index_patterns”: [
“xxxxxxxxxx”
],
“dls”: “”“{
“bool”: {
“must”: [
{
“term”: {
“variable_sensible”: “${attr.jwt.my_custom_attribute}”
}
}
]
}
}”“”,

Does it seem legit?

/EDIT

EDIT-2:

I’ve tried changing the role via API calls. Same thing, does not work with parameter substitution…
So, it’s not related to how the Dashboard UI does it, clearly. It’s really about the substitution / the access token… :frowning:

/EDIT-2

Any help/insight appreciated.
Many thanks in advance!

Configuration:

Relevant Logs or Screenshots:

2

Hi @Jimshell

As per the documentation below, ${attr.<TYPE>.<NAME>} parameter can have one of the following types: internal , jwt , proxy or ldap.
So it is not possible to use it for OpenID authentication.

3

Hi @Eugene7

Thank you for your reply!

Indeed. I was aware of this, but I was kind of expecting that, because Openid Connect relies on OAuth that relies itself on JWT tokens as its exchange format basis, parameter substitution would be available there too, readily, “out of the box” (still seems so “logical” to me…)

Incidentally, I worked on it today, and switched to jwt authentication, and everything works as intented. Too bad that you can’t have this feature while using openid auth, it’s really quite a pity, those access tokens are just the exact same thing… I get the access token from Keycloak “manually” to inject it “manually”… Openid Connect was created, partly, to address that hassle…

I think that I’ll raise a feature-request ticket about it, because it really should not be tough to get there.

Thank you again!