...

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

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

...

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.

...

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

...