Monday Jan 11, 2010

SEC5054: Certificate has expired

One of the authority certificates in the Glassfish truststore (i.e., cacerts.jks) expired on Jan 7, 2010. On startup, Glassfish will log a message (to server.log) indicating that the following certificate has expired.

Version: V1
  Subject: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
  Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2

  Key:  SunPKCS11-Solaris RSA public key, 1000 bits (id 17891456, session object)
  public exponent: 
  Validity: [From: Tue Nov 08 19:00:00 GMT-05:00 1994,
               To: Thu Jan 07 18:59:59 GMT-05:00 2010]
  Issuer: OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
  SerialNumber: [    02ad667e 4e45fe5e 576f3c98 195eddc0]

The expired authority certificate will be removed in update 18 of Java SE 6. It will also be removed from the Glassfish truststore.

No action is required on your part, as all certificates issued under the expired authority certificate have also expired.

If you would like to stop your installation of Glassfish from reporting the presence of the expired authority certificate, you can use keytool to remove the certificate from the Glassfish truststore.

=> cd domains/domainX/config
=> cp cacerts.jks
=> keytool -delete -keystore cacerts.jks -alias verisignserverca
Enter keystore password: 

to prevent the expired cert from reappearing in subsequently created domains, The cert should also be removed from the template truststore.

=> cd glassfish/lib/templates
=> cp cacerts.jks
=> keytool -delete -keystore cacerts.jks -alias verisignserverca
Enter keystore password: 

For more details on the expired certificate please see:

The Glassfish V3 admin guide may be found at:

For versions and installations of Glassfish that use Network Security Services, i.e., NSS, the certutil command may be used to remove the expired certificate from the cert8.db file, and the corresponding cert8.db template file. For example:

==> cd directory-where-cert8.db-is-located
==> cp cert8.db
==> certutil -D -n "Verisign/RSA Secure Server CA"

Monday Jan 04, 2010

How to Configure an Alternative Glassfish Container Policy Provider

Glassfish v3 bundles 2 alternative container policy providers. By default, Glassfish is configured to use a file-based provider based on the PolicyFile implementation of the JDK. Glassfish can be reconfigured to use an alternative provider by setting a specific value for the "jacc" attribute of the security-service element in domain.xml. The value of this attribute must be the name of a jacc-provider sub-element within security-service element. The default value of the "jacc" attribute is "default", which matches the name of the file based jacc-provider. Setting the value of this attribute to "simple", will cause the in-memory provider to be used. The admin console may be used to define additional jacc-provider configurations in domain.xml, and then any such provider can be configured for use by the Glassfish security-service, by setting its name as the value of the "jacc" attribute.

Thursday Jan 29, 2009

Adding Pluggable Authentication to all Servlet 3.0 Containers

Do you have an opinion as to whether Compatible Servlet 3.0 containers should be required to support the Servlet Container Profile of JSR 196? Support for the profile would ensure common integration of portable authentication mechanism implementations with the security-constraint processing machinery of any compatible Servlet container.[Read More]

Tuesday Jan 06, 2009

Defining Security Constraints on Content under Glassfish Docroot

This entry describes how to define security constraints on content served by the default web module. [Read More]

Tuesday Dec 16, 2008

Servlet 3.0: HTTP method exception lists in security constraints

The Servlet EG has tentatively agreed to a change to the Servlet 3.0 security constraint grammar that will allow security constraints to be targeted to all HTTP methods other than those specifically listed. This change will facilitate the mapping of the common security annotations to security constraints which will facilitate adoption, by Servlet 3.0, of the use of the common security annotations on Servlets.[Read More]

Friday Nov 07, 2008

Prelude includes Portable, In-Memory JACC Provider

We made some enhancements in Prelude to improve JACC policy provider replacability, and we added a new portable in-memory JACC Policy provider that can be configured as an alternative to the file-based JACC Policy provider. The file-based provider is configured by default. To enable the in-memory provider, do the following:
  • stop the application server (i.e., asadmin stop-domain)
  • edit domain.xml and add or change the security-service element to define the attribute jacc="simple"
  • restart the application server. (i.e, asadmin start-domain)
The in-memory provider was developed both to provide a simpler and more performant alternative, as well as to serve as a sample to help others develop their own providers. Portability was achieved by defining a JACCRoleMapper interface, and by defining the provider such that it can be trained (via a system property, i.e., to use a system specific implementation of the JACCRoleMapper interface. The source of the in-memory provider is available in the project repository.

Tuesday Aug 19, 2008

Servlet security constraints - summary and recommendations

This entry describes the Servlet security constraint model and offers some recommendations intended to help ensure that your application is protected as you intend it to be. Thanks to Jeff Williams of Aspect security for making me aware of common practice, and for his suggestions for simplifying the Servlet constraint model.[Read More]

Monday Aug 18, 2008

Using JACC to determine a caller's roles

This entry defines a technique for using the standard interfaces provided by JACC to implement a utility that returns all the role memberships of the caller of a Servlet or EJB). This technique may be used to decouple the calling application from the set of declared roles.[Read More]

Tuesday Jan 22, 2008

Pluggable Authentication in the Glassfish Web Tier

You can inject a new network authentication mechanism in the Glassfish Servlet container by:
  • implementing a JSR 196 server authentication module (i.e., a SAM), and
  • configuring the SAM as a message-security-provider via the Glassfish admin console, and
  • binding the SAM for use by your application via sun-web.xml.

A SAM differs from a custom realm in that the SAM can control the HTTP authentication dialog, while a realm is typically used by a system controlling the dialog (such as a SAM) to validate or augment credentials extracted from the exchanged messages. JSR 196 is also used by (and available within) the client and server-side web service pipelines of the Glassfish METRO stack.[Read More]

Tuesday Jan 15, 2008

How to define an ANYONE role in Glassfish

An ANYONE role is a role that is granted to every authenticated user and only to authenticated users. Any Glassfish realm may be configured such that it assigns one or more group principals as a side effect of any successful authentication at the realm. Any application role that is mapped to one of the assigned group principals can be used as an ANYONE role. An application defines an ANYONE role as follows:

  • configure the "assign.groups" property of the Glassfish realm used for the application. This can be accomplished by using the admin console. Login to the console and navigate to the realm specific configuration screen found under configuration => security => realms. In the "Assign Group:" input box on that screen, specify the name of the group principal that you want to be assigned by the realm.
  • declare a role either within the corresponding portable deployment descriptor, or by using either the @declareRoles or @rolesAllowed annotations.
  • map the assigned group principal to the declared role, as described in Principal 2 role mapping and Glassfish. If the default mapping is employed to map the group principal to the role, the name of the role must be equivalent to that of the assigned group. Otherwise, the role may be given any name.

Tuesday Dec 18, 2007

Policy Files, The SecurityManager, and Glassfish Access Control

Glassfish uses Jacc for its container access decisions. The container access decisions are performed independent of whether a System SecurityManager is configured for the Glassish Server. You should not define an unqualified grant of AllPermission in server.policy, .java.policy, or in any of the policy files identified in jre/lib/security/ JACC leverages the replacability afforded by the JRE to enable replacability of the container policy decision subsystem.[Read More]

Friday Nov 16, 2007

principal 2 role mapping and Glassfish

When you deploy a portable application or module on Glassfish, you don't need to define an application specific principal to role mapping. Glassfish allows you to activate a default mapping that will be applied on behalf of all applications that are (subsequently) deployed without an application specific mapping. This feature of glassfish is described in more detail in: Roles, Principals, and Principal to Role Mapping. The default mapping is canonical in that it maps groups to same-named roles. For example group principal "user" is mapped to role "user". Applications or modules deployed before the default mapping is activated, are unaffected.



« July 2016