Sunday Feb 27, 2011

What's New in GlassFish V3.1 Security

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:

  1. Clustering and Centralized Administration
  2. 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

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.

PAM Realm

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 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 and 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. Keystore was tampered with, or password was incorrect


Caused by: 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, 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

 The glassfish LDAPRealm was configured to use Oracle OID and OVD products in both secure and non -secure modes and it was tested to work as expected.

What is not Supported

Failover and Loadbalancing with SSL/IIOP is not supported in this release of GlassFish.

What's New in Metro 2.1 Security

As most of you are aware  Metro 2.1 integrates into GlassFish Open Source Edition V3.1 release.  Project  Metro is composed of  the JAXWS runtime as the core along with JAXB  plus  implementation of the all the WS-\* specifications (a.k.a WSIT).  

The WSIT workspace has been modularized as part of the GlassFish  V3.1/Metro 2.1 release and now uses maven as its build system.  This is in line with the larger GlassFish V3.X modular design.  As part of this the Metro Security source code which was formerly located under the project (XWSS) is now an integral part of the WSIT workspace and currently builds as two modules (wsit/ws-sx/wssx-api,  wsit/ws-sx/wssx-impl).

  1. Support for Policy-Alternatives (Preliminary)
  2. Support for  JAAS KeyStoreLoginModule
  3. High Availability of Nonce Cache 
  4. High Availability of SecureConversation Sessions 
  5. Support for Signing Tokens not in message via STR-Transform
  6. WS-I BSP 1.1 and RSP 1.0 Compliance 
  7. Support for RSA-SHA256 and higher bit SignatureAlgorithms 
  8. WebServices Interoperability with other Oracle Products

 Support for Policy Alternatives

WS-Policy defines a policy to be a collection of policy alternatives, where each policy alternative is a collection of policy assertions. Till date most of the usages of Policy in Metro WebServices would have a Single Policy Alternative under the wsp:policy element, something like this :

        xmlns:wsp="" >
       <sp:Basic256Rsa15 />

But in the context of security and possibly in other WS-\* areas there can be a need for the WebService to accept different  types of end-user authentication tokens.  For example  a particular client of the WebSerivce might only be able to authenticate using Username/Password mechanims, whereas another client might want to use Certificates.

Policy-Alternatives as defined by WS-Policy provide the underlying framework in which a WebService can advertise  it ability to accept  multiple forms of client-authentication tokens.

The implementation of Policy-Alternatives in Metro Security is based on a Generic Framework that defines an SPI and  treats Alternatives as First-Class Citizens. However  for this release of Metro 2.1 the implementation of the SPI supports  Alternatives that take the following restricted form :

<wsp:Policy ..>







                                <sp:X509Token sp:IncludeToken="">





                                </sp:X509Token>                                                             </wsp:Policy>







                        <sp:UsernameToken sp:IncludeToken="">











                        <sp:InitiatorToken>                                                               <wsp:Policy>

                                <sp:X509Token sp:IncludeToken="">










                                <sp:X509Token sp:IncludeToken="">













                        <sp:SamlToken sp:IncludeToken="">










So here the WebService Policy  has two  alternatives, one having SymmetricBinding + UsernameToken (as-SignedSupportingToken) and the other alternative having AsymmetricBinding + SAMLToken (as-SignedSupportingToken).  From an authentication token perspective the WebService is indicating that it can accept either a Signed UsernameToken or a Singed SAMLToken.

The default SPI implementation tries to distinguish alternatvies by looking at the SingedSupportingToken. And it currently tries to recognize only a SAML or UsernameToken under the SingedSupportingTokens. If the implementation is unable to select an alternative upon receiving the client message then an exception would be thrown.  If the  Once the Alternative is selected the incoming message's inferred policy has to then completely match the policy of the selected alternative.

Also note that the alternatives support is primarily on the server side for a server to advertise the kinds of alternatives it can accept. For the client side the client would still have to choose a particular Alternative and create a custom localized  wsit-client.xml which references the single-alternative that the client wishes to use.  This choice would be based on the kind of Authentication Token the client wishes to use for Authentication. 

Note that the  Metro runtime on the client side would arbitrarily pick one of the alternatives when provided with a WSDL containing multiple alternatives.

In future releases the support for the kind of alternatives will be improved based on developer feedback and customer needs.  A fully generic implementation of PolicyAlternatives in the context of the WS-Policy and WS-SecurityPolicy universe would require dealing with the general  problem of Policy-Equivalence in the presence of wild-cards and exceptions.

Support for  JAAS KeyStoreLoginModule

This feature tries to utilize the publicly available JDK login module

Configuration of  KeyStoreLoginModule is supported for both  pure JAXWS based WebServices as well as JSR-109 WebServices deployed on GlassFish.  Of particular interest is the ability to use PKCS11 stores with this LoginModule. This is documented in the JavaSE PKCS11 guide.  The  post here further explains the use of this feature in Metro Security.

High Availability of NonceCache

The Metro 2.1 release supports LoadBalancing and HighAvailability of WebServices for the first time and it aligns itself with the larger release goal of GlassFish V3.1. There will be posts from other Metro developers who would talk in more detail about the general LoadBalancing and HighAvailability support in metro ( I shall point them out to soon in another post).

If you are not aware the WSS UsernameToken can contain a Nonce when the Password Digest Authentication is enabled :

<sp:UsernameToken sp:IncludeToken="
       <sp:WssUsernameToken10 />
       <sp:HashPassword />

or when Nonce is explicitly enabled under the UsernameToken as below :

<sp:UsernameToken sp:IncludeToken="
       <sp:WssUsernameToken10 />

The Metro SecurityRuntime caches Nonce values it receives in a Global NonceCache. Nonces remain in the NonceCache for a period specified by the property  (under GlassFish 3.1 security-service) "MAX_NONCE_AGE".  Whenever the runtime detects a repeated Nonce it would throw a SOAPFault back to the client indicating Nonce Replay. This provides protection against replay attacks. The default value of the MAX_NONCE_AGE property when not specified explicitly is 900000 milliseconds.

In Metro 2.1/GlassFish 3.1  when running in HighAvailability  mode the NonceCache becomes highly available by using the GlassFish 3.1 BackingStore API's.  Note an application (WebService in this case) can be made highly available by specifying the  --availabilityenabled option to the glassfish deploy command (asadmin deploy   --availabilityenabled=true  <other options>  application-archive)

Refer to the GlassFish 3.1 High Availability Administration Guide from the GlassFish OSE V3.1 Documentation for more details on High Availability support.

High Availability of SecureConversation Sessions

When a secure  webservice is deployed in high availability mode (as described above) then any SecureConversation Session(s) utilized by the service also become fail-safe.  More details on this will be provided by other metro developers. Specifically checkout Jiandong's blog page.

Support for Signing Tokens not in message via STR-Transform

Prior to Metro 2.1, the WS-SecurityPolicy assertion <sp:ProtectTokens/>  would fail to include a signature over the Token when the token is not physically present in the message (IncludeTokenPolicy==Never).  We have tried to fix this in Metro 2.1.  The WS-SecurityPolicy spec says the following about ProtectTokens assertion :

  • In the case of SymmetricBinding, the  main signature MUST cover the Signature Token 
  • In the case of AsymmetricBinding, the main signature MUST cover Initiator Token
  • Endorsing signature MUST also cover the supporting token. 

When the token is not present in the message then an STR-Transform is used to reference the token.  Note that when token in question is a SAML token and it is not present in the message then Metro would still fail to protect the token.

 Protecting the token (binding it to the message signature) is important to prevent a substitution attack.

WS-I BSP 1.1 and RSP 1.0 Compliance

 The Metro 2.1 release  was tested for WS-I BSP (Basic Security Profile 1.1) and RSP (Reliable Secure Profile 1.0)  compliance.  There was also an extensive interoperability testing done with the WCF Stack and a Metro to WCF interoperability white-paper was produced.

Support for RSA-SHA256 and higher bit SignatureAlgorithm 

The W3C working draft of XML Signature Syntax and Processing version 1.1  recommends the use of SHA-256 over SHA-1 because recent advances in cryptanalysis have cast doubt on the long-term collision resistance of SHA-1.   Metro 2.1 adds experimental support for this using a proprietary WS-SecurityPolicy extension to the  <sp:AlgorithmSuite/> assertion. More details on this can be found in the following post.

WebServices Interoperability with other Oracle Products

A few important Security Scenarios which make use of  X509Token, SAML,  UsernameToken and PolicyAlternatives were  identified and tested using Metro Client and  WebService built using  Oracle(11g) SOASuite,  OSB, ADF and WebLogic Server respectively.  Reverse testing (as applicable) involving a Metro Service and clients built using the mentioned Oracle Products was also done.  Successful Interoperability was established and issues found during the testing were fixed.

Single Sign-On Using the GlassFish V3.1 OAM Security Provider


The Oracle GlassFish Server V3.1  release has a new Security Provider called the OAM Security Provider.  OAM stands for Oracle Access Manager.   Product Documentation for the Oracle GlassFish Server V3.1  is  available here.   The detailed documentation on configuring  the OAM Security Provider is in a chapter  called Integrating Oracle Access Manager  in the Oracle® GlassFish Server 3.1 Security Guide (Part No: 821-2435).

Oracle Access Manager allows users of your applications or IT systems to log in once and gain access to a broad range of IT resources. Oracle Access Manager provides an identity management and access control system that is shared by all your applications. The result is a centralized and automated single sign-on (SSO) solution for managing who has access to what information across your entire IT infrastructure.

The OAM Security Provider  provides a way for  WebApplications hosted on GlassFish  to be secured using  OAM and utilizes the capabilities of OAM to manage Single Sign-On (SSO).  

OAM Terminology

A WebGate is a Web server plug-in access client that intercepts HTTP requests for Web resources and forwards them to the Access Server for authentication and authorization. An AccessGate is a form of access client that processes requests for Web and non-Web resources (non-HTTP) from users or applications.

Usecases and Integration Architecture 

The OAM Security Provider is implemented as a Servlet Layer JSR-196 Server Authentication Module (SAM) and can be configured for use with WebApplications hosted on GlassFish.  The documentation link mentioned above describes in detail  how one can configure the Provider for use with WebApplications hosted on GlassFish.   The general documentation on how to configure a SAM with GlassFish is also available in a chapter called Administering Message Security of the Security Guide.

 The OAM Security Provider acts as an Authenticator and/or  Identity-Asserter depending on the usecase. The Authenticator function is exercised when GlassFish is facing the end-user directly. In the Authenticator function the OAM Security Provider does the following :

  1. Handles Authentication of the end-user at  OAM.  It challenges the user using an Authentication scheme (One of FORM, BASIC, CERTIFICATE) configured for the resource at OAM.  And upon successful authentication, OAM creates an OBSSOSession and returns it to the Provider.
  2. Setting a Cookie (ORA_GF_ObSSOCookie) in the response, created from the session identifier of the OBSSOSession.
  3. Sets the CallerPrincipal (into the Client Subject) in a form that is understood by the GlassFish Container
  4. Extracts Group Membership information for the authenticated user from the OAM backend for use by the container in its Authorization Decisions.

 The Security Provider acts as an Identity Asserter in two cases.  

  1. When GlassFish server is front-ended by a Proxy WebServer and an OAM WebGate configured at the Proxy handles the authentication of the end-user.  This case is not supported by the current release of the OAM Security Provider and will be supported in future. In this case the Provider would recieve a Cookie or Authenticated User Principal in a special header agreed upon between the Provider and the WebGate. Since the only way GlassFish server can recieve requests is via the proxy this agreement is secure.
  2. When GlassFish server is facing the end-user directly but it recieves Cookie (that was probably set by an earlier authentication step).

In the Identity Asserter function,  the OAM Security Provider does the following :

  1.      Checks if the Cookie received is still valid and returns an error if not valid
  2.      In case the Cookie represents a valid OBSSOSession of a Logged In User then it does exactly the same steps 3 and 4 as in the Authenticator function.

After successful authentication the authenticated client subject is passed over to the Container's authorization engine to check if  the  principal is authorized to access the GlassFish hosted resource.  The final decision to allow access to the resource is thus dictated by the GlassFish authorization engine based on  security-constraints defined for the resource (in web.xml and glassfish-web.xml) which define the allowed roles.


 Provisioning the OAM Security Provider involves tasks on both the GlassFish (acting as Client to OAM) and the OAM Server Instance side.

Configuration on the GlassFish side involves the following: 

  •   Configuring the provider on the glassfish side as a httpservlet layer SAM,
  •   Configuring the properties that control the various aspects of the provider.
  •   Binding the provider to the web application(s)
  •   Configuring an AccessGate (OAM 10g Terminology) that can communicate with the OAM Access Server.  AccessGate handles all the communications between the Security Provider and the Access Server. 

The OAM Security Provider (acting as an AccessGate) uses the Access Server SDK 10g API's to communicate with the Access Server. The level of security for the communication between the GlassFish AccessGate and the OAM Access Server can be configured (from open to secured with mutual SSL), when provisioning the AccessGate. 

Configuration on the OAM Server Side varies based on the version of the OAM Server. Specifically both 10g and 11g versions of OAM are supported.

The chapter Integrating Oracle Access Manager drescribes the details of how to provision the OAM and the GlassFish side.  

Establishing the Resource(s) which are being Protected  

One particular aspect of  provisioning that i would like to focus here is establishing the web resource being protected. The resource details need to be configured at  OAM, in 10g it would be part of  the PolicyDomain that you create under the PolicyManager. The  10g PolicyDomain is called ApplicationDomain in 11g ( and can be created from the PolicyConfiguration tab on the 11g console).

By default the OAM Security Provider would assume that  the resource being accessed is  a Proxy resource whose value is the following java string.

 "//" + <OAMHostIdVariation> + "/"+  glassfish-default  

 This is sufficient if the intent of using the provider is to perform authentication/identity-assertion and establish SSO for a bunch of applications configured to use the provider, while leaving the final authorization decision to the Containers authorization engine.  When using this scheme there is no need to configure any authorization policies at OAM for the resource  /glassfish-default. Neither will the authorization policies configured at OAM be checked.

 As clarified earlier, final authorization decision to allow the resource access lies with the GlassFish authorization engine and that would be based on the authorization policies specified declaratively (in web.xml and glassfish-web.xml) and/or through annotations on the servlet (refer JavaEE 6 tutorial for details of @ServletSecurity annotation).

 However if one desires, it is possible to ask the provider to instead construct the resource being accessed  based on the HttpRequest (request.getRequestURI()).  This can be done by setting the Provider option oam.check.resource.access  to true.  Note that using this scheme would mean that the individual resources (URI's) are configured at the  PolicyDomain/ApplicationDomain in the OAM Server.

 In addition the following two options and can be configured at the provider .  As the names suggest the first one would append the port number of request to the <OAMHostIdVariation> and the second one tells the provider to include the query parameters from the request in the resource access check.

Note that when the option oam.check.resource.access  is enabled, then any authorization policies configured for the resource  at OAM  will also be checked.  In other words final access to the resource will be allowed only if the authorization policies at both the OAM and the ones specified in the JavaEE WebApplication are satisfied by the authenticated client.

 Note that the HTTP Method (GET/POST) and the http url scheme (https/http) are also part of the final resource representation that OAM server uses. 

 The <OAMHostIdVariation>  is the value of the property oam.resource.hostid.variation configured at the SAM. When not specified the OAM provider would use HttpRequest.getServerName() as the value of this property. When configured its value should match one of the  Host Identifier(s) configured under the OAM PolicyConfiguration Tab (11g)/Access System Configuration Tab(10g).  You use Host identifiers to simplify the identification of a Web/Application server that hosts resources you want to protect with Oracle Access Manager.

Process overview: User authentication

For the usecase of a client attempting to access a GlassFish  resource protected at OAM using FORM/BASIC authentication, the following interaction diagram shows the messages that flow between the browser (client), the OAM Security Provider, and the OAM Server.  

Process Overview

  1. A user attempts to access a Oracle Access Manager-protected GlassFish resource.
  2. GlassFish Server challenges the user for a username and password (not Oracle Access Manager) using a predefined  login form because the application’s deployment descriptor requires authentication from the container. You may use your own login form, which must can be specified as an option to the Security Provider.
  3. GlassFish Server forwards the username and password to the Security Provider for authentication and authorization.
  4. The Authentication Provider uses the AccessGate to communicate with the Access Server to verify the user's identity.
  5.  If authentication is successful, the Security Provider would create a Subject with the authenticated principal and also set a Cookie in the response. 
  6.  The control returns to Container Authorization mechanism which would check if the  user has permission to access the requested resource.  
  7.  If authorization is successful,  GlassFish Server enables the user to access the requested resource.




February 2011