[
https://issues.apache.org/jira/browse/KAFKA-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131607#comment-15131607
]
Adam Kunicki commented on KAFKA-3199:
-------------------------------------
The contract would then become such that if a Subject already exists, Kafka has
to assume any required credentials are already present and would potentially
ignore what was specified in the kafka_client_jaas.conf
If you're OK with this then I believe it's safe.
But having another configuration, if present, we no longer have to make
assumptions about the user's intent. (Use existing credentials, or use the
settings found in kafka_client_jaas.conf (ignoring the existing credentials).
I'll open a pull request with a working example (without additional config
param)
> LoginManager should allow using an existing Subject
> ---------------------------------------------------
>
> Key: KAFKA-3199
> URL: https://issues.apache.org/jira/browse/KAFKA-3199
> Project: Kafka
> Issue Type: Improvement
> Components: security
> Affects Versions: 0.9.0.0
> Reporter: Adam Kunicki
> Assignee: Adam Kunicki
> Priority: Critical
>
> LoginManager currently creates a new Login in the constructor which then
> performs a login and starts a ticket renewal thread. The problem here is that
> because Kafka performs its own login, it doesn't offer the ability to re-use
> an existing subject that's already managed by the client application.
> The goal of LoginManager appears to be to be able to return a valid Subject.
> It would be a simple fix to have LoginManager.acquireLoginManager() check for
> a new config e.g. kerberos.use.existing.subject.
> This would instead of creating a new Login in the constructor simply call
> Subject.getSubject(AccessController.getContext()); to use the already logged
> in Subject.
> This is also doable without introducing a new configuration and simply
> checking if there is already a valid Subject available, but I think it may be
> preferable to require that users explicitly request this behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
