kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mayuresh Gharat <gharatmayures...@gmail.com>
Subject KAFKA-3722 : Discussion about custom PrincipalBuilder and Authorizer configs
Date Sat, 21 May 2016 00:00:44 GMT
Hi All,

I came across an issue with plugging in a custom PrincipalBuilder class
using the config "principal.builder.class" along with a custom Authorizer
class using the config "authorizer.class.name".

Consider the following scenario :

For PlainText we don't supply any PrincipalBuilder. For SSL we want to
supply a PrincipalBuilder using the property "principal.builder.class".

a) Now consider we have a broker running on these 2 ports and supply that
custom principalBuilder class using that config.

b) The interbroker communication is using PlainText. I am using a single
broker cluster for testing.

c) Now we issue a produce request on the SSL port of the broker.

d) The controller tries to build a channel for plaintext with this broker
for the new topic instructions.

e) PlainText tries to use the principal builder specified in the
"principal.builder.class" config which was meant only for SSL port since
the code path is same "ChannelBuilders.createPrincipalBuilder(configs)".

f) In the custom principal Builder if we are trying to do some cert checks
or down conversion of transportLayer to SSLTransportLayer so that we can
use its functionality we get error/exception at runtime.

The basic idea is the PlainText channel should not be using the
PrincipalBuilder meant for other types of channels.

Now there are few options/workarounds to avoid this :

1) Do instanceOf check in Authorizer.authorize() on TransportLayer instance
passed in and do the correct handling. This is not intuitive and imposes a
strict coding rule on the programmer.

2) TransportLayer should expose an API for telling the security protocol
type. This is not too intuitive either.

3) Add extra configs for Authorizer and PrincipalBuilder for each channel
type. This gives us a flexibility for the PrincipalBuilder and Authorizer
handle requests on different types of ports in a different way.

4) PrincipalBuilder.buildPrincipal() should take in extra parameter for the
type of protocol and we should document this in javadoc to use it to handle
the type of request. This is little better than 1) and 2) but again imposes
a strict coding rule on the programmer.

Just wanted to know what the community thinks about this and get any
suggestions/feedback . There's some discussion about this here :



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message