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