Geode Integrated Security

Integrated Security allows you to control the authentication/authorization of all Geode entities 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 Authenticator and 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, these 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

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

All Operations are enumerated via the enum 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

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

• 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