Policy Files, The SecurityManager, and Glassfish Access Control

Glassfish performs its container access decisions according to the Java Authorization Contract for Containers, aka (JACC or JSR 115). JACC mandates that servlet and ejb containers perform their container mediated access decisions (i.e., pre-dispatch caller access decisions, and application embedded privilege tests -> e.g., isCallerInRole) by employing the policy decision interfaces of the Standard Edition JRE.

JACC aligns the declarative security model of Java Enterprise Edition with the JAAS-based policy subsystem of the JRE. Since the policy subsystem of the JRE supports replacability (see Policy.setPolicy()), reliance on JACC facilitates replacability of the container policy infrastructure, including for the purpose of integrating with an external authorization subsystem or service provider.

One of the challenges of mapping container access decisions to the single Policy subsystem of the JRE was the differentiation of per application policy scopes. To support such differentiation, the JACC contract defined the concept of a policy context to represent a distinct policy scope. The JACC contract requires that containers identify the policy context in which an access decision is to be performed (prior to requesting the decision from the policy subsystem).

The JACC compatible Policy provider that is shipped with Glassfish, internally multiplexes policy decisions to a subordinate implementation of Java.security.Policy corresponding to the policy context in which the decision is to be performed. There is a default policy context that is used for decisions made outside of the context of any specific Java EE application or module, and the grant statements of the default policy context are included in every application/module specific policy context. The subordinate implementations of Policy within the Glassfish policy provider are all instances of sun.security.provider.PolicyFile which implements the default Policy and syntax of the Sun JRE (as described in PolicyFiles.html ).

When the Glassfish application server starts up, it establishes the default policy context by merging the contents of the server.policy file, with the contents of all of the files identified via policy url's in $JAVA_HOME/jre/lib/security/java.security. If you are responsible for the security administration of your application server, you will want to familiarize yourself with the contents of the java.security file. You should note that in the typical configuration of the JRE, the default policy context will contain the grant statements combined from the following 3 files.


Note that .java.policy is a "hidden" file that when present, is obtained from the home directory of the user who started the Glassfish server instance. It would probably be best to delete the .java.policy url from your java.security file, especially as explained below, if one or more system administrators may have have included an unqualified grant of java.security.AllPermission in their .java.policy file.

During deployment, the Glasfish policy provider translates security-contraints, method-permissions and common security annotations into grant statements and writes them to a file called granted.policy which is created in a policy directory corresponding to the application module.


if the application policy, as defined in the declarative constructs or in the common security annotations, indicates that access to one or more application resources is to be denied under all circumstances, then there will an additional file called excluded.policy in the same directory.

As noted above the policy in effect for the corresponding application module will be the union of the permissions granted to the default policy context and the permissions granted for the module in the corresponding granted.policy file and minus all the permissions excluded by the grant statements in the excluded.policy file (if there is one).

Independent of whether or not a SecurityManager is enabled in the JRE, The JACC contract requires that the container perform its access control decisions, and that the results of these decisions properly reflect whether the caller is in a permitted role. To achieve this effect, the Glassfish containers perform their access decisions by interacting directly with the policy subsystem (by calling Policy.implies() or Policy.getPermississions() which bypass both the SecurityManager and the AccessCOntroller). Moreover, in the typical Glassfish configuration, the System/JRE SecurityManager is NOT enabled.

Why you should not configure an unqualified grant of AllPermission in the default policy context!

One last comment before I end this note. It's probably never a good idea to add an unqualified grant of java.security.AllPermission to any of the policy files that are or could be combined into the Glassfish default policy context, as doing so will have the effect of neutering all of the container access decisions for all applications including the system applications. The effect on the system applications will effectively undermine the security of the container administration subsystems. As noted above, the System SecurityManager is typically disabled by default, and even if it were not, then adding such a grant to the default policy context is not an appropriate way to disable the SecurityManager, for the reason described above, and because neutering the Policy subsystem has the undesirable characteristic of requiring that cycles be wasted to perform policy checks that will never produce an interesting result. If you wish to disable the System SecurityManager please follow the instructions in the Glassfish Admin. Guide. The focus of this comment is on the use of unqualified grants of AllPermission in the default policy context. You may find utility in using such a grant in an application specific policy file.

The following is an example of an unqualified grant of AllPermission. It is unqualified, because the grant is made without restriction to CodeBase, Signer, or Principal set.

grant {
	permission java.security.AllPermission;

Stay tuned for future JACC related postings. I intend to give an overview of how one would go about creating a simple JACC provider, how one can go about localizing the non-portable aspects of principal-2-role mapping for use by a JACC provider, and how one might create a jacc provider that is able to employ resource scoped principal-2-role mappings.


Thanks for the post. I am amazed about the lack of online documentation regarding creating and deploying a custom JACC provider. I'm eagerly awaiting some more details about this.

Posted by Dave Pease on July 04, 2008 at 03:51 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« October 2016