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 introduced.
- 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
andOperationContext.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
At the end of this document is a reference list of all JMX and GFSH operations with their corresponding permissions.
...
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
Similarly, start a server
Code Block gfsh> start server --name=server1 --locators=localhost[10334]
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
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
andOperationContext.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.
OperationContext | Permission |
---|---|
CloseCQOperationContext | DATA:CLOSE_CQ |
ContainsKeyOperationContext | DATA:CONTAINS_KEY |
DestroyOperationContext | DATA:DESTROY |
ExecuteCQOperationContext | DATA:EXECUTE_CQ |
ExecuteFunctionOperationContext | DATA:EXECUTE_FUNCTION |
GetDurableCQsOperationContext | DATA:GET_DURABLE_CQS |
GetOperationContext | DATA:GET |
InvalidateOperationContext | DATA:INVALIDATE |
KeySetOperationContext | DATA:KEY_SET |
PutAllOperationContext | DATA:PUTALL |
PutOperationContext | DATA:PUT |
QueryOperationContext | DATA:QUERY |
RegionClearOperationContext | DATA:REGION_CLEAR |
RegionCreateOperationContext | DATA:REGION_CREATE |
RegionDestroyOperationContext | DATA:REGION_DESTROY |
RegisterInterestOperationContext | DATA:REGISTER_INTEREST |
RemoveAllOperationContext | DATA:REMOVEALL |
StopCQOperationContext | DATA:STOP_CQ |
UnregisterInterestOperationContext | DATA:UNREGISTER_INTEREST |
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.
...