[FEATURE] user attributes from HTTP headers

[rursprung]

Is your feature request related to a problem?
currently in DLS/FLS only user attributes from the authentication (e.g. claims from a JWT) can be referenced. however, sometimes other attributes are needed as well.

What solution would you like?
currently we grab all user attributes which we reference in our DLS from the JWT. we now have a use-case where my DLS needs to filter something based on an information not present in the JWT (the information is still secure even if it's not part of a signed JWT because i have the information in OpenSearch whether the value provided can be valid). i currently don't see any way of passing something like this in, so i was thinking if it'd be ok to extend the user attribute mapping to allow mapping HTTP headers to user attributes

What alternatives have you considered?
extending the JWT is not an option in our case (the information is not known to the IdP)

Do you have any additional context?
n/a

[nibix]

Generally, I agree that OpenSearch is lacking a proper user attribute mapping. But, we cannot just copy all HTTP headers to the user object, as this would bloat the user object. Thus, we would need to have some selective mechanism.

A similar project does this like this: https://docs.search-guard.com/latest/authentication-authorization-configuration#mapping-user-information

For HTTP headers though, one would need to be super careful that you can actually trust this information. Is it in your case the JWT which marks the request as trusted? This seems to be a slightly special situation, doesnt it?

[rursprung]

thanks for your feedback @nibix!

yes, the intention isn't to copy all headers. i also briefly chatted with @cwperks about this and the idea would be to have an explicit whitelisting of HTTP headers in the config which can then be referenced in the mapping.
also, it'd have to be clearly documented that HTTP headers are under the influence of the user so they may only be used in a DLS/FLS if their content can be guaranteed to be safe.

one more issue i see is that we're currently doing string replacement when doing variable substitution so we might have to sanitize the input?
or rework the variable substitution to work more like stored scripts where the variable substitution happens in the core and (AFAIK) cannot influence the query anymore.

A similar project does this like this: https://docs.search-guard.com/latest/authentication-authorization-configuration#mapping-user-information

this looks very interesting for other use-cases, though it doesn't apply to our use-case (we cannot ask another backend for the data; it is request-specific)

[cwperks]

@rursprung TY for filing this! It sounds like a good feature request to me as long as the cluster admin can configure an allowlist of headers (and values?) that are substitutable.

[rursprung]

thanks @cwperks! are there specific things which we should nail down before implementation can start?
i think having an allowlist of headers is a good thing™️ - for the values i'm not sure how that's going to work? for my use-case i could technically do it (though it'd be rather painful), but i'm not sure if for all use-cases there's a list of known good values.
maybe it'd be possible to allow the admin to configure a regexp for a valid value (e.g. allow only alphanumerical values?)

[rursprung]

the other thing to clarify is: what name should these attributes have? we e.g. have attr.jwt.* for JWT based ones - should these be attr.header.*? i presume there won't be an auth realm named "header", so there shouldn't be a clash in the future?