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
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 n
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
Hi Jason,
Thanks for the replies.
I think it would be better to discuss with an example that we were trying
to address with KIP-111 and see if the current mentioned solution would
address it.
Let's consider a third party library called authz_lib that is provided by
some Security team at some co
Hi Mayuresh,
To clarify, the intention is to use the KafkaPrincipal object built by the
KafkaPrincipalBuilder inside the Session. So we would remove the logic to
construct a new KafkaPrincipal using only the name from the Principal. Then
it should be possible to pass the `AuthzPrincipal` to the un
Perfect.
As long as there is a way we can access the originally created Principal in
the Authorizer, it would solve the KIP-111 issue.
This is really helpful, thanks again.
Thanks,
Mayuresh
On Fri, Aug 25, 2017 at 3:13 PM, Jason Gustafson wrote:
> Hi Mayuresh,
>
> To clarify, the intention is
No problem. I'll add a note to the KIP to emphasize that we will use the
same object built by the KafkaPrincipalBuilder in the Session object passed
to the authorizer.
-Jason
On Fri, Aug 25, 2017 at 3:17 PM, Mayuresh Gharat wrote:
> Perfect.
> As long as there is a way we can access the origina
Jason
Do you anticipate any backward compatibility issues with existing custom
implementation of the authorization interface/plugins?
Thanks
Bosco
On 8/25/17, 3:22 PM, "Jason Gustafson" wrote:
No problem. I'll add a note to the KIP to emphasize that we will use the
same object built
Hi Don,
I don't think so. We are not making any changes to the Authorizer interface
itself. The KafkaPrincipal object does not change either, though we now
explicitly allow it to be extended. That means you have to exercise a
little caution when combining a custom PrincipalBuilder with a custom
Au
Jason, thanks for confirming that. Since there are existing custom plugins, we
might have to give enough time for them to start using the newer interface.
I quickly glanced over the KIP, it looks good. Here is one comment:
---
In the future, we may add support for groups to Kafka. This was b
Hey Don,
That is not actually part of the KIP. It was a (somewhat pedantic) example
used to illustrate how the kafka principal semantics could be applied to
authorizers which understood group-level ACLs. The key point is this:
although a principal is identified only by its type and name, the
Kafka
Jason, thanks for the clarification.
Bosco
On 8/25/17, 4:59 PM, "Jason Gustafson" wrote:
Hey Don,
That is not actually part of the KIP. It was a (somewhat pedantic) example
used to illustrate how the kafka principal semantics could be applied to
authorizers which understoo
Thanks all for the discussion. I'll begin a vote in the next couple days.
-Jason
On Fri, Aug 25, 2017 at 5:01 PM, Don Bosco Durai wrote:
> Jason, thanks for the clarification.
>
> Bosco
>
>
> On 8/25/17, 4:59 PM, "Jason Gustafson" wrote:
>
> Hey Don,
>
> That is not actually part of th
Thanks, Jason, this is a great improvement!
One minor nit. The current KafkaPrincipal#equals looks like this:
>@Override
>public boolean equals(Object o) {
>if (this == o) return true;
>if (!(o instanceof KafkaPrincipal)) return false;
>
>KafkaPrincipal that = (Ka
bq. change the check in equals() to be this.getClass().equals(other.
getClass())
I happened to have Effective Java on hand.
Please take a look at related discussion on page 39.
Josh later on mentioned Liskov substitution principle and a workaround
(favoring composition).
FYI
On Mon, Aug 28, 2
Hi Colin,
Thanks for the comments. Seems reasonable to provide a safer `equals` for
extensions. I don't think this needs to be part of the KIP, but I can add
it to my patch.
Moving `fromString` makes sense also. This method is technically already
part of the public API, which means we should prob
Thanks, Jason. +1 (non-binding)
Colin
On Tue, Aug 29, 2017, at 09:12, Jason Gustafson wrote:
> Hi Colin,
>
> Thanks for the comments. Seems reasonable to provide a safer `equals` for
> extensions. I don't think this needs to be part of the KIP, but I can add
> it to my patch.
>
> Moving `fromS
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 wrote:
> Hi All,
>
> I've added a new KIP to improve and
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 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
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 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
Sure.
Thanks,
Mayuresh
On Wed, Aug 23, 2017 at 5:07 PM, Jun Rao 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
> wrote:
>
>> Bump. I'll open a vote in a few days i
21 matches
Mail list logo
