This example demonstrates basic command security and user authentication in a client application backed by a secured Geode cluster. It also demonstrates use of secure sockets (SSL) between all members and between a client and a server. This example assumes that Java is installed.
Geode security is based on Apache Shiro. Permissions are defined by
A single permission is represented by a
:-separated string, e.g.,
Permissions need not be fully specified. Abridged permissions are hierarchical. A permission of
CLUSTER:MANAGE, for all target regions and all key values. Using wildcard annotation, a permission of
CLUSTER is equivalent to
In this example, four users with varying permissions attempt to read and write data in two regions.
superUser user has full permissions and may read and write to all regions.
dataReader user has
DATA:READ permission, granting read access to all regions.
dataWriter user has
DATA:WRITE permission, granting write access to all regions.
region1dataAdmin has permissions
DATA:WRITE:region1, granting read and write access only to
For more information on what permission is required for a given operation, refer to the documentation.
Two interfaces must be implemented to secure a Geode cluster:
Your implementation of
org.apache.geode.security.AuthInitialize should handle the interaction with any existing security infrastructure (e.g., ldap). In this example, we provide a trivial implementation in
These credentials are then given to your implementation of
org.apache.geode.security.SecurityManager to authenticate the user (i.e., to log in). The security manager also handles authorization of the authenticated user for particular operations. How permissions are assigned to users is also determined by the security manager. In this example, we group permissions by role, and assign each user one or more roles in a JSON file. This file is located at
geode-examples/clientSecurity to be the current working directory. Each step in this example specifies paths relative to that directory.
Build the example
$ ../gradlew build
Start a secure cluster consisting of one locator with two servers with two regions. Refer to
scripts/start.gfsh. When starting a secure cluster, you must specify a security manager that implements authorization. In this example, we use the security manager
org.apache.geode.examples.clientSecurity.ExampleSecurityManager. This security manager reads a JSON file that defines which roles are granted which permissions, as well as each user's username, password, and roles. The JSON is present in
src/main/resources/example_security.json. You can execute the
scripts/start.gfsh script with the command:
$ ../gradlew start
Run the example. Each user will attempt to put data to
/region2, and then read data from
/region2. Unauthorized reads and writes throw exceptions caused by
NotAuthorizedException, which we catch and print in this example.
$ ../gradlew run
Stop the cluster using the script
You can run this script with the command:
$ ../gradlew stop
org.apache.geode.security.AuthInitialize to pass user credentials from any existing security infrastructure.
org.apache.geode.security.SecurityManager to handle user authentication and operation authorization.
SecurityManager by the
security-manager property of all locator and server property files. An unsecured member or a member secured by a different security manager will not be allowed to join the cluster.
If additional properties are required by your implementation of the security manager, these may be defined in your locator or server property files. For instance, our implementation also requires
security-json to be defined.