kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ismael Juma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KAFKA-4454) Authorizer should also include the Principal generated by the PrincipalBuilder.
Date Fri, 02 Dec 2016 10:21:58 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15714715#comment-15714715
] 

Ismael Juma edited comment on KAFKA-4454 at 12/2/16 10:21 AM:
--------------------------------------------------------------

Yes, I understand that we can simply add a field to `KafkaPrincipal` without the `SimplePrincipal`
changes. It's just that it accentuates the differences between authentication and authorization.
For the former case, `getName` has to include all the information as that is what gets sent
over the wire.

On the other hand, for authorization, one could use other fields as the authorizer implementation
is in the same process as the broker and can potentially access other fields. The way to solve
your issue today would be to add the additional information to the `getName` String and then
parse it, which I agree is not nice. So, I would be fine with giving access to the underlying
principal.

[~junrao], does that make sense to you? You have more context on the original thinking regarding
`KafkaPrincipal`.


was (Author: ijuma):
Yes, I understand that we can simply add a field to `KafkaPrincipal` without the `SimplePrincipal`
changes. It's just that it accentuates the differences between authentication and authorization.
For the former case, `getName` has to include all the information as that is what gets sent
over the wire.

On the other hand, for authorization, one could use other fields as the authorizer implementation
is in the same process as the broker and can potentially access other fields. The way to solve
your issue today would be to add the additional information to the `getName` String and then
parse it, which I agree is not nice. So, I would be fine with giving access to the underlying
principal.

[~junrao], does that make sense to you? You have more context on the original thinking for
`KafkaPrincipal`.

> Authorizer should also include the Principal generated by the PrincipalBuilder.
> -------------------------------------------------------------------------------
>
>                 Key: KAFKA-4454
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4454
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 0.10.0.1
>            Reporter: Mayuresh Gharat
>            Assignee: Mayuresh Gharat
>             Fix For: 0.10.2.0
>
>
> Currently kafka allows users to plugin a custom PrincipalBuilder and a custom Authorizer.
> The Authorizer.authorize() object takes in a Session object that wraps KafkaPrincipal
and InetAddress.
> The KafkaPrincipal currently has a PrincipalType and Principal name, which is the name
of Principal generated by the PrincipalBuilder. 
> This Principal, generated by the pluggedin PrincipalBuilder might have other fields that
might be required by the pluggedin Authorizer but currently we loose this information since
we only extract the name of Principal while creating KaflkaPrincipal in SocketServer.  
> It would be great if KafkaPrincipal has an additional field "channelPrincipal" which
is used to store the Principal generated by the plugged in PrincipalBuilder.
> The pluggedin Authorizer can then use this "channelPrincipal" to do authorization.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message