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
Part 1: Admin Authentication
Part 3: Admin Message Encryption
Out-of-the-box, GlassFish Server 3.1 does not permit remote administration. This is to reduce your exposure to an attack from elsewhere in the network. If you try to do remote administration GlassFish sends a "403 - Forbidden" HTTP status as the response. This is true regardless of whether you use asadmin, an IDE, or the REST interface.
You can turn remote administration on using
which actually accomplishes two things. It enables remote administration and also encrypts all admin traffic (more about that in Part 3).
Before you run enable-secure-admin, make sure that the DAS is the only GlassFish process running -- that is, stop any instances. Then after you run enable-secure-admin restart the DAS and then you can start up remote instances. Part of the instance start-up will download the updated configuration to the instances so they can communicate securely with the DAS.
Note: Enabling secure admin does not change anything about how GlassFish deals with the default admin account. In particular the default admin username remains "admin" and the default password remains empty. Before enabling secure admin - and therefore enabling remote administration - you will probably want to either change the admin password (see the asadmin change-admin-password command) or add at least one additional admin account which disables the default admin account handling described in Part 1.
One reason you might want to enable remote administration is to set up a remote instance - a server on a different host from where the DAS is running - without using SSH. Remote administration needs to be turned on because commands you run on the remote host need to communicate with the DAS...and that is remote administration pure and simple. Joe DiPol has written a nice blog talking about how to set up remote instances without using SSH.
You can turn remote administration off again by shutting down any instances, leaving the DAS only up, then running
and then restarting the DAS and starting any instances up again.
In addition to controlling remote administration, enable-secure-admin and disable-secure-admin controls the encryption of admin traffic. Continue on to Part 3 for more about that.