Process Diagram
The following diagram illustrates the flow of security information during initial cluster connections. It also shows which security-related file originates the security information:
From a Terracotta server point of view, security checks take place at the time a connection is made with another node on the cluster:
1. After startup, servers can make connection requests to servers named in the configuration.
2. A connection request from server2 initiates the process of establishing a secure connection using SSL.
3. Server1 authenticates server2 using stored credentials. Credentials are also associated with a role that authorizes server2. The process is symmetrical: server2 authenticates and authorizes server1.
4. A connection request from a Terracotta client initiates the process of establishing a secure connection using SSL.
5. Server1 authenticates and authorizes the client using stored credentials and associated roles.
Because a client might communicate with any active server in the cluster during its lifetime, the client must be able to authenticate with any active server. Clients should be able to authenticate against all servers in the cluster because active servers might fail over to mirror servers.
From a Terracotta client point of view, security checks occur at the time the client attempts to connect to an active server in the cluster:
1. The client uses a server URI that includes the client username.
A typical (non-secure) URI is <server-address>:<port>. A URI that initiates a secure connection takes the form <client-username>@<server-address>:<port> .
2. A secure connection using SSL is established with the server.
3. The client sends a password fetched from a local keychain file. The password is associated with the client username.
