Securing Administration in GlassFish Server 3.1 - Part 1: Admin Authentication

If you are an administrator of a GlassFish installation, you will see some new facets of administrative security in GlassFish Server 3.1.  In this series of blogs I describe three key aspects: admin authentication, remote administration, and admin message encryption.  Some of this will be familiar to you if you have worked with earlier releases of GlassFish, and some will be new.

 Remember that convenience and security are often at odds with each other. We have tried hard to keep the out-of-the-box experience with GlassFish Server 3.1 convenient while not creating security problems. And we have tried to make it very easy to run in a very secure administrative environment. 

See also:

Part 2: Remote Administration

Part 3: Admin Message Encryption

Part 1: Admin Authentication

In GlassFish Server 3.1 - in fact, since the early days of GlassFish 3 -
all administrative commands arrive at the domain admin server (the DAS)
as HTTP (or HTTPS) requests.  GlassFish 3.1 also supports remote
instances, and the DAS itself sends administrative commands to remote
instances in the same domain, also over HTTP or HTTPS.  So in GlassFish
Server 3.1 both the DAS and the instances can receive admin requests. 
I'll refer to the DAS and instances as "servers" below.

A server authenticates every administrative request it receives before it executes it.  There are several ways this can happen:

  1. An end user admin client (such as asadmin, the admin console, an IDE, and so on) sends a request to the DAS, including the user-provided admin username and password in an HTTP header. The user might use command-line options to specify the username and a password file which contains the password setting.  The DAS makes sure that the username and password are for a valid administrative account.  If not, or if no username and password accompany the request, the DAS rejects the request and asks the client to repeat the request with a valid username and password using standard HTTP status values.

  2. The DAS sends a request to an instance.  Instances accept admin requests only from the DAS (with only a few exceptions - see below) so the instance verifies that message actually came from the DAS before acting on it.

  3. An end user sends one of a limited set of commands to the local non-DAS instance on the same system (such as to start an instance) using asadmin.  (These are the exceptions I mentioned earlier.)

  4. The asadmin utility, running on behalf of the DAS, sends a request to the DAS.  This happens, for example, if you use the start-instance command.  The DAS causes asadmin to run on the target system to execute a start-local-instance command.  

  5. An admin client can use the REST interface to send a monitoring request to an instance, or to send a management or monitoring request to the DAS.  As with other user-sent requests, the server makes sure the request has a valid admin username and password.  Note that instances accept only monitoring (read-only) requests.  You can use the REST interface to make configuration changes, but those requests must go to the DAS which will forward them as needed to the instances.

Authentication and the Default Admin Account

If the domain contains exactly one valid administrative account, then GlassFish considers that account to be the default admin account.  If at any time there are at least two admin accounts, GlassFish treats no admin account as the default.

When you install GlassFish or create a new domain, GlassFish creates a default admin account, with default username "admin" and an empty default password.  So suppose you have just installed GlassFish.  If you send an admin request to the DAS with no username, the DAS will act as if your request had actually specified "admin" for the username. Specifying no password is equivalent to giving an empty password - which conveniently is the password for the out-of-the-box default admin account.  

All this means that you can run asadmin commands -- or use the admin console or submit REST requests -- without having to specify an admin username or password.  This is consistent with past releases of GlassFish.

For many users this is too lenient. You can run the asadmin change-admin-password command to change any admin account's password.  You can add at least one other admin user which will disable the default admin account handling entirely.

Plus, by default GlassFish Server will not accept remote end-user admin requests; they must come from the same system where you are running the DAS.  So even if you keep the out-of-the-box default admin account, no one (including you!) will be able to send admin requests to the DAS from elsewhere in the network.

For more about that, continue on to Part 2: Remote Administration.


Post a Comment:
  • HTML Syntax: NOT allowed

News and musings on the technology I work on at Oracle.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« January 2017