...

2. Introduction of security-manager configuration and SecurityManager interface for the new Integrated Security

3. Introduction of GeodePermission

The notion of a permission in the form of a noun (Resource) and verb (Operation) is being introduced.

This will typically be represented as a colon-separated tuple in the form of RESOURCE:OPERATION. In some cases, permissions are also applicable to regions; in such cases the permission would be in the form RESOURCE:OPERATION: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

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.create

It is a static creation method returning an SecurityManager object. SecurityManger is the new interface you will need to impelement for both authentication and authorization. See SecurityManger javadoc for details.

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 OperationContextGeodePermission.Resource, which are "CLUSTER" and "DATA".

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 authorize(Principal principal, GeodePermission permission) {
  Resource resource = permission.getResource();
  Operation operation = permission.getOperation();
  if(principalHasAccessToPerformGivenOperationOnGivenResource() {
    return true;
  }
  return false;
}

...

enum GeodePermission.Operation, which are "MANAGE", "READ" and "WRITE".

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

Client-Server

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.

...

The Data Browser page requires the permissions CLUSTER:READ and  and DATA:READ. Access to all other pages requires only CLUSTER:READ permission 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.

...