Sun logo      Previous      Contents      Next     

Sun Java™ System Application Server Platform Edition 8 Administration Guide

Chapter 9
Security

This chapter describes some core application server security concepts, and describes how to configure security for the Sun Java™ System Application Server Platform Edition 8. This chapter contains the following topics:

About Application Server Security

Overview of Security

Security is about protecting data: how to prevent unauthorized access or damage to it in storage or transit. The Application Server has a dynamic, extensible security architecture based on the J2EE standard. Built in security features include cryptography, authentication and authorization, and public key infrastructure. The Application Server is built on the Java security model, which uses a "sandbox" where applications can run safely, without potential risk to systems or users.

Application and System Security

Broadly, there are two kinds of application security:

In addition to application security, there is also system security, which affects all the applications on an Application Server system.

Programmatic security is controlled by the applications developer, so this document will not discuss it; declarative security is somewhat less so, and this document will touch on it occasionally. This document is intended for system administrators, and so will focus on system security.

Tools for Managing Security

The Application Server provides two tools for managing security:

Additionally, Java 2 Platform, Standard Edition (J2SE) provides two tools for managing security:

For more information on using keytool, policytool, and other Java security tools, see Java2 SDK Tools and Utilities at http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security.

Security Responsibilities

Security responsibilities are assigned to the following:

Application Developer

The application developer is responsible for the following:

An application developer may use tools such as deploytool to edit application deployment descriptors.

Application Deployer

The application deployer is responsible for:

An application deployer may use tools such as deploytool to edit application deployment descriptors.

System Administrator

The system administrator is responsible for:

A system administrator may use the Admin Console to manage server security settings, and keytool to manage certificates.

Authentication and Authorization

Authentication and authorization are central concepts of application server security.

Authentication

Authentication is the way an entity (a user, an application, or a component) determines that another entity is who it claims to be. An entity uses security credentials to authenticate itself. The credentials may be a user name and password, a digital certificate, or something else.

Typically, authentication means a user logging in to an application with a username and password; but it might also refer to an EJB providing security credentials when it requests a resource from the server. Usually, servers or applications require clients to authenticate; additionally, clients may require servers to authenticate themselves, too. When authentication is bidirectional, it is called mutual authentication.

When an entity tries to access a protected resource, the Application Server uses the authentication mechanism configured for that resource to determine whether to grant access. For example, a user may enter a user name and password in a web browser, and if the application verifies those credentials, the user is authenticated. The user is associated with this authenticated security identity for the remainder of the session.

The Application Server supports four types of authentication, as outlined in Table 9-1. An application specifies the type of authentication it uses in its deployment descriptors. Use deploytool to configure the authentication method for an application. For more information, see Tools for Managing Security.

Table 9-1  Application Server Authentication Methods

Authentication Method

Communication Protocol

Description

User Credential Encryption

Basic

HTTP (SSL optional)

Uses the server’s built-in pop-up login dialog box.

None, unless using SSL.

Form-based

HTTP (SSL optional)

Application provides its own custom login and error pages.

None, unless using SSL.

Client Certificate

HTTPS
(HTTP over SSL)

Server authenticates the client using a public key certificate.

SSL

Digest

HTTP

Uses server’s built-in pop-up login dialog box

Passwords MD5 encrypted.

Single Sign-On

Single sign-on enables multiple applications in one virtual server instance to share user authentication state. With single sign-on, a user who logs in to one application becomes implicitly logged in to other applications that require the same authentication information.

Single sign-on is based on groups. All web applications whose deployment descriptor defines the same group and use the same authentication method (basic, form, digest, certificate) share single sign-on.

Single sign-on is enabled by default for virtual servers defined for the Application Server. For information on disabling single sign-on, see Configuring Single Sign-On (SSO).

Authorization

Once a user is authenticated, his or her level of authorization determines what operations he can perform. A user’s authorization is based on his role. For example, a human resources application may authorize managers to view personal employee information for all employees, but allow employees to only view their own personal information. For more on roles, see Users, Groups, Roles, and Realms.

JACC Providers

JACC (Java Authorization Contract for Containers) is part of the J2EE 1.4 specification that defines an interface for pluggable authorization providers. This enables you to set up third-party “plug in” modules to perform authorization.

By default, the Application Server provides a simple, file-based authorization engine that complies with the JAAC specification. In addition, you may specify additional third-party JAAC providers.

JACC providers use the Java Authentication and Authorization Service (JAAS) APIs. JAAS enables services to authenticate and enforce access controls upon users. It implements a Java technology version of the standard Pluggable Authentication Module (PAM) framework.

Audit Logging

The Application Server can provide an audit trail of all authentication and authorization decisions through audit modules. The Application Server provides a default audit module, and you can also configure your own custom audit modules. For information on developing custom audit modules, see the J2EE 1.4 Application Server Developer's Guide.

Users, Groups, Roles, and Realms

The Application Server enforces its authentication and authorization policies upon the following entities:

Note: Users and groups are designated for the entire Application Server, whereas each application defines its own roles. Then, the applications specify mappings between users/groups and roles, as illustrated in Figure 9-1.

A realm is a repository containing user and group information and their security credentials. A realm is also called a security policy domain.

Figure 9-1  Role Mapping

Groups

A J2EE group (or simply group) is a category of users classified by common traits, such as job title or customer profile. For example, users of an e-commerce application might belong to the “customer” group, but the big spenders would belong to the “preferred” group. Categorizing users into groups makes it easier to control the access of large numbers of users.

Roles

A role defines which applications and what parts of each application users can access and what they can do. In other words, roles determine users’ and authorization levels.

For example, in a personnel application all employees might have access to phone numbers and email addresses, but only managers would have access to salary information. The application could define at least two roles: employee and manager; only users in the manager role could view salary information.

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, in the personnel application there might be groups such as “full-time,” “part-time,” and “on-leave,” but users in all these groups would still be in the employee role.

Roles are defined in application deployment descriptors. In contrast, groups are defined for an entire server and realm. The application developer or deployer maps roles to one or more groups for each application in its deployment descriptor.

Realms

A realm, also called a security policy domain or security domain, is a scope over which the server defines and enforces a common security policy. In practical terms, a realm is a repository where the server stores user and group information.

The Application Server comes pre-configured with two realms: file (the initial default realm) and certificate. You can set up two other realms: ldap and solaris, in addition to custom realms. Applications can specify the realm to use in their deployment descriptor. If they do not specify a realm, the Application Server will use its default realm.

In the file realm, the server stores user credentials locally in a file. You can use the Admin Console to manage users in the file realm. For more information, see Managing file Realm Users

In the certificate realm, the server stores user credentials in a certificate database. When using the certificate realm, the server uses certificates with the HTTPS protocol to authenticate web clients. For more information about certificates, see Introduction to Certificates and SSL.

In the ldap realm the server gets user credentials from a Lightweight Directory Access Protocol (LDAP) server such as the Sun Java System Directory Server. LDAP is a protocol for enabling anyone to locate organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet. Consult your LDAP server documentation for information on managing users and groups in the ldap realm.

In the solaris realm the server gets user credentials from the Solaris operating system. This realm is supported on the Solaris 9 OS and later versions. Consult your Solaris documentation for information on managing users and groups in the solaris realm.

A custom realm is any other repository of user credentials, such as a relational database or third-party component. For more information, see Creating a Custom Realm.

Introduction to Certificates and SSL

Digital Certificates

Digital certificates (or simply certificates) are electronic files that uniquely identify people and resources on the Internet. Certificates also enable secure, confidential communication between two entities.

There are different kinds of certificates, such as personal certificates, used by individuals, and server certificates, used to establish secure sessions between the server and clients through secure sockets layer (SSL). For more information on SSL, see Secure Sockets Layer.

Certificates are based on public key cryptography, which uses pairs of digital keys (very long numbers) to encrypt, or encode, information so it can be read only by its intended recipient. The recipient then decrypts (decodes) the information to read it.

A key pair contains a public key and a private key. The owner distributes the public key and makes it available to anyone. But the owner never distributes the private key; it is always kept secret. Because the keys are mathematically related, data encrypted with a key can be decrypted only with the other key in the pair.

A certificate is like a passport: it identifies the holder and provides other important information. Certificates are issued by a trusted third party called a Certification Authority (CA). The CA is analogous to passport office: it validates the certificate holder’s identity and “signs” the certificate so that it cannot be forged or tampered with. Once a CA has signed a certificate, the holder can present it to prove their identity and establish encrypted, confidential communications.

Most importantly, a certificate binds the owner’s public key to the owner’s identity. Like a passport binds a photograph to personal information about its holder, a certificate binds a public key to information about its owner.

In addition to the public key, a certificate typically includes information such as:

Digital Certificates are governed by the technical specifications of the x.509 format. To verify the identity of a user in the certificate realm, the authentication service verifies an X.509 certificate, using the common name field of the X.509 certificate as the principal name.

Certificate Chains

Web browsers are pre-configured with a set of “root” CA certificates that the browser automatically trusts. Any certificates from elsewhere must come with a certificate chain to verify their validity. A certificate chain is series of certificates issued by successive CAs, eventually ending in a root CA certificate.

When a certificate is first generated, it is a self-signed certificate. A self-signed certificate is one for which the issuer (signer) is the same as the subject (the entity whose public key is being authenticated by the certificate). When the owner sends a certificate signing request (CSR) to a CA then and imports the response, the self-signed certificate is replaced by a chain of certificates. At the bottom of the chain is the certificate (reply) issued by the CA authenticating the subject's public key. The next certificate in the chain is one that authenticates the CA's public key. Usually, this is a self-signed certificate (that is, a certificate from the CA authenticating its own public key) and the last certificate in the chain.

In other cases, the CA may return a certificate chain of certificates. In this case, the bottom certificate in the chain is the same (a certificate signed by the CA, authenticating the public key of the key entry), but the second certificate in the chain is a certificate signed by a different CA, authenticating the public key of the CA you sent the CSR to. Then, the next certificate in the chain will be a certificate authenticating the second CA's key, and so on, until a self-signed "root" certificate is reached. Each certificate in the chain (after the first) thus authenticates the public key of the signer of the previous certificate in the chain.

Secure Sockets Layer

Secure Sockets Layer (SSL) is the most popular standard for securing Internet communications and transactions. Web applications use HTTPS (HTTP over SSL). HTTPS uses digital certificates to ensure secure, confidential communications between server and clients. In an SSL connection, both the client and the server encrypt data before sending it, then decrypt it upon receipt

When a web browser (client) wants to connect to a secure site, an “SSL handshake” happens:

After the “handshake,” the client has verified the identity of the Web site, and only the client and the web server have a copy of the session key. From then, on the client and the server use the session key to encrypt all their communications with each other. Thus, their communications is ensured to be secure.

The newest version of the SSL standard is called TLS (Transport Layer Security). The Application Server supports the Secure Sockets Layer (SSL) 3.0 and the Transport Layer Security (TLS) 1.0 encryption protocols.

To use SSL, the Application Server must have a certificate for each external interface, or IP address, that accepts secure connections. The HTTPS service of most web servers will not run unless a digital certificate has been installed. Use the procedure in Generating a Server Certificate to set up a digital certificate that your web server can use for SSL.

Ciphers

A cipher is a cryptographic algorithm used for encryption or decryption. SSL and TLS protocols support a variety of ciphers used to authenticate the server and client to each other, transmit certificates, and establish session keys.

Some ciphers are stronger and more secure than others. Clients and servers may support different cipher suites. You can choose ciphers from the SSL3 and TLS protocols. During a secure connection, the client and the server agree to use the strongest cipher they both have enabled for communication, so it is usually sufficient to enable all ciphers.

Using Name-based Virtual Hosts

Using name-based virtual hosts for a secure application can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined prior to authentication, and it is therefore not possible to assign multiple certificates to a single IP address.

If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most browsers will compare the server’s domain name against the domain name listed in the certificate, if any (applicable primarily to official, CA-signed certificates). If the domain names do not match, these browsers will display a warning. In general, only address-based virtual hosts are commonly used with SSL in a production environment.

Firewalls

A firewall controls the flow of data between two or more networks, and manages the links between the networks. A firewall may consist of both hardware and software elements. This section describes some common firewall architectures and their configuration. The information here pertains primarily to the Application Server. For details about a specific firewall technology refer to the documentation from your firewall vendor.

In general, you must configure you firewalls so that clients can access the necessary TCP/IP ports. For example, if the HTTP listener is operating on port 8080, you must, you must configure the firewall to allow HTTP requests on port 8080. Likewise, if HTTPS requests are setup for port 1043, you must configure your firewalls to allow HTTPS requests on port 1043.

If you want to allow direct RMI/IIOP access from the Internet to EJB modules, you must open the RMI/IIOP listener port as well, but this is strongly discouraged since it creates security risks.

In the double firewall architecture, you must configure the outer firewall to allow for HTTP and HTTPS transactions. You must configure the inner firewall to allow the HTTP server plug in to communicate with the Application Server behind the firewall.

Security Managment With the Admin Console

The Admin Console enables you to manage:

Server Security Settings

On the Security Settings page, you can set properties for the server as a whole, such as the default realm, the anonymous role, the default principal user name and password. For more information, see Configuring Security Settings.

Realms and file Realm Users

The concept of realms was introduced in Users, Groups, Roles, and Realms. With the Admin Console, you can:

See Admin Console Tasks for Realms for details on these tasks.

JACC Providers

JACC providers were introduced in JACC Providers. With the Admin Console, you can:

See Admin Console Tasks for JACC Providers for details on these tasks.

Audit Modules

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

With the Admin Console, you can:

See Admin Console Tasks for Audit Modules for details on these tasks.

HTTP and IIOP Listener Security

Each virtual server in the HTTP service provides network connections through one or more HTTP listeners. For general information about the HTTP service and HTTP listeners, see What Is the HTTP Service?

The Application Server supports CORBA (Common Object Request Broker Architecture) objects, which use the Internet Inter-Orb Protocol (IIOP) to communicate across the network. An IIOP listener accepts incoming connections from remote clients of EJBs and from other CORBA-based clients. For general information on IIOP listeners, see IIOP Listeners.

With the Admin Console you can:

See Admin Console Tasks for Listeners for details on these tasks.

Admin Console Tasks for Security

Configuring Security Settings

The Security page in the Admin Console enables you to set a variety of system-wide security settings. To edit these settings:

  1. In the tree component, select the Security node in the Admin Console tree.

    2. The Security page displays.

  2. Modify the values as desired. Table 9-2 describes the settings on this page.
  3. Enter additional properties to pass to the Java Virtual Machine (JVM) in the Additional Properties section.
  4. Valid properties are dependent upon the type of realm being configured.
    Select Save to save the changes or Load Defaults to restore the default values.

    Table 9-2  General Security Settings

    Setting

    Description

    Audit Logging

    Whether audit logging is enabled. If enabled, the server will load and run all the audit modules specified in the Audit Modules setting. Otherwise, the server does not access audit modules. Disabled by default.

    Default Realm

    The active (default) realm the server uses for authentication. Applications will use this realm unless they specify a different realm in their deployment descriptor. All configured realms appear in the list. The initial default realm is the file realm.

    Anonymous Role

    The name for the default or anonymous role. The anonymous role is assigned to all users. Applications can use this role in their deployment descriptors to grant authorization to anyone.

    Default Principal

    Specifies the default user name. The server uses this when no principal is provided. If you enter a value in this field, you must enter a corresponding value in the Default Principal Password field.

    You do not need to set this attribute for normal server operation.

    Default Principal Password

    Password of the default principal specified in the Default Principal field.

    You do not need to set this attribute for normal server operation.

    JACC

    Class name of a configured JACC provider. See Creating a JACC Provider for Information on adding JACC providers.

    Audit Modules

    List of audit module provider classes, delimited by commas. A module listed here must be already configured. If Audit Logging is enabled, this setting must list audit modules. By default, the server uses an audit module named default. For information on creating new audit modules, see Creating an Audit Module.

Controlling Access to Administration Tools

Only users in the asadmin group are able to access Admin Console and asadmin command line utility. To give a user access to these administration tools, add them to the asadmin group, as follows:

  1. Expand the Security node in the Admin Console tree.
  2. Expand the Realms node.
  3. Select the file node.
  4. Click the Manage Users button from the Edit Realm page.

    5. Initially after installation, only the administrator user name and password entered during installation will be listed. By default, this user belongs to the group asadmin, which gives rights to modify the Application Server. Assign users to this group only if you want to grant them administrator privileges for the Application Server.

  5. Click New to add a new user to the file realm.
  6. Enter the correct information into the User Id, Password, and Group List fields. To authorize a user to make modifications to the Application Server, include the asadmin group in the Group List.
  7. Click OK to add this user to the file realm or click Cancel to quit without saving.

Configuring Mutual Authentication

In mutual authentication, both server and client-side authentication are enabled. To test mutual authentication, you must have a client with a valid certificate. For information on creating a client certificate, see The J2EE 1.4 Tutorial.

Enabling Mutual Authentication for the Certificate Realm

The Application Server uses the certificate realm for HTTPS authentication. To specify mutual authentication for all the applications that use this realm, follow this procedure:

  1. In the Admin Console tree, expand Security, then expand Realms, and select certificate.
  2. Click the Add Property button.
    • In the Name field, enter clientAuth.
    • In the Value field, enter true.
  3. Click Save.
  4. Restart the Application Server.

    5. After you restart the server, it will require client authentication for all applications that use the certificate realm.

Enabling Mutual SSL Authentication an Application

If you to enable mutual authentication for a specific application, use deploytool to set the method of authentication to Client-Certificate. For more information about using deploytool, refer to the Security chapter of the J2EE Tutorial.

Configuring Single Sign-On (SSO)

Single sign-on enables multiple applications to share user sign-on information, rather than requiring each application to have separate user sign-on. Applications using single sign-on authenticate the user one time, and the authentication information is propagated to all other involved applications.

Single sign-on applies to web applications configured for the same realm and virtual server.

Note: Single sign-on uses an HTTP cookie to transmit a token that associates each request with the saved user identity, so it can only be used when the browser client supports cookies.

Single sign-on operates according to the following rules:

Single sign-on is enabled by default for the Application Server. To disable it or configure other properties, follow this procedure:

  1. In the tree component, expand the HTTP service node.
  2. Open the Virtual Servers node, and select the virtual server for which you want to disable single sign-on support.
  3. Click Add Property.

    4. A blank property entry is added to the bottom of the list.

  4. Enter sso-enable in the new Name field.
  5. Enter false in the new Property field.
  6. Add or change any other single sign-on properties:

    Property Name

    Description

    Values

    sso-max-inactive-seconds

    Number of seconds after which a user’s single sign-on record becomes eligible for purging if no client activity is received. Access to any of the applications on the virtual server keeps the single sign-on record active.

    Default is 300 seconds (5 minutes). A higher value provides longer persistence for users, but consumes more memory on server.

    sso-reap-interval-seconds

    Interval (in seconds) between purges of expired single sign-on records.

    Default is 60

  7. Click Save.
  8. Restart the Application Server.

Admin Console Tasks for Realms

Creating a Realm

The Application Server comes preconfigured with two realms: file and certificate. You can create two other realms: ldap and solaris, in addition to custom realms. Generally, you will have one realm of each type on a server. However, you can have a different certificate database for each virtual server on your system.

To create a security realm, follow these steps:

  1. In the tree component, expand the Security node.
  2. Expand the Realms node.
  3. On the Realms page, click New.

    4. The Create Realm page is displayed.

  4. Enter a name for the realm in the Name field: file, certificate, ldap, solaris, or the name of a custom realm you are defining.

Specify the class name for the realm you want to create, as shown in the following table:

Realm Name

Class Name

file

com.sun.enterprise.security.auth.realm.file.FileRealm

certificate

com.sun.enterprise.security.auth.realm.certificate.CertificateRealm

ldap

com.sun.enterprise.security.auth.realm.ldap.LDAPRealm

solaris

com.sun.enterprise.security.auth.realm.solaris.SolarisRealm

custom

Name of LoginModule class.

  1. Add the required properties and any desired optional properties for the realm.
  2. Click OK.

Equivalent asadmin command: create-auth-realm

Creating the ldap Realm

The ldap realm performs authentication using information from an LDAP server. User information may include user name, password, and the groups to which the user belongs. You must create the desired users and groups in your LDAP directory, or the information must already exist.

You must add the three properties shown in Table 9-3.

Table 9-3  Required properties for ldap realm

Property Name

Description

Value

directory

LDAP URL of the directory server.

LDAP URL of the form ldap://hostname:port
For example, ldap://myldap.foo.com:389.

base-dn

Base DN for the location of user data, which 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.

Domain for the search, for example: dc=siliconvalley, dc=BayArea, dc=sun, dc=com.

jaas-context

Type of login module to use for this realm.

Must be ldapRealm.

Additionally, you may add any of the optional properties listed in Table 9-4.

Table 9-4  Optional properties for ldap realm

Property Name

Description

Default

search-filter

Search filter to use to find the user.

uid=%s (%s expands to the subject name)

group-base-dn

Base DN for the location of groups data.

Same as the base-dn, but it can be tuned if necessary

group-search-filter

Search filter to find group memberships for the user.

uniquemember=%d (%d expands to the user element DN)

group-target

LDAP attribute name that contains group name entries.

CN

search-bind-dn

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

LDAP password for the DN given in search-bind-dn.

 

Example

For example, suppose an LDAP user, Joe Java, is defined in your LDAP directory as follows:

uid=jjava,ou=People,dc=acme,dc=com
uid=jjava
givenName=joe
objectClass=top
objectClass=person
objectClass=organizationalPerson
objectClass=inetorgperson
sn=java
cn=Joe Java

The required properties in the ldap realm would be:

Property Name

Property Value

directory

LDAP URL to your server, for example: ldap://ldap.acme.com:389

base-dn

ou=People,dc=acme,dc=com.

Could be rooted higher, for example dc=acme,dc=com, but searches would traverse a larger part of the tree, reducing performance.

jaas-context

ldapRealm

Creating the solaris Realm

The solaris realm gets user and group information from the underlying Solaris user database, as determined by the system’s configuration. The Solaris realm invokes the underlying PAM infrastructure for authenticating. If the configured PAM modules require root privileges, the domain must run as root to use this realm. For details, see your Solaris documentation for security services.

The solaris realm has one required property, jaas-context that specifies the type of login module to use. The property value must be solarisRealm.

Note: The solaris realm is supported only for Solaris 9 or later.

Creating a Custom Realm

In addition to the four built-in realms, you can also create custom realms that store user data in some other way, such as in a relational database. Development of a custom realm is outside the scope of this document; for more information, see the Sun Java System Application Server Platform Edition 8 Developer's Guide. See http://developers.sun.com/prodtech/appserver/reference/techart/as8_authentication/index.html for an example implementation of a custom realm

As an administrator, the main thing you need to know is that a custom realm is implemented by a class derived from the Java Authentication and Authorization Service (JAAS) package: this class is called the LoginModule.

To configure the Application Server to use a custom realm:

  1. Follow the procedure outline in Creating a Realm, entering the name of your custom realm and the name of the LoginModule class. You can use any unique name for your custom realm, for example myCustomRealm.
  2. Add the following properties:

    Property Name

    Property Value

    jaas-context

    LoginModule class name, for example simpleCustomRealm

    auth-type

    Description of the realm, for example “A simple example custom realm”.

  3. Click OK.
  4. Edit the domain's login configuration file install_dir/domains/domain_name/config/login.conf, and add the fully-qualified class name of the JAAS LoginModule at the end of the file, as follows:
    5. realmName {
      fully-qualified-LoginModule-classname required;
    };

    For example,

    nyCustomRealm {
      com.foo.bar.security.customrealm.SimpleCustomRealm required;
    };
  5. Copy the LoginModule class and all dependent classes into the directory install_dir/domains/domain_name/lib/classes.
  6. Restart the Server.
  7. Make sure that the realm is properly loaded.

    8. Check install_dir/domains/domain_name/logs/server.log to make sure the server loaded the realm: The server should invoke the realm’s init() method.

Editing a Realm

  1. In the tree component, expand the Security node.
  2. Expand the Realms node.
  3. Select the name of an existing realm.

    4. The Edit Realm page displays.

  4. Edit existing properties and their values as desired.

    5. For information on file realm properties, see Editing the file Realm. To manage users in the file realm, click the Manager Users button; see Managing file Realm Users for more information.

    For information on certificate realm properties, see Editing the certificate Realm.

  5. To add additional properties, click the Add Properties button. The page displays a new row. Enter a valid property name and property value. Table 9-6 describes optional properties for the certificate realm. Table 9-3 and Table 9-4 describe optional properties for the ldap realm.
  6. Click Save to save the changes or Reload Defaults to discard your changes and restore the Application Server default values.

Editing the file Realm

The server maintains all user, group, and password information in a file called a keyfile. The file property specifies the location of the keyfile.

Table 9-5  Required properties for the file realm

Property name

Description

Default Value

file

Full path and name of the keyfile.

install_dir/domains/domain-name/
config/keyfile

jaas-context

Type of login module to use for this realm.

fileRealm is the only valid value

Except for a single admin user in the asadmin group, the keyfile is initially empty, so you must add users before you can use the file realm. For instructions, see Managing file Realm Users.

Note: Users in the group asadmin are authorized to use the Admin Console and asadmin tools. Add only users to this group that you want to have server administrative privileges.

Managing file Realm Users

You can manage file realm users with the Admin Console. Users and groups in the file realm are listed in the key file, whose location is specified by the file property.

A user in the file realm can belong to a J2EE group, a category of users classified by common traits. For example, customers of an e-commerce application might belong to the CUSTOMER group, but the big spenders would belong to the PREFERRED group. Categorizing users into groups makes it easier to control the access of large numbers of users.

Initially after installation of the Application Server, the only user is the administrator entered during installation. By default, this user belongs to the group asadmin, which gives rights to modify the Application Server. Any users you assign to this group will have administrator privileges, that is, they will have access to asadmin and Admin Console.

To manage file realm users, follow this procedure:

  1. Expand the Security node in the Admin Console tree.
  2. Expand the Realms node.
  3. Select the file node.
  4. Click the Manage Users button from the Edit Realm page.

    5. The File Users page displays. In this page, you can perform the following tasks:

    • Add a user.
    • Edit an existing user.
    • Delete a user.

      • Follow the corresponding procedure in the following sections.

Adding a User

In the File Users page, to add a new user:

  1. Click New to add a new user to the file realm.
  2. Enter the following information on the File Users page:
    • User Id (required) - The name of the user.
    • Password (required) - The user’s password.
    • Confirm Password (required) - The user’s password again, for verification.
    • Group List (optional) - a comma-separated list of the groups to which the user belongs. These groups do not need to be defined elsewhere.
  3. Click OK to add this user to the list of users in the file realm. Click Cancel to quit without saving.

Equivalent asadmin command: create-file-user

Editing a User

In the File Users page, to change a user’s information:

  1. In the User Id column, click the name of the user you want to modify.
  2. Change the user’s password by entering a new password in the Password and Confirm Password fields.
  3. Change the groups to which the user belongs by adding or deleting groups in the Group List field. Separate group names with commas. Groups need not be previously defined.
  4. Click Save to save this user to the list of users in the file realm. Click Cancel to quit without saving.
Deleting a User

In the File Users page, to delete a user:

  1. Select the checkbox to the left of the name of the user(s) you want to delete.
  2. Click Delete.
  3. Click Close to return to the Edit Realm page.

Equivalent asadmin command: delete-file-user

Editing the certificate Realm

The certificate realm supports SSL authentication. This realm sets up the user identity in the Application Server’s security context, and populates it with user data obtained from cryptographically verified client certificates in the trust-store and keystore files (see Certificate Files.) You an add users to these files using keytool; for more information see the J2EE 1.4 Tutorial chapter titled Security.

With the certificate realm, J2EE containers handle authorization processing based on each user’s Distinguished Name (DN) from his or her certificate. The DN is the name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. For more information on keystores and trust-stores, refer to the keytool documentation at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html

Table 9-6 lists the optional properties for the certificate realm.

Table 9-6  Optional properties for certificate realm

Property

Description

assign-groups

A comma-separated list of group names. All clients who present valid certificates are assigned to these groups. For example, employee,manager, where these are the names of user groups.

jaas-context

Type of login module to use for this realm. For the certificate realm, the value must be certificateRealm.

Deleting a Realm

  1. Expand the Security node of the Application Server tree.
  2. Select the Realms node.
  3. Click in the box beside the realm to be deleted.
  4. Click Delete.
  5. Click Save to save the changes or Reload Defaults to negate your changes and restore the Application Server default values.

Equivalent asadmin command:delete-auth-realm

Setting the Default Realm

The default realm is the realm that the Application Server will use for authentication and authorization if an application’s deployment descriptor does not specify a realm. To set the default realm:

  1. In the tree component, select the Security node

    2. The Security page displays.

  2. In the Default Realm field, pick the desired realm from the drop-down list.
  3. Click Save to save the changes or Reload Defaults to negate your changes and restore the Application Server default values.
  4. Restart the server.

Admin Console Tasks for JACC Providers

Creating a JACC Provider

JACC (Java Authorization Contract for Containers) is part of the J2EE 1.4 specification that defines an interface for pluggable authorization providers. This enables you to set up third-party “plug in” modules to perform authorization. By default, the Application Server provides a simple, JACC-compliant file-based authorization engine. For more information, see JACC Providers.

To create a JACC provider:

  1. In the tree component, expand the Security node.
  2. Select the JACC Providers node.
  3. On the JACC Providers page, click New.
  4. On the Create JACC Provider page, enter the following:
    • Name – The application name as displayed in the deployed application list.
    • Policy Configuration – The name of the class that implements the policy configuration factory.
    • Policy Provider – The name of the class that implements the policy factory.
  5. Add additional properties to the provider by clicking the Add Property button. Valid properties include:
    • repository: the directory that contains the policy file. For the default provider, this value is install_dir/domain_dir/generated/policy.
  6. Click OK to save this configuration, or click Cancel to quit without saving.

Editing a JACC Provider

  1. In the tree component, expand the Security node.
  2. Expand the JACC Providers node.
  3. Select the node of the JACC provider that you want to edit.
  4. On the Edit JACC Provider page, modify the provider information as desired:
    • Policy Configuration – The name of the class that implements the policy configuration factory.
    • Policy Provider – The name of the class that implements the policy factory.
  5. To add additional properties, click the Add button. Enter the name and value for the property. Valid entries include:
    • repository: the directory that contains the policy file. For the default provider, this value is install_dir/domain_dir/generated/policy.
  6. To delete an existing property, click in the checkbox to the left of the property, then click Delete Properties.
  7. Click Save.

Deleting a JACC Provider

  1. In the tree component, expand the Security node.
  2. Select the JACC Providers node.
  3. Click in the checkbox to the left of the JACC provider you wish to delete.
  4. Click Delete.

Setting the Active JACC Provider

To specify the JACC provider that the server uses:

  1. In the tree component, select the Security node

    2. The Security page displays.

  2. In the JACC field, enter the name of the JACC provider that you want the server to use. The tree component lists all the configured JACC providers.
  3. Select Save to save the changes.
  4. Restart the Application Server.

Admin Console Tasks for Audit Modules

Creating an Audit Module

The Application Server provides a simple default audit module; for more information, see Using the Default Audit Module.

To create a new audit module:

  1. In the tree component, expand the Security node.
  2. Select the Audit Modules node.
  3. On the Audit Modules page, click New.
  4. On the Create Audit Module page, enter the following information:
    • Name – The name of the new audit module.
    • Classname – The fully-qualified name of the class that implements this module.
  5. To add additional JVM properties to this module, click Add Property. Specify a name and value for each property.
  6. Click OK to save your entries, or click Cancel to quit without saving.

Editing an Audit Module

To edit an audit module:

  1. In the tree component, expand the Security node.
  2. Expand the Audit Modules node.
  3. Click the node of the audit module that you want to edit.
  4. On the Edit Audit Module page, modify the class name if desired.
  5. Enter any additional properties for the module by selecting the Add button and entering the name and value of the property. Valid values include:
    • auditOn: specifies whether or not to use this audit module. Possible values are true and false.
  6. Modify any existing properties by selecting the name or value to be modified, and entering the changes directly into the text field.
  7. Delete a property by selecting the checkbox to the left of the property and clicking Delete Properties.
  8. Click Save.

Deleting an Audit Module

To delete an audit module:

  1. In the tree component, expand the Security node.
  2. Select the Audit Modules node.
  3. Click in the checkbox to the left of the audit module you want to delete.
  4. Click Delete.

Setting the Active Audit Module

To specify the audit module that the server uses:

  1. In the tree component, select the Security node

    2. The Security page displays.

  2. In the Audit Modules field, enter the name of the audit module that you want the server to use. (The built-in audit module is called default.)
  3. Select Save to save the changes.
  4. Restart the Application Server.

Using the Default Audit Module

The default audit module logs authentication and authorization requests to the server log file. For information on changing the location of the log file, see Configuring General Logging Settings.

Authentication log entries include the following information:

Regardless of whether audit logging is enabled, the Application Server logs all denied authentication events.

Authorization log entries include the following information:

Enabling and Disabling Audit Logging

To specify the audit module that the server uses:

  1. In the tree component, select the Security node.

    2. The Security page displays.

  2. To enable logging, select the Audit Logging check box. To disable it, deselect it.
  3. Select Save to save the changes.
  4. Restart the Application Server.

Enabling and Disabling the Default Audit Module

In addition to enabling logging, you must set any properties required by the specific audit module you want to use. In the case of the default audit module, follow this procedure:

  1. In the tree component, select the Security node.
  2. Expand the Audit Modules node.
  3. Click the default node.
  4. Set the value of the auditOn property to true.
  5. Select Save to save the changes.
  6. Restart the Application Server.

Admin Console Tasks for Listeners

Configuring Security for HTTP Listeners

Each virtual server in the HTTP service provides network connections through one or more HTTP listeners. With the Admin Console, you can create new HTTP listeners and edit the settings of existing HTTP listeners.

To edit security settings for an existing HTTP listener:

  1. Expand the HTTP Service node.
  2. Select the HTTP Listeners node.
  3. Click the name of the HTTP listener for which you want to enable security.

    4. Alternatively, if you want to create a new listener, click New and follow the procedure in Creating an HTTP Listener.

  4. Follow the procedure in Setting Listener Security Properties to set security properties.
  5. Click Save to save the changes, or click Load Defaults to restore the listener to its default values.

Equivalent asadmin command: create-http-listener

Configuring Security for IIOP Listeners

The Application Server supports CORBA (Common Object Request Broker Architecture) objects, which use the Internet Inter-Orb Protocol (IIOP) to communicate across the network. An IIOP listener accepts incoming connections from remote clients of EJBs and from other CORBA-based clients. With the Admin Console, you can create new IIOP listeners and edit the settings of existing IIOP listeners.

To edit security properties for an IIOP listener:

  1. Expand the ORB node.
  2. Select the IIOP Listeners node.
  3. Click the name of the IIOP listener for which you want to enable security.

    4. Alternatively, if you want to create a new listener, click New and follow the procedure in Creating an IIOP Listener.

  4. Follow the procedure in Setting Listener Security Properties to set security properties.
  5. When you are done setting all properties, click Save to save the changes, or click Load Defaults to restore the properties to their default values.

If you created a new listener, it will now be listed in the Current Listeners table on the IIOP Listeners page.

Equivalent asadmin command: create-iiop-listener

Setting Listener Security Properties

Follow this common procedure for setting both HTTP listener and IIOP listener security properties:

  1. In the Edit HTTP Listener or Edit IIOP Listener page, go to the section labeled Security.
  2. Check the Enabled box in the Security field. When this option is selected, you must select SSL3/TLS to specify which type of security is enabled.
  3. If you want clients to authenticate themselves to the Application Server when using this listener, check the Enabled box in the Client Authentication field.
  4. Enter the name of an existing server keypair and certificate in the Certificate Nickname field.

    5. You can find the Certificate Nickname with the keytool command
    keytool -list -v -keystore keystore.jks.

  1. In the SSL3/TLS section:
    1. Disable SSL3 or TLS if desired, but you must enable at least one. By default, both SSL3 and TLS will be enabled.
    2. Enable individual cipher suites if desired. By default, all supported cipher suites are enabled.

Security Tasks for Connector Connection Pools

About Connector Connection Pools

A connector module (also called a resource adapter) enables J2EE applications to interact with enterprise information systems (EISs). A connector resource provides an application with a connection to an EIS. A connector connection pool is a group of reusable connections for a particular EIS.

Security maps enable you to create a mapping between J2EE users and groups and EIS users and groups. Use the asadmin command line utility to create, update, list, and delete security maps for connector connection pools.

Note: In this context, users are referred to as principals.

Creating a Security Map

A security map for a connector connection pool maps application users and groups (principals) to EIS principals. Use a security map when an application user needs to execute EIS operations that require a specific identity in the EIS.

Use the asadmin command create-connector-security-map to create or update security maps for a connector connection pool. If a security map already exists for a connector connection pool, this command appends the existing security map to the map provided by create-connector-security-map. This command supports supports the use of the wild-card asterisk (*) to indicate all users or all user groups.

Mapping Principals

When an application principal initiates a request to an EIS, the application server first checks for an exact principal using the security map defined for the connector connection pool to determine the mapped backend EIS principal. If there is no exact match, then the application server uses the wild card character specification, if any, to determine the mapped backend EIS principal.

For example, to map app_principal1 and app_principal2 in the application to dbuser1 in the EIS, use the following asadmin command:

asadmin> create-connector-security-map --connectionpoolid TESTPOOL --principal app_principal1, app_principal2 --mappedusername dbuser1

Other Tasks for Security Maps

The asadmin utility also provides the following commands for working with security maps:

Working with Certificates and SSL

Certificate Files

Installation of the Application Server generates a digital certificate suitable for internal testing. By default, the Application Server stores its certificate information in two files in the install_dir/domains/domain_name/config directory:

Changing the Location of Certificate Files

By default, the keystore and trust-store files are stored in the install_dir/domains/domain_name/config directory. To change this default location:

  1. In the Admin Console tree component, select the Application Server node.
  2. Click the JVM Settings tab.
  3. Click the JVM Options sub-tab.
  4. On the JVM Options page, edit the Debug Options field as follows:
    5. -Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/path/ks_name
    -Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/path/ts_name

    where ks_name is the keystore file name and ts_name is the trust-store file name.

  5. Click Save.
  6. Restart the Application Server.

Using Keytool

You can use keytool to set up and work with digital certificates. keytool ships with the J2SE software and enables you to administer public/private key pairs and associated certificates. It also enables users to cache the public keys (in the form of certificates) of their communicating peers.

To run keytool, you must have configured your shell environment properly such that the path refers to the J2SE /bin directory. For more information on keytool, see the keytool documentation at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html

Generating a Server Certificate

You can use keytool to generate, import, and export certificates. By default, keytool creates a keystore file in the directory where you run it.

To generate a server certificate:

  1. Change to the directory in which you want to generate the server certificate.

    2. Always generate the certificate in the directory containing the server’s keystore and trust-store files, by default install_dir/domains/domain_name/config. For information on changing the location of these files, see Changing the Location of Certificate Files.

  2. Enter the following keytool command to generate the server certificate in the keystore file, keystore.jks:
    3. keytool -genkey -alias keyAlias
    -keyalg RSA
    -keypass changeit
    -storepass changeit
    -keystore keystore.jks
  1. Enter the following keytool command to export the generated server certificate to the file server.cer:
    2. keytool -export -alias keyAlias
    -storepass changeit
    -file server.cer
    -keystore keystore.jks
  2. If you want to have the certificate signed by a certificate authority, see Signing a Digital Certificate for more information.
  3. To create the trust-store file cacerts.jks and add the server certificate to the trust-store, enter the following keytool command:
    4. keytool -import -v -trustcacerts
    -alias server-alias
    -file server.cer
    -keystore cacerts.jks
    -keypass changeit
  1. Type yes, then press Enter.

    2. Then keytool displays something like this:

    Certificate was added to keystore
    [Saving cacerts.jks]
  2. Restart the Application Server.

For complete information about using keytool, see the keytool documentation at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html

Signing a Digital Certificate

After creating a digital certificate, the owner must be sign it to prevent forgery. E-commerce sites, or those for which authentication of identity is important can purchase a certificate from a well-known Certificate Authority (CA). If authentication is not a concern, for example if you simply want to ensure private secure communications, you can save the time and expense involved in obtaining a CA certificate and use a self-signed certificate.

Using a Certificate From a CA

To use a digital certificate signed by a CA:

  1. Follow the instructions on the CA’s website for generating certificate keypairs.
  2. Download the generated certificate keypair.

    3. Save the certificate in the directory containing the server keystore and trust-store files, by default install_dir/domains/domain1/config directory. See Changing the Location of Certificate Files for instructions on changing this location.

  3. In your shell, change to the directory where you have saved the certificate.
  4. Use keytool to import the certificate into your local keystore and, if necessary, your local trust-store.
    5. keytool -import -v -trustcacerts
    -alias server-alias
    -file server.cer
    -keystore cacerts.jks
    -keypass changeit
    -storepass changeit
  1. Restart the Application Server.

For complete information about using keytool, see the keytool documentation at:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html

Deleting a Certificate

You can delete a certificate with keytool. Follow this procedure:

  1. Use keytool -delete to delete the existing certificate.
    2. keytool -delete
    -alias alias_name
    -keystore keystore_name
    -storepass password

    For a complete list of possible options for the -delete command, refer to the keytool documentation at:



Previous      Contents      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.