12. Security

Apache Geode & Pivotal GemFire employ Username/Password-based Authentication along with Role-based Authorization to secure your client to server data exchanges and operations.

Spring Data for Apache Geode & Pivotal GemFire (SDG) provides first-class support for Apache Geode & Pivotal GemFire’s Security framework, which is based on the SecurityManager interface. Additionally, Apache Geode’s Security framework is integrated with Apache Shiro, making the security for servers an even easier and more familiar task.

When you apply Spring Boot for Apache Geode & Pivotal GemFire (SBDG), which builds on the bits provided in SDG, it makes short work of enabling Auth in both your clients and servers.

12.1.1 Auth for Servers

The easiest and most standard way to enable Auth in your servers is to simply define 1 or more Apache Shiro Realms as beans in the Spring ApplicationContext.

For example:

Declaring an Apache Shiro Realm. 

@Configuration
class ApacheGeodeSecurityConfiguration {

    @Bean
    DefaultLdapRealm ldapRealm(..) {
        return new DefaultLdapRealm();
    }

    ...
}

When an Apache Shiro Realm (e.g. DefaultLdapRealm) is declared and registered in the Spring ApplicationContext, Spring Boot will automatically detect this Realm bean (or Realm beans if more than 1) and the Apache Geode & Pivotal GemFire servers in the cluster will automatically be configured with Authentication/Authorization enabled.

Alternatively, you can provide an custom, application-specific implementation of Apache Geode & Pivotal GemFire’s SecurityManager interface, declared and registered as a bean in the Spring ApplicationContext:

Declaring a custom Apache Geode/Pivotal GemFire SecurityManager. 

@Configuration
class ApacheGeodeSecurityConfiguration {

    @Bean
    CustomSecurityManager customSecurityManager(..) {
        return new CustomSecurityManager();
    }

    ...
}

Spring Boot will discover your custom, application-specific SecurityManager implementation and configure the Apache Geode & Pivotal GemFire servers in the cluster with Authentication/Authorization enabled.

	Tip
	The Spring team recommends that you use Apache Shiro to manage the Authentication & Authorization of your Apache Geode & Pivotal GemFire servers over implementing Apache Geode or Pivotal GemFire’s SecurityManager interface.

# Spring Boot client application.properties
spring.data.gemfire.security.username = jdoe
spring.data.gemfire.security.password = p@55w0rd!

Securing data in motion is also essential to the integrity of your application.

For instance, it would not do much good to send usernames and passwords over plain text Socket connections between your clients and servers, nor send sensitive data over those same connections.

Therefore, both Apache Geode & Pivotal GemFire support SSL between clients & servers, JMX clients (e.g. Gfsh) and the Manager, HTTP clients when using the Developer REST API or Pulse, between peers in the cluster, and when using the WAN Gateway.

Spring Data for Apache Geode & Pivotal GemFire (SDG) provides first-class support for enabling and configuring SSL as well. Still, Spring Boot makes it even easier to configure and enable SSL, especially during development.

Apache Geode & Pivotal GemFire require certain properties to be configured, which translate to the appropriate javax.net.ssl.* properties required by the JRE, to create Secure Socket Connections using JSSE.

But, ensuring that you have set all the required SSL properties correctly is an error prone and tedious task. Therefore, Spring Boot for Apache Geode & Pivotal GemFire (SBDG) applies some basic conventions for you, out-of-the-box.

Simply create a trusted.keystore, JKS-based KeyStore file and place it in 1 of 3 well-known locations:

When this file is named trusted.keystore and is placed in 1 of these 3 well-known locations, Spring Boot for Apache Geode & Pivotal GemFire (SBDG) can automatically configure your client to use SSL Socket connections.

If you are using Spring Boot to configure and bootstrap an Apache Geode or Pivotal GemFire server:

Spring Boot configured and bootstrapped Apache Geode or Pivotal GemFire server. 

@SpringBootApplication
@CacheServerApplication
class SpringBootApacheGeodeCacheServerApplication {
    ...
}

Then, Spring Boot will apply the same procedure to enable SSL on the servers as well.

	Tip
	During development it is convenient not to set a trusted.keystore password when accessing the keys in the file. However, it is highly recommended that you secure the trusted.keystore file when deploying your application to a production environment.

If your trusted.keystore file is secured with a password, you will need to additionally specify the following property:

Accessing a secure trusted.keystore. 

# Spring Boot application.properties
spring.data.gemfire.security.ssl.keystore.password = p@55w0rd!

You can also configure the location of the keystore and truststore files, if they are separate, and have not been placed in 1 of the default, well-known locations searched by Spring Boot:

Accessing a secure trusted.keystore. 

# Spring Boot application.properties
spring.data.gemfire.security.ssl.keystore = /absolute/file/system/path/to/keystore.jks
spring.data.gemfire.security.ssl.keystore.password = keystorePassword
spring.data.gemfire.security.ssl.truststore = /absolute/file/system/path/to/truststore.jks
spring.data.gemfire.security.ssl.truststore.password = truststorePassword

See the SDG EnableSsl annotation for all the configuration attributes and the corresponding properties expressed in application.properties.

Currently, neither Apache Geode nor Pivotal GemFire along with Spring Boot/Spring Data for Apache Geode/Pivotal GemFire offer any support for securing your data while at rest (e.g. when your data has been overflowed or persisted to disk).

To secure data at rest when using Apache Geode or Pivotal GemFire, with or without Spring, you must employ 3rd party solutions like disk encryption, which is usually highly contextual and technology specific.

For example, to secure data at rest using Amazon EC2, see Instance Store Encryption.