You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Jun Rao <ju...@confluent.io.INVALID> on 2021/09/21 17:51:53 UTC
Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC
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 <ma...@gmail.com> 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 <ki...@mustardgrain.com> 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 using the issuer uri?
> >
> >
> > Are you referring to validating the JWT was issued by a known, configured
> > issuer, or something more different/more dynamic?
> >
> > The current design allows for optionally requiring that the iss claim
> > from the JWT match a statically configured issuer from the configuration.
> > See expectedIssuer under the broker configuration.
> >
> > 2. Can the access token be reused for multiple connections from the same
> > client?
> >
> >
> > That's an excellent question - I will double-check that it is reused.
> > Hopefully the existing client authentication mechanism supports that
> level
> > of reuse.
> >
> > 3. Do we support configuring separate ssl configs for connecting
> > authorization server/jwks endpoint?
> >
> >
> > Yes, that documentation is forthcoming soon.
> >
> > It will be a set of configuration options similar to the existing SSL
> > socket configuration, but specific to the HTTPS endpoint for the
> OAuth/OIDC
> > provider connections.
> >
> > 4. Do we want support any readable username as principal if it is present
> > in the token claims
> >
> >
> > Yes. See the subClaimName and principalClaimName configuration options.
> > Those will allow specifying a claim name other than sub for the
> principal.
> >
> > Now that I'm writing this out I realize that the configuration names are
> > different on the client and broker for some reason 🤔 I'll change that.
> >
> > 5. I agree with Ron, We should move the public classes to
> > "o.a.k.c.s.oauthbearer.secured" package.
> >
> >
> > Sounds good. I made the change in the KIP.
> >
> > Thanks,
> > Manikumar
> >
> >
> > Thanks for your feedback!
> >
> >
> > On Thu, Aug 19, 2021 at 11:46 PM Kirk True <ki...@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 <ki...@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
> > > >
> > >
> >
> >
> >
>
Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC
Posted by Kirk True <ki...@mustardgrain.com>.
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 added a couple of sentences to that effect to the KIP.
Thanks,
Kirk
>
> Jun
>
> On Wed, Aug 25, 2021 at 8:54 PM Manikumar <ma...@gmail.com> 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 <ki...@mustardgrain.com> 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 using the issuer uri?
> > >
> > >
> > > Are you referring to validating the JWT was issued by a known, configured
> > > issuer, or something more different/more dynamic?
> > >
> > > The current design allows for optionally requiring that the iss claim
> > > from the JWT match a statically configured issuer from the configuration.
> > > See expectedIssuer under the broker configuration.
> > >
> > > 2. Can the access token be reused for multiple connections from the same
> > > client?
> > >
> > >
> > > That's an excellent question - I will double-check that it is reused.
> > > Hopefully the existing client authentication mechanism supports that
> > level
> > > of reuse.
> > >
> > > 3. Do we support configuring separate ssl configs for connecting
> > > authorization server/jwks endpoint?
> > >
> > >
> > > Yes, that documentation is forthcoming soon.
> > >
> > > It will be a set of configuration options similar to the existing SSL
> > > socket configuration, but specific to the HTTPS endpoint for the
> > OAuth/OIDC
> > > provider connections.
> > >
> > > 4. Do we want support any readable username as principal if it is present
> > > in the token claims
> > >
> > >
> > > Yes. See the subClaimName and principalClaimName configuration options.
> > > Those will allow specifying a claim name other than sub for the
> > principal.
> > >
> > > Now that I'm writing this out I realize that the configuration names are
> > > different on the client and broker for some reason 🤔 I'll change that.
> > >
> > > 5. I agree with Ron, We should move the public classes to
> > > "o.a.k.c.s.oauthbearer.secured" package.
> > >
> > >
> > > Sounds good. I made the change in the KIP.
> > >
> > > Thanks,
> > > Manikumar
> > >
> > >
> > > Thanks for your feedback!
> > >
> > >
> > > On Thu, Aug 19, 2021 at 11:46 PM Kirk True <ki...@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 <ki...@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
> > > > >
> > > >
> > >
> > >
> > >
> >
>