Thoughts on my current and past work:
Java cloud developer experience,
WebLogic Server multi-tenancy, GlassFish...

A Few Changes to Secure Administration in GlassFish 3.1.2

Tim Quinn
Consulting Member of Technical Staff

Security continues to be a focus for us, and we've made some additional strides in admin security for GlassFish 3.1.2, now available for download.  The documentation (especially the security guide) does a very good job explaining this, so I'll just summarize a few things here.  (You can read about some significant improvements we made in GlassFish 3.1.1 in this earlier post if you are not familiar with them.)

DAS-to-instance Traffic is Always Secure

Sometimes the domain admin server (the DAS) needs to send admin messages to other instances in the domain.  Beginning with GlassFish 3.1.2 that traffic is always secured using SSL encryption.  Further, the instances authenticate the DAS - they make sure the DAS is who it claims to be - also using the SSL certificate.  This is true whether or not you explicitly enable or disable secure admin.

Secure admin in 3.1.2

In GlassFish 3.1.1 enabling secure admin did two things: it secured the DAS-to-instance admin traffic and also allowed the DAS to accept remote admin requests. 

Because DAS-to-instance traffic is always secured in GlassFish 3.1.2, enabling and disabling secure admin will control only whether you allow the DAS to accept remote admin requests. 

Note that GlassFish 3.1.2 will not let you enable secure admin if you have any admin accounts with an empty password.  So, if you want to enable secure admin for an out-of-the-box installation you'll need to do this first:


and respond to the prompts for the "admin" username. 

 Why change things?

GlassFish now always uses SSL encryption for the DAS-to-instance traffic simply to be more secure.  The DAS does not typically have to send many commands to instances, so any performance penalty from using SSL on those messages is very small.  Especially if you have the DAS and instances running on different hosts this more secure approach is much better.

We imposed the additional requirement on enable-secure-admin - requiring all admin users to have non-empty passwords - to help you protect your GlassFish domain.  This change prevents anyone from another
system from sending admin requests to your GlassFish domain using the
default, out-of-the-box admin username and password.  (And, no, the change-admin-password command will not let you set an empty admin password if secure admin is already enabled!)

As I noted in the earlier 3.1.1 posts about secure admin, there can be a tension between ease-of-use and security.  If you are accustomed to installing a new version of GlassFish, enabling secure admin, and then accessing it from other systems - including from an IDE - you might find it annoying to have to change the default admin password to a non-empty value before you can enable secure admin.  But the enable-secure-admin command will remind you about the admin password if you haven't already changed it.  And once you change the password and enable secure admin you'll be able to sleep better at night.  Well, at least you should not be restless because of GlassFish admin security.

Join the discussion

Comments ( 2 )
  • guest Friday, March 2, 2012

    Thanx for the information. I wonder if it is not possible to access the the DAS from remote in "safe" environments (like firewall protected regions) without using enable-secure-admin.

  • Tim Quinn Friday, March 2, 2012

    There is no way to do this in the current implementation.

    We are trying to make our two most common use cases easy.

    In the first, a developer works on the same host where the DAS is running. In this case the admin requests come from the same host and an empty password is considered an acceptable risk, given that the developer probably has physical control over the system. This works out of the box while prohibiting access from other hosts.

    In the second, a developer or administrator needs to access the DAS from some other system. Because the default admin username and password are well known (in fact they are documented!) it is considered an unacceptable risk to expose a DAS, even a developer's DAS, to possible attacks from other systems using the default credentials. So, unless you enable secure admin GlassFish refused any remote admin requests. And you cannot enable secure admin without changing any empty admin passwords.

    I see your point, that the local network behind the firewall can be secure. But it also might not be. Owners of other systems behind the firewall might not be as diligent as you in protecting their systems. There would always be the chance that an intruder could install rogue code to forward requests from outside through the compromised trusted system to your DAS. This scenario might seem far-fetched but it is possible and would open up your system to threats.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.