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:
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:
Full compliance with the Java Servlet 2.5 security model, including role-based authorization. For more information, see the Security chapter in the Java Servlet 2.5 specification at
Support for single sign-on across all Web Server applications within a single security domain.
Support for several underlying authentication realms, such as simple file and LDAP. Certificate authentication is also supported for SSL client authentication. Solaris OS platform authentication is also supported.
Support for declarative security through Web Server specific XML-based role mapping.
Support for Java Security Manager enforcement.
For more information about Java EE security, see the Chapter 6, Certificates and Keys, in Sun Java System Web Server 7.0 Update 8 Administrator’s Guide
This section provides an overview of the common security terminology.
The most common security processes are authentication, authorization, realm assignment, and role mapping.
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 Sun Java System Web Server 7.0 Update 8 Administrator’s Guide.
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.
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.
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.
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:
Single sign-on across all Web Server applications within a single security domain
Programmatic login
The parallel Access Control List (ACL)-based security model, in addition to the Java EE/Servlet security model
Support for secure ACL-based Java web applications, in addition to native content
This section discusses the following:
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:
Authenticate the caller
Authorize the caller for access to each servlet/JSP based on the applicable access control configuration
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:
ACL-based authentication and authorization
Java EE/Servlet-based authentication and authorization
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 access control is described at length in the Configuring Access Control in Sun Java System Web Server 7.0 Update 8 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 .
On lists of user names and passwords passed as cleartext.
Certificates bind a name to a public key.
Digest authentication uses encryption techniques to encrypt the user’s credentials.
The ACL-based access control model includes the following features:
ACL-based authentication uses the following configuration files:
install_dir/config/*.acl files
install_dir/config/server.xml
Authentication is performed by auth-db modules that are configured in the server.xml file.
Authorization is performed by access control rules set in the install_dir/config/*.acl files, if ACLs are configured.
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.
, 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:
Servlets
JavaServer Pages (JSP) components
HTML documents
Miscellaneous resources, such as image files and compressed archives
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:
Java EE/Servlet-based authentication uses the following configuration files:
The web application deployment descriptor files web.xml and sun-web.xml
install_dir/config/server.xml
Authentication is performed by Java security realms that are configured through <auth-realm> entries in the server.xml file.
Authorization is performed by access control rules in the deployment descriptor file, web.xml, in case any such rules have been set.
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 Sun Java System Web Server 7.0 Update 8 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.
The component containers are responsible for providing Java EE application security. Two security forms are provided by the container: programmatic security and declarative 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 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.
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?)>
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 (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 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 Sun Java System Web Server 7.0 Update 8 Administrator’s Guide.
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.
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:
Single sign-on applies to web applications configured for the same realm and virtual server. The realm is defined by the realm-name element in the web.xml file. For information about virtual servers, see the Sun Java System Web Server 7.0 Update 8 Administrator’s Guide.
As long as users access only unprotected resources in any of the web applications on a virtual server, they are not challenged to authenticate themselves.
As soon users access a protected resource in any web application associated with a virtual server, they are challenged to authenticate using the login method defined for the web application currently being accessed.
Once authenticated, the roles associated with this user are used for access control decisions across all associated web applications, without challenging the user to authenticate to each application individually.
When the user logs out of one web application, for example, by invalidating or timing out the corresponding session if form-based login is used, the user's sessions in all web applications are invalidated. Any subsequent attempt to access a protected resource in any application requires the users authorization.
The single sign-on feature uses HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be used in client environments that support cookies.
To configure single sign-on, set the following properties in the single-sign-on element of the server.xml file:
enabled: If false, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server. The default is false.
idle-timeout: Specifies the time after which a users single sign-on record becomes eligible for purging if no client activity is received. Because single sign-on applies across several applications on the same virtual server, access to any of the applications keeps the single sign-on record active. The default value is 5 minutes (300 seconds). Higher values provide longer single sign-on persistence for the users at the expense of more memory use on the server.
To configure single sign-on through CLI, see the enable-single-signon(1) and disable-single-signon(1) man pages.
The following example shows a configuration with all default values:
<single-sign-on> <enabled>1</enabled> <idle-timeout>300</idle-timeout> </single-sign-on> |
Servlets can be configured to permit access to users with the appropriate authorization level.
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.
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.
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.
In message security, security information is inserted into messages that travel through the networking layers and reaches the message destinations.
Setting up wadm
Configuring Message Security Provider
Message Security Provider in Application
This section describes the following topics:
Actions of Request and Response Policy Configurations
To configure other security facilities
Security Enhancements to server.xml
Security Enhancements to sun-web.xml
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. |
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.
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.
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 Sun Java System Web Server 7.0 Update 8 Administrator’s Guide.
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 Sun Java System Web Server 7.0 Update 8 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-related additions to sun-web.xml are described in detail in the following sections.
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 |
1 |
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 |
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. |
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 | |
request-protection |
0 or 1 |
Describes the authentication requirements applicable to a request | |
response-protection |
0 or 1 |
Describes the authentication requirements applicable to a response |
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 | |
operation-name |
0 or 1 |
WSDL name of an operation of the web service |
PCDATA |
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)#IMPLIEDTable 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 |
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)#IMPLIEDTable 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 |
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 |
1 |
Name of the service method |
PCDATA |
method-params |
0 or 1 |
List of the fully qualified Java type names of the method parameters. |
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 |
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)"
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-2007 Sun Microsystems,Inc. 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>
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 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:
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.
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.
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.
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.
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.
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:
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.
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.
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 Sun Java System Web Server 7.0 Update 8 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.
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 Sun Java System Web Server 7.0 Update 8 Administrator’s Guide. |
Certificates and public key cryptography |
The chapter “Using Certificates and Keys” in the Sun Java System Web Server 7.0 Update 8 Administrator’s Guide. |
ACL-based security |
The chapter “Controlling Access to Your Server” in the Sun Java System Web Server 7.0 Update 8 Administrator’s Guide. |
Configuring authentication services in the server.xml files |
The chapter “Controlling Access to Your Server” in the Sun Java System Web Server 7.0 Update 8 Administrator’s Guide and Sun Java System Web Server 7.0 Update 8 Administrator’s Configuration File Reference. |