Authentication is the way in which an entity (a user, an application, or
a component) determines that another entity is who it claims to be. An
entity uses security credentials to authenticate itself. The credentials
might be a user name and password, a digital certificate, or something
else. Usually, servers or applications require clients to authenticate
themselves. Additionally, clients might require servers to authenticate
themselves. When authentication is bidirectional, it is called mutual
JSR 375 Authentication Mechanisms and Identity Stores
The Java EE Security API defines the
HttpAuthenticationMechanism interface defines an SPI for writing
authentication mechanisms that can be provided with an application and
deployed using CDI. Developers can write their own implementations of
HttpAuthenticationMechanism to support specific authentication token
types or protocols. There are also several built-in authentication
mechanisms that perform BASIC, FORM, and Custom FORM authentication.The
HttpAuthenticationMechanism interface defines three methods -
methods align closely with the methods defined by the JASPIC
IdentityStore interface provides an abstraction of an identity
store that holds user account information including name, password,
group membership, and potentially other attributes. Implementations of
IdentityStore interface are used to validate caller credentials,
typically username and password, and retrieve and group information.
There are built-in implementations of this SPI that can validate
credentials against external LDAP or Database identity stores.
IdentityStore is intended primarily for use by
HttpAuthenticationMechanism implementations, but could be used by
other authentication mechanisms, such as a JASPIC
a container’s built-in authentication mechanisms. Though
HttpAuthenticationMechanism implementations can authenticate users in
any manner they choose, the
IdentityStore interface provides a
convenient mechanism. A significant advantage of using
IdentityStore over the declarative
mechanisms defined by the Servlet specification is that it allows an
application to control the identity stores that it authenticates
against, in a standard, portable way. You can use the built-in
implementations of the plug-in SPIs, or define custom implementations.
Passwords are your first line of defense against unauthorized access to
the components and data of GlassFish Server. For Information about how
to use passwords for GlassFish Server, see Administering
Master Password and Keystores
The master password is not tied to a user account and it is not used for
authentication. Instead, GlassFish Server uses the master password only
to encrypt the keystore and truststore for the DAS and instances.
When you create a new GlassFish Server domain, a new self-signed
certificate is generated and stored in the domain keystore and
truststore. The DAS needs the master password to open these stores at
startup. Similarly, the associated server instances need the master
password to open their copy of these stores at startup.
If you use a utility such as keytool to modify the keystore or
truststore, you must provide the master password in that case as well.
The master password is a shared password and must be the same for the
DAS and all instances in the domain in order to manage the instances
from the DAS. However, because GlassFish Server never transmits the
master password over the network, it is up to you to keep the master
password in sync between the DAS and instances.
If you change the master password, you can choose to enter the master
password manually when required, or save it in a file.
Understanding Master Password Synchronization
The master password is used encrypt the keystore and truststore for the
DAS and instances. The DAS needs the master password to open these
stores at startup. Similarly, the associated server instances need the
master password to open their copy of these stores at startup.
GlassFish Server keeps the keystore and truststore for the DAS and
instances in sync, which guarantees that all copies of the stores are
encrypted with the same master password at any given time.
However, GlassFish Server does not synchronize the master password
itself, and it is possible that the DAS and instances might attempt to
use different master passwords.
Consider the following potential scenario:
You create a domain and instances, using the default master password
(changeit). As a result, the DAS and instances have keystores and
truststores encrypted using changeit.
You use the
change-master-password subcommand on the DAS to change
the master password to ichangedit. As a result, the DAS and instance
keystores and truststores are encrypted using ichangedit.
Access to the keystore and truststore from an instance now requires
the master password ichangedit. You are responsible for changing the
master password as needed.
If you do not use a master password file, you assume the responsibility
for using the
change-master-password subcommand on the DAS and
instances to keep the master passwords in sync. Be aware that not using
a master password file has additional considerations for the
start-instance and start-cluster subcommands, as described in
Additional Considerations for the
If you do use a master password file, you assume the responsibility for
change-master-password subcommand on the DAS and instances
to keep the master password file in sync.
Using the Default Master Password
GlassFish Server uses the known phrase "changeit" as the default master
password. This master password is not stored in a file. The default
password is a convenience feature and provides no additional security
because it is assumed to be widely known.
All GlassFish Server subcommands work as expected with the default
master password and there are no synchronization issues.
Saving the Master Password to a File
--savemasterpassword option indicates
whether the master password should be written to the file system in the
master-password file for the DAS or a node. The default is false.
For a domain, the master password is kept in
For a node, the master-password file is kept in
nodes/`node-name/agent/master-password`. You can set a master password
at the node level and all instances created on that node will use that
master-password file. To do this, use the
--nodedir option and provide
a node name.
The master-password file is encoded, not encrypted. You must use
filesystem permissions to protect the file.
Using the Master Password When Creating a Domain
--usemasterpassword option specifies whether the
keystore is encrypted with a master password that is built into the
system, or by a user-defined master password.
If false (default), the keystore is encrypted with a well-known
password (changeit) that is built into GlassFish Server.
If true, the subcommand obtains the master password from the
AS_ADMIN_MASTERPASSWORD entry in the password file you specified in
--passwordfile option of the
asadmin utility. Or, if none is
--usemasterpassword prompts the user for the master password.
An administration password, also known as the admin password, is used to
invoke the Administration Console and the
asadmin utility. As with the
default admin username, the default admin password is usually set during
installation but it can be changed. For instructions, see To
Change an Administration Password.
Files that contain encoded passwords need to be protected using file
system permissions. These files include the following:
This file contains the encoded master password and should be protected
with file system permissions 600.
Any password file created to pass as an argument by using the
--passwordfile argument to the
asadmin utility should be protected
with file system permissions. Additionally, any password file being used
for a transient purpose, such as setting up SSH among nodes, should be
deleted after it has served its purpose.
Web Browsers and Password Storage
Most web browsers can save login credentials entered through HTML forms.
This function can be configured by the user and also by applications
that employ user credentials. If the function is enabled, then
credentials entered by the user are stored on their local computer and
retrieved by the browser on future visits to the same application. This
function is convenient for users, but can also be a security risk. The
stored credentials can be captured by an attacker who gains access to
the computer, either locally or through some remote compromise. Further,
methods have existed whereby a malicious web site can retrieve the
stored credentials for other applications, by exploiting browser
vulnerabilities or through application-level cross-domain attacks.
To prevent your web browser from saving login credentials for the
GlassFish Server Administration Console, choose "No" or "Never for this
page" when prompted by the browser during login.