Back to other Admin Subprojects Back to Administration Starting Point

Introduction

This page provides some of the projects we have done in administration security area.

Master Password Related Changes

First off, please make yourself familiar with the terminology by referring to this page. Thus, Master Password is the password that locks the keystore and truststore that server needs to open, should it need to get the private key(s) and/or access the certs of other servers it trusts. It should be noted that this discussion applies to JKS based stores only since we haven't provided an NSS support yet, for V3. And I admit, this area is rather confusing because of players like JSSE system properties involved.

So, the problem is how the master password that unlocks the stores should be made available to the server's runtime. It should be as secure as possible, but at the same time, different services in server runtime need to get an "easy" programmatic access to the password in clear, so they can do what they want with the store.

Following should be kept in mind:

1. There is only one keystore/truststore pair for the server from a sysadmin standpoint. Sysadmins prefer to manage as few passwords as possible. For the time being, ignoring the crypto accelerator passwords, there is only one master password that sysadmins need to know ¹.
2. We have two ways to start the servers: asadmin start-domain and java -jar glassfish.jar and this should work in both the cases.

Details

1. asadmin arranges for securely passing the master password from asadmin process (VM1) to the actual server VM (VM2). We use stdin for this. For this purpose, an option -read-stdin true/false is introduced on server main class: ASMain. This makes an Init Service (v3/core/kernel/../admin/IdmService.java) in server read the stdin and get the password securely from there. Similar things happen in case of java -jar, if you use -read-stdin true option.
2. IdmService also implements a contract called IdentityManagement that everyone else should Inject into their implementation.
3. IdmService verifies that the master password is correct, by opening the stores (keystore.jks).
4. Per security team's advice, it also sets up the default JSSE System Properties to this password:

System.setProperty(SystemPropertyConstants.KEYSTORE_PASSWORD_PROPERTY, masterPassword);
        System.setProperty(SystemPropertyConstants.TRUSTSTORE_PASSWORD_PROPERTY, masterPassword);

It's expected that subsystems use IdentityManagement contract rather than JSSE properties to get the master password. This is to allow for changes in underlying storage mechanism. IdentityManagement (currently supports only JKS) will be enhanced to support NSS if required.

Provision of a Local Password

To allow local commands to work compatibly with v2, without the need to authenticate to the server,
we introduced a special "local password". When the server starts up, it uses SecureRandom to
generate a cryptographically unique "password" (just a sequence of 40 bytes). This password is
stored in the file config/local-password in the domain directory that is protected so that only the owner of the domain
can read the file. The intent is that only the owner of the domain, running on the same machine
as the server, can access the file. The password is stored as a hex string.

Commands that operate locally, such as stop-domain, read the local password from the file and
use it in the authentication information sent to the server. If the server gets a request with
authentication information that includes a password that matches the local password (which effectively
"can't" happen by accident or by guessing) the request is allowed. (The user name is not checked.)

The effect is that commands executing on the same machine as the server, and executing as the same
user who owns the server, can authenticate to the server using this local password without ever
having to prompt the user for a password.

A few notes about the current implementation:

• The local password is regenerated every time the server starts.
• The local password file is never read by the server so any changes to the file can't compromise security.
• If the local password file can't be written by the server, no password is stored, effectively disabling this feature.

Footnotes

There are ways to deal with this password in terms of how to store it for unattended boots (the so-called "master-password" file in server's config folder) etc. See asadmin create-domain options for details.
This obsoletes the IdentityManager class that was used earlier (in V2).