Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 13 Oct 2015 14:36:05 +0000 (UTC)
From: "Jan Karlsson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12856608.1439816261000.24659.1444746965331@Atlassian.JIRA>
In-Reply-To: <JIRA.12856608.1439816261000@Atlassian.JIRA>
References: <JIRA.12856608.1439816261000@Atlassian.JIRA>
 <JIRA.12856608.1439816261379@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-10091) Align JMX authentication
 with internal authentication
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955032#comment-14955032 ] 

Jan Karlsson edited comment on CASSANDRA-10091 at 10/13/15 2:35 PM:
--------------------------------------------------------------------

Great points. Thank you for taking the time to review this.

First of all, I agree completely on the use of {{IAuthenticator::legacyAuthenticate}}. Originally this patch was against 2.1 and I only recently forward ported it. I just wanted to get it out so we can commence with the discussion. I agree that we will have to make use of the {{IAuthenticator::newSaslAuthenticator}} and we should Investigate further.

Also great points on {{IAuthorizer::authorizeJMX}}. While I see the merit in your points on the subject. I cannot stress the importance of wildcards. It seemed like an unpleasant experience to go through countless permissions and apply them one at a time. I know this is somehow lessened by the fact that you will only do this once per role, which can then be assigned to different users. However calling a simple command like {{nodetool status}} will require 4~ different permissions under the hood while starting Jconsole can only be done by adding 10~ different permissions.

Simplifying the {{JMXResource}} might be the way to go but we should consider how much freedom we will lose from doing this. I was actually debating this very thing when I implemented it. Should I have only meta permission, should I expose all permissions or both? I settled on doing both to cater to every use case.

The problem is that the mapping between nodetool commands and permissions is somewhat confusing. For instance in your remapping proposal. One would have to give SELECT, DESCRIBE and EXECUTE to be able to get all information out of {{nodetool info}}. Not something one would expect from such a command. This is why these meta-permissions were born.

It is simpler to give {{MBREAD}} to a user, then to give {{MBGET|MBINSTANCEOF|MBQUERYNAMES}}. With this solution, both variants are possible. Furthermore giving only MBGET or MBINSTANCEOF is also an option, if you happen to have such a use case. One could argue that this might be an uncommon use case, but I have a hard time ruling it out.

 However if the consensus is that we should simplify it, which does have it's advantages, then I agree with your proposal.


was (Author: jan karlsson):
Great points. Thank you for taking the time to review this.

First of all, I agree completely on the use of {{IAuthenticator::legacyAuthenticate}}. Originally this patch was against 2.1 and I only recently forward ported it. I just wanted to get it out so we can commence with the discussion. I agree that we will have to make use of the {{IAuthenticator::newSaslAuthenticator}} and we should Investigate further.

Also great points on {{IAuthorizer::authorizeJMX}}. While I see the merit in your points on the subject. I cannot stress the importance of wildcards. It seemed like an unpleasant experience to go through countless permissions and apply them one at a time. I know this is somehow lessened by the fact that you will only do this once per role, which can then be assigned to different users. However calling a simple command like {{nodetool status}} will require 4~ different JMXResources under the hood. 

Simplifying the {{JMXResource}} might be the way to go but we should consider how much freedom we will lose from doing this. I was actually debating this very thing when I implemented it. Should I have only meta permission, should I expose all permissions or both? I settled on doing both to cater to every use case.

The problem is that the mapping between nodetool commands and permissions is somewhat confusing. For instance in your remapping proposal. One would have to give SELECT, DESCRIBE and EXECUTE to be able to get all information out of {{nodetool info}}. Not something one would expect from such a command. This is why these meta-permissions were born.

It is simpler to give {{MBREAD}} to a user, then to give {{MBGET|MBINSTANCEOF|MBQUERYNAMES}}. With this solution, both variants are possible. Furthermore giving only MBGET or MBINSTANCEOF is also an option, if you happen to have such a use case. One could argue that this might be an uncommon use case, but I have a hard time ruling it out.

 However if the consensus is that we should simplify it, which does have it's advantages, then I agree with your proposal.

> Align JMX authentication with internal authentication
> -----------------------------------------------------
>
>                 Key: CASSANDRA-10091
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jan Karlsson
>            Assignee: Jan Karlsson
>            Priority: Minor
>             Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal authentication. This would reduce the overhead of keeping passwords in files on the machine and would consolidate passwords to one location. It would also allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes for the authenticator and authorizer. We could then add some parameters where the user could specify what authenticator and authorizer to use in case they want to make their own.
> This could also be done by creating a premain method which creates a jmx server. This would give us the feature without changing the Cassandra code itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a custom authenticator and authorizer. It is currently build as a premain, however it would be great if we could put this in Cassandra instead.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)