GlassFish - World's first Java EE 7 Application Server


v1.2

GlassFish 3.1: Master Password

Background

Here is how things stand as of 3.1 MS6

  1. The master password is the password that is used to encrypt the DAS (and instances) keystore. Therefore the DAS and associated server instances need the password to open the keystore at startup.
  2. The master password is the same for the DAS and all instances in the domain
  3. The default master password is "changeit"
  4. The master password can be saved in a master-password file:
    1. DAS: domains/domainname/master-password
    2. Instance: nodes/node-name/instance-name/master-password
  5. The master-password file is essentially encoded not encrypted. It must be protected using filesystem permissions.
  6. The default installation includes a master-password file.
  7. A master password can be set during domain or instance creation by entering it interactively or via the asadmin passwordfile (AS_ADMIN_MASTERPASSWORD). It is saved to the master-password file if the --savemasterpassword option is used. This is supported by:
    1. create-domain
    2. create-local-instance
  8. A master password is provided during domain or instance startup via the master-password file or by entering it interactively or via the asadmin passwordfile. This is supported by:
    1. start-domain
    2. start-local-instance
  9. The master-password may be changed on the DAS by running change-master-password. The DAS must be down to run this command. change-master-password supports the --savemasterpassword option.
  10. There is no command to change the master-password file on an instance. You must copy over the master-password file from the DAS. This is considered a bug.
  11. The master-password file is not synchronized with instances. Currently it is never sent over the network.
  12. In general, synchronization to remote instances will always be over https because you must enable secure admin to perform remote admin. This applies to the asadmin to DAS admin protocol as well.
  13. It is believed that the DAS currently remembers the master password it was provided, but that is considered a bug and that behavior should not be counted on.
  14. In v2 the master password is provided to the DAS and the node agent. The node agent handles sharing the master password with instances it starts. I assume this means if I provided the master password to the node agent I did not need to provide it when using start-instance or start-cluster.

The Problem

Scenario 1: I've changed the master password on the DAS. I'm using master-password file.
  1. If I create an instance using create-instance I must manually copy the master-password file to the instance. I must do this for each instance since the file is at the instance level – not the node level.
  2. If I create an instance using create-local-instance I must provide the master-password to create-local-instance and use --savemasterpassword.
  3. If I have existing instances I must manually change the saved master password on all instances.
    1. Right now I have to do that by copying the master-password file to the instances.
  4. If I do this then start-local-instance, start-instance and start-cluster should all work fine.
Scenario 2: I've changed the master password on the DAS. I'm NOT using a master-password file.
  1. When I start the DAS using start-domain I must provide the master password interactively or via the asadmin password file. That's as expected.
  2. When I start an instance using start-local-instance I must provide the master password interactively or via the asadmin password file. That's as expected.
  3. I can't start the instance using start-instance. It will report an error that a master password is needed but was not provided.
  4. I can't start the cluster using start-cluster.

The Solution

For 3.1:
  1. Move the location of the instance master-password file from nodes/node-name/instance-name/master-password to nodes/node-name/agent/master-password. With this change I can set a master password at the node level and all instances created on that node will use that master-password file. (14989)
  2. Enhance change-master-password to support nodes. This means adding a "--nodedir" option and being able to provide a node_name. (14990)
  3. Change create-domain to prompt for the master password only if --savemasterpassword is used, otherwise the default master password is used and the user must use change-master-password to change it later. As part of this change a new option, --usemasterpassword, is added to support the scenario of having a master password without a master password file. (14981, 15048)
  4. Document that if you have changed the master password and are not using a master password file, then start-instance and start-cluster do not work. You must start those instances locally either by using start-local-instance or the native service support.

With these changes our support in 3.1 for users using a master-password file (Scenario 1) is at parity with v2. If I change the master password on the DAS (using --savemasterpassword) then I must go to each host and run "change-master-password --savemasterpassword nodename" for each node on the host (typically just one). In v2 I needed to run change-master-password on each nodeagent.

But Scenario 2 (no master-password file) is worse than v2. In v2 I had to go to each host and start each nodeagent with the master password, but once I did that I could do start-instance and start-cluster. In v3 I must go to each host and start each instance with the master password (using start-local-instance). start-cluster/start-instance will not work.

For 3.2:
  • Scenario1: Master-password file: automatically synchronize the DAS master-password file to the instances
    • Treat the master-password file just like the keystore. Have create-instance copy it over along with the keystore to the remote instance using SSH. Have the synchronization service synchronize it just like the keystore.
    • The copy always occurs over SSH so the password is encrypted on the wire. Synchronization is over SSL when secure admin is enabled, but is over straight http if you have not enabled secure admin.
  • Scenario2: No master-password file: modify start-cluster and start-instance to take a master password and pass it to start-local-instance (over SSH).
    • Add the ability for start-instance and start-cluster to take AS_ADMIN_MASTERPASSWORD via a password file. This would be an optional parameter, so the commands will never prompt for it. The asadmin protocol is over https for remote administration, but can be just http if the asadmin client is run on the same host as the DAS.
    • Modify start-instance to pass the master-password to start-local-instance, either via Tim's read-from-stdin capability, or via a transient asadmin password file. This will occur over SSH to remote instances so the wire is encrypted.

Security Considerations For 3.2 Solution

In the below questions "master password" refers to the master password in a form that is either clear text, or encoded using a reversible algorithm.

  1. Is it acceptable to automatically (without direct user acknowledgement) replicate the master password over https and/or SSH to remote instances?
  2. Is it acceptable to automatically (without direct user acknowledgement) replicate the master password over http to instances if secure admin has not been enabled.
  3. Is it acceptable for the user to explicitly transmit (via the asadmin client) the master password to the DAS over https for remote administration.
  4. Is it acceptable for the user to explicitly transmit (via the asadmin client) the master password to the DAS over http for local administration (asadmin client is running on same system as the DAS).