JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Application Development Guide
search filter icon
search icon

Document Information


Part I Development Tasks and Tools

1.  Setting Up a Development Environment

2.  Class Loaders

3.  Debugging Applications

Part II Developing Applications and Application Components

4.  Securing Applications

Security Goals

GlassFish Server Specific Security Features

Container Security

Declarative Security

Application Level Security

Component Level Security

Programmatic Security

Roles, Principals, and Principal to Role Mapping

Realm Configuration

Supported Realms

How to Configure a Realm

How to Set a Realm for an Application or Module

Creating a Custom Realm

JACC Support

Pluggable Audit Module Support

Configuring an Audit Module

The AuditModule Class

The server.policy File

Default Permissions

System Properties

Changing Permissions for an Application

Enabling and Disabling the Security Manager

Configuring Message Security for Web Services

Message Security Providers

Message Security Responsibilities

Application Developer Responsibilities

Application Deployer Responsibilities

System Administrator Responsibilities

Application-Specific Message Protection

Using a Signature to Enable Message Protection for All Methods

Configuring Message Protection for a Specific Method Based on Digital Signatures

Understanding and Running the Sample Application

To Set Up the Sample Application

To Run the Sample Application

Programmatic Login

Programmatic Login Precautions

Granting Programmatic Login Permission

The ProgrammaticLogin Class

User Authentication for Single Sign-on

Adding Authentication Mechanisms to the Servlet Container

The GlassFish Server and JSR 196

Writing a Server Authentication Module

Sample Server Authentication Module

Compiling and Installing a Server Authentication Module

Configuring a Server Authentication Module

Binding a Server Authentication Module to Your Application

5.  Developing Web Services

6.  Using the Java Persistence API

7.  Developing Web Applications

8.  Using Enterprise JavaBeans Technology

9.  Using Container-Managed Persistence

10.  Developing Java Clients

11.  Developing Connectors

12.  Developing Lifecycle Listeners

13.  Developing OSGi-enabled Java EE Applications

Part III Using Services and APIs

14.  Using the JDBC API for Database Access

15.  Using the Transaction Service

16.  Using the Java Naming and Directory Interface

17.  Using the Java Message Service

18.  Using the JavaMail API


The server.policy File

Each GlassFish Server domain has its own global J2SE policy file, located in domain-dir/config. The file is named server.policy.

The GlassFish Server is a Java EE compliant application server. As such, it follows the requirements of the Java EE specification, including the presence of the security manager (the Java component that enforces the policy) and a limited permission set for Java EE application code.

The following topics are addressed here:

Default Permissions

Internal server code is granted all permissions. These are covered by the AllPermission grant blocks to various parts of the server infrastructure code. Do not modify these entries.

Application permissions are granted in the default grant block. These permissions apply to all code not part of the internal server code listed previously. The GlassFish Server does not distinguish between EJB and web module permissions. All code is granted the minimal set of web component permissions (which is a superset of the EJB minimal set). Do not modify these entries.

A few permissions above the minimal set are also granted in the default server.policy file. These are necessary due to various internal dependencies of the server implementation. Java EE application developers must not rely on these additional permissions. In some cases, deleting these permissions might be appropriate. For example, one additional permission is granted specifically for using connectors. If connectors are not used in a particular domain, you should remove this permission, because it is not otherwise necessary.

System Properties

The following predefined system properties, also called variables, are available for use in the server.policy file. The system property most frequently used in server.policy is ${com.sun.aas.instanceRoot}. For more information about system properties, see the asadmin create-system-properties command in the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

Table 4-1 Predefined System Properties

depends on operating system
Specifies the directory where the GlassFish Server is installed.
depends on operating system
Specifies the top level directory for a server instance.
Specifies the name of the host (machine).
depends on operating system
Specifies the installation directory for the Java runtime.
depends on operating system
Specifies the library directory for the GlassFish Server Message Queue software.
Specifies the name of the configuration used by a server instance.
Specifies the name of the server instance. This property is not used in the default configuration, but can be used to customize configuration.
Specifies the name of the cluster. This property is only set on clustered server instances. This property is not used in the default configuration, but can be used to customize configuration.
Specifies the name of the domain. This property is not used in the default configuration, but can be used to customize configuration.

Changing Permissions for an Application

The default policy for each domain limits the permissions of Java EE deployed applications to the minimal set of permissions required for these applications to operate correctly. Do not add extra permissions to the default set (the grant block with no codebase, which applies to all code). Instead, add a new grant block with a codebase specific to the applications requiring the extra permissions, and only add the minimally necessary permissions in that block.

If you develop multiple applications that require more than this default set of permissions, you can add the custom permissions that your applications need. The com.sun.aas.instanceRoot variable refers to the domain-dir. For example:

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/-" {

You can add permissions to stub code with the following grant block:

grant codeBase "file:${com.sun.aas.instanceRoot}/generated/-" {

In general, you should add extra permissions only to the applications or modules that require them, not to all applications deployed to a domain. For example:

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/MyApp/-" {

For a module:

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/MyModule/-" {

Note - Deployment directories may change between GlassFish Server releases.

An alternative way to add permissions to a specific application or module is to edit the granted.policy file for that application or module. The granted.policy file is located in the domain-dir/generated/policy/app-or-module-name directory. In this case, you add permissions to the default grant block. Do not delete permissions from this file.

When the GlassFish Server policy subsystem determines that a permission should not be granted, it logs a server.policy message specifying the permission that was not granted and the protection domains, with indicated code source and principals that failed the protection check. For example, here is the first part of a typical message:

JACC Policy Provider: PolicyWrapper.implies, context(null)- 
permission((java.util.PropertyPermission write)) 
domain that failed(ProtectionDomain
(file:/E:/glassfish/domains/domain1/applications/cejug-clfds/ ... )

Granting the following permission eliminates the message:

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/cejug-clfds/-" {
    permission java.util.PropertyPermission "", "write";

Note - Do not add to the server.policy file for application code. Doing so completely defeats the purpose of the security manager, yet you still get the performance overhead associated with it.

As noted in the Java EE specification, an application should provide documentation of the additional permissions it needs. If an application requires extra permissions but does not document the set it needs, contact the application author for details.

As a last resort, you can iteratively determine the permission set an application needs by observing AccessControlException occurrences in the server log.

If this is not sufficient, you can add the JVM option to the domain. Use the following asadmin create-jvm-options command, then restart the server:

asadmin create-jvm-options

For more information about the asadmin create-jvm-options command, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

You can use the J2SE standard policytool or any text editor to edit the server.policy file. For more information, see

For detailed information about policy file syntax, see

For information about using system properties in the server.policy file, see

For detailed information about the permissions you can set in the server.policy file, see

The Javadoc for the Permission class is at

Enabling and Disabling the Security Manager

The security manager is disabled by default.

In a production environment, you may be able to safely disable the security manager if all of the following are true:

Disabling the security manager may improve performance significantly for some types of applications.

To enable the security manager, do one of the following: