NIFI-14782 Extended Kafka3ConnectionService OAuth authentication with…

[turcsanyip]

… SASL Extensions support

Summary

NIFI-14782

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[turcsanyip]

@dan-s1 Thanks for your suggestions. Updated the PR.

[mark-bathori]

Thanks @turcsanyip for this improvement. The changes look good and work as expected.
+1

[pvillard31]

It is extremely unlikely but the dynamic properties are configured with support for expression language at environment level. Users should definitely use parameters instead but they could technically reference environment variable through expression language. Do we want to do something about it? Right now we would not evaluate the dynamic property with expression language for the SASL extensions.

[dan-s1]

Probably makes sense to combine these

Suggested change

	if (subject.startsWith(PARTITIONS_PROPERTY_PREFIX)) {
	builder.valid(true);
	} else if (subject.startsWith(SASL_EXTENSION_PROPERTY_PREFIX)) {
	builder.valid(true);
	} else {
	if (subject.startsWith(PARTITIONS_PROPERTY_PREFIX) || subject.startsWith(SASL_EXTENSION_PROPERTY_PREFIX)) {
	builder.valid(true);
	} else {

[turcsanyip]

These are unrelated concepts, so I did not want to combine them, even with minimal code duplication. Also, the PARTITIONS_PROPERTY_PREFIX is a leftover from the old Kafka processors and it is not supported at the moment. It will be re-added in #10538. I would defer to that PR to finalize it.

[turcsanyip]

It is extremely unlikely but the dynamic properties are configured with support for expression language at environment level. Users should definitely use parameters instead but they could technically reference environment variable through expression language. Do we want to do something about it? Right now we would not evaluate the dynamic property with expression language for the SASL extensions.

Good catch @pvillard31, I did not notice it. Checked PropertyContext parameter in OAuthBearerLoginConfigProvider (where the dynamic properties are used) and it does not support enumerating (or getting the collection of) PropertyDescriptiors / PropertyValues that would be needed to check the property type and then evaluate the value. So the viable way is to disable EL support for these properties.

[pvillard31]

Are you suggesting to have a customValidate to make the component invalid if EL is used for SASL extension properties? Or completely remove EL support for all dynamic properties? I'd be fine with the first option, I'm not sure that would be OK to go with the second option.

[turcsanyip]

None of them but setting the EL flag on the given dynamic property conditionally, similar to the description.

[pvillard31]

Oh yeah, of course, even better

[pvillard31]

Thanks for the changes @turcsanyip