| Sun ONE Application Server 7 Administrator's Guide to Security |
Chapter 1
Introducing Sun ONE Application Server SecurityThis section discusses fundamental security concepts and provides an overview of security features and functionality as applied in the Sun™ ONE Application Server 7 environment.
This section addresses the following topics:
Application Server SecurityAs the administrator responsible for server security, you are focussing on protecting the Sun ONE 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 ONE Application Server environment, your general areas of responsibility include:
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 ONE 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 ONE 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 ONE Application Server logs. A complete access log provides a sequential trail of Sun ONE Application Server access events.
Information on logging is contained in the Sun ONE Application Server Administrator’s Guide.
HTTP Server Security Features
The HTTP server security features include:
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 ONE 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 ONE 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 ONE 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:
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 ONE Application Server Developer’s Guide to NASPI.
J2EE Application Security FeaturesThe 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 ONE Application Server Developer’s Guide.
The following J2EE security features are supported in the Sun ONE Application Server environment:
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 ONE 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 ONE 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 ONE Application Server container. Form authentication is supported.
Refer to the Sun ONE 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 ONE Application Server are file, ldap, certificate, and solaris.
Refer to the Sun ONE 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 ONE Application Server Developer’s Guide for more information.
Resource Authentication
The Sun ONE Application Server supports authentication into external resources (which may require separate authentication).
Refer to the Sun ONE 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 ONE Application Server Developer’s Guide for more information.
Good PracticesThere are many precautions you can take to protect your Sun ONE 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:
These topics are discussed in "General Security Measures".
Files Associated With Server SecurityMany of the Sun ONE 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:
Details on the contents of the Sun ONE Application Server configuration files are contained in the Sun ONE 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 ONE 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
The dbswitch.conf file specifies the LDAP directory used by the Sun ONE 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 ONE 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 ONE 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 ONE 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 ONE Application Server Administrator’s Configuration File Reference.
The obj.conf File
The obj.conf file contains directives that instruct the Sun ONE 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 ONE Application Server Developer’s Guide to NASPI.
The password.conf File
If you want an SSL/TLS-enabled Sun ONE 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 ONE Application Server Administrator’s Configuration File Reference.
The certmap.conf File
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:
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 ONE Application Server.
By default, the Sun ONE 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 ONE Application Server Developer’s Guide to NASPI.
The htaccess Files
The htaccess files are dynamic configuration files that store a subset of configuration options. You can use htaccess files in combination with the Sun ONE 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 ONE 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 ONE Application Server Developer’s Guide for more information.
