[jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication

["Sam Tunnicliffe (JIRA)" <ji...@apache.org>]

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

Sam Tunnicliffe commented on CASSANDRA-10091:
---------------------------------------------

[~Jan Karlsson] sorry it's been a while without any progress, but I've pushed a branch [here|https://github.com/beobal/cassandra/tree/10091-trunk] with another proposal for authz. In it, rather than push the JMX-specific stuff down into {{IAuthenticator}}, the JMX authenticator handles the pattern matching of {{ObjectName}}. It uses {{IAuthenticator::list}}, rather than {{IAuthenticator::authorize}}, so it essentially pulls back all grants for the given Subject, performing the necessary filtering on resource type and so on itself. The hierarchy of {{JMXResource}} becomes simpler again; just a root resource representing all beans (or more accurately, the {{MBeanServer}} and all of the beans it manages), then individual resources representing {{ObjectNames}}, which may or may not contain wildcards.

To get jconsole and jmc working, I set up the following initial permissions:

{code}
CREATE ROLE jmx WITH LOGIN = false;
GRANT SELECT ON ALL MBEANS TO jmx;
GRANT DESCRIBE ON ALL MBEANS TO jmx;
GRANT EXECUTE ON MBEAN 'java.lang:type=Threading' TO jmx;
GRANT EXECUTE ON MBEAN 'com.sun.management:type=HotSpotDiagnostic' TO jmx;

CREATE ROLE test WITH PASSWORD = 'test' AND LOGIN = true AND SUPERUSER = false;
GRANT jmx TO test;
{code}

Then to smoke test I added the following:
{code}
GRANT ALL PERMISSIONS ON MBEAN 'org.apache.cassandra.db:type=ColumnFamilies,keyspace=system_schema,columnfamily=keyspaces' TO test;
GRANT ALL PERMISSIONS ON MBEAN 'org.apache.cassandra.auth:type=PermissionsCache' TO test;
{code}

With those permissions, the {{test}} role was able to modify attributes and invoke operations on just the {{system_schema.keyspaces}} bean, without having additional privileges on any other column family bean (other than the {{SELECT}} and {{DESCRIBE}} inherited from {{jmx}}). Likewise, that role could update attributes and invoke {{invalidate}} on the {{PermissionsCache}} bean, but not the {{RolesCache}} equivalent.

The branch also includes a simplified version of {{JMXPasswordAuthenticator}}, it seems to work fine without {{CassandraLoginModule}}, but if I've overlooked something there let me know. 

I haven't yet added any tests, and {{JMXAuthorizer}} should cache the permissions it retrieves from {{IAuthorizer}}. The latter will probably involve some refactoring of the existing permissions & role caches, so I wanted to get feedback on the overall approach before starting that.


> Align JMX authentication with internal authentication
> -----------------------------------------------------
>
>                 Key: CASSANDRA-10091
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
>             Project: Cassandra
>          Issue Type: New Feature
>            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)