Oracle iPlanet Web Server 7.0.9 Developer's Guide to Java Web Applications

Chapter 8 Securing Web Applications

This chapter describes the basic goals and features of Web Server security features related to the Java Servlet Container. It also describes how to write secure Java web applications containing components that perform user authentication and access authorization tasks.

This chapter has the following sections:

Supported Security Features

Web Server provides highly secure, interoperable, and distributed component computing based on the Java EE security model. The security goals for Web Server include the following:

For more information about Java EE security, see the Chapter 6, Certificates and Keys, in Oracle iPlanet Web Server 7.0.9 Administrator’s Guide

Common Security Terminology

This section provides an overview of the common security terminology.

The most common security processes are authentication, authorization, realm assignment, and role mapping.

Authentication

Authentication verifies the user. For example, when the user provides a user name and password in a web browser, if those credentials match the permanent profile stored in the active realm, the user is authenticated. The user is associated with a security identity for the remainder of the session. For more information on authentication realms, see Managing Authentication Realms in Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

Authorization

Authorization permits a user to perform desired operations after being authenticated. For example, a human resources application might authorize managers to view personal employee information for all employees, but allow employees to view only their own personal information.

Realms

A realm, also called a security policy domain or a security domain in the Java EE specification, is a scope over which a common security policy is defined and enforced by the security administrator of the security service. Supported realms in Web Server are file, ldap, certificate, solaris, custom, and native.

Java EE Application Role Mapping

In the Java EE/Servlet security model, a client may be defined in terms of a security role. For example, a company might use its employee database to generate both a company-wide phone book application and payroll information obviously, While all employees might have access to phone numbers and email addresses, only some employees would have access to the salary information. Employees with the right to view or change salaries might be defined as having a special security role.

A role is different from a user group in that a role defines a function in an application, while a group is a set of users who are related in some way. For example, members of the groups astronauts, scientists, and pilots all fit into the role of SpaceShuttlePassenger.

In Web Server, roles correspond to users, groups or both used and groups configured in the active realm.

Security Features Specific to the Web Server

In addition to supporting the Java EE 1.4 security model, Web Server also supports the following features that are specific to the Web Server:

This section discusses the following:

Web Server Security Model

Secure applications require a client to be authenticated as a valid application user and have authorization to access servlets and JSPs.

Applications with a secure web container may enforce the following security processes for clients:

Authentication is the process of confirming an identity. Authorization means granting access to a restricted resource to an identity. Access control mechanisms enforce these restrictions. Authentication and authorization can be enforced by a number of security models and services.

Web Server provides authentication and authorization support through the following mechanisms, which are discussed in this section:

Whether performed by the ACL subsystem or the Java EE/Servlet authentication subsystem, authentication and authorization are still the two fundamental operations that define secure web content.

ACL-Based Authentication and Authorization

ACL-based access control is described at length in the Configuring Access Control in Oracle iPlanet Web Server 7.0.9 Administrator’s Guide. This section provides a brief overview of the key concepts.

Web Server supports authentication and authorization through the use of locally stored ACLs, which describe what access rights a user has for a resource. For example, an entry in an ACL can grant a user named John read permission to a particular folder named misc:


acl "path=/export/user/990628.1/docs/misc/";
  authenticate (user,group) {
      database = "default";
      method = "basic";
   };
   deny (all)
  (user = "John");
   allow (read);

            

The core ACLs in Web Server support three types of authentication: basic, certificate, and digest.

Basic authentication relies .

The ACL-based access control model includes the following features:

In addition, the Web Server SSL engine supports external crypto hardware to offload SSL processing and to provide optional tamper-resistant key storage.

For more information about ACL-based access control and the use of external crypto hardware, see the Web Server Administrator’s Guide.

Java EE/Servlet-Based Authentication and Authorization

, In addition to providing ACL-based authentication, Web Server also implements the security model defined in the Java EE 1.4 specification to provide several features that help you develop and deploy secure Java web applications.

A typical Java EE-based web application consists of the following parts, access to any or all of which can be restricted:

The Java EE servlet-based access control infrastructure relies on the use of security realms. When a user tries to access the main page of an application through a web browser, the web container prompts for the user's credential information. The container then passes the information for verification to the realm that is currently active in the security service.

A realm, represents a set of known users along with optional group membership information. The main implementation also encapsulates a mechanism for performing authentication against the data set.

The main features of the Java EE/Servlet-based access control model are described below:

Web Application and URL Authorizations

Secure web applications may have authentication and authorization properties. The web container supports three types of authentication: basic, certificate, and form-based. The core ACLs support basic, certificate, and digest. For more information about ACL configuration, see the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

When a browser requests an application URL that requires authentication, the web container collects the user authentication information, for example, user name and password and passes it to the security service for authentication.

For Java EE web applications, Web Server checks the application's web.xml file for information on which parts of the application are protected, and which roles are authorized to access. It also checks sun-web.xml to see whether the currently authenticated user belongs to one of the required roles, either directly through user mapping or indirectly through group mapping.

Container Security

The component containers are responsible for providing Java EE application security. Two security forms are provided by the container: programmatic security and declarative security.

Programmatic Security

In programmatic security, a servlet uses method calls to the security API, as specified by the Java EE security model, to make business logic decisions based on the caller or remote user's security role. Programmatic security should only be used when declarative security alone is insufficient to meet the application's security model.

The Java EE 1.4 specification defines programmatic security with respect to servlets as consisting of two methods of the servlet HttpServletRequest interface. Web Server supports these interfaces as defined in the specification.

In addition to the programmatic security defined in the Java EE specifications, Web Server also supports programmatic login. For more information, see Programmatic Login.

Declarative Security

Declarative security means that the security mechanism for an application is declared and handled externally to the application. Deployment descriptors describe the Java EE application's security structure, including security roles, access control, and authentication requirements.

Web Server supports the DTDs specified by the Java EE 1.4 specification, and has additional security elements included in its own deployment descriptors. Declarative security is the application deployers responsibility.

User Authentication by Servlets

Web Server supports the web-based login mechanisms required by the Java EE 1.4 specification :

The login-config element in the web.xml deployment descriptor file describes the authentication method used, the application's realm name displayed by the HTTP basic authentication, and the form login mechanisms attributes.

The login-config element syntax is as follows:

<!ELEMENT login-config (auth-method?,realm-name?,form-login-config?)>

Note –

The auth-method subelement of login-config is optional. However, but if it is not included, the server defaults to HTTP Basic Authentication, which is not very secure.


For more information about web.xml elements, see the Java Servlet 2.5 specification at

http://java.sun.com/products/servlet/download.html

For more information on sun-web.xml elements, see Chapter 9, Deploying Web Applications.

HTTP Basic Authentication

HTTP basic authentication (RFC 2617) is supported by Web Server. Because passwords are sent with base64 encoding, this authentication type is not very secure. Use SSL or another equivalent transport encryption to protect the password during transmission.

SSL Mutual Authentication

SSL 3.0 and the means to perform mutual client/server certificate-based authentication is a Java EE 1.4 specification requirement. This security mechanism provides user authentication using HTTPS (HTTP over SSL). For more information, see Creating a Configuration in Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

Form-Based Login

The login screen's look and feel cannot be controlled with the HTTP browsers built-in mechanisms. Java EE can to package a standard HTML or servlet JSP based form for logging in. The login form is associated with a web protection domain and is used to authenticate previously unauthenticated users.

Because passwords are sent unless protected by the underlying transport, this authentication type is not very secure. Use of SSL or another equivalent transport encryption to protect the password during transmission.

For the authentication to proceed appropriately, the login form action must always be j_security_check. For more information, see Chapter 4, Developing Servlets.

The following HTML sample shows how to program the form in an HTML page:


<form method="POST" action="j_security_check">
        <input type="text" name="j_username">
         <input type="password" name="j_password">
      </form>

         

You can specify the parameter encoding for the form. For details, see parameter-encoding Element.

User Authentication for Single Sign-On

Single sign-on across applications on the Web Server is supported by the Web Server servlets and JSPs. This feature allows multiple applications that require the same user sign-on information to share this information between them, rather than having the user sign on separately for each application. These applications are created to authenticate the user once. When needed, this authentication information is propagated to all other involved applications.

An example application using the single sign-on scenario could be a consolidated airline booking service that searches all airlines and provides links to different airline web sites. Once the user signs on to the consolidated booking service, the user information can be used by each individual airline site without requiring another sign-on.

Single sign-on operates according to the following rules:

To configure single sign-on, set the following properties in the single-sign-on element of the server.xml file:

The following example shows a configuration with all default values:


<single-sign-on>
        <enabled>1</enabled>
         <idle-timeout>300</idle-timeout>
      </single-sign-on>      

User Authorization by Servlets

Servlets can be configured to permit access to users with the appropriate authorization level.

Defining Roles

Security roles define an application function, made up of a number of users, groups, or both users and groups. The relationship between users and groups is determined by the specific realm implementation being used.

You can define roles in the Java EE deployment descriptor file, web.xml, and the corresponding role mappings in the Web Server deployment descriptor file, sun-web.xml. For more information about sun-web.xml, see Chapter 9, Deploying Web Applications.

Each security-role-mapping element in the sun-web.xml file maps a role name permitted by the web application to principals and groups. For example, a sun-web.xml file for a deployed web application might contain the following:


     <sun-web-app>
        <security-role-mapping>
           <role-name>manager</role-name>
           <principal-name>jgarcia</principal-name>
           <principal-name>mwebster</principal-name>
           <group-name>team-leads</group-name>
        </security-role-mapping>
        <security-role-mapping>
           <role-name>administrator</role-name>
           <principal-name>dsmith</principal-name>
        </security-role-mapping>
     </sun-web-app>

         

Note that the role-name in this example must match the role-name in the security-role element of the corresponding web.xml file.

For web applications, the roles are always specified in the sun-web.xml file. A role can be mapped to specific principals, to groups or both principals and groups. The principal or group names used must be valid principals or groups in the current realm.

Defining Servlet Authorization Constraints

At the servlet level, you can define access permissions using the auth-constraint element of the web.xml file.

The auth-constraint element on the resource collection must be used to indicate the user roles permitted to the resource collection. Refer to the Java Servlet specification for details on configuring servlet authorization constraints.

Fetching the Client Certificate

When you enable SSL and require client certificate authorization, your servlets have access to the client certificate as shown in the following example:


if (request.isSecure()) {
         java.security.cert.X509Certificate[] certs;
         certs = request.getAttribute("javax.servlet.request.X509Certificate");
        if (certs != null) {
            clientCert = certs[0];
            if (clientCert != null) {
               // Get the Distinguised Name for the user.
               java.security.Principal userDN = clientCert.getSubjectDN();
               ...
            }
         }
      }

      

The userDn is the fully qualified distinguished name for the user.

Using Web Services Message Security

In message security, security information is inserted into messages that travel through the networking layers and reaches the message destinations.

Configuring the Web Server for Message Security

This section describes the following topics:

Actions of Request and Response Policy Configurations

The following table shows message protection policy configuration and the resulting message security operations performed by the WS-Security SOAP message security providers for that configuration.

Table 8–1 Message Protection Policy Configuration

Message Protection Policy 

Resulting WS-Security SOAP Message Protection Operation 

auth-source= "sender"

The message contains the wase:security header that contains a wsse:UsernameToken with password.

auth-source="content"

The content of the SOAP message body is signed. The message contains a wsse:Security header that contains the message body signature represented as a ds:Signature.

auth-source="sender" auth-recipient="before-content" OR auth-recipient="after-content"

The content of the SOAP message body is encrypted and replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains a wsse:UsernameToken with password and an xenc:EncryptedKey. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient.

auth-source= "content" auth-recipient= "before-content"

The content of the SOAP message body is encrypted and replaced with the resulting xend:EncryptedData. The xenc:EncryptedData is signed. The message contains a wsse:Security header that contains an xenc:EncryptedKey and a ds:Signature. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient.

auth-source="content"

auth-recipient="after-content"

The content of the SOAP message body is signed, then encrypted, and then replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains an xenc:EncryptedKey and a ds:Signature. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient.

auth-recipient="before-content" OR auth-recipient="after-content"

The content of the SOAP message body is encrypted and replaced with the resulting xend:EncryptedData. The message contains a wsse:Security header that contains an xenc:EncryptedKey. The xenc:EncryptedKey contains the key used to encrypt the SOAP message body. The key is encrypted in the public key of the recipient.

No policy specified 

No security operations are performed by the modules. 

ProcedureTo Configure Other Security Facilities

The Web Server implements message security using message security providers integrated in its SOAP processing layer. The message security providers depend on other security facilities of Web Server.

  1. If using a username token, configure a user database, if necessary.

    When using a username and password token, an appropriate realm must be configured and an appropriate user database must be configured for the realm.

  2. Manage certificates and private keys, if necessary.

    After configuring the Web Server facilities for use by message security providers as described in Managing Certificates in Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

Security Enhancements to server.xml

The server element in server.xml contains one or more soap-auth-provider elements, each of which contains a list of configured soap message security providers. The server element also includes a default-soap-auth-provider-name for the default SOAP message-level authentication provider.

See Chapter 3, Elements in server.xml, in Oracle iPlanet Web Server 7.0.9 Administrator’s Configuration File Reference for more information.

Administration Command-Line Interface (CLI) support is provided to add, remove, and list the soap-auth-provider element in server.xml. The CLI also supports adding a deafult-soap-auth-provider-name to server.xml.

Security Enhancements to sun-web.xml

Security-related additions to sun-web.xml are described in detail in the following sections.

webservice-endpoint Element

The syntax for the webservice-endpoint element is as follows:

<!ELEMENT webservice-endpoint (port-component name, endpoint-address-uri?,
(login-config|message-security-binding)?,transport-guarantee?,
service-gname?,tie-class?, servlet-imp-class?)>
Table 8–2 webservice-endpoint Element

Element Name 

Occurrences 

Description  

Type 

port-component-name

Unique name of a Web Service within a module. This name should be the same as the endpoint: name in sun-jaxws.xml.

PCDATA 

endpoint-address-uri

0 or 1  

Unused for Web Server  

PCDATA 

login-config

 

Unused for Web Server 

 

message-security-binding

0 or 1  

Used to bind a Web Service endpoint or port to a specific security provider. This element can also be used to provide a definition of message security requirements to be enforced by the security provider. 

See Table 8–3

message-security—binding

transport-guarantee

0 or 1 

Unused for Web Server  

PCDATA 

service-qname

0 or 1  

Unused for Web Server 

 

tie-class

0 or 1  

Unused for Web Server 

PCDATA 

servlet-impl-class

0 or 1 

Unused for Web Server 

Class name 

message-security-binding Element

The message-security-binding element is used to bind a web service endpoint or port to a specific security provider.

The syntax for this element is as follows:

<!ELEMENT message-security-binding (message-security*)>
<!ATLIST message-security-binding
auth-layer %message-layer;#REQUIRED
provider-id CDATA #IMPLIED >
Table 8–3 message-security-binding Element

Element name 

Occurrences 

Description 

Type 

message-security

0 or more  

Specifies the message security requirements of request and response for the endpoint or port 

See Table 8–5

Table 8–4 Attributes of the message-security-binding Element

Attribute name 

Description 

Type 

Default 

auth-layer

Layer at which the security should be enforced 

Entity message-layer 

This attribute is required. 

provider-id

Identifies the provider-config that should be used

CDATA 

If a value is not specified, then the default provider is used. If no default provider exists at the layer, the authentication requirements defined in the message-security-binding are not enforced.

message-security Element

The syntax for the message-security element is as follows:

<!ELEMENT message-security (message+, request-protection?, response-protection?)>

Table 8–5 message-security Element

Element name 

Occurrences 

Description 

Type 

message

1 or more  

Describes the methods or operations to which the security requirements apply 

Table 8–6

request-protection

0 or 1 

Describes the authentication requirements applicable to a request  

Table 8–7

response-protection

0 or 1 

Describes the authentication requirements applicable to a response  

Table 8–8

message Element

The syntax for the message element is as follows: <!ELEMENT (java-method?|operation-name?)>.

Table 8–6 message element

Element name 

occurrences 

Description 

Type 

java-method

0 or 1 

Java methods on which the security should be enforced 

Table 8–9

operation-name

0 or 1 

WSDL name of an operation of the web service 

PCDATA 

Attributes of request-protection Element

The syntax for the request-protection element is as follows.

<!ELEMENT request-protection EMPTY>
<!ATTLIST request-protection
auth-source (sender|content)#IMPLIED
auth-recipient (before-content |after-content)#IMPLIED
Table 8–7 request-protection Element

Attribute name 

Description 

Value  

Default 

auth-source

Defines a requirement for message layer sender authentication for example, username and password or content authentication, for example, digital signature 

sender or content

Implied 

auth-recipient

Defines a requirement for message layer authentication of the receiver of a message to its sender for example, by XML encryption.  

A before-content attribute value indicates that recipient authentication occurs before any content authentication.

before-content or after-content

Implied 

response-protection Element

The syntax for the response-protection element is as follows:

<<!ELEMENT response-protection EMPTY>
<!ATTLIST response-protection
auth-source (sender|content)#IMPLIED
auth-recipient (before-content |after-content)#IMPLIED
Table 8–8 Attributes of the response-protection Element

Attribute name 

Description 

Value  

Default 

auth-source

Defines a requirement for message layer sender authentication, for example, username and password) or content authentication, for example, digital signature

sender or content

Implied 

auth-recipient

Defines a requirement for message layer authentication of the receiver of a message to its sender, for example by XML encryption.  

The before-content attribute value indicates that recipient authentication occurs before any content authentication with respect to the target of the containing auth-policy.

before-content or after-content

Implied 

java-method Element

The syntax for the java-method element is as follows:

<!ELEMENT java-method (method-name,method-params?)>
Table 8–9 java-method Element

Element name 

Occurrences 

Description 

Value 

method-name

Name of the service method  

PCDATA 

method-params

0 or 1  

List of the fully qualified Java type names of the method parameters. 

Table 8–10

method-params Element

The syntax for method-params (method-param*) element is as follows:

Table 8–10 Attributes of the method-params Element

Element name 

Occurrences 

Description 

Value 

method-params

0 or more 

Fully qualified Java type name of a method parameter 

PCDATA 

message-layer Entity

The message-layer entity defines the value of the value of the auth-layer attribute.

The syntax for message-layer entity is:<!Entity %message-layer "(SOAP)"

Using Message Security Provider in an Application

The following sub-web.xml example shows how to use the server.xml message security provider provider1 in a web application.

<?xml version="1.0" encoding="UTF-8"?>

<!--
		Copyright 2006, 2010 Oracle Corporation. All rights reserved.
		Use is subject to license terms.
-->

<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc. 
//DTD Application Server 8.1 Servlet 2.5//EN" 
"http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
		<context-root>/jaxws-fromwsdl-soap12</context-root>
		<servlet>
			<servlet-name>fromwsdl</servlet-name>
			<webservices-endpoint>
				<port-component-name>fromwsdl-soap12</port-component-name>
				<message-security-binding auth-layer="SOAP"
				<provider-id>provider1</provider-id>
				</message-security-binding>
				</webservices-endpoint>
				</servlet>
		</sun-web-app>

Note –

The port-component-name element should be the same as the name attribute in the endpoint element in sun-jaxws.xml. If the provider-id element is not specified in sun-web.xml, then the default-soap-auth-provider-name configured in server.xml is be used as the provider.


Deploy the sample web application fromwsdl-soap12.war on to the Web Server.

Programmatic Login

Programmatic login enables a deployed Java EE application to invoke a login method. If the login is successful, a SecurityContext is established as if the client had authenticated using any of the conventional Java EE mechanisms.

Programmatic login is useful for application with unique needs that cannot be accommodated by any of the Java EE standard authentication mechanisms.

This section discusses the following topics:

Precautions

The Web Server is not involved in how the login information (user name and password) is obtained by the deployed application. The application developer must ensure that the resulting system meets security requirements. If the application code reads the authentication information across the network, the application must to determine whether to trust the user.

Programmatic login enables the application developer to bypass the Web Server-supported authentication mechanisms and feed authentication data directly to the security service. While flexible, this capability should not be used without some understanding of security issues.

Because this mechanism bypasses the container-managed authentication process and sequence, the application developer must be very careful in making sure that authentication is established before accessing any restricted resources or methods. The application developer must also verify the status of the login attempt and to alter the behavior of the application accordingly.

The programmatic login state does not necessarily persist in sessions or participate in single sign-on.

Lazy authentication is not supported for programmatic login. If an access check is reached and the deployed application has not properly authenticated using the programmatic login method, access is denied immediately and the application might fail if not properly coded to account for this occurrence.

Granting Programmatic Login Permission

The ProgrammaticLoginPermission permission is required to invoke the programmatic login mechanism for an application. This permission is not granted by default to deployed applications because it is not a standard Java EE mechanism.

To grant the required permission to the application, add the following code to the instance-dir/config/server.policy file:

grant codeBase "file:jar_file_path" {
    permission com.sun.appserv.security.ProgrammaticLoginPermission
    "login";
 };

The jar_file_path is the path to the application's JAR file.


Note –

If the Security Manager is disabled, it is not mandatory to grant permission.


For more information about the server.policy file, see The server.policy File.

ProgrammaticLogin Class

The com.sun.appserv.security.ProgrammaticLogin class enables a user to log in programmatically.

The login method for servlets or JSPs has the following signature:

public Boolean login(String user, String password, 
javax.servlet.http.HttpServletRequest request, 
javax.servlet.http.HttpServletResponse response)

This method performs the authentication. It returns true if the login succeeded, false if the login failed.

Enabling the Java Security Manager

Web Server supports the Java Security Manager. The Java Security Manager is disabled by default when you install the product, which can improve performance significantly for some types of applications. Enabling the Java Security Manager might improve security by restricting the rights granted to your Java EE web applications. To enable the Java Security Manager, add the following JVM options to the server.xml file.

<jvm-options>-Djava.security.manager</jvm-options>

<jvm-options>-Djava.security.policy=instance-dir

/config/server.policy</jvm-options>

where instance-dir is the path to the installation directory of this server instance.

Whether you should run with the Security manager depends on your application and deployment needs.

Running with the Security Manager helps catch some specification issues with Java EE applications. All Java EE applications should be able to run with the Security Manager active and with only the default permissions. Therefore, the Security Manager should be turned on during development. Applications that can easily be deployed in environments where the Security Manager is always active, such as some versions of Sun Java System Application Server. Running with the Security Manager also helps isolate applications and may catch inappropriate operations.

The main drawback of running with the Security Manager is that it negatively affects performance. Depending on the application details and the deployment environment, this impact could be minor or quite significant.

The server.policy File

Each Web Server instance has its own standard Java Platform, Standard Edition (Java SE™ platform) policy file, located in the instance-dir/config directory. The file is named server.policy.

Web Server is a Java EE 1.4-compliant web server. As such, it follows the recommendations and requirements of the Java EE specification, including the optional presence of the Security Manager, which is the Java component that enforces the policy, and a limited permission set for Java EE application code.

This section includes the following topics:

Default Permissions

Internal server code is granted all permissions 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.

A few permissions above the minimal set are also granted in the default server.policy file. These permissions are necessary due to various internal dependencies of the server implementation. Java EE application developers should not rely on these additional permissions.

Changing Permissions for an Application

The default policy for each instance limits the permissions of Java EE-deployed applications to the minimal set of permissions required for these applications to operate correctly. If you develop applications that require more than this default set of permissions, you can edit the server.policy file to add the custom permissions that your applications need.

You should add the extra permissions only to the applications that require them, not to all applications deployed to a server instance. Do not add extra permissions to the default set, which is the grant block with no codebase, which applies to all code. Instead, add a new grant block with a codebase specific to the application requiring the extra permissions, and only add the minimally necessary permissions in that block.


Note –

Do not add java.security.AllPermission 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 information is not sufficient, you can add the -Djava.security.debug=all JVM option to the server instance. For details, see the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

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

http://java.sun.com/docs/books/tutorial/security1.2/tour2/index.html.

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

http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html.

For the Javadoc for the Permission class is see

http://java.sun.com/j2se/1.4.2/docs/api/java/security/Permission.html.

Related Information

The following table describes where you can find more information about security and security configuration topics in the Web Server documentation:

Table 8–11 More Information on Security-related Issues

Subject 

Location 

Configuring Java security and realm-based authentication 

The chapter “Securing Your Web Server” in the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

Certificates and public key cryptography 

The chapter “Using Certificates and Keys” in the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

ACL-based security 

The chapter “Controlling Access to Your Server” in the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide.

Configuring authentication services in the server.xml files

The chapter “Controlling Access to Your Server” in the Oracle iPlanet Web Server 7.0.9 Administrator’s Guide and Oracle iPlanet Web Server 7.0.9 Administrator’s Configuration File Reference.