Collective security

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

Administrative domain security configuration

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

• User domain

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

• Server domain

  This domain relies on SSL certificate-based authentication.

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 is granted the Administrator role. See Configuring secure JMX connection to Liberty for details.

Server-to-server communication falls within the server domain and 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 composed 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 extra trusted certificate entries to the collectiveTrust.jks keystore. All trust is copied when a controller is replicated; therefore, SSL customization must 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 does 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 does 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". For example:

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

Setting clientAuthentication="true" on the collective controller is inadvisable and prevents some common and expected behaviors. For example, this setting prevents authentication with user names and passwords in Admin Center and collective command line utilities.

Setting clientAuthentication="true" on a collective member might be desirable to prevent user name and password logins. This setting does not break collective operations as all operations originating from the controller are authenticated using the certificate.

Members can be prevented from publishing information to the collective controller by using the CollectiveRegistration MBean. The disavow and avow methods prevent authentication and enable authentication.

The Liberty server default keystore type is PKCS12. The JKS keystore type also works. Depending on when the collective keystores were created, they might be JKS keystores that have the .jks file extension or they might be the PKCS12 keystores with the .p12 file extension.

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 must 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 that is stored at these nodes 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 is 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.