cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication
Date Tue, 13 Oct 2015 11:28:05 GMT


Sam Tunnicliffe commented on CASSANDRA-10091:

Thanks for the patch, I think this will make a great feature provided we can figure out a
few issues. Please excuse the wall of text coming up...

My main concern from the authn side of things is the use of {{IAuthenticator::legacyAuthenticate}}.
While this works fine for {{PasswordAuthenticator}}, the method is optional and only really
intended to support legacy Thrift authentication (the fact that {{PasswordAuthenticator}}
uses it internally during CQL authentication is an implementation detail). The preferred method
for authentication is through SASL, which allows a wider variety of backends to be plugged
in. I know that in the wild there are custom implementations which use this mechanism to do
stuff like Kerberos authentication and clusters using those authenticators wouldn't be able
to make use of this functionality (or at least I can't see how they could as it stands). It
would be ideal if we could have {{JMXAuthenticator}} plug into the SASL auth code and make
use of {{IAuthenticator::newSaslAuthenticator}}. 

I'd like to investigate further, but it looks like this could be possible using [JMXMP|].
We could switch the connection to JMXMP if configured with advanced JMX auth and I think it
should be possible to then define a custom {{SaslServer}} which wraps a {{SaslNegotiator}}
instance provided by the configured {{IAuthenticator}}. Note that I haven't actually *tried*
to do this, but reading [the JMXMP docs|],
particularly section *11.4.2 SASL Provider*, it seems feasible.

On the authz side, I also have a couple of remarks/suggestions.

I'm not a big fan of adding {{IAuthorizer::authorizeJMX}}. One reason is that it's going to
require all custom implementations to add a new method before upgrading (even though implementors
could make that a no-op and require that users don't enable JMX authz). More generally though,
it feels bad to special case JMX resources in this this way, and I wouldn't want to set a
precedent of adding a special authentication method for a particular resource type, I'd rather
think some more about how the resources are modelled and whether that can be changed to fit
what's already there bit better. I think the fundamental issue with {{JMXResource}} is that
JMX {{ObjectName}}s are not really hierarchical, but pattern based. For example, with {{DataResource}}s,
we're able to grant permissions on a particular keyspace and have those apply automatically
to all tables in the keyspace. I don't think that kind of hierarchy can be modelled using
{{ObjectName}}. On the surface, it seems like something it should be possible by granting
perms on {{org.apache.cassandra.db:type=ColumnFamilies,keyspace=<keyspace>,columnfamily=*}},
but the equally valid mbean name {{org.apache.cassandra.db:type=ColumnFamilies,keyspace=*,columnfamily=<table>}}
clearly sits outside the hierarchy, and necessitates the special handling of wildcards &
patterns which in turn requires {{IAuthorizer::authorizeJMX}}.

I propose a simplification to {{JMXResource}} to allow only fully qualified bean names, with
no support for wildcards or pattern matching. I would introduce a level representing the domain
into the hierarchy, so that permissions can be applied at that level, or for specific beans.
So the hierarchy would be {{ROOT/DOMAIN/MBEAN}} where {{MBEAN}} would represent a full set
of key/value pairs. The constructor of {{JMXResource}} should canonicalise the key/value pairs
in a way consistent with {{ObjectName::getCanonicalKeyPropertyListString}} so that authorizers
can do a simple lexical comparision. So the some example mappings between an MBean and the
corresponding {{JMXResource}} would look like:

||MBean ObjectName||JMXResource||
|java.lang:name=G1 Old Gen,type=MemoryPool|mbeans/java.lang/name=G1 Old Gen,type=MemoryPool|

On a related note, it also feels wrong to special case permissions on JMX resources. I'd much
prefer it if we could re-use the existing permissions, which I think we probably can do. It
seems as though the proposed new permissions in the patch actually map pretty well to existing

||Proposed MB permssion||Existing permission||

I wouldn't bother with the meta-permissions {{MBREAD}} and {{MBWRITE}} as their existing equivalents
are already deprecated. 

If the consensus is that the semantics of the MBean operations really don't match the existing
permission then it would be better to figure out what it is generically that's missing and
add new permissions to express that, one which should be re-usable for future, non-JMX resource

> Align JMX authentication with internal authentication
> -----------------------------------------------------
>                 Key: CASSANDRA-10091
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jan Karlsson
>            Assignee: Jan Karlsson
>            Priority: Minor
> 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
> 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

View raw message