This chapter describes the basic goals and features of Sun Java System Web Server 6.1 security, and describes how to write secure web applications containing components that perform user authentication and access authorization tasks. Since it is helpful to have a basic understanding of security responsibilities and terminology, the beginning of the chapter discusses those topics.
This chapter has the following sections:
In an enterprise computing environment there are many security risks. The goal of Sun Java System Web Server is to provide highly secure, interoperable, and distributed component computing based on the J2SE security model. The security goals for Sun Java System Web Server include the following:
Full compliance with the Java Servlet 2.3 security model. This includes servlet role-based authorization. For more information, see the Security chapter in the Java Servlet 2.3 specification, which can be downloaded from:
Support for single sign-on across all Sun Java System 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. For Solaris, OS platform authentication is supported in addition to these.
Support for declarative security via Sun Java System Web Server-specific XML-based role mapping.
Support for Java policy (Security Manager) enforcement.
The Sun Java System Web Server 6.1 Administrator’s Guide also contains detailed information about J2SE-based security.
Before delving into the specific security features of Sun Java System Web Server, it is helpful to first understand responsibilities pertaining to security. This section provides that overview.
A J2SE platform's primary goal is to isolate the developer from the security mechanism details and facilitate a secure application deployment in diverse environments. This goal is addressed by providing mechanisms for the application security specification requirements declaratively and outside the application.
When developing applications for Sun Java System Web Server, it is necessary to decide whether your application should use the traditional Sun Java System Web Server native ACL subsystem or the J2SE/Servlet access control model. For guidelines on how to make this decision, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
The roles described in this section apply to the J2SE/Servlet model and are described in more detail in the J2SE specification:
The application developer is responsible for the following:
Specifying application roles.
Defining role-based access restrictions for the application components (servlets and JSPs components).
If programmatic security is used, verifying the user roles and authorizing access to features based on these roles. (Programmatic security management is discouraged because it hard-codes the security login in the application instead of allowing the containers to manage it.)
The application assembler or application component provider must identify all security dependencies embedded in a component, including:
All role names used by the components that call isUserInRole.
References to all external resources accessed by the components.
References to all intercomponent calls made by the component.
The application deployer takes all component security views provided by the assembler and uses them to secure a particular enterprise environment in the application, including:
Assigning users or groups (or both) to security roles.
Refining the privileges required to access component methods to suit the requirements of the specific deployment scenario.
Before getting into the specific security features and capabilities of Sun Java System Web Server, it is helpful to have a basic understanding of the common security terminology used throughout this chapter. This section provides that overview.
The most common security processes are authentication, authorization, realm assignment, and role mapping. The following sections define this and other common security terminology:
Authentication verifies the user. For example, the user may enter a user name and password in a web browser, and 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.
Authorization permits a user to perform the desired operations, after being authenticated. For example, a human resources application may 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 J2SE 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 Sun Java System Web Server are file, ldap, certificate, solaris, custom, and nativerealm. For more information about supported realms, see Realm Configuration.
In the J2SE/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 (occasionally) politicians all fit into the role of SpaceShuttlePassenger.
In Sun Java System Web Server, roles correspond to users or groups (or both) configured in the active realm.
The component containers are responsible for providing J2SE application security. Two security forms are provided by the container, as discussed below: programmatic security and declarative security.
Programmatic security is when a servlet uses method calls to the security API, as specified by the J2SE 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 J2SE 1.3 specification defines programmatic security with respect to servlets as consisting of two methods of the servlet HttpServletRequest interface. Sun Java System Web Server supports these interfaces as defined in the specification.
In addition to the programmatic security defined in the J2SE specifications, Sun Java System 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 external to the application. Deployment descriptors describe the J2SE application's security structure, including security roles, access control, and authentication requirements.
Sun Java System Web Server supports the DTDs specified by the J2SE 1.3 specification, and has additional security elements included in its own deployment descriptors. Declarative security is the application deployer's responsibility.
In addition to supporting the J2SE 1.3 security model, Sun Java System Web Server also supports the following features that are specific to the Web Server:
Single sign-on across all Sun Java System Web Server applications within a single security domain.
Programmatic login.
The parallel Access Control List (ACL)-based security model, in addition to the J2SE/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, and access control mechanisms enforce these restrictions. Authentication and authorization can be enforced by a number of security models and services.
Sun Java System Web Server 6.1 provides authentication and authorization support through the following mechanisms, which are discussed in this section:
ACL-based authentication and authorization
J2SE/Servlet-based authentication and authorization
Whether performed by the ACL subsystem or the J2SE/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 Sun Java System Web Server 6.1 Administrator’s Guide. This section provides a brief overview of the key concepts.
Sun Java System Web Server 6.1 supports authentication and authorization through the use of locally stored access control lists (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 Sun Java System Web Server 6.1 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 main features of the ACL-based access control model are described below:
ACL-based authentication uses the following configuration files:
server-install/httpacl/*.acl files
server-install/userdb/dbswitch.conf
server-install/config/server.xml
Authentication is performed by auth-db modules that are configured in the dbswitch.conf file.
Authorization is performed by access control rules set in the server-install/httpacl/*.acl files, if ACLs are configured.
In addition, the Sun Java System Web Server 6.1 SSL engine supports external crypto hardware to offload SSL processing and to provide optional tamper-resistant key storage.
For more information about access control and the use of external crypto hardware, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
Sun Java System Web Server 6.1, apart from providing ACL-based authentication, also leverages the security model defined in the J2SE 1.3 specification to provide several features that help you develop and deploy secure Java web applications.
A typical J2SE-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 J2SE/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, and then passes it for verification to the realm that is currently active in the security service.
A realm, also called a security policy domain or security domain in the J2SE specification, is a scope over which a common security policy is defined and enforced by the security administrator of the security service.
The main features of the J2SE/Servlet-based access control model are described below:
J2SE/Servlet-based authentication uses the following configuration files:
The web application deployment descriptor files web.xml and sun-web.xml
server-install/config/server.xml
Authentication is performed by Java security realms that are configured through AUTHREALM 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 6.1 SP6 Administrator’s Guide.
When a browser requests the main application URL, the web container collects the user authentication information (for example, user name and password) and passes it to the security service for authentication.
For J2SE web applications, Sun Java System Web Server consults the security policies (derived from the deployment descriptors) associated with the web resource to determine the security roles used to permit resource access. The web container tests the user credentials against each role to determine if it can map the user to the role.
The web-based login mechanisms required by the J2SE 1.3 specification are supported by the Sun Java System Web Server. These mechanisms are discussed in this section:
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 mechanism's 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 officially optional, 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.3 specification (chapter SRV.13, “Deployment Descriptor”). You can find the specification here:
http://java.sun.com/products/servlet/download.html
For more information regarding sun-web.xml elements, see Chapter 7, Deploying Web Applications.
HTTP basic authentication (RFC 2617) is supported by the Sun Java System Web Server. Because passwords are sent with base64 encoding, this authentication type is not very secure. Use of SSL or another equivalent transport encryption is recommended to protect the password during transmission.
SSL 3.0 and the means to perform mutual (client/server) certificate-based authentication is a J2SE 1.3 specification requirement. This security mechanism provides user authentication using HTTPS (HTTP over SSL).
The Sun Java System Web Server SSL mutual authentication mechanism (also known as HTTPS authentication) supports the following cipher suites:
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
The login screen's look and feel cannot be controlled with the HTTP browser's built-in mechanisms. J2SE introduces the ability to package a standard HTML or servlet/JSP based form for logging in. The login form is associated with a web protection domain (an HTTP realm) and is used to authenticate previously unauthenticated users.
Because passwords are sent in the clear (unless protected by the underlying transport), this authentication type is not very secure. Use of SSL or another equivalent transport encryption is recommended to protect the password during transmission.
For the authentication to proceed appropriately, the login form action must always be j_security_check.
The following is an HTML sample showing 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.
The single sign-on across applications on the Sun Java System Web Server is supported by the Sun Java System 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 one time, and 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 6.1 SP6 Administrator’s Guide or the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference.
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 as user accesses a protected resource in any web application associated with a virtual server, the user is 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 user to authenticate him or herself again.
The single sign-on feature utilizes 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 VS element of the server.xml file:
sso-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 value is set to false.
sso-max-inactive-seconds: Specifies the time after which a user's single sign-on record becomes eligible for purging if no client activity is received. Since 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.
sso-reap-interval-seconds: Specifies the interval between purges of expired single sign-on records. The default value is 60.
Here is an example configuration with all default values:
<VS id="server1" ... > ... <property name="sso-enabled" value="true"> <property name="sso-max-inactive-seconds" value="300"> <property name="sso-reap-interval-seconds" value="60"> </VS> |
Servlets can be configured to only permit access to users with the appropriate authorization level. This section covers the following topics:
Security roles define an application function, made up of a number of users, groups, or both. The relationship between users and groups is determined by the specific realm implementation being used.
You define roles in the J2SE deployment descriptor file,web.xml, and the corresponding role mappings in the Sun Java System Web Server deployment descriptor file, sun-web.xml. For more information about sun-web.xml, see Chapter 7, 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 either specific principals or to groups (or both). The principal or group names used must be valid principals or groups in the current realm.
On the servlet level, you 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.
This section provides an overview of the configuration characteristics of the supported realms. For detailed information about configuring realms, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
The section describes the following realms:
The file realm is the default realm when you first install Sun Java System Web Server, and has the following configuration characteristics:
Name: file
Classname: com.iplanet.ias.security.auth.realm.file.FileRealm
Required properties are as follows:
file: The name of the file that stores user information. By default this file is instance_dir/config/keyfile.
jaas-context: The value must be fileRealm.
The user information file is initially empty, so you must add users before you can use the file realm.
The LDAP realm allows you to use an LDAP database for user security information, and has the following configuration characteristics:
Name: ldap
Classname: com.iplanet.ias.security.auth.realm.ldap.LDAPRealm
Required properties are as follows:
directory: The LDAP URL to your server.
base-dn: The base DN for the location of user data. This base DN can be at any level above the user data, since a tree scope search is performed. The smaller the search tree, the better the performance.
jaas-context: The value must be ldapRealm.
You can add the following optional properties to tailor the LDAP realm behavior:
search-filter: The search filter to use to find the user. The default is uid=%s (%s expands to the subject name).
group-base-dn: The base DN for the location of group data. By default it is same as the base-dn, but it can be tuned if necessary.
group-search-filter: The search filter to find group memberships for the user. The default is uniquemember=%d (%d expands to the user element DN).
group-target: The LDAP attribute name that contains group name entries. The default is CN.
search-bind-dn: An optional DN used to authenticate to the directory for performing the search-filter lookup. Only required for directories that do not allow anonymous search.
search-bind-password: The LDAP password for the DN given in search-bind-dn.
You must create the desired user(s) in your LDAP directory. You can do this from the Sun™ Java System Directory Server console, or through any other administration tool that supports LDAP and your directory's schema. User and group information is stored in the external LDAP directory.
The principal-name used in the deployment descriptors must correspond to your LDAP user information.
The Solaris realm allows authentication using Solaris user name and password data. This realm is supported only on Solaris 9, and has the following configuration characteristics:
Name: solaris
Classname: com.iplanet.ias.security.auth.realm.file.SolarisRealm
Required properties are as follows:
jaas-context: The value must be solarisRealm.
Users and groups are stored in the underlying Solaris user database, as determined by the system’s PAM (Pluggable Authentication Module) configuration.
The Solaris realm invokes the underlying PAM infrastructure for authentication. If the configured PAM modules require root privileges, the instance must run as root to use this realm. For details, see the "Using Authentication Services (Tasks)" chapter in the Solaris 9 System Administration Guide: Security Services.
The certificate realm supports SSL authentication. The certificate realm sets up the user identity in Sun Java System Web Server's security context and populates it with user data from the client certificate. The J2SE containers then handle authorization processing based on each user's DN from his or her certificate. The certificate realm has the following configuration characteristics:
Name: certificate
Classname: com.iplanet.ias.security.auth.realm.certificate.CertificateRealm
You can add the following optional property to tailor the certificate realm behavior:
assign-groups: If this property is set, its value is taken to be a comma-separated list of group names. All clients presenting valid certificates are assigned membership to these groups for the purposes of authorization decisions in the web container.
When you deploy an application, you must specify CLIENT-CERT as the authentication mechanism in the web.xml file as follows:
<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>
You must obtain a client certificate and install it in your browser to complete the setup for client certificate authentication. For details on how to set up the server and client certificates, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
You can configure the server instance for SSL authentication in these ways:
Configure an SSLPARAMS element in server.xml, then restart the server. For more information about the server.xml file, see the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference.
Use the Administration interface as described in the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
In most cases, it is not necessary to configure a certificate realm in server.xml when using CLIENT-CERT authentication in web applications. Since the CLIENT-CERT authentication method inherently implies certificate-based authentication, Sun Java System Web Server will internally use a certificate realm even if one is not configured in server.xml. You can still configure a certificate realm if you want to specify properties for it (for example, assign-groups).
You can create a custom realm by providing a Java™ Authentication and Authorization Service (JAAS) login module and a realm implementation. Note that client-side JAAS login modules are not suitable for use with Sun Java System Web Server. For more information about JAAS, refer to the JAAS specification for Java 2 SDK, v1.4, available here:
http://java.sun.com/products/jaas/
A sample application that uses a custom realm is available with Sun Java System Web Server at the following location:
server_root/plugins/java/samples/webapps/security
The native realm is a special realm that provides a bridge between the core Sun Java System Web Server ACL-based authentication and the J2SE/Servlet authentication model. By using the native realm for Java web applications, it becomes possible to have the ACL subsystem perform the authentication (instead of having the Java web container do so) and yet have this identity available for Java web applications.
This functionality is provided by pluggable realm called NativeRealm, which acts as a bridge between the J2SE security subsystem and the access control security subsystem.
Depending on whether a security constraint is configured for a web application, the two modes of operation described below are supported by the native realm:
If a security constraint is defined in the application’s deployment descriptor file, web.xml, the web container carries out normal authentication and authorization processing. When the NativeRealm realm is invoked for validating user information, the task of verification is delegated to the core auth-db specified in the realm configuration. See the Sun Java System Web Server 6.1 SP6 Administrator’s Guide for more information on how to configure auth-db in dbswitch.conf and server.xml.
For example (classname= is all on one line, with no spaces):
<AUTHREALM name="native" classname="com.iplanet.ias.security.auth.realm.webcore. NativeRealm"> <PROPERTY name="auth-db" value="name"> <PROPERTY name="jaas-context" value="nativeRealm"> </AUTHREALM>
If a security constraint is not defined in the application’s deployment descriptor file web.xml when using NativeRealm, the Java web container does not carry out authentication and authorization tasks. These tasks are left to the core access control lists (ACLs). ACLs are collections of rules that follow a hierarchy and determine whether access should be granted or denied for the requested resource. The ACLs yield the user’s identity, which is then made available to the Java web application. In other words, if the servlet later invokes a principal’s identity with the request.getUserPrincipal() method, the correct user identity will be returned.
In this scenario it is not necessary to provide an auth-db to the NativeRealm configuration, since the access control list that was applied to the given request is already bound to an auth-db.
For example:
<AUTHREALM name="native" classname="com.iplanet.ias.security.auth.realm.webcore. NativeRealm"> </AUTHREALM>
For more details about access control lists, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.
While it is possible to apply both ACL access control rules and web.xml security constraints on a single application, this usage is discouraged. It may lead to duplicate authentication prompts or otherwise confusing behavior. You should always pick either core ACL or J2SE web.xml-based access control mechanisms for a given web application.
Programmatic login allows a deployed J2SE 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 J2SE mechanisms.
Programmatic login is useful for an application with unique needs that cannot be accommodated by any of the J2SE standard authentication mechanisms.
This section discusses the following topics:
The Sun Java System Web Server is not involved in how the login information (user name and password) is obtained by the deployed application. Programmatic login places the burden on the application developer with respect to assuring that the resulting system meets security requirements. If the application code reads the authentication information across the network, it is up to the application to determine whether to trust the user.
Programmatic login allows the application developer to bypass the application 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.
Since 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. It is also the application developer's responsibility to 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 may 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 this is not a standard J2SE mechanism.
To grant the required permission to the application, add the following 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.
For more information about the server.policy file, see The server.policy File.
The com.sun.appserv.security.ProgrammaticLogin class enables a user to perform login 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
Returns true if login succeeded, false if login failed
Sun Java System Web Server 6.1 supports the Java Security Manager. The Java Security Manager is disabled by default when you install the product, which may improve performance significantly for some types of applications. Enabling the Java Security Manager may improve security by restricting the rights granted to your J2SE web applications. To enable the Java Security Manager, “uncomment” entries in the server.xml file:
<JVMOPTIONS>-Djava.security.manager</JVMOPTIONS>
<JVMOPTIONS>-Djava.security.policy=instance_dir
/config/server.policy</JVMOPTIONS>
where instance_dir is the path to the installation directory of this server instance.
Based on your application and deployment needs, you should evaluate whether to run with or without the Security Manager.
Running with the Security Manager on will help catch some spec-compliance issues with J2SE applications. All J2SE applications should be able to run with the Security Manager active and with only the default permissions. For this reason it is recommended that the Security Manager be turned on during development. This will help produce applications that can easily be deployed in environments where the Security Manager is always active (such as 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 impacts performance. Depending on the application details and the deployment environment, this impact may be negligible or quite significant.
Each Sun Java System Web Server instance has its own standard Java™ 2 Platform, Standard Edition (J2SE) policy file, located in the instance_dir/config directory. The file is named server.policy.
Sun Java System Web Server 6.1 is a J2SE 1.3-compliant web server. As such, it follows the recommendations and requirements of the J2SE specification, including the optional presence of the Security Manager (the Java component that enforces the policy), and a limited permission set for J2SE application code.
This section includes the following topics:
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.
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. J2SE application developers must not rely on these additional permissions.
The default policy for each instance limits the permissions of J2SE-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 (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 J2SE 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 -Djava.security.debug=all JVM option to the server instance. For details, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide or the Sun Java System Web Server 6.1 SP6 Administrator’s Configuration File Reference.
You can use the J2SE 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
The Javadoc for the Permission class is here:
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 Sun Java System Web Server 6.1 documentation:
Table 5–1 More Information on Security-related Issues
For Information On |
See |
---|---|
Configuring Java security and realm-based authentication |
The chapter “Securing Your Web Server” in the Sun Java System Web Server 6.1 Administrator’s Guide. |
Certificates and public key cryptography |
The chapter “Using Certificates and Keys” in the Sun Java System Web Server 6.1 Administrator’s Guide. |
ACL-based security |
The chapter “Controlling Access to Your Server” in the Sun Java System Web Server 6.1 Administrator’s Guide. |
Configuring auth-db in the dbswitch.conf and server.xml files |
The chapter “Controlling Access to Your Server” in the Sun Java System Web Server 6.1 Administrator’s Guide. |