Geode is introducing additional security features which allow finer grained control for JMX operations as well as GFSH commands. This page describes those changes and new functionality which has been introduced.

1. No changes for existing implementations of Authenticator and AccessControl for client-server security

The API for authentication and authorization has not changed. However, in order to authorize and secure JMX and GFSH operations, existing implementations will need to be modified.

2. Introduction of Resource and OperationCode

The notion of a permission in the form of a noun (Resource) and verb (OperationCode) is being introduced. This will typically be represented as a colon-separated tuple in the form of RESOURCE:OPERATION_CODE. In some cases, permissions are also applicable to regions; in such cases the permission would be in the form RESOURCE:OPERATION_CODE:REGION. Currently the following have been defined:

Resource

• CLUSTER
• DATA

Operation

• MANAGE
• READ
• WRITE
• CLOSE_CQ
• CONTAINS_KEY
• DESTROY
• EXECUTE_CQ
• EXECUTE_FUNCTION

• GET

• GET_DURABLE_CQS
• INVALIDATE
• KEY_SET

• PUT

• PUTALL

• QUERY

• REGION_CLEAR

• REGION_CREATE

• REGION_DESTROY

• REGISTER_INTEREST

• REMOVEALL

• STOP_CQ

• UNREGISTER_INTEREST

Operations in RED refer to existing client-server operations.

The Reference section, at the end of this page, details all permissions for Client-Server as well as JMX and CLI operations.

3. Expanded functionality for OperationContext

All Resources are enumerated via the enum OperationContext.Resource.

All OperationCodes are enumerated via the enum OperationContext.OperationCode.

All of the existing OperationContext.is* methods have been deprecated in favor of testing against the relevant enums.

The resource and operation code, for a given context, can be retrieved using OperationContext.getResource and OperationContext.getOperationCode respectively.

Existing code, implementing AccessControl, would have needed to check the type of the OperationContext as passed into the authorizeOperation method. This is still possible, however it will now be easier to achieve the same functionality by simply checking the Resource and OperationCode of the context. For example, existing code might have looked like this:

  @Override
  public boolean authorizeOperation(String regionName, OperationContext context) {
    if (context instanceof PutOperationContext) {
      // cast to PutOperationContext
    } else if (context instanceof QueryOperationContext) {
      // cast to QueryOperationContext
    } else {
      // Must be JMX or CLI
    }
    return false;
  }

Can now be changed to:

@Override
public boolean authorizeOperation(String regionName, OperationContext context) {
  switch (context.getOperationCode()) {
    case PUT:
      // cast to PutOperationContext
      break;
    case QUERY:
      // cast to QueryOperationContext
      break;
    case READ:
    case WRITE:
    case MANAGE:
      // Must be JMX or CLI - no need to cast; just use the 'context' as is
      break;
  }
  return false;
}

Note that any JMX or CLI contexts are not associated with a specific sub-type of OperationContext and can be handled without having to cast the context parameter.

All client-server operations are associated with a Resource of DATA.

Reference

Client-Server

Client-server permissions are associated with their respective OperationContexts as follows. Permissions appear as Resource:OperationCode tuples.

GFSH and JMX

Following are lists for gfsh commands, (highlighted in green), and JMX operations with their corresponding permissions. Permissions appear as Resource:OperationCode tuples.

Entries with a green background are gfsh commands; the others are JMX operations.

• Page:
  Releasing Apache Geode
• Page:
  Running a Geode cluster in docker
• Page:
  Adding REST Cluster Management Operations
• Page:
  Creating a persistent cache service
• Page:
  Publishing Geode Metrics to External Monitoring Systems