Hi Kirk, Thanks for the KIP!
1. Do we want to support validating issuers using the issuer uri? 2. Can the access token be reused for multiple connections from the same client? 3. Do we support configuring separate ssl configs for connecting authorization server/jwks endpoint? 4. Do we want support any readable username as principal if it is present in the token claims 5. I agree with Ron, We should move the public classes to "o.a.k.c.s.oauthbearer.secured" package. Thanks, Manikumar On Thu, Aug 19, 2021 at 11:46 PM Kirk True <k...@mustardgrain.com> wrote: > Hi Ron, > > On Sat, Aug 14, 2021, at 11:27 AM, Ron Dagostino wrote: > > Hi Kirk -- thanks for the KIP! Having concrete implementations > > out-of-the-box will be very helpful. > > > > > As seen in this diagram, the login callback is executed on the client > and > > the validate callback is executed on the broker. > > > > There was no diagram when I looked. Maybe there is a broken link or > > something? > > I double-checked and it's showing for me on the published version of the > wiki, even after I've logged out. > > Would you mind checking again when you get the chance? > > > > The name of the implementation class will be > > > org.apache.kafka.common.security.oauthbearer.internals.secured.OAuthBearerLoginCallbackHandler > > > > I think the internals package was meant for non-public stuff Most of it > > seems that way, although the "unsecured" implementation is in there -- > but > > that's maybe a grey area since it isn't meant to be used in production > > scenarios and is mostly leveraged in unit tests. Perhaps move the > proposed > > class into a "o.a.k.c.s.oauthbearer.secured" package? Then any > > implementation details beyond the public stuff can live under the > > "...internals.secured" package that you mentioned? The same comment > > applies to the validator callback handler class. > > In a draft I had the secured package directly under the oauthbearer > package as you describe but I received some out-of-band feedback to aim for > parity with the unsecured package layout. > > I don't have a preference for either. I do agree that it seems weird for a > package named internals to be used in configuration since its name implies > that things could change. > > > I'm confused by loginRetryMaxWaitMs and loginRetryWaitMs. The former has > > "Max" in the name, but only the description of the latter mentions it > being > > a max amount of time? Are the descriptions incorrect or perhaps > reversed? > > Yes. Thanks for catching that. I've added more description in a separate > paragraph above the enumerated configurations. > > > > Ensure the encoding algorithm isn't none and matches what the expected > > algorithm expecting > > > > "expected algorithm expecting" some kind of grammar issue? > > Haha! Yes - thanks for catching that too! > > It now reads: > > > Ensure the encoding algorithm (`alg` from the header) isn't `none` and > matches the expected algorithm for the JWK ID > > > Thanks again -- very exciting! > > Thanks for the feedback!!! > > Kirk > > > > > Ron > > > > > > > > > > > > On Fri, Aug 13, 2021 at 3:53 PM Kirk True <k...@mustardgrain.com> wrote: > > > > > Hi all! > > > > > > I have created a new KIP for a new OAuth/OIDC related authentication > > > feature. > > > > > > This task is to provide a concrete implementation of the interfaces > > > defined in KIP-255 to allow Kafka to connect to an OAuth / OIDC > identity > > > provider for authentication and token retrieval. While KIP-255 > provides an > > > unsecured JWT example for development purposes, this will fill in the > gap > > > and provide a production-grade implementation. > > > > > > Here's the KIP: > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186877575 > > > > > > Thanks! > > > Kirk > > >
