Product Documentation : Terracotta Management Console User Guide : Setting up Security : Certificate-Based Client Authentication
Certificate-Based Client Authentication
As an alternative to the hash-based message authentication scheme of basic security (as described in Basic Connection Security), you can use certificate-based client authentication with BigMemory Go nodes. This form of authentication is not available for use with the Terracotta Server Array.
Setting up client authentication automatically turns off hash-based authentication. Note that you must configure SSL to use this security option. For procedures, see Adding SSL.
You must set up keystores for all managed agents and a truststore for the TMS as described in Basic Connection Security and Adding SSL. In addition, you must also set up truststores for all managed agents and a keystore for the TMS, as described in the following procedure.
To enable certificate-based client authentication:
1. Enable client authentication on the REST service by setting the managementRESTService element's needClientAuth attribute to "true" in the managed agent's configuration:
<ehcache ...>
...
<managementRESTService enabled="true"
securityServiceLocation="http://localhost:9889/tmc/api/assertIdentity"
sslEnabled="true" needClientAuth="true" />
...
</ehcache>
2. Provide a truststore for the managed agent at the default location, ${user.home}/.tc/mgmt/truststore, or by setting the truststore location with the system property javax.net.ssl.trustStore.
3. The password for the truststore must be included in the managed agent's keychain.
The password must be keyed with the truststore file's URI. Or set the password with the system property javax.net.ssl.trustStorePassword.
4. Provide an identity store for the TMS at the default location, ${user.home}/.tc/mgmt/tms-keystore, or by setting the identity-store location with the system property javax.net.ssl.keyStore.
The managed agent is rejected by the TMS unless a valid certificate is found.
5. The password for the TMS identity store must be included in the TM keychain, as described in Creating a Shared Secret.
The password must be keyed with the identity-store file's URI. Alternatively, set the password with the system property javax.net.ssl.keyStorePassword.
6. To allow an SSL connection from the managed agent, an SSL connector must be configured. If the TMS is deployed with the provided Jetty web server, add the following to /management-console/etc/jetty.xml (in the BigMemory kit) as shown:
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
<Arg>
<New class="org.eclipse.jetty.http.ssl.SslContextFactory">
<Set name="keyStore">/home/.tc/mgmt/tms-keystore</Set>
<Set name="keyStorePassword">
OBF:1v9u1w1c1ym51xmq1rwd1rwh1xmk1ym91w261v8s</Set>
<Set name="keyManagerPassword">
OBF:1v9u1w1c1ym51xmq1rwd1rwh1xmk1ym91w261v8s</Set>
<Set name="TrustStore">/home/.tc/mgmt/tms-truststore</Set>
<Set name="keyStorePassword">
OBF:1v9u1w1c1ym51xmq1rwd1rwh1xmk1ym91w261v8s</Set>
<Set name="needClientAuth">true</Set>
</New>
</Arg>
<Set name="port">9999</Set>
<Set name="maxIdleTime">30000</Set>
</New>
</Arg>
</Call>
Note the following about the configuration shown:
*If the TMS WAR is deployed with a different container, make the equivalent changes appropriate to that container.
*The SSL port must be free (unused by any another process) to avoid collisions.
*maxIdletime can be set to a value that suits your environment.
*If the default keystore or truststore are not being used, enter the correct paths to the keystore and truststore being used.
*Passwords have been obfuscated using a built-in Jetty tool:
java -cp lib/jetty-runner.jar org.eclipse.jetty.util.security.Password myPassword
This command, which must be run from the TMC root directory, returns an obfuscated version of myPassword.
Copyright © 2010-2017 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback