Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Date: Thu, 1 Sep 2016 18:58:20 +0000 (UTC)
From: "Alejandro Abdelnur (JIRA)" <jira@apache.org>
To: dev@kafka.apache.org
Message-ID: <JIRA.12936412.1454523612000.471892.1472756300687@Atlassian.JIRA>
In-Reply-To: <JIRA.12936412.1454523612000@Atlassian.JIRA>
References: <JIRA.12936412.1454523612000@Atlassian.JIRA> <JIRA.12936412.1454523612282@arcas>
Subject: [jira] [Commented] (KAFKA-3199) LoginManager should allow using an
 existing Subject
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 01 Sep 2016 18:58:23 -0000


    [ 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)