[
https://issues.apache.org/jira/browse/KAFKA-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969096#comment-14969096
]
Ismael Juma commented on KAFKA-2675:
------------------------------------
Some input would be appreciated on the following:
1. Decide on `serviceName` configuration: do we want to keep it in two places?
This is the only config we are storing in 2 places (all the other ones are
either in the Kafka config or the JAAS file). We need to have it in the Kafka
config because the IBM JDK fails if it sees this property in the JAAS file.
Given this, I think we need strong justification to support setting this in the
JAAS file. [~harsha_ch], you said that the reason to have it in the JAAS file
is that many other projects do that. Do you have a reference for the projects
that do it?
2. auth.to.local config name is a bit opaque, is there a better one?
The full config name is kafka.security.auth.to.local, and it's similar to the
Hadoop system property:
http://www.cloudera.com/content/www/en-us/documentation/archive/cdh/4-x/4-3-1/CDH4-Security-Guide/cdh4sg_topic_19.html
Other options that I can think of could be:
principal.to.local
principal.to.local.rules
auth.to.local.rules
A reason to have `rules` in the name is that we could support the definition of
a class to do the mapping in the future. Hortonworks supports this via a
`principal.to.local.class` property:
http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_secure-kafka-ambari/content/ch_secure-kafka-config-options.html
3. Implement or remove SASL_KAFKA_SERVER_REALM config
This config is not used at the moment. The documentation says "Default will be
from kafka jaas config". Maybe we can remove it then? [~harsha_ch], your input
is appreciated.
4. Consider making Login's thread a daemon thread
Rajini asked if this should be a daemon thread. It was a daemon thread to start
with, but [~junrao] suggested that it perhaps should be non-daemon because we
wait for it during shutdown. [~rsivaram]'s concern is that we may prevent
clients from exiting normally. This won't happen if `KafkaConsumer.close()` is
called, but it can happen if `close()` is not called. It seems like making it a
daemon thread is the safest option. What do you think [~junrao]?
It would be very helpful to get your feedback so that we can wrap the
SASL/Kerberos feature.
> SASL/Kerberos follow-up
> -----------------------
>
> Key: KAFKA-2675
> URL: https://issues.apache.org/jira/browse/KAFKA-2675
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Reporter: Ismael Juma
> Assignee: Ismael Juma
> Fix For: 0.9.0.0
>
>
> This is a follow-up to KAFKA-1686.
> 1. Decide on `serviceName` configuration: do we want to keep it in two places?
> 2. auth.to.local config name is a bit opaque, is there a better one?
> 3. Implement or remove SASL_KAFKA_SERVER_REALM config
> 4. Consider making Login's thread a daemon thread
> 5. Write test that shows authentication failure due to invalid user
> 6. Write test that shows authentication failure due to wrong password
> 7. Write test that shows authentication failure due ticket expiring
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
