Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide

- Previous: Chapter 8 J2EE Containers
- Next: Admin Console Tasks for Security

# About Application Server Security

- Overview of Security

- About Authentication and Authorization

- Understanding Users, Groups, Roles, and Realms

- Introduction to Certificates and SSL

- About Firewalls

- Managing Security With the Admin Console

## 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. The following topics are discussed:

- Understanding Application and System Security

- Tools for Managing Security

- Managing Security of Passwords

- Assigning Security Responsibilities

### Understanding Application and System Security

Broadly, there are two kinds of application security:

- In programmatic security, application code written by the developer handles security chores. As an administrator, you don’t have any control over this mechanism. Generally, programmatic security is discouraged since it hard-codes security configurations in the application instead of managing it through the J2EE containers.

- In declarative security, the container (the Application Server) handles security through an application’s deployment descriptors. You can control declarative security by editing deployment descriptors directly or with a tool such as `deploytool`. Because deployment descriptors can change after an application is developed, declarative security allows for more flexibility.

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 application developer, so this document does not discuss it; declarative security is somewhat less so, and this document touches on it occasionally. This document is intended primarily for system administrators, and so focuses on system security.

### Tools for Managing Security

The Application Server provides the following tools for managing security:

- Admin Console, a browser-based tool used to configure security for the entire server, to manage users, groups, and realms, and to perform other system-wide security tasks. For a general introduction to the Admin Console, see Tools for Administration. For an overview of the security tasks you can perform with the Admin Console, see Managing Security With the Admin Console.

- `asadmin`, a command-line tool that performs many of the same tasks as the Admin Console. You may be able to do some things with `asadmin` that you cannot do with Admin Console. You perform `asadmin` commands from either a command prompt or from a script, to automate repetitive tasks. For a general introduction to `asadmin`, see Tools for Administration.

- `deploytool`, a graphical packaging and deployment tool for editing application deployment descriptors to control individual applications’ security. Because `deploytool` is intended for application developers, this document does not describe its use in detail. For instructions on using `deploytool`, see the tool’s online help and The J2EE 1.4 Tutorial at `http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html`.

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

- `keytool`, a command-line utility for managing digital certificates and key pairs. Use `keytool` to manage users in the `certificate` realm.

- `policytool`, a graphical utility for managing system-wide Java security policies. As an administrator, you will rarely need to use `policytool`.

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

In the Enterprise Edition, two other tools that implement Network Security Services (NSS) are available for managing security. For more information on NSS, go to `http://www.mozilla.org/projects/security/pki/nss/`. The tools for managing security include the following:

- `certutil`, a command-line utility for managing certificates and key databases.

- `pk12util`, a command-line utility used to import and export keys and certificates between the certificate/key databases and files in PKCS12 format.

For more information on using `certutil`, `pk12util`, and other NSS security tools, see NSS Security Tools at `http://www.mozilla.org/projects/security/pki/nss/tools`.

### Managing Security of Passwords

In this release of the Application Server, the file `domain.xml`, which contains the specifications for a particular domain, initially contains the password of the Sun Java System Message Queue broker in clear text. The element in the `domain.xml` file that contains this password is the `admin-password` attribute of the `jms-host` element. Because this password is not changeable at installation time, it is not a significant security impact.

However, use the Admin Console to add users and resources and assign passwords to these users and resources. Some of these passwords are written to the `domain.xml` file in clear text, for example, passwords for accessing a database. Having these passwords in clear text in the `domain.xml` file can present a security hazard. You can encrypt any password in `domain.xml`, including the `admin-password` attribute or a database password using the following procedure.

#### To encrypt a password in domain.xml

1. From the directory where the `domain.xml` file resides (domain-dir`/config` by default), run the following `asadmin` command:

       asadmin create-password-alias --user admin alias-name

   For example,

       asadmin create-password-alias --user admin jms-password

   A password prompt appears (`admin` in this case). Refer to the man pages for the `create-password-alias`, `list-password-aliases`, `delete-password-alias` commands for more information.

2. Remove and replace the password in `domain.xml`. This is accomplished using the `asadmin set` command. An example of using the `set` command for this purpose is as follows:

       asadmin set --user admin server.jms-service.jms-host.
       default_JMS_host.admin-password='${ALIAS=jms-password}'

3. Restart the Application Server for the relevant domain.

#### Protecting files with encoded passwords

Some files contain encoded passwords that need protecting using file system permissions. These files include the following:

- domain-dir`/master-password`

  This file contains the encoded master password and should be protected with file system permissions 600.

- Any password file created to pass as an argument using the `--passwordfile` argument to `asadmin` should be protected with file system permissions 600.

#### To change the master password

The master password (MP) is an overall shared password. It is never used for authentication and is never transmitted over the network. This password is the choke point for overall security; the user can choose to enter it manually when required, or obscure it in a file. It is the most sensitive piece of data in the system. The user can force prompting for the MP by removing this file. When the master password is changed, it is re-saved in the master-password keystore.

1. Stop the Application Server for the domain. Use the `asadmin change-master-password` command, which prompts for the old and new passwords, then re-encrypts all dependent items. For example,

       asadmin change-master-password>
       Please enter the master password>
       Please enter the new master password>
       Please enter the the new master password again>

2. Restart the Application Server.

   Caution –

   At this point in time, server instances that are running must not be started and running server instances must not be restarted until the SMP on their corresponding node agent has been changed. If a server instance is restarted before changing its SMP, it will fail to come up.

3. Stop each node agent and its related servers one at a time. Run the `asadmin change-master-password` command again, and then restart the node agent and its related servers.

4. Continue with the next node agent until all node agents have been addressed. In this way, a rolling change is accomplished.

#### To change the admin password

Encrypting the admin password was discussed in Managing Security of Passwords. Encrypting the admin password is strongly encouraged. If you want to change the admin password before encrypting it, use the `asadmin set` command. An example of using the `set` command for this purpose is as follows:

    asadmin set --user admin
    server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

It is also possible to change the admin password using the Admin Console as in the following procedure.

1. In the Admin Console tree component, expand the Configurations node.

2. Select the instance to configure:

   - To configure a particular instance, expand the instance’s config node. For example, the default instance, `server`, expand the `server-config` node.

   - To configure the default settings for all instances, expand the `default-config` node.

3. Expand the Security node.

4. Expand the Realms node.

5. Select the `admin-realm` node.

6. Click the Manage Users button from the Edit Realm page.

7. Select the user named `admin`.

8. Enter the new password and confirm the password.

9. Click Save to save or click Close to close without saving.

### Assigning Security Responsibilities

Security responsibilities are assigned to the following:

- Application Developer

- Application Deployer

- System Administrator

#### Application Developer

The application developer is responsible for the following:

- Specifying roles and role-based access restrictions for application components.

- Defining an application’s authentication method and specifying the parts of the application that are secured.

An application developer can use tools such as `deploytool` to edit application deployment descriptors. These security tasks are discussed in more detail in the Security chapter of The J2EE 1.4 Tutorial, which can be viewed at `http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html`.

#### Application Deployer

The application deployer is responsible for:

- Mapping 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.

An application deployer can use tools such as `deploytool` to edit application deployment descriptors. These security tasks are discussed in more detail in the Security chapter of The J2EE 1.4 Tutorial, which can be viewed at `http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html`.

#### System Administrator

The system administrator is responsible for:

- Configuring security realms.

- Managing user accounts and groups.

- Managing audit logs.

- Managing server certificates and configuring the server’s use of secure sockets layer (SSL).

- Handling other miscellaneous system-wide security features, such as security maps for connector connection pools, additional JACC Providers, and so on.

A system administrator uses the Admin Console to manage server security settings and `certutil` to manage certificates. This document is intended primarily for system administrators.

## About Authentication and Authorization

Authentication and authorization are central concepts of application server security. The following topics are discussed related to authentication and authorization:

- Authenticating Entities

- Authorizing Users

- Specifying JACC Providers

- Auditing Authentication and Authorization Decisions

- Configuring Message Security

### Authenticating Entities

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 user name 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 can 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 can 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 Authenticating Entities. An application specifies the type of authentication it uses within its deployment descriptors. For more information on using `deploytool` to configure the authentication method for an application, see The J2EE 1.4 Tutorial at `http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html`.

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

#### Verifying 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 To configure single sign-on (SSO).

### Authorizing Users

Once a user is authenticated, the level of authorization determines what operations can be performed. 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 view only their own personal information. For more on roles, see Understanding Users, Groups, Roles, and Realms.

### Specifying 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 the administrator 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 JACC specification. It is also possible to specify additional third-party JACC 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.

### Auditing Authentication and Authorization Decisions

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, as well as the ability to customize the audit modules. For information on developing custom audit modules, see the Application Server Developer's Guide.

### Configuring Message Security

Message Security enables a server to perform end-to-end authentication of web service invocations and responses at the message layer. The Application Server implements message security using message security providers on the SOAP layer. The message security providers provide information such as the type of authentication that is required for the request and response messages. The types of authentication that are supported include the following:

- Sender authentication, including username-password authentication.

- Content authentication, including XML Digital Signatures.

Two message security providers are included with this release. The message security providers can be configured for authentication for the SOAP layer. The providers that can be configured include `ClientProvider` and `ServerProvider`.

Support for message layer security is integrated into the Application Server and its client containers in the form of (pluggable) authentication modules. By default, message layer security is disabled on the Application Server.

Message level security can be configured for the entire Application Server or for specific applications or methods. Configuring message security at the Application Server level is discussed in Chapter 10, Configuring Message Security. Configuring message security at the application level is discussed in the Developer’s Guide chapter titled Securing Applications.

## Understanding Users, Groups, Roles, and Realms

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

- Users: An individual identity defined in the Application Server. In general, a user is a person, a software component such as an enterprise bean, or even a service. A user who has been authenticated is sometimes called a principal. Users are sometimes referred to as subjects.

- Groups: A set of users defined in the Application Server, classified by common traits.

- Roles: A named authorization level defined by an application. A role can be compared to a key that opens a lock. Many people might have a copy of the key. The lock doesn't care who seeks access, only that the right key is used.

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

Note –

Users and groups are designated for the entire Application Server, whereas each application defines its own roles. When the application is being packaged and deployed, the application specifies mappings between users/groups and roles, as illustrated in the following figure.

##### Figure 9–1 Role Mapping

### Users

A user is an individual (or application program) identity that has been defined in the Application Server. A user can be associated with a group. The Application Server authentication service can govern users in multiple realms.

### 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’ 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 might define at least two roles: `employee` and `manager`; only users in the `manager` role are allowed to 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 preconfigured with three realms: `file` (the initial default realm), `certificate`, and `admin-realm`. It is possible to also set up `ldap`, `solaris`, or custom realms. Applications can specify the realm to use in their deployment descriptor. If they do not specify a realm, the Application Server uses its default realm.

In the `file` realm, the server stores user credentials locally in a file named `keyfile`. 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.

The `admin-realm` is also a `FileRealm` and stores administrator user credentials locally in a file named `admin-keyfile`. Use the Admin Console to manage users in this realm in the same way you manage users in the `file` realm. For more information, see Managing file Realm Users.

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. 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

The following topics are discussed in this section:

- About Digital Certificates

- About Secure Sockets Layer

### About 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) technology. For more information on SSL, see About 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 one 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 as proof of identity and to 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:

- The name of the holder and other identification, such as the URL of the Web server using the certificate, or an individual’s email address.

- The name of the CA that issued the certificate.

- An expiration date.

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.

#### About Certificate Chains

Web browsers are preconfigured 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 CA certificates, 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 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 can return a 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 to which you sent the CSR. Then, the next certificate in the chain is 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.

### About 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), which 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:

- The browser sends a message over the network requesting a secure session (typically, by requesting a URL that begins with `https` instead of `http`).

- The server responds by sending its certificate (including its public key).

- The browser verifies that the server’s certificate is valid and is signed by a CA whose certificate is in the browser’s database (and who is trusted). It also verifies that the CA certificate has not expired.

- If the certificate is valid, the browser generates a one time, unique session key and encrypts it with the server’s public key. The browser then sends the encrypted session key to the server so that they both have a copy.

- The server decrypts the message using its private key and recovers the session key.

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 this point forward, the client and the server use the session key to encrypt all their communications with each other. Thus, their communications are 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 described in To generate a certificate using the `keytool` utility to set up a digital certificate that your Web server can use for SSL.

#### About 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 can support different cipher suites. 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 probably will 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 display a warning. In general, only address-based virtual hosts are commonly used with SSL in a production environment.

## About Firewalls

A firewall controls the flow of data between two or more networks, and manages the links between the networks. A firewall can 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, configure the firewalls so that clients can access the necessary TCP/IP ports. For example, if the HTTP listener is operating on port 8080, configure the firewall to allow HTTP requests on port 8080 only. Likewise, if HTTPS requests are setup for port 8181, you must configure the firewalls to allow HTTPS requests on port 8181.

If direct Remote Method Invocations over Internet Inter-ORB Protocol (RMI-IIOP) access from the Internet to EJB modules are required, open the RMI-IIOP listener port as well, but this is strongly discouraged because it creates security risks.

In 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.

## Managing Security With the Admin Console

The Admin Console provides the means to manage the following aspects of security:

- Server Security Settings

- Realms and file Realm Users

- JACC Providers

- Audit Modules

- Message Security

- HTTP and IIOP Listener Security

- Admin Service Security

- Security Maps

### Server Security Settings

On the Security Settings page, set properties for the entire server, including specifying the default realm, the anonymous role, and the default principal user name and password. For more information, see To configure security settings.

### Realms and file Realm Users

The concept of realms was introduced in Understanding Users, Groups, Roles, and Realms.

- Create a new realm

- Delete an existing realm

- Modify the configuration of an existing realm

- Add, modify, and delete users in the `file` realm

- Set the default realm

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

### JACC Providers

JACC providers were introduced in Specifying JACC Providers. Use the Admin Console to perform the following tasks:

- Add a new JACC provider

- Delete or modify an existing JACC provider

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

### Audit Modules

Audit modules were introduced in Auditing Authentication and Authorization Decisions. 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.

Use the Admin Console to perform the following tasks:

- Add a new audit module

- Delete or modify an existing audit module

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

### Message Security

The concept of message security was introduced in Configuring Message Security. Use the Admin Console to perform the following tasks:

- Enable message security

- Configure a message security provider

- Delete or configure an existing message security configuration or provider

See Chapter 10, Configuring Message Security 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 EJB components and from other CORBA-based clients. For general information on IIOP listeners, see IIOP Listeners.

With the Admin Console, perform the following tasks:

- Create a new HTTP or IIOP listener, and specify the security it uses.

- Modify the security settings for an existing HTTP or IIOP listener.

See Admin Console Tasks for Listeners and JMX Connectors for details on these tasks.

### Admin Service Security

The Admin Service determines whether the server instance is a regular instance, a domain administration server (DAS), or a combination. Use the Admin Service to configure a JSR-160 compliant remote JMX connector, which handles communication between the domain administration server and the node agents, which manage server instances on a host machine, for remote server instances.

With the Admin Console, perform the following tasks:

- Manage the Admin Service

- Edit the JMX connector

- Modify the security settings of the JMX connector

See To configure security for the Admin Service’s JMX connector for details on these tasks.

### Security Maps

The concept of security maps for connector connection pools is introduced in About Security Maps. Use the Admin Console to perform the following tasks:

- Add a security map to an existing connector connection pool

- Delete or configure an existing security map

See Admin Console Tasks for Connector Connection Pools for details on these tasks.

- Previous: Chapter 8 J2EE Containers
- Next: Admin Console Tasks for Security

- © 2010, Oracle Corporation and/or its affiliates