- All Implemented Interfaces:
- java.lang.reflect.InvocationHandler
public class AuthorizationProxy
extends java.lang.Object
implements java.lang.reflect.InvocationHandler
Provides a proxy interface to the platform's MBeanServer instance to perform
role-based authorization on method invocation.
When used in conjunction with a suitable JMXAuthenticator, which attaches a CassandraPrincipal
to authenticated Subjects, this class uses the configured IAuthorizer to verify that the
subject has the required permissions to execute methods on the MBeanServer and the MBeans it
manages.
Because an ObjectName may contain wildcards, meaning it represents a set of individual MBeans,
JMX resources don't fit well with the hierarchical approach modelled by other IResource
implementations and utilised by ClientState::ensurePermission etc. To enable grants to use
pattern-type ObjectNames, this class performs its own custom matching and filtering of resources
rather than pushing that down to the configured IAuthorizer. To that end, during authorization
it pulls back all permissions for the active subject, filtering them to retain only grants on
JMXResources. It then uses ObjectName::apply to assert whether the target MBeans are wholly
represented by the resources with permissions. This means that it cannot use the PermissionsCache
as IAuthorizer can, so it manages its own cache locally.
Methods are split into 2 categories; those which are to be invoked on the MBeanServer itself
and those which apply to MBean instances. Actually, this is somewhat of a construct as in fact
*all* invocations are performed on the MBeanServer instance, the distinction is made here on
those methods which take an ObjectName as their first argument and those which do not.
Invoking a method of the former type, e.g. MBeanServer::getAttribute(ObjectName name, String attribute),
implies that the caller is concerned with a specific MBean. Conversely, invoking a method such as
MBeanServer::getDomains is primarily a function of the MBeanServer itself. This class makes
such a distinction in order to identify which JMXResource the subject requires permissions on.
Certain operations are never allowed for users and these are recorded in a deny list so that we
can short circuit authorization process if one is attempted by a remote subject.