Liberty profile: Collective security

This article provides an overview of collective security.

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 Configuring 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 that are 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 may make an outbound connection to a collective controller. The collective controller's collectiveTrust.jks keystore must contain the HTTPS SSL certificate for each member. It is highly recommended that all HTTPS certificates be signed by a root signer, which can then be added to the collectiveTrust.jks keystore. Using SSL certificates that do not have a common root signer will not scale.
• Each controller can make an outbound connection to a collective member. As above, the collective members's collectiveTrust.jks must contain the HTTPS SSL certificate for each controller. It is highly recommended that all HTTPS certificates be signed by a root signer, which can then be added to the collectiveTrust.jks keystore. Using SSL certificates that do not have a common root signer 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 you 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 avow and disavow 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 noted above. 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 your organization might have established.