This site hosts historical documentation. Visit www.terracotta.org for recent product information.

Cluster Security

Introduction

The Enterprise Edition of the Terracotta kit provides standard authentication methods to control access to Terracotta servers. Enabling one of these methods causes a Terracotta server to require credentials before allowing a JMX connection to proceed.

You can choose one of the following to secure servers:

  • SSL-based security – Provides certificate-based authentication for all nodes (including clients) and secures the entire cluster with encrypted connections. Can be used with role-based authorization.
  • LDAP-based authentication – Uses your organization's authentication database to secure access to Terracotta servers.

Configure SSL-based Security

See the advanced security page to learn how to use Secure Sockets Layer (SSL) encryption and certificate-based authentication to secure enterprise versions of Terracotta clusters.

Configure Security Using LDAP (via JAAS)

Lightweight Directory Access Protocol (LDAP) security is based on JAAS and requires Java 1.6. Using an earlier version of Java will not prevent Terracotta servers from running; however security will not be enabled.

To configure security using LDAP, follow these steps:

  1. Save the following configuration to the file .java.login.config:

    Terracotta {
    com.sun.security.auth.module.LdapLoginModule REQUIRED
    java.naming.security.authentication="simple"
    userProvider="ldap://orgstage:389"
    authIdentity="uid={USERNAME},ou=People,dc=terracotta,dc=org"
    authzIdentity=controlRole
    useSSL=false
    bindDn="cn=Manager"
    bindCredential="****"
    bindAuthenticationType="simple"
    debug=true;
    };
    

    Edit the values for userProvider (LDAP server), authIdentity (user identity), and bindCredential (encrypted password) to match the values for your environment.

  2. Save the file .java.login.config to the directory named in the Java property user.home.

  3. Add the following configuration to each <server> block in the Terracotta configuration file:

    <server host="myHost" name="myServer">
    ...
     <authentication>
       <mode>
         <login-config-name>Terracotta</login-config-name>
       </mode>
     </authentication>
    ...
    </server>
    
  4. Start the Terracotta server and look for a log message containing "INFO - Credentials: loginConfig[Terracotta]" to confirm that LDAP security is in effect.

    NOTE: Incorrect Setup
    If security is set up incorrectly, the Terracotta server can still be started. However, you may not be able to shut down the server using the shutdown script (**stop-tc-server**) or the Terracotta console.

User Roles

There are two roles available for Terracotta servers and clients:

  • admin – The user with the "admin" role is the initial user who sets up security. Thereafter, the "admin" user can perform system functions such as shutting down servers, clearing or deleting caches and cache managers, and reloading configurations.

  • terracotta – This is the operator role. The default username for the operator role is "terracotta". The "terracotta" user can connect to the TMC and access the read-only areas. In addition, the "terracotta" user can start a secure server. But a user must have the "admin" role in order to run the stop-tc-server script.

Extending Server Security

Since JMX messages are not encrypted, server authentication does not provide secure message transmission once valid credentials are provided by a listening client. To extend security beyond the login threshold, consider the following options:

  • Place Terracotta servers in a secure location on a private network.
  • Restrict remote queries to an encrypted tunnel such as provided by SSH or stunnel.
  • If using public or outside networks, use a VPN for all communication in the cluster.
  • If using Ehcache, add a cache decorator to the cache that implements your own encryption and decryption.