Allow for custom oauth settings

[Sam-Kramer]

Is your feature request related to a problem? Please describe.
Our Kafka setup integrates with our environments, which has a bespoke security setup. It uses OAuth2, but we need to be able specify our own callbacks and principals.

Describe the solution you'd like
Allow the ability to specify in the oauth2 listener config:

• listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.class
• listener.name.sasl_ssl.oauthbearer.sasl.login.callback.handler.class
• listener.name.sasl_ssl.oauthbearer.principal.builder.class
• principal.builder.class
• listener.name.sasl_ssl.oauthbearer.connections.max.reauth.ms

Describe alternatives you've considered
Another idea here, which is probably more ideal, is to simply allow for custom authentication section, and is up to the user to specify their listener config. I don't see this as being too egregious, as there already is a section for custom authorization.

Additional context
Happy to contribute!

[scholzj]

Wouldn't it be better to make the Strimzi OAuth library work with your setup? Our idea for it is to make it usable with any OAuth 2 server. So maybe the things you need there might be needed by others as well. (of course I do not know your setup, so it is hard to say how much unique it is)

I also wonder whether principal.builder.class is something what can be configurable without breaking other things as/if it is not configurable per listener (mainly taking about the internal listeners here - for the user configured ones it would be up to you make sure it works I guess).

I like the idea of having some custom authentication to make it easier to use custom authentication plugins. That could serve more use-cases as well - for example #5473 etc. And we already have custom authorization type which this would complement. If you wanna contribute that, I think it might be worth having a proposal for it. It will allow us to discuss which fields should be configurable to make it really custom - I wonder if for the other use cases some other fields might be useful as well.

[Sam-Kramer]

Yeah I should mention I do apologize as this is very bespoke requirements. The annoying thing here is it's hard to expect a lot of setups/groups/organizations/companies to conform to a certain standard, especially around authorization/authentication. That said, I think as you mention custom auth here is probably the best way to go, just so it's usable for everyone in the community, and can help these random edge-cases.

Of course, I also think if someone is going down the custom auth route, it should be fully expected that they're off-roading, and I think the only expectation there should be that your properties are passed through. Especially seeing as, you'll have to bundle a custom image already in order to get your custom classes on the classpath.

I'll write a proposal for this :)

[Sam-Kramer]

I also wonder whether principal.builder.class is something what can be configurable without breaking other things as/if it is not configurable per listener (mainly taking about the internal listeners here - for the user configured ones it would be up to you make sure it works I guess).

How are you handling this today with Strimzi's OAuth @scholzj ? I see that if Strimzi OAuth is declared, we override the principal.builder.class to use https://github.com/strimzi/strimzi-kafka-oauth/blob/main/oauth-server/src/main/java/io/strimzi/kafka/oauth/server/OAuthKafkaPrincipalBuilder.java.

I assume operator and the other listeners still use cert-based authn/z, and the OAuthKafkaPrincipalBuilder supports both?

[Sam-Kramer]

Read the code a bit more of OAuthKafkaPrincipalBuilder, and that's exactly what's happening.

[scholzj]

Well, the difference is that that is our own principal builder which is written and tested to handle this. That might not apply for any custom builder a user provides.

[Sam-Kramer]

Submitted a proposal: strimzi/proposals#41

[Sam-Kramer]

Fixed in #6162