By kumarjayanti on Feb 27, 2011
GlassFish V3.1 Security
The GlassFish OSE V3.1 release builds on the modular, Java EE 6 based GlassFish Server Open Source Edition (OSE) 3.0, and adds the following primary features:
- Clustering and Centralized Administration
- High Availability
The security enhancements also fall broadly under the above two buckets. A new Security Guide accompanies the V3.1 release documentation and it covers a combination new and existing material. The content is distributed under the following chapters :
- Administering System Security
- Administering User Security
- Administering Message Security
- Administering Security in Cluster Mode
- Managing Administrative Security
- Running in a Secure Environment
In this post i shall summarize the following security aspects in V3.1 :
- Policy Generation in Cluster Mode
- Synchronization of security artifacts in a cluster
- Dynamic Reconfiguration
- the new GlassFish PAMRealm
- Support for Weblogic Deployment Descriptor
- Configuring the <ssl/> child element of listener/protocol elements
- Upgrading from GlassFish V2.X Enterprise edition to V3.1
- Working with server.policy file
- JAAS LoginModule support for CertificateRealm
- Changes to Default Digest/Hash algorithms
- JAAS LoginModules : Using the JSR-196 Login-Bridge Profile
- Interoperability with Oracle Identity Management
- What is not Supported
some other important security aspects such as High Availability and replication of the Session, enabling secure administration, SSH based cluster provisioning etc. will be covered by other developers of GlassFish 3.1 and will also be part of the various glassfish developer guides.
Policy Generation in Cluster Mode
If you are aware the default policies for authorization in the form of granted.policy and exclude.policy are generated at deployment time based on declarative information in the deployment descriptor and annotations on the EJB/Servlet classes. When running in a cluster mode this policy generation occurs on each of the server instances in the cluster. This is a consequence of the fact that Administrative commands that are executed on the DAS are replicated to the effected server instances. This is done by sending to the server instances the same admin command request that was sent to the DAS.
There is no user visible impact of this feature, but it helps to understand how policy generation is handled in the V3.1 cluster.
Synchronization of Security Artifacts in a Cluster
Refer to the GlassFish Server V3.1 High Availability Administration Guide for more information about Resynchronizing GlassFish Server Instances and the DAS. It is normally a good idea to setup all the required policy settings (server.policy), keystore and truststore on the DAS and the individual server instances before setting up the cluster. Incase you need to change any artifact (ex server.policy settings) for the cluster afterwards then you need to make the required changes to the artifact on DAS and touch domain.xml. Then a restart of the cluster would cause the modified file to be copied over to the instances.
Dynamic reconfiguration refers to using the --target operand to CLI subcommands to make a change to a server instance (if the user-specified target is a server instance), or all server instances that are part of the cluster (if the user-specified target is a cluster). For example: asadmin create-auth-realm some-options --target some-target. The value of the optional --target operand can be a cluster , server, instance or configuration name. The corresponding list-\* commands take the target as a primary operand (without the --target).
Refer the chapter on Administering Security in Cluster mode from the Security Guide for more details on dynamic reconfiguration.
Please refer the following post for more details on this.
Support for WebLogic Deployment Descriptor
Essentially this feature allows deployment of weblogic applications on GlassFish. There is support for weblogic deployment descriptor (weblogic.xml and weblogic-application.xml). In the context of security the security-role-assignment which maps role-name(s) to principal-name(s) is supported. The special externally-defined element is not supported under the security-role-assignment.
A sample application can be accessed from the developer tests area.
Configuring the <ssl/> child element of listener/protocol elements.
In V3.1 the <ssl/> element makes use of a classname attribute with its value as com.sun.enterprise.security.ssl.GlassfishSSLImpl. This class provides the required keymanager and trustmanager's to grizzly layer that manages the SSL connection. This attribute was not used in V3.0.1. When this attribute is absent the default Grizzly implementation of the SSL Implementation SPI is used. The GlassfishSSLImpl class would use keystore and truststore indicated by the javax.net.ssl.keyStore and javax.net.ssl.trustStore system properties. And the glassfish master-password which protects the stores is used internally by the implementation.
When this classname attribute is not present, then the default Grizzly implementation needs to obtain the keystore password via the ssl element. Otherwise a non-default value for glassfish masterpassword will result in the following exception when we try to access the port 8181 via https.
java.io.IOException: Keystore was tampered with, or password was incorrect
Caused by: java.security.UnrecoverableKeyException: Password verification failed
Developers are therefore advised not to use these undocumented facilities in the <ssl/> element and stick to the use of the classname attribute as it exists by default. Refer to the following issue GLASSFISH-15973 for more details on problems that can arise when changing the <ssl/> element.
Upgrading from GlassFish V2.X Enterprise edition to V3.1
When a GlassFish V2.X enterprise edition is being upgraded to V3.1 then there will be some manual steps involved. This is because GlassFish V3.1 does not support NSS (Network Security Services) stores. Please refer to the V3.1 Upgrade Guide for detailed instructions on the Upgrade Process.
Working with server.policy
If you are running V3.1 with Security Manager ON (setting jvm-option -Djava.security.manager), and want to control what permissions should be granted to the running applications then please refer to the comments in server.policy and also the chapter on Administering System Security from the GlassFish Security Guide for more details. The server.policy file can either be edited manually or one can use policytool from JDK.
JAAS LoginModule support for CertificateRealm
The Certificate Realm in earlier releaes of glassfish did not allow for a JAAS LoginModule where the developer could do additional authentication checks on the client-certificate or do custom group assignment based on some attributes in the certificate. In GlassFish V3.1 you can configure a JAAS loginmodule for the certificate realm. More details can be accessed in the following post
Changes to default Digest/Hash algorithms
The default digest algorithm (SHA-1) for encoding file-users in the GlassFish FileRealm has been changed to a more stronger SHA-256 algorithm. The following post explains this and its implications in more detail. The default digest algorithm for JDBC has also been changed from MD5 to the more stronger SHA-256. In addition the digest algorithm has been made configurable via a property under the security-service configuration. The following post explains this in more detail.
Integrating JAAS LoginModules: Using the JSR-196 Login Bridge Profile
The LoginModule Bridge Profile is a provision in the JSR-196 (JASPIC) spec, by which a server-side message layer authentication module (ServerAuthModule) may delegate some security processing to JAAS LoginModules. Support for this profile existed in earlier releases of glassfish but we have never explained this in our documentations. The following post provides more details with a sample explaining how this can be done.
Interoperability with Oracle Identity Management Products
What is not Supported
Failover and Loadbalancing with SSL/IIOP is not supported in this release of GlassFish.