Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Administrator's Guide to Security

> ## Chapter 1
> Introducing Sun Java System Application Server Security

> This section discusses fundamental security concepts and provides an overview of security features and functionality as applied in the Sun Java System Application Server 7 environment.

> Note | Not all the content in this guide is applicable or usable for J2EE applications; some material only applies to the HTTP server. For information and instructions on developing secure J2EE applications, refer to the J2EE specifications and the Sun Java System Application Server Developer’s Guide.

> This section addresses the following topics:

> - Application Server Security
> - HTTP Server Security Features
> - J2EE Application Security Features
> - Good Practices
> - Files Associated With Server Security

> ##

> Application Server Security

> As the administrator responsible for server security, you are focussing on protecting the Sun Java System Application Server and its data from unauthorized access, damage (both intentional and unintentional), theft, and misrepresentation. This is done by using a combination of good security practices and a set of security tools, which include such mechanisms as digital certificates, encryption, authorization, and auditing.

> In the Sun Java System Application Server environment, your general areas of responsibility include:

> - Certificate Administration
> - SSL/TLS Encryption
> - Authentication
> - Auditing

> ### Certificate Administration

> A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key included in the certificate belongs to that entity. Both clients and servers can have certificates.

> Information on how certificates work in the Sun Java System Application Server environment is contained in Administering Certificates.

> ### SSL/TLS Encryption

> Encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient; decryption is the process of transforming encrypted information so that it is intelligible again.

> A cipher is a cryptographic algorithm (a mathematical function), used for encryption or decryption. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols supported by the Sun Java System Application Server contain numerous cipher suites. Some ciphers are stronger and more secure than others.

> SSL 3.0 and TLS 1.0 encryption protocols are supported. Information on encryption can be found in Administering SSL/TLS Encryption.

> ### Authentication

> Authentication is the mechanism by which callers and service providers prove to one another that they are acting on behalf of specific users or systems. When the proof is bidirectional, it is referred to as mutual authentication. 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 database domain, the user is authenticated. The user is associated with this authenticated security identity for the remainder of the session.

> Server authentication refers to the confident identification of a server by a client; that is, identification of the organization assumed to be responsible for the server at a particular network address.

> In virtual server authentication, you can have a different certificate database for each virtual server on your system. Each virtual server database can contain multiple certificates. Virtual servers can also have different certificates within each instance.

> ### Auditing

> Auditing is the method by which significant events are recorded for subsequent examination, such as errors or security breaches. All authentication events are logged to the Sun Java System Application Server logs. A complete access log provides a sequential trail of Sun Java System Application Server access events.

> Information on logging is contained in the Sun Java System Application Server Administration Guide.

> ##

> HTTP Server Security Features

> Note | The features described as HTTP server features are applicable only to the HTTP server side of the Sun Java System Application Server and not for J2EE applications. In some cases, equivalent functionality is available to J2EE applications as well.

> The HTTP server security features include:

> - HTTP Server User-Group Authentication
> - HTTP Server Host-IP Authentication
> - HTTP Server SSL Client Authentication
> - HTTP Server Access Control
> - Netscape API (NSAPI)

> ### HTTP Server User-Group Authentication

> User-Group authentication requires that users authenticate themselves before access can be granted. This is done by entering a user name and password, using a client certificate, or using the digest authentication plug-in. Types of User-Group authorization supported by the Sun Java System Application Server include Basic, Default, SSL, Digest, and Custom.

> For information on HTTP server User-Group authentication, refer to HTTP Server User-Group Authentication and Implementing Host-IP Authentication.

> For information on user-group authentication for J2EE applications, refer to the Sun Java System Application Server Developer’s Guide.

> ### HTTP Server Host-IP Authentication

> Host-IP authentication, also known as Host-IP access control, is a method of limiting access to the Admin Server, or the files and directories on your web site, by making them available only to clients who are using specific computers.

> Information on HTTP server Host-IP authentication is contained in Implementing Host-IP Authentication.

> ### HTTP Server SSL Client Authentication

> Client authentication refers to authenticating client certificates by cryptographically verifying the certificate signature and the certificate chain leading to the CA on the trust CA list. Clients can have multiple certificates, much like a person might have several different pieces of identification.

> Information on HTTP server client authentication is contained in Setting Up Client Authentication.

> Note | SSL client authentication is also available for J2EE applications, as described in the Sun Java System Application Server Developer’s Guide.

> ### HTTP Server Access Control

> By creating a hierarchy of rules called access control entries (ACEs) you can allow or deny access to individuals, groups, or other entities such as particular servers or applications. Each ACE specifies whether or not the server should check the next ACE in the hierarchy. The collection of ACEs you create is called an access control list (ACL).

> There are many options for restricting access to your HTTP server content, among them:

> - Restricting Access to the Entire Server
> - Restricting Access to a Directory (Path)
> - Restricting Access to a URI (Path)
> - Restricting Access to a File Type
> - Restricting Access Based on Time of Day
> - Restricting Access Based on Security

> Information on HTTP server access control is contained in Administering HTTP Server Access Control.

> ### Netscape API (NSAPI)

> A C language API which provides a number of HTTP-centric utility functions, the NSAPI allows plugins to provide Server Application Function (SAF) functions that participate in request processing and other server activities.

> Information can be found in the Sun Java System Application Server Developer’s Guide to NASPI.

> ##

> J2EE Application Security Features

> The J2EE application authentication and authorization requirements are defined by the J2EE specification and are briefly listed here.

> Note | For developing J2EE application security, use the security mechanisms as described in the J2EE specifications and the Sun Java System Application Server Developer’s Guide.

> The following J2EE security features are supported in the Sun Java System Application Server environment:

> - Declarative Security
> - Programmatic Security
> - User Authentication
> - Realm Administration
> - Single Sign-On
> - Resource Authentication
> - Pluggable Authentication

> ### Declarative Security

> In declarative security, authorization is handled by the container. Deployment descriptors are referenced to determine whether the principal associated with the current security context is permitted access to the requested operation.

> Web applications may also specify transport guarantee requirements of confidentiality or integrity. This translates to requiring SSL for such resources.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### Programmatic Security

> In programmatic security, authorization is handled by the application code directly. This code is written by the developer.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### User Authentication

> Three caller authentication paths exist: web client, J2EE application client (running in the application container), and external RMI/IIOP clients that do not use the Sun Java System Application Server container. Form authentication is supported.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### Realm Administration

> The Administration interface provides the capability to add/edit/delete supported realms from the server. Realms included in the Sun Java System Application Server are file, ldap, certificate, and solaris.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### Single Sign-On

> For single sign-on, a user’s authentication state can be shared across multiple J2EE applications in a single virtual server instance.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### Resource Authentication

> The Sun Java System Application Server supports authentication into external resources (which may require separate authentication).

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### Pluggable Authentication

> Pluggable authentication allows for J2EE applications to use the Java Authentication and Authorization Service (JAAS) feature from the J2SE platform. Developers can plug in their own authentication mechanisms.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ##

> Good Practices

> There are many precautions you can take to protect your Sun Java System Application Server resources. Some involve mechanisms (such as authentication or encryption) and many are simply based on security-aware operational practices and common sense.

> Some good practices include:

> - Limiting physical access to the Sun Java System Application Server
> - Setting up firewalls
> - Limiting access to administration capabilities
> - Managing passwords
> - Limiting the presence of other applications on the server
> - Configuring for protected and unprotected servers

> These topics are discussed in General Security Measures.

> ##

> Files Associated With Server Security

> Many of the Sun Java System Application Server configuration files are used to define security parameters for the server. The main security-related tasks associated with each file are listed briefly in the following sections:

> - The init.conf File
> - The dbswitch.conf File
> - The server.xml File
> - The password.conf File
> - The certmap.conf File
> - ACL Files
> - The htaccess Files
> - Keyfile
> - The server.policy File

> Details on the contents of the Sun Java System Application Server configuration files are contained in the Sun Java System Application Server Administrator’s Configuration File Reference.

> ### The init.conf File

> The init.conf file contains low-level server configuration information, such as the path the server is installed to, performance tuning options, location of plugin shared objects, and so on. This is the startup file. When the Sun Java System Application Server starts up, it looks in this file to establish a set of global variable settings that affect the server instance’s behavior and configuration. Security-related tasks include:

> - To use the chroot command to secure an unprotected server, all paths in init.conf must be absolute; paths in obj.conf must be relative to the chroot directory. Refer to Securing Against an Unprotected Server for guidelines.
> - Installing an SSL-enabled server creates SSL directive entries in the init.conf file for global security parameters. Refer to Configuring Security Globally for instructions.
> - You can control the ACL user cache by setting directives in the init.conf file. Refer to Configuring the ACL User Cache for further information.
> - To manually enable your server to use the htaccess file, you need to first modify the server’s init.conf file to load, initialize, and activate the plug-in. Refer to Enabling htaccess from init.conf for instructions.

> ### The dbswitch.conf File

> Note | This section only applies to HTTP server content.

> The dbswitch.conf file specifies the LDAP directory used by the Sun Java System Application Server. It is only read at server startup.

> You can globally define user authentication databases in the dbswitch.conf file. Refer to Accessing Databases from Virtual Servers for further information.

> ### The server.xml File

> The server.xml file is the main configuration file for the Sun Java System Application Server. Security-related tasks include:

> - Handles configuration of HTTP listeners (including SSL ciphers, certificates, and so on), virtual servers, access control lists, and so on. Handles the relationships between these entities.
> - Contains a list of security domains with configuration data for the provider class and realm-specific properties. Refer to the Sun Java System Application Server Developer’s Guide for more information on security domains (realms).
> - SSL properties for virtual servers can be found on a per-server basis in the ssl element of the server.xml file. Refer to Configuring Security Globally for more information.
> - By manually editing the server.xml file, you can tell the Sun Java System Application Server to start with an external server certificate. Refer to Starting the Server with an External Certificate for more information.

> Further information on the server.xml file can be found in the Sun Java System Application Server Administrator’s Configuration File Reference.

> ### The obj.conf File

> Note | This section only applies to HTTP server content.

> The obj.conf file contains directives that instruct the Sun Java System Application Server on how to handle requests from clients. Security-related tasks include:

> - HTTP server authentication uses the default method you specify in the obj.conf file, or Basic if there is no setting in the obj.conf file. For more information, refer to HTTP Server User-Group Authentication.
> - If you have named ACLs or created separate ACL files, you can reference them in the obj.conf file. For further information on doing this, refer to Referencing ACL Files in the obj.conf File.
> - Handles configuration of the NSAPI request processing path (each virtual server may have its own obj.conf file). Further information is contained in the Sun Java System Application Server Developer’s Guide to NASPI.

> ### The password.conf File

> If you want an SSL/TLS-enabled Sun Java System Application Server to be able to restart unattended when configured for SSL, you can save the trust database password in a password.conf file.

> Note | Be sure that your system is adequately protected so that this file and the key databases are not compromised. Such protection is discussed in Limiting Physical Access.

> Further information on the password.conf file can be found in Using the password.conf File and the Sun Java System Application Server Administrator’s Configuration File Reference.

> ### The certmap.conf File

> Note | This section only applies to HTTP server content.

> The certmap.conf file specifies how a certificate, designated by name, is mapped to an LDAP entry, designated by issuerDN. The certmap.conf file provides the following information:

> - Where in the LDAP tree the server should begin its search
> - What certificate attributes the Sun Java System Application Server should use as search criteria when searching for the entry in the LDAP directory
> - Whether or not the server goes through an additional verification process

> Refer to Working with the certmap.conf File for further information.

> ### ACL Files

> Access control list (ACL) files are text files that contain lists identifying who can access the resources stored on your Sun Java System Application Server.

> Note | The access control methods described in this document should not be used for J2EE application development. Using these methods, especially ACLs, could cause your applications to work unpredictably and be inconsistent with the J2EE model. For application development, use the J2EE security mechanisms as described in the J2EE specifications and the Sun Java System Application Server Developer’s Guide.

> By default, the Sun Java System Application Server uses a single ACL file that contains all the lists for accessing your server. As an alternative to this default, you can create multiple ACL files and reference them in the obj.conf file.

> Information on working with ACL files is contained Administering HTTP Server Access Control. Additional information can be found in the Sun Java System Application Server Developer’s Guide to NASPI.

> ### The htaccess Files

> Note | This section only applies to HTTP server content.

> The htaccess files are dynamic configuration files that store a subset of configuration options. You can use htaccess files in combination with the Sun Java System Application Server standard access controls (standard access controls are always applied before any htaccess access controls).

> Information on working with htaccess files is contained in Using htaccess Files.

> ### Keyfile

> The keyfile contains the list of users for the file realm (applicable only for J2EE applications). Every server instance has a default keyfile which is empty. Users can be added through the Administration interface or the command-line interface.

> By default, the file realm is always set to use this file, with the name keyfile. However, the name and location of this file can be changed by editing the file realm properties in the server.xml file.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> ### The server.policy File

> The server.policy file contains the J2SE policy configuration which will be in effect for all the Java code running in an instance.

> Refer to the Sun Java System Application Server Developer’s Guide for more information.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.