Hi all, KIP-430 proposed an new method to the Scala `Authorizer` trait with a default implementation so that existing implementations continue to work. But Scala 2.11 doesn't convert the default implementation in a trait to a default implementation in Java. So this breaks existing Java authorizer implementations when building with Scala 2.11 version of core. Due to this, we are dropping the Authorizer API related changes.
Thanks to Rajini for noticing this. Updated the KIP <https://cwiki.apache.org/confluence/display/KAFKA/KIP-430+-+Return+Authorized+Operations+in+Describe+Responses#KIP-430-ReturnAuthorizedOperationsinDescribeResponses-ChangesdroppedfromtheProposal> . Please let us know if any concerns. Thanks, Manikumar On Thu, Feb 28, 2019 at 10:00 AM Manikumar <manikumar.re...@gmail.com> wrote: > Hi All, > > While implementing KIP-430, we have added supportedOperations() method to > kafka.security.auth.ResourceType public API. > This will be used to maintain supported operations for a resourceType. > Updated the KIP > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-430+-+Return+Authorized+Operations+in+Describe+Responses#KIP-430-ReturnAuthorizedOperationsinDescribeResponses-ResourceTypeAPIChanges> > with the new method details. > Please take a note of this. > > Thanks, > Manikumar > > On Wed, Feb 20, 2019 at 6:42 PM Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > >> If there are no other concerns or suggestions, I will start vote on this >> KIP later today. >> >> Thanks, >> >> Rajini >> >> On Mon, Feb 18, 2019 at 10:09 AM Rajini Sivaram <rajinisiva...@gmail.com> >> wrote: >> >> > Hi Magnus, >> > >> > Have your concerns been addressed in the KIP? >> > >> > Thanks, >> > >> > Rajini >> > >> > On Wed, Feb 13, 2019 at 3:33 PM Satish Duggana < >> satish.dugg...@gmail.com> >> > wrote: >> > >> >> Hi Rajini, >> >> That makes sense, thanks for the clarification. >> >> >> >> Satish. >> >> >> >> On Wed, Feb 13, 2019 at 7:30 PM Rajini Sivaram < >> rajinisiva...@gmail.com> >> >> wrote: >> >> > >> >> > Thanks for the reviews! >> >> > >> >> > Hi Satish, >> >> > >> >> > The authorised operations returned will use the same values as the >> >> > operations returned by the existing DescribeAclsResponse. AdminClient >> >> will >> >> > return these using the existing enum AclOperation. >> >> > >> >> > Hi Magnus, >> >> > >> >> > The MetadataResponse contains these two lines: >> >> > >> >> > - Metadata Response => throttle_time_ms [brokers] cluster_id >> >> > controller_id [topic_metadata] [authorized_operations] <== ADDED >> >> > authorized_operations >> >> > - topic_metadata => error_code topic is_internal >> [partition_metadata] >> >> > [authorized_operations] <== ADDED authorized_operations >> >> > >> >> > The first is for the cluster's authorized operations and the second >> for >> >> > each topic. Did I misunderstand your question? The full set of >> >> operations >> >> > for each resource type is included in the subsection `AdminClient API >> >> > Changes`. >> >> > >> >> > Under `Rejected Alternatives` I have included addition of a separate >> >> > request to get this information rather than extend an existing one. >> The >> >> > rationale for including all the information in one request is to >> enable >> >> > clients to get all relevant metadata using a single API rather than >> >> have to >> >> > send multiple requests, get responses and combine the two while >> >> resource or >> >> > ACLs may have changed in between. It seems neater to use a single API >> >> since >> >> > a user getting authorized operations is almost definitely going to >> do a >> >> > Describe first and access control for both of these is controlled >> using >> >> > Describe access. If we add new resource types with a corresponding >> >> > Describe, we would simply need to add `authorized_operations` for >> their >> >> > Describe. >> >> > >> >> > Hi Manikumar, >> >> > >> >> > Added IdempotentWrite for Cluster, thanks for pointing that out! I >> was >> >> > thinking that if authorizer is not configured, we could return all >> >> > supported operations since the user can perform all operations. >> Added a >> >> > note to the KIP. >> >> > >> >> > Regards, >> >> > >> >> > Rajini >> >> > >> >> > >> >> > >> >> > On Wed, Feb 13, 2019 at 11:07 AM Manikumar < >> manikumar.re...@gmail.com> >> >> > wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > Thanks for the KIP. >> >> > > >> >> > > 1. Can't we include IdempotentWrite/ClusterResource Operations for >> >> Cluster >> >> > > resource. >> >> > > 2. What will be the API behaviour when the authorizer is not >> >> configured?. I >> >> > > assume we return empty list. >> >> > > >> >> > > Thanks, >> >> > > Manikumar >> >> > > >> >> > > On Wed, Feb 13, 2019 at 12:33 AM Rajini Sivaram < >> >> rajinisiva...@gmail.com> >> >> > > wrote: >> >> > > >> >> > > > Hi all, >> >> > > > >> >> > > > I have created a KIP to optionally request authorised operations >> on >> >> > > > resources when describing resources: >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-430+-+Return+Authorized+Operations+in+Describe+Responses >> >> > > > >> >> > > > This includes only information that users with Describe access >> can >> >> obtain >> >> > > > using other means and hence is consistent with our security >> model. >> >> It is >> >> > > > intended to made it easier for clients to obtain this >> information. >> >> > > > >> >> > > > Feedback and suggestions welcome. >> >> > > > >> >> > > > Thank you, >> >> > > > >> >> > > > Rajini >> >> > > > >> >> > > >> >> >> > >> >
