Geode Integrated Security

Geode is introducing a security features which allow you to control authentication/authorization on all aspects of Geode in one implementation. When Integrated Security is turned on, all client/server communications, peer to peer, gateway authentication, jmx operations, gfsh commands and Pulse are all protected with this security mechanism.

1. No changes for existing implementations of Authentication/Authorization for client-server security

The API for Authenticator and AccessControl has not changed. Your implementation 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, your will need to start your server/locator with this line in your gemfire.properties file:

security-manager = com.abc.security.MySecurityManager

It is a class implementing the SecurityManager interface. Make sure your class has a zero argument constructor so that we can call to create the object. SecurityManger is the new interface you will need to implement for both authentication and authorization. See SecurityManger javadoc for details. You can use SampleSecurityManager as an example to write your own implementation.

mention the gfsh commands to start locator/server with security

3. Introduction of GeodePermission

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

GeodePermission is in one of those forms:

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

All Resources are enumerated via the enum GeodePermission.Resource, which are "CLUSTER" and "DATA".

All Operations are enumerated via the enum GeodePermission.Operation, which are "MANAGE", "READ" and "WRITE". Note "MANAGE" does not imply "WRITE", nor "WRITE" implies "READ" either.

RegionName and Key are provided for region key access as well.

For example, you can see a GeodePermission defined as "CLUSTER:READ", "CLUSTER:MANAGE", "DATDA:READ", "DATA:READ:regionA", or "DATA:READ:regionA:key1".

Note GeodePermission is hierarchical. If you have permission for "DATA:READ", you automatically have data read permission on all regions and all keys, i.e. you have permission for "DATA:READ:regionA". If you have permission for "DATA:READ:regionA", you automatically have data read permission on all keys in regionA, i.e, you have permission for "DATA:READ:regionA:key1".

4. Operations and their corresponding GeodePermission

5. PostProcessor

Client-Server

region.registerInterestRegex

region.unRegisterInterestRegex

region.unRegisterInterestList

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.

• 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