The J2SE Security Model

Java bytecode running within a JVM can potentially perform malicious acts. Because of this, all code must run under the auspices of a security manager—which every JVM includes. The security manager provides highly granular control over what code can and cannot do. Although most applications run under the default security manager, the J2SE specification allows for customized security managers to be implemented and executed within the JVM.

Security managers must be told how to control access to restricted resources. This is accomplished with a security policy file. When the JVM is started, command-line options allow the use of a custom security manager and policy file. If no policy file is specified, the default policy file that is shipped with the Java runtime is utilized.

A policy file consists of one of more grant entries. Each grant entry consists of source code/permission pairs. The source code can be specified using an URL representing the path of the classes, with or without wildcards. The permissions are specified by a list of access rights to restricted resources that the source code is granted. The J2SE specification includes provisions for code to be signed or encrypted using keys found in digital certificates. Grant entries can also provide access to restricted resources based on the name of the code signer. Both methods of granting permissions are intended to give only trusted and known classes access to restricted resources.

Both J2SE and J2EE come with a utility called keytool. This utility is used to create digital certificates. These certificates can be used in a development environment. However, for a production environment, a Certificate Authority such as VeriSign or Entrust should be used to digitally sign the certificate and put it in a public directory. The J2EE version of keytool adds a Java cryptographic extension provider that implements RSA algorithms and thus allows RSA-signed certificates to be imported. The next chapter will take you through the process of generating a digital certificate, having it signed by a CA, importing it into WebLogic Server, and using it with the SSL protocol.

BEA WebLogic Server uses a customized policy file named weblogic.policy that is located in [WEBLOGIC_HOME]\weblogic81\server\lib. This file sets permissions for WebLogic Server itself and for the applications running within it. Using this file unmodified is usually acceptable, but when running third-party software, you might want to restrict resources available to that software. This can be accomplished by modifying the weblogic.policy file. More information can be found at http://e-docs.bea.com/wls/docs81/secmanage/index.html.