[
https://issues.apache.org/jira/browse/KAFKA-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15456314#comment-15456314
]
Alejandro Abdelnur commented on KAFKA-3199:
-------------------------------------------
[~sriharsha], thanks for you quick reply.
Following why I think is relevant, not in form but in behavior. The proposed
patch does the following change:
{code}
private LoginManager(LoginType loginType, Map<String, ?> configs) throws
IOException, LoginException {
this.loginType = loginType;
String loginContext = loginType.contextName();
- login = new Login(loginContext, configs);
+
+ // Check for an existing Subject
+ AccessControlContext context = AccessController.getContext();
+ subject = context != null ? Subject.getSubject(context) : null;
+
+ // Otherwise try to login
+ if (subject == null || !JaasUtils.hasValidKerberosTicket(subject)) {
+ login = new Login(loginContext, configs);
+ login.startThreadIfNeeded();
+ subject = login.subject();
+ } else {
+ login = null;
+ }
this.serviceName = getServiceName(loginContext, configs);
- login.startThreadIfNeeded();
}
{code}
So, while the Kafka API does not receive a {{Subject}} as parameter, it will
obtain it from the current context, and if there is one it will use it. If the
subject was obtained from the context, Kafka client should not be responsible
for it s renewal and that is what the patch is doing.
> 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)
