No it’s not based on sasl - will upload to a jira ticket and let you know
Cheers Joe On 24 Jan 2014, at 16:27, Jun Rao <jun...@gmail.com> wrote: > Joe, > > Thanks for looking into this. We do plan to support security. However, > timing-wise, this probably has to be done after the client rewrites, which > changes how the client uses sockets and potentially adds new request types. > Our current estimate is that the producer rewrite will take probably about > 2 months to complete and consumer rewrite will take another 2-3 months > after that. > > Is your implementation based on sasl? Perhaps you can at least upload your > patch to a jira so that we can take a look? > > Thanks, > > Jun > > > > On Fri, Jan 24, 2014 at 7:56 AM, Joe Brown <brownjoe...@gmail.com> wrote: > >> Hi All >> >> I’ve been looking at the wiki proposal to add Auth and Auth to kafka >> https://cwiki.apache.org/confluence/display/KAFKA/Security >> >> In the meantime I’ve had a recent immediate requirement to implement >> something similar - my solution is detailed below - fairly quick and dirty >> but achieved the desired results. At the moment the code is branched off >> the 0.8-beta - though to move to 0.8.0 is trivial - the question is when >> will the https://cwiki.apache.org/confluence/display/KAFKA/Security be >> looked at, if this is a ways off then I could consider creating a patch and >> pull request for my code. >> >> FYI my requirements were very specific - for example no encryption of the >> data, changes minimised - easy to re-apply to future releases. >> Authentication >> >> Authentication is achieved by passing the client’s public certificate >> along with a message, signed by the client’s private key, every time the >> client opens a connection to a broker. The underlying Apache Kafka >> BlockingChannel was altered to ensure the connection is only established on >> a successful authentication response from the broker. >> >> The broker, to authenticate the client, first verifies the client’s public >> certificate against the issuing CA certificate held in the broker >> truststore. The broker then uses the verified client’s certificate to >> verify the signed message from the client. On authentication by the broker >> the successful authentication response is sent to the client. The client DN >> is then registered against the client connection as trusted by the broker. >> >> - Use of standard java.security.* and java.security.cert.* classes were >> used for Authentication >> Authorization >> >> Authorization is controlled by the file referenced by the property >> “auth.config.path” configured on the broker. On broker initialization the >> file is read, changes to this file will be reloaded at intervals defined by >> the “auth.file.watch.seconds" property. >> >> Both Producer (produce) and Consumer (fetch) Requests are intercepted on >> the broker to check whether the client connection is authenticated and then >> whether the associated client DN has the permission to read (fetch) or >> write (produce) from/to the given topic. >> >> - Uses simple json config file for authorization >> >> Thoughts please? >> >> Cheers >> >> Joe
