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. However, in order to authorize and secure JMX and GFSH operations, existing implementations will need to be modifiedYour 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

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

dsaas

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:

functionality is automatically activated when the Geode properties security-client-authenticator and security-client-accessor are set.

Permissions are designed to be noun-verby and are in the form of RESOURCE:OPERATION[:REGION] tuples. The following values are valid:

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

At the end of this document is a reference list of all JMX and GFSH operations with their corresponding permissions.

To quickly get started using permissions for JMX and GFSH a sample implementation of com.gemstone.gemfire.security.Authenticator and com.gemstone.gemfire.security.AccessControl is provided by the class com.gemstone.gemfire.security.templates.SampleJsonAuthorization. This implementation requires a JSON file which defines the allowed users and their corresponding permissions. For example:

{
  "roles": [
    {
      "name": "cluster",
      "operationsAllowed": [
        "CLUSTER:MANAGE",
        "CLUSTER:WRITE",
        "CLUSTER:READ"
      ]
    },
    {
      "name": "data",
      "operationsAllowed": [
        "DATA:MANAGE",
        "DATA:WRITE",
        "DATA:READ"
      ],
      "regions": ["region1", "region2"]
    }
  ]
  "users": [
    {
      "name": "super-user",
      "password": "1234567",
      "roles": [
        "cluster",
        "data"
      ]
    },
    {
      "name": "joebloggs",
      "password": "1234567",
      "roles": [
        "data"
      ]
    }
  ]
}

In this example we have two roles defined: cluster and data. The data role only has access to two regions: region1 and region2.

To start using this sample perform the following steps:

1. Using gfsh, start a locator with security activated.

   Code Block
   language bash
   gfsh> start locator --name=locator1 \ --J=-Dgemfire.security-client-authenticator=com.gemstone.gemfire.security.templates.SampleJsonAuthorization.create \ --J=-Dgemfire.security-client-accessor=com.gemstone.gemfire.security.templates.SampleJsonAuthorization.create

2. Similarly, start a server

   Code Block
   gfsh> start server --name=server1 --locators=localhost[10334]

3. Start a new instance of gfsh and connect with one of the users defined in your JSON file. The super-user should be allowed to do everything in gfsh.

   Code Block
   gfsh> connect --locators=localhost[10334] --user=super-user --password=1234567

4. Disconnect and reconnect with a user with lesser privileges:

   Code Block
   gfsh> disconnect gfsh> connect --locators=localhost[10334] --user=joebloggs --password=1234567 gfsh> stop server --name=server1 An error occurred while attempting to stop a Cache Server: Subject does not have permission [CLUSTER:READ]

Client-Server Security

You may notice that this new functionality is activated in the same way that the existing client-server authentication and authorization is activated. The intention is that eventually all means of accessing Geode will be secured with exactly the same callbacks.

If you already have an existing implementation of Authenticator and AccessControl no changes to existing code should be necessary. However, you should be aware of the following:

• 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:

  Code Block
  language java
  @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:

  Code Block
  language java
  @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.

...