Add support for consistent installation procedures and security settings based on security.properties file

[GoogleCodeExporter]

1. To which tool/application/daemon will this feature apply?

Applies to all tools that operate out of a Tungsten installation.  

2. Describe the feature in general

Tungsten 2.1.1 introduces support for security using the security.properties 
file.  Set-up and configuration of this file need to be part of installation of 
Tungsten products.  The overall requirements regarding security configuration 
are as follows: 

* Security.properties should be place in a standard location as part of 
installation and properly regenerated on upgrade. 

* The file format should be simple and easy to follow for support purposes. 

* Other security-related files such as keystore, truststore, etc. may be 
located outside of the release so that they persist across upgrades and 
re-installations. 

* Individual Tungsten products and tools will decide how to use the information 
in security.properties, which will contain globally required file locations and 
default settings.  

3. Describe the feature interface

* Installation will be enhanced to include a setting named --security-dir, 
which is the location of the directory that contains user-generated files like 
trust and key stores.  

* The security.properties file will be generated and place in 
cluster-home/conf.  It will be structured in such a away to work with minimal 
reconfiguration, as follows.  In this example we use a variable ${security_dir} 
to locate the full paths for security-related files.  

#################################
# SECURITYPROPERTIES            #
#################################

# Location of files used for security. 
security.dir=/some/path/to/security/files

# RMI + JMX authentication and encryption parameters
security.jmx.authentication=false
security.jmx.tungsten.authenticationRealm=true
security.jmx.tungsten.authenticationRealm.encrypted.password=true
security.jmx.encryption=false
security.jmx.username=tungsten

# Password and access file
security.password_file.location=${security.dir}/passwords.store
security.access_file.location=${security.dir}/remote.access

# Keystore and Trustore for SSL and encryption
security.keystore.location=${security.dir}/tungsten_keystore.jks
security.keystore.password=tungsten
security.truststore.location=${security.dir}/tungsten_truststore.ts
security.truststore.password=tungsten

* As shown in the examples JMX related files will be so-named in 
security.properties so that they can be used efficiently.  

* Services (like the replicator) and utilities (like trepctl) will load the 
security.properties on start-up.  The security package classes will provide 
simple methods do load properties and set system properties efficiently.  It is 
up to each such program to decide how to use this information.  For instance, 
replicators enable SSL encryption at the service level through settings to the 
static-svc.properties files (see Issue 508).  Similarly trepctl and similar 
utilities should have options to enable encryption and passwords, much as DBMS 
clients like mysql, psql, and others do. 

* To the extent it does not conflict with the foregoing, installations should 
make enabling security settings as easy as possible through additional options 
like '--thl-ssl=true' or '--enable-jmx-passwords'.  

* The installations will not distribute default files for security, as this 
introduces a massive security hole from if there are well-known, sample 
certificates and passwords that are easily available to evildoers.  Instead, we 
will supply separate scripts and documentation to help users generate such 
files easily. 

4. Give an idea (if applicable) of a possible implementation

This will be implemented in the Ruby install code (mostly tpm with some 
backwards compatibility to tungsten-installer) along with appropriate support 
from the Java classes in package com.continuent.tungsten.common.security.  

5. Describe pros and cons of this feature.

5a. Why the world will be a better place with this feature.

This will enable security features to be enabled easily and make them 
reasonably understandable.  Having a simple, centralized file with external 
user-prepared files also makes it easier to handle cloud installations, product 
upgrades, and add new security features over time. 

5b. What hardship will the human race have to endure if this feature is
implemented.

Mostly a lot of review and discussion to get this right and that is shared by a 
relatively small number of people.  The implementation is pretty easy once you 
decide what to do.   

6. Notes

This framework will support Continuent's closed source products as well. 

Original issue reported on code.google.com by robert.h...@continuent.com on 13 Jul 2013 at 3:59

[GoogleCodeExporter]

Original comment by linas.vi...@continuent.com on 15 Jul 2013 at 9:12

• Added labels: FixedIn-2.1.1
• Removed labels: FixedIn-2.1.2

[GoogleCodeExporter]

The '--security-directory' option should default to '$CONTINUENT_ROOT/share' 
since we make sure that directory always exists and is owned by the Tungsten 
user.

Original comment by jeff.m...@continuent.com on 15 Jul 2013 at 1:00

[GoogleCodeExporter]

Change in the security.properties file made. Added substitution and a simple 
test.

Passing over to Jeff to implement the rest in tpm

Original comment by ludovic....@continuent.com on 15 Jul 2013 at 3:17

[GoogleCodeExporter]

The new arguments will be

--security-directory
--enable-thl-ssl|--thl-ssl
--enable-rmi-ssl|--rmi-ssl
--enable-rmi-authentication|--rmi-authentication
--rmi-username

Original comment by jeff.m...@continuent.com on 17 Jul 2013 at 11:44

[GoogleCodeExporter]

The following arguments have been added:

--security-directory (default:<--home-directory>/share)
--thl-ssl (default: false)
--rmi-ssl (default: false)
--rmi-authentication (default: false)
--rmi-user (default: tungsten)
--java-keystore-password (default: tungsten)
--java-truststore-password (default: tungsten)

I need to add validation of the settings before this can be considered 
complete. To do that I need to know how to test the various settings from the 
command line.

- Validate the keystore and truststore exist
- Validate the rmi user exists in both files and properly authenticates
- Validate the proper certificate exists for thl encryption

Original comment by jeff.m...@continuent.com on 23 Jul 2013 at 5:06

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

1) Validate the keystore and truststore exist
This also verifies that the password is correct:

keytool -list -v -keystore ./tungsten_keystore.jks -storepass tungsten

2) Validate the proper certificate exists for thl encryption
Same as 1), you can check that the certificate is in the list. You can use 
-alias if needed
https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.ht
ml

3)Validate the rmi user exists in both files and properly authenticates
There are commnand line jmx client you could use to make a call to a running 
manager and see if you get a response:
http://crawler.archive.org/cmdline-jmxclient/
http://wiki.cyclopsgroup.org/jmxterm
https://github.com/jeanarcand/jmxbox

Original comment by ludovic....@continuent.com on 24 Jul 2013 at 7:43

[GoogleCodeExporter]

All the validation that's currently possible is in. Keystore and truststore 
with the given passwords are tested.
There's no simple way to test the password or jmxremote file, however that's 
not really needed.

Original comment by linas.vi...@continuent.com on 12 Aug 2013 at 3:59

• Changed state: Documenting

[GoogleCodeExporter]

The documentation for this has already been update, and an entry added to the 
release notes.  

Original comment by mc.br...@continuent.com on 12 Aug 2013 at 4:56

• Changed state: Fixed