Integrated Security allows you to control the authentication/authorization of all 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 introducedentities within one implementation. When Integrated Security is turned on, all client/server communications, peer to peer, gateway authentication, jmx operations, gfsh commands and Pulse are protected with this single security mechanism.

1. No changes for

...

legacy implementations of Authentication/Authorization for client-server security

The API for authentication Authenticator and authorization AccessControl has not changed. Your implementations of those are still honored in client/server communication if you choose not to implement the new security interface. However, in order to authorize and secure JMX and GFSH operations, existing implementations will need to be modifiedthese two are deprecated now and will be removed in the future.

2. Introduction

...

of security-manager configuration and SecurityManager interface for Integrated Security

To turn on integrated security, start your servers/locators with the security-manager property set in your gemfire.properties file:

security-manager = com.example.security.MySecurityManager

The security-manager property identifies the class name of the SecurityManager interface implementation. SecurityManager is the interface you implement for both authentication and authorization. Make sure your class has a zero argument constructor so that Geode can instantiate the object. See the SecurityManager javadoc for details. There is an ExampleSecurityManager in the geode-core/src/main/java/org/apache/geode/examples/security directory that you can use as an example to write your own implementation.

3. Introduction of ResourcePermission

In SecurityManager, you will see that a ResourcePermission is passed in the authorization call. ResourcePermission is an object that defines the nature of the operation the Principal is trying to perform.

ResourcePermission is in one of those forms:

Resource:Operation
Resource:Operation:RegionName
Resource:Operation:RegionName:Key

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.

...

All Resources are enumerated via the enum OperationContextResourcePermission.Resource, currently CLUSTER and DATA.

All OperationCodes Operations 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;
}

...

ResourcePermission.Operation, which are MANAGE, READ, and WRITE. Note that MANAGE does not imply WRITE, and WRITE does not imply READ.

RegionName and Key are provided for those operations that are to be authorized based upon a region key access as well. For example, you can see a ResourcePermission defined as CLUSTER:READ, CLUSTER:MANAGE, DATA:READ, DATA:READ:regionA, or DATA:READ:regionA:key1.

Note that a ResourcePermission is hierarchical. If a principal has permission for DATA:READ, it automatically has data read permission on all regions and all keys. That is, it has permission for DATA:READ:regionA. Given permission for DATA:READ:regionA, the principal automatically has data read permission on all keys in regionA. That is, it has permission for DATA:READ:regionA:key1.

4. Introduction of PostProcessor

Before a value is returned, it gets a pass through the post processor, if there is one. Specify your post processor with this line in your gemfire.properties file:

security-post-processor = com.example.security.MyPostProcessor

where the value is the name of the class that implements the PostProcessor interface. Make sure your class has a zero argument constructor so that Geode can instantiate the object. See the PostProcessor javadoc for details. You can use SamplePostProcessor as an example to write your own implementation.

Note regarding legacy implementations: We completely redo the way we call post processing; the interface is a lot simpler.

5. Operations and their corresponding ResourcePermission

Below is the list of operations with their corresponding ResourcePermission:

Client-Server Operations

GFSH Commands

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.

Pulse

Pulse access is divided into two main categories, namely access to the Data Browser page and everything else.

The Data Browser page requires the permissions CLUSTER:READ and DATA:READ. Access to all other pages requires only CLUSTER:READ permission.

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.

alter jdbc-connection

alter jdbc-mapping

create jdbc-connection

create jdbc-mapping

describe jdbc-connection

describe jdbc-mapping

destroy jdbc-connection

destroy jdbc-mapping

list jdbc-connections

list jdbc-mappings

create jndi-binding

describe jndi-binding

destroy jndi-binding

list jndi-binding

Pulse

Pulse access is divided into two main categories: access to the Data Browser page and everything else.

The Data Browser page requires the permissions CLUSTER:READ and DATA:READ. Access to all other pages requires only CLUSTER:READ permission.

JMX Operations

...