Page History

Geode is introducing a security features implementation which allow allows you to control the authentication/authorization on of all aspects of Geode in entities 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 all protected with this single security mechanism.

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

...

To turn on integrated security, your will need to start your serverservers/locator locators with this line property set in your gemfire.properties file:

security-manager = com.abcexample.security.MySecurityManager

It is This property identifies the class name that implements of the SecurityManager interface implementation. SecurityManger is the new interface you will need to implement for both authentication and authorization. Make sure your class has a zero argument constructor so that we can instantiate the object. SecurityManger is the new interface you will need to implement for both authentication and authorization. See  See the SecurityManger javadoc for details. You can use SampleSecurityManager as There is a SampleSecurityManager in the geode-core/src/main/java/org/apache/geode/security/templates directory that you can use as an example to write your own implementation.

3. Introduction of GeodePermission

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

GeodePermission ResourcePermission is in one of those forms:

...

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

All Operations are enumerated via the enum GeodePermissionenum ResourcePermission.Operation, which are " MANAGE", " READ" , and " WRITE". Note "that MANAGE" does not imply " WRITE", nor "WRITE" implies "READ" eitherand 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  For example, you can see a GeodePermission ResourcePermission defined as "CLUSTER:READ", "CLUSTER:MANAGE", "DATDADATA:READ", "DATA:READ:regionA", or "DATA:READ:regionA:key1".

Note GeodePermission that a ResourcePermission is hierarchical. If you have a principal has permission for "DATA:READ", you it automatically have has data read permission on all regions and all keys, i.e. you have . That is, it has permission for "DATA:READ:regionA". If you have Given permission for "DATA:READ:regionA", you the principal automatically have has data read permission on all keys in regionA, i. e, you have That is, it has permission for "DATA:READ:regionA:key1".

4. Introduction of PostProcessor

...