Collective security
You can use the principles of collective security in Liberty to address data in motion and data at rest.
- The administrative domain security configuration for collectives is comprised of two parts:
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 Liberty for complete 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 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: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 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: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.