Collective security

We can use the principles of collective security in the Liberty profile to address data in motion and data at rest.

The two principal areas of collective security are:

• Administrative domain security configuration

  Addresses data in motion, authentication and authorization

• Collective repository data security

  Addresses data at rest, authentication and authorization

Administrative domain security configuration

The administrative domain security configuration for collectives is comprised of two parts:

• User domain

  This domain relies on Java role-based security that defines the Administrator role. This can be mapped to users within the configured user registry.

• Server domain

  This domain relies on SSL certificate-based authentication.

In order for users to access the collective controller's MBeans, they must be in the Administrator role. All administrative actions through the collective require that the user be granted the Administrator role. See Configure secure JMX connection to the Liberty profile for complete details.

Server-to-server communication falls within the server domain and, as such, no user identities or passwords are used to communicate between members of a collective. Each member of the collective has a unique identity within the collective that is comprised of its host name, user directory, and server name. Each member within the collective defines its server domain configuration, which consists of the serverIdentity.jks and collectiveTrust.jks files. These files contain the SSL certificates necessary to establish secure communications within the collective. The HTTPS key configuration must have specific trust settings, which are established by default.

The server domain SSL configuration can be customized by adding additional trusted certificate entries to the collectiveTrust.jks keystore. All trust is copied when a controller is replicated; therefore, SSL customization should be applied to the initial controller. Adding trust to the collectiveTrust.jks keystore is only necessary if the default HTTPS certificates are not used. If the HTTPS SSL configuration is modified, the following certificate rules apply:

• HTTPS trust must be established by all controllers and members within the collective. If the HTTPS SSL certificates are modified, the following root signers from the collective controller must be added to the HTTPS SSL truststore:

  • The controllerRoot signer from the rootKeys.jks keystore must be added to all collective members HTTPS SSL truststore.

  • The controllerRoot signer and the memberRoot signer from the rootKeys.jks keystore must be added to all collective controllers' HTTPS SSL truststore.

• Each member can make an outbound connection to a collective controller. The collective controller's collectiveTrust.jks keystore must contain a certificate chain that trusts the HTTPS SSL certificate for each member. It is highly recommended that all HTTPS certificates be signed by a root signer, which then can be added to the collectiveTrust.jks keystore. Using individual SSL certificates that do not have a common root signer is sufficient to establish trust but will not scale.

• Each controller can make an outbound connection to a collective member. The collective member's collectiveTrust.jks keystore must contain a certificate chain that trusts the HTTPS SSL certificate for each controller. It is highly recommended that all HTTPS certificates be signed by a root signer, which then can be added to the collectiveTrust.jks keystore. Using individual SSL certificates that do not have a common root signer is sufficient to establish trust but will not scale.

Server-to-server communication requires that SSL authentication be supported. If the HTTPS SSL configuration is customized, the SSL configuration must specify clientAuthenticationSupported="true". It is recommended that we do not use clientAuthenticationRequired="true"; because that will prevent authentication with user names and passwords. For example:

<!-- clientAuthenticationSupported set to enable bidirectional trust -->
    <ssl id="defaultSSLConfig"
         keyStoreRef="defaultKeyStore"
         trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

Members can be prevented from publishing information to the collective controller through the use of the CollectiveRegistration MBean. The disavow and avow methods will prevent authentication and enable authentication, respectively.

Collective repository data security

The collective repository data security policy covers the policy for data at rest—specifically, the policy of accessing the contents of the collective repository.

The current security policy for collective data is as follows:

• The system reserves three node names: sys.host.auth.info, sys.jmx.auth.info, and sys.nologin. These nodes are under a host or server's repository namespace. User-created nodes should avoid using the sys. prefix.

• The sys.host.auth.info and sys.jmx.auth.info nodes are not accessible through the MBean to prevent disclosure of system credentials. Accessing the data stored at these nodes will result in a null response.

• A collective member is restricted to modifying only its own information in the repository. Authenticated administrative users have unrestricted access to information in the repository except as previously noted. Authenticated administrative users are all users granted the Administrative role.

Because the collective repository ultimately resides on the disk, the file system permission settings must be secure for the environment. It is recommended that the collective controller's configuration be readable and writable only by the user, readable only by the group, and not accessible at all by the world—in other words, chmod 0640. Follow any security guidelines that the organization might have established.

Concepts:

Collective architecture

File transfer in a Liberty collective

File transfer

Liberty collective troubleshooting

Tasks:

Set the default host name of a Liberty server

Configure a Liberty collective

Register host computers with a Liberty collective

Set the JAVA_HOME variable for Liberty collective members

Configure Liberty collective replica sets

Generating collective controller SSL keys

Reference:

Example of setting up a JMX routing environment

List of provided MBeans

Overriding Liberty server host information