New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config.yml settings for OpenID Connect not working with nested hierarchy for roles #551
Comments
Issue still present in latest version of Opensearch (1.2.0) No roles are retrieved from jwt with nested roles. |
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! |
[Triage] This is being reopened as a result of #3877. This will require investigation before we can determine the extent of the changes required for this. @scrawfor99 will add a comment. |
Same problem! |
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 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. |
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:
When the token looks like this, it works:
However, when I try to restructure the roles_key to this:
and restructure my JWT to look like this:
I think it's the way I defined the "roles_key" field. Any help is appreciated.
The text was updated successfully, but these errors were encountered: