This repository has been archived by the owner on May 3, 2021. It is now read-only.
added a new parameter to the openid configuration section in config.y… #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
We have discovered a security flaw in the OpenDistro OIDC implementation in that the aud (audience) claim is not validated when the access token is a JWT.
This effectively means it is making an assumption that the OIDC JWT provider is wholly private, i.e. no JWT will be signed by that provider intended for any service other than Elasticsearch.
This is of course untrue with an enterprise OIDC login system that supports multiple applications.
Because of this, any application running in the organisation can receive a JWT token (destined for a completely different application) and use it to impersonate the user to Elasticsearch, without their knowledge.
This pull request contains our suggested fix for OpenDistro 0.10.
This issue is likely also present in later versions of OpenDistro so ideally this fix would be forward-ported to the newer versions that are compatible with Elasticsearch 7+.
This adds a new optional parameter "audiences" to the openid configuration block in config.yml. This can be set to a list of valid audiences. If this is set then the JWT must contain at least one of the configured valid audience strings, if it doesn't then the JWT is considered invalid and authentication is denied. If the audiences parameter is unset then the behaviour is the same as it is now, i.e. the aud claim is not validated.
Credit to Max Bowsher for highlighting this issue to us.
Thanks,
Mark