Hey Mayuresh,
Thanks for the comments.
- The KIP says that a user can have a class that extends KafkaPrincipal.
> Would this extended class be used when constructing the Session object
> in
> the SocketServer instead of constructing a new KafkaPrincipal?
Yes, that's correct. We want to allow the authorizer to be able to leverage
additional information from the authentication layer.
- The KIP says "A principal is always identifiable by a principal type
> and a name. Nothing else should ever be required." This might not be
> true
> always, right? For example, we might have a custom third party ACL
> library
> that creates a custom Principal from the passed in cert (this is done in
> PrincipalBuilder/KafkaPrincipalBuilder) and the custom Authorizer might
> use this third party library to authorize using this custom Principal
> object. The developer who is implementing the Kafka Authorizer should
> not be caring about what the custom Principal would look like and its
> details, since it will just pass it to the third party library in Kafka
> Authorizer's authorize() call.
I'm not sure I understand this. Are you saying that the authorizer and
principal builder are implemented by separate individuals? If the
authorizer doesn't understand how to identify the principal, then it
wouldn't work, right? Maybe I'm missing something?
Let me explain how I see this. The simple ACL authorizer that Kafka ships
with understands user principals as consisting of a type and a name. Any
principal builder that follows this assumption will work with the
SimpleAclAuthorizer. In some cases, the principal builder may provide
additional metadata in a KafkaPrincipal extension such as user groups or
roles. This information is not needed to identify the user principal, so
the builder is still compatible with the SimpleAclAuthorizer. It would also
be compatible with a RoleBasedAuthorizer which understood how to use the
role metadata provided by the KafkaPrincipal extension. Basically what we
would have is a user principal which is related to one or more role
principals through the KafkaPrincipal extension. Both user and role
principals are identifiable with a type and a name, so the ACL command tool
can then be used (perhaps with a custom authorizer) to define permissions
in either case.
On the other hand, if a user principal is identified by more than just its
name, then it is not compatible with the SimpleAclAuthorizer. This doesn't
necessarily rule out this use case. As long as the authorizer and the
principal builder both agree on how user principals are identified, then
they can still be used together. But I am explicitly leaving out support in
the ACL command tool for this use case in this KIP. This is mostly about
clarifying what is compatible with the authorization system that Kafka
ships with. Of course we can always reconsider it in the future.
Thanks,
Jason
On Fri, Aug 25, 2017 at 10:48 AM, Mayuresh Gharat <
gharatmayures...@gmail.com> wrote:
> Hi Jason,
>
> Thanks a lot for the KIP and sorry for the delayed response.
>
> I had a few questions :
>
>
> - The KIP says that a user can have a class that extends KafkaPrincipal.
> Would this extended class be used when constructing the Session object
> in
> the SocketServer instead of constructing a new KafkaPrincipal?
>
>
> - The KIP says "A principal is always identifiable by a principal type
> and a name. Nothing else should ever be required." This might not be
> true
> always, right? For example, we might have a custom third party ACL
> library
> that creates a custom Principal from the passed in cert (this is done in
> PrincipalBuilder/KafkaPrincipalBuilder) and the custom Authorizer might
> use this third party library to authorize using this custom Principal
> object. The developer who is implementing the Kafka Authorizer should
> not be caring about what the custom Principal would look like and its
> details, since it will just pass it to the third party library in Kafka
> Authorizer's authorize() call.
>
>
> Thanks,
>
> Mayuresh
>
>
> On Thu, Aug 24, 2017 at 10:21 AM, Mayuresh Gharat <
> gharatmayures...@gmail.com> wrote:
>
> > Sure.
> >
> > Thanks,
> >
> > Mayuresh
> >
> > On Wed, Aug 23, 2017 at 5:07 PM, Jun Rao <j...@confluent.io> wrote:
> >
> >> Hi, Mayuresh,
> >>
> >> Since this KIP covers the requirement in KIP-111, could you review it
> too?
> >>
> >> Thanks,
> >>
> >> Jun
> >>
> >>
> >> On Tue, Aug 22, 2017 at 3:04 PM, Jason Gustafson <ja...@confluent.io>
> >> wrote:
> >>
> >>> Bump. I'll open a vote in a few days if there are no comments.
> >>>
> >>> Thanks,
> >>> Jason
> >>>
> >>> On Sat, Aug 19, 2017 at 12:28 AM, Ismael Juma <ism...@juma.me.uk>
> wrote:
> >>>
> >>> > Thanks for the KIP Jason. It seems reasonable and cleans up some
> >>> > inconsistencies in that area. It would be great to get some feedback
> >>> from
> >>> > Mayuresh and others who worked on KIP-111.
> >>> >
> >>> > Ismael
> >>> >
> >>> > On Thu, Aug 17, 2017 at 1:21 AM, Jason Gustafson <ja...@confluent.io
> >
> >>> > wrote:
> >>> >
> >>> > > Hi All,
> >>> > >
> >>> > > I've added a new KIP to improve and extend the principal building
> API
> >>> > that
> >>> > > Kafka exposes:
> >>> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> >>> > > 189%3A+Improve+principal+builder+interface+and+add+
> support+for+SASL
> >>> > > .
> >>> > >
> >>> > > As always, feedback is appreciated.
> >>> > >
> >>> > > Thanks,
> >>> > > Jason
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
> >
> > --
> > -Regards,
> > Mayuresh R. Gharat
> > (862) 250-7125
> >
>
>
>
> --
> -Regards,
> Mayuresh R. Gharat
> (862) 250-7125
>
