Hi all,
I just wanted to mention that there have been some minor updates to the
configuration for OAuth.
The most relevant change is that I introduced an exponential backoff for when
we attempt to retrieve the JWKS (JSON Web Key Set) from the OAuth/OIDC
provider. Rather than hard-code the
Hi Kirk,
Thanks for the updates. Looks good.
Just one comment on the naming of configs. For configs that are very
specific to OAUTHBEARER, can we add `sasl.oauthbearer` as the prefix,
similar to `sasl.kerberos.` that we use for Kerberos configs, e.g. `
sasl.login.sub.claim.name`. For configs
Hi Rajini,
I've updated the KIP with your feedback. Let me know if there's anything still
amiss.
Thanks,
Kirk
On Wed, Oct 6, 2021, at 5:27 PM, Kirk True wrote:
> Hi Rajini,
>
> Thank you very much for your in-depth review! You highlighted a lot of dark
> corners :)
>
> >1. The diagram
Hi Rajini,
Thank you very much for your in-depth review! You highlighted a lot of dark
corners :)
>1. The diagram shows broker startup followed by `broker requests keys
>from JWKS endpoint`.
> - Do we open broker ports only after we successfully get the keys? We
> need to
Hi Kirk,
Thanks for the KIP! This should really help drive adoption of
SASL/OAUTHBEARER for Kafka.
Some comments/questions:
1. The diagram shows broker startup followed by `broker requests keys
from JWKS endpoint`.
- Do we open broker ports only after we successfully get the keys?
Hi Manikumar,
On Wed, Aug 25, 2021, at 8:54 PM, Manikumar wrote:
> Thanks for the reply,
>
> Can we also update the KIP about the testing approach?
Yes, I've added that as a dedicated section in the KIP:
Hi Jun,
On Tue, Sep 21, 2021, at 10:51 AM, Jun Rao wrote:
> Hi, Kirk,
>
> Thanks for the KIP. Does the proposal support reauthentication outlined
> in KIP-368?
Yes, the existing mechanism for re-authentication is implemented at a higher
layer of the code, so we just get it for "free."
I've
Hi, Kirk,
Thanks for the KIP. Does the proposal support reauthentication outlined
in KIP-368?
Jun
On Wed, Aug 25, 2021 at 8:54 PM Manikumar wrote:
> Thanks for the reply,
>
> Can we also update the KIP about the testing approach?
>
> Thanks,
>
> On Wed, Aug 25, 2021 at 12:01 AM Kirk True
Thanks for the reply,
Can we also update the KIP about the testing approach?
Thanks,
On Wed, Aug 25, 2021 at 12:01 AM Kirk True wrote:
> Hi Manikumar!
>
> On Mon, Aug 23, 2021, at 12:59 PM, Manikumar wrote:
>
> Hi Kirk,
>
> Thanks for the KIP!
>
> 1. Do we want to support validating issuers
Hi Manikumar!
On Mon, Aug 23, 2021, at 12:59 PM, Manikumar wrote:
> Hi Kirk,
>
> Thanks for the KIP!
>
> 1. Do we want to support validating issuers using the issuer uri?
Are you referring to validating the JWT was issued by a known, configured
issuer, or something more different/more
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
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
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
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
14 matches
Mail list logo
