Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Received-SPF: pass (athena.apache.org: domain of brownjoe043@gmail.com
 designates 74.125.82.48 as permitted sender)
From: Joe Brown <brownjoe043@gmail.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_6D8D7AC3-A91A-4B02-B36D-746CD38FA056"
Message-Id: <C6DCCD8A-9A0D-4730-8B13-0F404CC853AA@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Simple Auth and Auth
Date: Thu, 23 Jan 2014 19:07:40 +0000
References: 
 <CAOeJiJjORd5cB4jJX2fjE-cQ3rx2NSaFOFZcbJ=iHKvxysR55g@mail.gmail.com>
To: dev@kafka.apache.org
In-Reply-To: 
 <CAOeJiJjORd5cB4jJX2fjE-cQ3rx2NSaFOFZcbJ=iHKvxysR55g@mail.gmail.com>

--Apple-Mail=_6D8D7AC3-A91A-4B02-B36D-746CD38FA056
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi All

I=92ve been looking at the wiki proposal to add Auth and Auth to kafka =
https://cwiki.apache.org/confluence/display/KAFKA/Security=20

In the meantime I=92ve 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=92s public certificate =
along with a message, signed by the client=92s 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.=20

The broker, to authenticate the client, first verifies the client=92s =
public certificate against the issuing CA certificate held in the broker =
truststore. The broker then uses the verified client=92s 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 =
=93auth.config.path=94 configured on the broker. On broker =
initialization the file is read, changes to this file will be reloaded =
at intervals defined by the =93auth.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=

--Apple-Mail=_6D8D7AC3-A91A-4B02-B36D-746CD38FA056--