[security] Support impersonation via SASL/PLAIN authorization id - #3857
[security] Support impersonation via SASL/PLAIN authorization id#3857beryllw wants to merge 5 commits into
Conversation
|
Thanks a lot for the review, @litiliu! |
litiliu
left a comment
litiliu
left a comment
There was a problem hiding this comment.
One compatibility concern with #3047: FlussProtocolPlugin materializes security.sasl.plain.credentials into security.sasl.plain.jaas.config by parsing and regenerating only user_* options. This PR introduces impersonate_* as a non-credential JAAS option, so it will be silently dropped whenever the credentials map is configured or dynamically updated.
Is impersonation intentionally unsupported together with security.sasl.plain.credentials? If not, the JAAS regeneration should preserve impersonate_*, with tests covering both startup and dynamic credentials updates.
…ns when materializing SASL/PLAIN credentials
|
I'll open a follow-up PR to support dynamically altering the impersonation grants themselves. |
| * Register a new prefix here when this handler starts consuming a new option; a unit test | ||
| * asserts the plugin's extraction covers every prefix listed here. | ||
| */ | ||
| public static final List<String> KNOWN_OPTION_PREFIXES = |
There was a problem hiding this comment.
Would it be simpler and more compatible to preserve all options from the original PlainLoginModule entry instead of maintaining a prefix allowlist? Since security.sasl.plain.credentials is syntactic sugar, materializing it should ideally overlay the corresponding user_* options without dropping unrelated JAAS options. We could parse the single entry through JaasConfig, copy AppConfigurationEntry#getOptions(), overlay the credentials, and serialize it safely. This would also avoid exposing and synchronizing KNOWN_OPTION_PREFIXES.
2 participants
Purpose
Linked issue: close #3837
Brief change log
Tests
API and Format
Documentation