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