Previous     Contents     Index     DocHome     Next     
iPlanet Application Server Administrator's Guide



Chapter 5   Securing iPlanet Application Server


This chapter describes how to implement iPlanet Application Server security.

The following topics are included in this chapter:



About Security

Implementing application security is a joint effort between the application developers and the server administrator; application developers are responsible for determining the level of security to implement and implementing that level into their applications; the administrator is responsible for managing the users and groups who use the application.

The administrator is also responsible for managing authorization to application components within an application. For Java applications using J2EE standard components, authorization is implemented via roles. Roles are created during deployment time using the iPlanet Application Server Deployment Tool and administered using the iPlanet Application Server Administration Tool (For more information about the Deployment Tool see the online Help system that is provided with the tool.). For C++ applications, authorization is implemented via access control lists that are stored in LDAP and managed using iASAT.

This chapter explains how to set up users and groups and then how they are used to secure applications. It also describes how user entries are stored in iPlanet Directory Server and managed using iPlanet Console and LDIF. The following topics are described in this section:


Limitations of This Document

This chapter provides descriptions of the basic start-up tasks you must perform when setting up Directory Server in association with your instance of iPlanet Application Server, as well as how to use iPlanet Console to manage users and groups. See iPlanet Directory Server and iPlanet Console documentation for detailed instructions and descriptions of these products.

You can find Directory Server documentation installed with your instance of iPlanet Application Server in the following location:

iASInstallDir/manual/en/slapd/

iPlanet Console documentation is available on iPlanet's web site in the following location:

http://docs.iplanet.com/docs/manuals/console.html


What Is LDAP?

Every instance of iPlanet Application Server uses Directory Server to store shared server information, including information about users and groups. Directory Server supports Lightweight Directory Access Protocol (LDAP) versions 2 and 3. LDAP is an open directory access protocol that runs over TCP/IP. It is scalable to a global size and millions of entries. Using Directory Server, you can store all of your enterprise's information in a single, centralized repository of directory information that any application server can access via the network.

iPlanet Directory Server is installed with each instance of iPlanet Application Server.

The types of Directory Servers that can be configured for iPlanet Application Server are as listed below:

Master LDAP Server. . The LDAP server that maintains the master data.

Consumer LDAP Server. The LDAP server that contains a copy of the data that is maintained by the master LDAP server. Multiple consumer LDAP servers can be configured for iPlanet Application Server.

Primary LDAP Server. The first LDAP server that is configured to iPlanet Application Server, for configuration information.

Backup LDAP Server. The second LDAP server that is configured to iPlanet Application Server. iPlanet Application Server connects to this server if the primary LDAP server fails. Multiple backup LDAP servers can be configured for iPlanet Application Server.


What Is iPlanet Console?

iPlanet Console is a stand-alone Java application. It finds all resources and applications registered in Directory Server, and displays them in a graphical interface. iPlanet Console functions independently of any server, and you can use it from any computer or workstation connected to your enterprise.

iPlanet Console is installed with each instance of iPlanet Application Server. You use iPlanet Console to manage users and groups for iPlanet Application Server. You can also use iPlanet Console to launch the iPlanet Application Server Administration Tool, but only for local instances of iPlanet Application Server -- that is, instances of iPlanet Application Server installed on the same machine as iPlanet Console. You must launch remote instances of iPlanet Application Server from the command line or from the Windows NT start menu.



Storing and Managing Users and Groups


The information you specify for each user and group you create is stored in the Directory Server. The information held in Directory Server is shared between all application servers when you have multiple servers supporting an application.

This section provides information for the following topics:


Implementing Security

If access to an application consists of authenticating a user's user name and password, the user name and password must be stored in the Directory Server.

An application starts the user authentication process by calling the application component—usually a servlet—responsible for user authentication. The user's login privileges are then verified against the list of users stored in Directory Server.

The authentication process verifies access to an application based on a user's name and password. To implement authentication, you must create a user profile, which holds the user name and password, for all users of an application. This procedure is described in .

Once a user is successfully authenticated, access to specific application components implementation depends on the type of application: Java application using J2EE standard components or C++ applications.


Note There are types of authentication other than verification of user name and password. For example, some applications authenticate a user through a certificate.



Authorization for J2EE Applications

Access to application components responsible for application security is based on declarative role information defined in the deployment descriptor XML file. Security can also be defined programmatically during development by using security APIs such as isCallerInRole() provided by J2EE. See the Developer's Guide (Java) for more information.


Authorization for C++ Applications

Access to application components responsible for application security is managed declaratively using access control lists provided in the iPlanet Application Server Administration Tool. Security can also be defined programmatically during development by using the LDAP JDK included with each installation of iPlanet Application Server. See the Developer's Guide (Java) for more information.


Using iPlanet Console to Add Entries to Directory Server

You can use iPlanet Console to create user entries and group entries. A user entry contains information about an individual person or object in the directory. A group consists of all users who share a common attribute. For example, all users in a particular department might belong to the same group.


What Is a Distinguished Name (DN)?

Each of the users and groups in your enterprise is represented in Directory Server by a distinguished name (DN). A DN is a text string that contains identifying attributes. You use DNs whenever you make changes in the directory's users and groups database. For example, you need to specify DN information each time you create or modify directory entries, set up access controls, and set up user accounts for applications such as mail or publishing. The users and groups interface of iPlanet Console helps you create or modify DNs.

For example, this might be a typical DN for an employee of iPlanet Communications Corporation:

uid=doe,e=doe@iplanet.com,cn=John Doe,o=Netscape Communications Corp.,c=US

The abbreviations before each equal sign in this example have the following meanings:

  • uid: user ID

  • e: email address

  • cn: the user's common name

  • o: organization

  • c: country

DNs may include a variety of name-value pairs. They are used to identify both certificate subjects and entries in directories that support LDAP.


Creating User Entries Using iPlanet Console

User security is best suited for applications that have a small number of known users. You must create a user profile for each user who accesses the application.

You must be a Directory Server administrator or a user with the necessary permissions to create a user.

To create a new user entry in the directory using iPlanet Console, perform the following steps:

  1. On Windows Systems.

    From the Windows Start menu, click Programs>iPlanet Server Products> Select iPlanet Console 4.0.

    On Solaris Systems.

    Navigate to the <iASInstall> path, and type the following command:

    ./startconsole.

    The iPlanet Console login dialog box appears:



  2. In the User ID text field, provide the user name that was specified during iPlanet Application Server installation.

  3. In the Password field, type in the password that you provided for the iPlanet Console Administration Server, during iPlanet Application Server installation. iPlanet Console's main window appears, as shown in the following figure:



  4. Click the Users and Groups tab.

    The following window appears:



  5. Choose New User from the drop-down list in the lower-right corner of the window, and then click Create.

    The Select Organizational Unit dialog box appears, as shown in the following figure:



  6. In the Select Organizational Unit window, click the directory subtree (ou) to which the user will belong, then click OK.

    The Create User window appears, as shown in the following figure:



  7. In the Create User window, enter user information.


    Note
      • The full name of the user is equivalent to the common name (cn) in the directory and is automatically generated based on the First Name and Last Name entered above. You can edit this name later, if required.

      • A user ID is automatically generated from the first and last names you enter. You can replace this user ID with one of your choosing. The user ID must be unique from all other user IDs in the directory.


  8. Click the Licenses tab when you finish entering user information in the Create User window.

    The following window appears:



  9. Select the servers the user you are creating is licensed to use.

  10. (Optional) Click the Languages tab.

    The following window appears:



    • Use the Preference Languages drop-down list to select the user's preferred language. Select a language to see the Pronunciation field when appropriate.

    • Enter language-related information.

    • Click OK.


Creating Group Entries Using iPlanet Console

A group consists of all users who share a common attribute. For example, all users with DNs containing the attribute ou=Sales belong to the Sales group. Once you create a new group, you add users, or members, to it. You can use three types of groups in your directory: static, dynamic, and certificate groups.


Creating a Static Group
Create a static group by specifying the same group attribute in the DNs of any number of users. A static group doesn't change unless you add a user to it or delete a user from it. For example, a number of users can have the attribute department=marketing in their DN. These users are not members of the Marketing group, until you explicitly add each user to the that group.

To create a static group in the directory, perform the following steps:

  1. In iPlanet Console, click the Users and Groups tab to display the following window:



  2. Choose New Group from the drop-down list in the lower-right corner of the window and then click Create.

    The following dialog box appears:



  3. In the Select Organizational Unit window, select the directory subtree (ou) to which the group will belong, then click OK.

    The Create Group window appears:



  4. In the Create Group window, enter group information, then click the Members tab.

    The following window appears:



  5. If you only want to create the group now and plan to add group members later, click OK and skip the rest of this procedure.

    To immediately add members to the group, continue to the next step.

  6. Click Add. The Search users and groups dialog box appears:



    Locate a user you want to add to the Members User ID list and click Ok. Repeat this step until all the users you want to add to the group are displayed in the Member User ID list.


Modifying Database Entries Using iPlanet Console

Before you can modify user or group data, you must first use the Users and Groups Search function to locate the user or group entry in the user directory. You can then select operations from the menu toolbar to change the entry. The operations you perform apply to all users in the Search list.

See iPlanet Console documentation for more information.


Using LDIF to Add Entries to Directory Server

Directory Server uses the LDAP Data Interchange Format (LDIF) to describe a directory and directory entries in text format. LDIF is commonly used to initially build a directory database or to add large numbers of entries to the directory all at once. You can also add or edit entries using the ldapmodify command along with the appropriate LDIF update statements.

To add entries to the database using LDIF, first define the entries in an LDIF file, then import the LDIF file from Directory Server.


Formatting LDIF Entries

LDIF consists of one or more directory entries separated by a blank line. Each LDIF entry consists of an optional entry ID, a required distinguished name, one or more object classes, and multiple attribute definitions.

The basic form of a directory entry represented in LDIF is:

dn: distinguished name

objectClass: object class

objectClass: object class

...

attribute type[;subtype]:attribute value

attribute type[;subtype]:attribute value

...

You must supply the DN and at least one object class definition. In addition, you must include any attributes required by the object classes that you define for the entry. All other attributes and object classes are optional. You can specify object classes and attributes in any order. The space after the colon is also optional. For information on standard object classes and attributes, refer to the iPlanet Directory Server documentation at:
http://docs.iplanet.com/docs/manuals/directory.html


Modifying Database Entries Using ldapmodify

You use the ldapmodify command-line utility to modify entries in an existing Directory Server database. ldapmodify opens a connection to the specified server using the distinguished name and password you supply, and modifies the entries based on LDIF update statements contained in a specified file. Because ldapmodify uses LDIF update statements, ldapmodify can do everything that ldapdelete can do. Most of Directory Server's command-line utilities are stored in a single location. You can find them in the following directory:

<iASInstallDir>/bin/slapd/server

The command line tools ldapdelete, ldapmodify, and ldapsearch—are stored in the following directory:

<iASInstallDir>/shared/bin

The following is an example of the command used to add a user to an LDIF file:

ldapmodify -h myserverhost -p 389 -D "Directory Manager" -w admin -a -f MyUsersFile


Creating Entries Programmatically

You can also create entries programmatically within an application using the LDAP JDK included with each installation of iPlanet Application Server. See the Developer's Guide (Java) for more information.



Setting Authorization to Access Application Components


Authorization to access application components depends upon the type of application:

This section includes the following topics:


Setting Role-Based Authorization (for J2EE Applications)

Roles for an application component are set globally for all application components within a module. From the Administration Tool, you can add a role to an application module and set the users and groups who belong to a role. Access is granted to any application component within a module if the requestor is a member of a pre-defined role.

If a user is not a member of a role, the application can direct the user to re-login, prompt the user to exit the application, or direct the user to a different part of the application.


Managing Roles for EJBs and Servlets

You need to use iPlanet Application Server Administration Tool (iASAT) to manage the roles of deployed applications. When you manage roles, you can specify groups to which users belong and add only groups to the role rather than adding individual users as members to the role. This is useful if you are using individual user-based security; you save the administration maintenance of updating users in the role when users change.

For example, if you have created users for an web bank application and a user closes all accounts, you need to remove that user only from the appropriate group or groups, as opposed to removing the user from the groups and any roles.


Note Roles for servlets and EJBs are created in the deployment descriptor XML files before deployment. See the online help that is provided with the Deployment Tool for more information.


To manage a role, perform the following steps:

  1. On the iASAT toolbar, click Application to open the Application window.

  2. In the left pane of the Application window, expand the iPlanet Application Server instance where the application is deployed.

  3. Open the application folder and highlight a servlet or EJB icon, as shown in the following figure:



  4. In the right pane of the Application window, click the roles tab to view the roles and role members that have been defined for this EJB/servlet.



  5. Highlight the role that you want to manage and click Edit Role, at the bottom of the window.

    The Edit Role dialog box opens showing you all the users and groups that are currently members of this role.



  6. To add a group and a user to a role, complete the following:

    1. To add a group to a role, in the Available Groups box, highlight one or more groups and click the right-arrow button.


      Note When you select multiple groups from the Available Groups box, the users in the Available Users box are not displayed.


    2. To add a user to a role, first highlight a group to which the user currently belongs from the Available Groups list and then highlight the user(s) in the Users in Group box. Finally click the right-arrow button to add the user to the role.

  7. To remove a group or user from a role, highlight the user(s) and or group(s) in the Users/Groups in Role box and click the left-arrow.


Setting Access Control List Authorization (for C++ Applications)

Access control lists (ACLs) allow you to set permissions for users and groups. A permission relates to an action the user is allowed to perform, such as read or write.

iPlanet Application Server comes with default permissions, but you can also create your own application-specific permissions and ACLs. The information in an ACL is used by the application to verify the permissions of the current user or group for an action the user attempts.

If a user does not have a certain permission, the application can direct the user to re-login, prompt him to exit the application, or direct him to a different part of the application.


Creating an Access Control List

You need to use iASAT to create and manage access control lists (ACLs). When creating an ACL, you can create groups to which users belong and add only groups to the ACL rather than adding individual users as members to the ACL. This is useful if you are using individual user-based security; you save the administration maintenance of updating users in the ACL when users change.

For example, if you have created users for an intranet application and a user leaves the company, you need to remove that user only from the appropriate group or groups, as opposed to removing the user from the groups and any ACLs.

To create an access control list, perform the following steps:

  1. On the iASAT toolbar, click Security to open the Security window.

    The following window appears:



  2. Click New. The New Access Control List dialog box appears, as shown in the following figure:



  3. In the Access Control List text field, enter a name for the ACL.

    The name can be any word or words you choose to distinguish one ACL from another.

  4. To add a user or group to the ACL, click Add User or Group.

    The Add User or Group dialog box appears.



  5. Select the users and/or groups you want to add to the ACL.

    You can filter the list of users that appears in the result set by entering a string in the User Filter text box. For instance, to show only user IDs that begin with "F," enter F* in the User Filter text box, then click the icon next to the User Filter text box. The user IDs matching your filter criteria appear in the list box below. The User Filter applies only to users, not to groups.

  6. Click OK.

  7. To add a new permission to the ACL, click New Permission.

    The New Permission dialog box appears.



  8. Provide a new permission action word.

    A permission defines the level of access a user or group has to a particular application or part of an application.

  9. Click OK.

  10. To set the appropriate permissions for the groups in the ACL, check each permission for that group.


Modifying an Access Control List

You can modify the following ACL properties:

  • add groups

  • create new permissions

  • edit permissions

You can also remove groups from the system.

To modify an access control list, perform the following steps:

  1. On the iASAT toolbar, click Security to open the Security window.

    The following window appears:



  2. Highlight the Access Control List that you want to modify.

  3. Click Modify. The Modify Access Control List dialog box appears.



  4. To add a new user or group, click Add User or Group. The Add User or Group dialog box appears.



  5. Select the group or groups you want to add to the ACL.

    You can filter the list of users that appear in the list by entering a string in the User Filter text box. For instance, to show only user IDs that begin with "F," enter F* in the User Filter text box, then click the icon next to the User Filter text box. The user IDs matching your filter criteria appear in the list box below. The User Filter applies only to users, not to groups.

  6. Click OK.

  7. In the Modify Access Control List window, click New Permission to create a new permission.

    The New Permission dialog box appears.



  8. Provide a new permission such as Read, Write, in the Permission text field and click OK.

  9. In the Modify Access Control List window, you can edit the permissions for a group, by selecting or deselecting the checkboxes next to the permissions.

  10. To remove a group, select that group and click Remove in the Modify Access Control List window.



Enabling Encryption Between Web Server And Application Server

You can selectively encrypt the traffic between Web Server(s) and Application Server(s). The Executive Server (KXS) manages the traffic between the servers. You may need to enable encryption for components that require high security, such as servlets that gather credit card information, login servlets, etc. Components are encrypted using 128 bit keys and RSA BSafe 3.0 library, which ensures safe transfer of information.

This section also describes how you can verify the encryption details in KXS logs and how to create a cryptext key for encryption.

The following topics are included in this section:


To Enable Encryption Between Web Server And Application Server

To enable encryption of traffic between Web Server(s) and Application Server(s), perform the following steps:

  1. Open iPlanet Registry Editor.

    (See About iPlanet Registry Editor)

  2. Open the following key:

    SOFWARE/iPlanet/Application Server/6.0/CCSO/Security/

  3. You will see a value that looks like this; EnableEncryption=0. By default, encryption is disabled. To enable encryption, modify this value to read EnableEncryption=D (D stands for Domestic 128 bit data type string). Encryption is now enabled.


To Verify The Encryption Log Messages

To verify the encryption log messages in the KXS log file, perform the following steps:

  1. Open iPlanet Registry Editor.

    (See "About iPlanet Registry Editor")

  2. Open the following key:

    SOFWARE/iPlanet/Application Server/6.0/CCSO/Security/

  3. From the Edit menu, choose Add Value. The Add Value dialog box appears, as shown in the following figure:



  4. In the Name field, type LogEncryption.

  5. In the Value field, type 1.

  6. From the Type drop-down list, select Integer.

When you create this key, encryption log messages will be logged in the KXS logs.


To Enable Encryption For Each J2EE Component

To enable encryption for individual J2EE components such as JSPs and Servlets (encryption cannot be enabled for EJBs) perform the following steps:

  1. Open the ias-web.xml file of the application for whose component you want to enable encryption.

  2. Search for and locate the servlet or JSP for which you want to enable encryption.

  3. Locate the <encrypt>false</encrypt> tag for the component. Change false to true.

  4. Register the application using iasdeploy.

To verify that the encryption is enabled and working, open KXS logs and search for messages that are similar to the following:

[11/Jan/2001 19:58:43:0] info: CRPT-001: Encrypting 2309 bytes, keysize = 128 bits

[11/Jan/2001 19:58:43:5] info: NSAPICLI-012: plugin reqstart, tickct: 1903570535

[11/Jan/2001 19:58/:43:5] info: NSAPICLI-009: plugin reqexit: Os+.12995s. (198114 0537)

[11/Jan/2001 19:58:52:2] info: CRYPT-004: Decrypting 1897 bytes, keysize = 128 bits

Note that if you enable encryption for a component, encryption will take place even if it has been disabled in iPlanet Registry.



Using Firewalls for Security


iPlanet Application Servers are typically deployed together with web servers and client databases applications. In this scenario, inter-process communication is of a very high level and this makes and data integrity and security issues very important. To ensure smooth and secure communication between application servers, web servers and the client applications that run on application servers, security components of the system are frequently separated by firewalls.

This section describes how you can effectively plan and deploy iPlanet Application Servers in fire-wall protected environments. The following topics are described in this section:


Basics of Network Security

Private networks, such a company's Local Area Network (LAN) are not directly connected to public networks such as the Internet, but pass through a firewall which is intended to control access. Access to public networks is controlled using approved protocols on the approved port numbers of specific machines.


Types of Firewalls

There are many different types of firewalls, each with its own set of advantages and disadvantages. Firewalls do not necessarily consist of simply one type of machine, but typically involve other machines that may be present. These other systems may configured to provide basic traffic routing, but may or may not be configured to provide firewall functionality. The three main types of firewalls are described in the following sections:


Routers
These are fast, and in the simpler versions, relatively cheap. At their most basic, they sit between two networks, and relay connections between them. Configuration parameters can be specified to allow or disallow connections to or from individual IP Addresses or ranges of IP Addresses.

More complex versions of routers will inspect data to determine the security protocol being used, and the port number to which the security protocol is addressed. Control can be exercised on connections using specific protocols and directed to specific ports (filters).

Routers can be machines built specifically for the task, or can be implemented using a computer (typically running UNIX operating system) with multiple network interfaces. The advantage of using a general purpose machine as a dedicated router is that the router can also run proxy servers.


Proxy Servers
Proxy Servers are normally used in conjunction with some form of router to ensure that data access can be only through the proxy server. A proxy server usually sits on a machine that either straddles the firewall, or more frequently, sits behind a primary router on a small, dedicated network often known as a De-Militarized Zone (DMZ), with another router between the proxy server and the private network. The proxy system is generally a very basic, stripped down system which has few or no normal user applications, just programs which act as proxy servers for various protocols.

A proxy server is designed to act as a server to some client inside the private network. For example an HTTP proxy server will behave as an HTTP server as far as a web browser on the private network is concerned. The browser will connect to the HTTP proxy server and send a request for a document. The HTTP proxy server will then in turn act as a browser and will connect to the server from which the document has been requested. The remote HTTP server is not aware of the proxy server. When the HTTP proxy server gets the requested document, it scans the document for viruses before passing it on to the users' browser on the private network. The actions that the HTTP proxy server performs before surrendering the document to the browser can be specified in the HTTP proxy server. This enables additional security and also ensures the quality and wholesomeness of information.


Stateful Inspection Firewall
An increasingly popular form of firewall is a machine, which doesn't simply route information, but also inspects the contents of information packages. Using the information obtained, higher level protocols can be determined. This can extend right up to the level of application protocols. Once the communication protocols have been established the system uses state tables to determine which operations to allow until the protocol enters a new state.

For example, let us assume that an incoming telnet connection will be a TCP/IP (Transmission Control Protocol/Internet Protocol) connection directed to port number 23 on the destination machine. The telnet server will respond with the number of a port, to which the telnet client should connect. The statefull inspection firewall system will recognize the telnet opening state, and examine the returned data for the port number to which the client should connect. When the host (the machine that initiated the connection) directs the connection to the destination port, the statefull inspection firewall system will allow the connection. Other random connections to non-standard ports will normally be denied.

Statefull inspection firewalls are fast because not all data has to be examined. They can be used for general purpose security, unlike proxy servers, which need to be specifically created to handle a given protocol. Creating a proxy for a new protocol can also take a significant amount of time. With a statefull inspection firewall system, a new state table can be created quickly and easily, often by simply monitoring the new protocol to determine appropriate state transitions and actions.

The ensuing sections describe the architecture of iPlanet Application Server and the how communication takes place within iPlanet Application Server.


iPlanet Application Server Architecture

iPlanet Application Server is composed of several modules. The basic component is the Executive Server (KXS) which creates the components of the application, manages per session data, load monitoring and load-balancing with other instances of iPlanet Application Server.

The following diagram illustrates the basic iPlanet Application Server architecture.


Note You will see the name Kiva mentioned several times in the following diagram. This is because the original name of iPlanet Application Server was "Kiva". Therefore, some iPlanet Application Server components are preceded with the name Kiva, for example KJS (Kiva Java Server) KCS (Kiva C++ Server) and KXS (Kiva Executive Server).


.

The application code runs in multi-threaded processes created by KXS. There are two types of processes; the C++ Server (KCS) and the Java Server (KJS).

The system is managed through the Administration Server (KAS). The web server may be installed on the same machine as iPlanet Application Server, but will typically be installed on a separate machine.

The communication between the web server and iPlanet Application Server is through a plug in, residing in the web server which communicates directly with iPlanet Application Server. If multiple instances of iPlanet Application Server have been installed, the plug in communicates with the iPlanet Application Server selected by the load balancing system. In cases where the web server in use does not have a plug in available, the communication module may be called as a CGI (Common Gateway Interface) application, which establishes connection to iPlanet Application Server. The use of the CGI model is less efficient, and normally used only as a last resort.

The second method of communication is using OCL (Object Constraint Language), which uses CORBA to locate the required services and communicate with them through iPlanet Application Server. This is recommended only for the intranet because of the lack of standardized security for IIOP (Internet Inter-Object Protocol) connections.

The next section describes how a firewall is structured and how communication takes place between servers, applications and security protocols.


Inter-Process Communication Protocol

Inter-process communication between servers, applications and security protocol occurs in a number of ways. The communication links and protocols involved are as given below:


Ephemeral Ports

Ephemeral ports are the anonymous ports created in response to a request from a client to a server. In UDP (User Datagram Protocol), these will be the port numbers used for reply datagrams. For TCP/IP, these will be the port numbers for the connection that a server creates in response to a request from a client.

Ephemeral ports can be any ports not currently in use, and not in the reserved range (0-1023). It is common practice to allocate these ports from the range (1024-5000). However, some systems, notably Solaris, now allocate ephemeral port numbers that belong to a different range. Typically any port number greater than 32768 can be allocated as an emphemeral port, going by the recognition that for large systems with many connections the limited range of port numbers may not be sufficient.

It is important to verify the values used and to ensure that the appropriate range or ranges are enabled for ephemeral ports on any firewalls where ephemeral port usage exists. Typically this will be > 32768 for modern Solaris systems and 1023 to 5000 for Windows systems.


Transmission Control Protocol/Internet Protocol (TCP/IP)

There are multiple TCP/IP connections carrying different types of traffic as listed in the following table. The addresses and ports indicated in the table are default values:

Connection

Traffic

Port/Addr

Purpose

Web Connector Plug-in to KXS

Request data

10818

User I/O

KXS to KCS/KJS

Internal data

10819 (*)

Send requests

CGI to KXS

Request data

See Text

User I/O

KCS/KJS to KXS

Internal data

10818

Results/Admin

Admin UI to KAS

Internal data

10817

Admin.


Note (*) Begins at this number and increases by for each KCS/KJS.


Most of these communication channels are used for more than one type of data transfer. Data transfers are multiplexed over the same TCP/IP connection.

When a web server other than the web servers that support a plug in is used, communication with KXS will be through small CGI applications.

The port used for communication between CGI to KXS is not fixed, but is allocated as:

10819 + (number of KCS/JKS engines)

Therefore, if 4 KJS engines and one KCS engine are installed, the CGI port will be configured at port number 10824, that is default CGI port number 10819+3, during installation of iPlanet Application Server.

TCP/IP communication for web servers is allocated on port 80 or 443 depending on the use of HTTP or HTTPS (Secure HTTP).


IP Multicast

In the case of multiple iPlanet Application Server instances, iPlanet Application Server uses 2 IP multicast channels, which handle the following communication tasks:

  • IP multicast channel 1 communicates load balancing information between KXS processes.

  • IP multicast channel 2 communicates administration information and commands between KAS processes.

It should be noted that traffic on the KXS channel can be heavy, and increases with system load. Default addresses for KXS channels are given in the following table:



MCast

Address

Port

KXS <-> KXS  

228.8.18.71  

9607  

KAS <-> KAS  

228.8.18.71  

9608  


Note The multiplexing of internal server data over a single TCP/IP channel is sometimes referred to as the Kiva Communications Protocol (KCP). This protocol is meant only for internal data transfer.



User Datagram Protocol (UDP)

The Web Connector Plug-in uses UDP. It uses the Ping protocol to verify that the KXS process with which the Web Connector Plug-in is currently associated is still alive. A thread running within the KXS responds to the ping. Response to a ping indicates that the KXS is running. Lack of response indicates that failover should be initiated. to switch to an alternate KXS. Default UDP ports are given in the following table:

UDP Packet

Port

Ping request

9610

Ping response

Ephemeral

Where UDP is not permissible, the ping may be deactivated by modifying the Web Connector Plug-in's iPlanet Registry. To disable response to a ping request, perform the following tasks:

  1. Start iPlanet Registry

    (See "About iPlanet Registry Editor")

  2. Open the following key:

    SOFTWARE/iPlanet/Application Server/6.0/CCS0/CONN/

  3. Modify the DisableEcho key. Set the value to 1.
    Tip To modify a value in iPlanet Registry, perform the following steps:

      1. Double-click the key name or select the key and choose Modify Value from the Edit menu, to bring up the Modify Value dialog box.

      2. Enter the new value in the dialog box.

      3. Click OK to register the change in iPlanet Registry.


When you turn UDP pinging off, the currently selected iPlanet Application Server may fail and this could cause a delay, until the TCP/IP connection times out. This may take up to several minutes, depending upon TCP/IP configuration parameters.

Note that if the network disables UDP, the ping must be disabled in the Web Connector Plug-in registry for the Web Connector Plug-in to work. UDP ping is used only by the web server plug in and not by the CGI interface.

The following table provides a summary of the protocols, addresses and purpose of iPlanet Application Server components:

What

Protocol

Port/Addr

Purpose

Web Connector Plug-in

TCP/IP

10818

Web Connector Plug-in to KXS

Web Connector Plug-in/CGI

TCP/IP

> 1024

Return connection

Web Connector Plug-in

UDP/IP

9610

Keepalive ping

Web Connector Plug-in

UDP/IP

Ephemeral

Ping return

KXS to KCS/KJS

TCP/IP

10819

KXS to KCS/KJS

CGI to KXS

TCP/IP

Last KCS/KJS + 1

CGI apps. to KXS

KCS/KJS to KXS

TCP/IP

10818

KCS/KJS to KXS

KXS

IP Multicast

228.8.28.71:9607

KXS to KXS

KAS

IP Multicast

228.8.18.71:9608

KAS to KAS

Admin UI to KAS

TCP/IP

10817

Admin.


Encrypting Data Channels

You can encrypt communication that occurs between the Web Connector Plug-in and KXS. When you do this, the same ports and addresses continue to be used, but data transfers are encrypted. This is recommended on an absolute need-basis, because of the overhead associated with data encryption using secure cyphers. See "Enabling Encryption Between Web Server And Application Server.



Configuring Firewalls With iPlanet Application Server


This section examines some common firewall configurations and the parameters to be configured for correct functioning. These examples illustrate where firewalls can reasonably be placed within a iPlanet Application Server implementation.

Although it is possible to place a firewall between iPlanet Application Server instances (an iPlanet Application Server instance being a KXS/KJS/KCS process group) this is not recommended. If such a firewall is implemented it is essential that it implements IGMP (Internet Group Management Protocol) to allow IP across the firewall.

Although firewalls are not recommended between iPlanet Application Server instances, the implementation of a fast, dedicated network for IP Multicast traffic between iPlanet Application Server machines may be advisable in some circumstances.

The iPlanet Application Server system is designed for networks running at LAN speeds, so distributing iPlanet Application Server instances across a WAN (Wide Area Network) may lead to performance problems.


Single Firewall

The simplest and most common firewall configuration is with a firewall between the web server and the Internet as shown in the following illustration:



Figure 5-1    Single Firewall Between the Web Server and the Internet - Example 1

In this case, firewall configuration is straightforward. The firewall needs to be configured to allow HTTP connections to port 80 and/or HTTPS 443 as appropriate. Return data is on a port above 1024, so these ports need to be opened for outgoing (reply) connections.

The advantage of this configuration is simplicity. The biggest disadvantage is that there is a single line of defense. Once the firewall is breached the only defense is the security of each of the individual machines within the private network.

The table below summarizes the protocols and ports which need to be configured to the firewall to permit correct functioning.

Protocol

Direction

Port

Reason

TCP/IP

Incoming

80

HTTP requests

TCP/IP

Incoming

443

HTTPS requests

TCP/IP

Reply (out)

>1024

HTTP(S) response

Sometimes, it may be required to run the web server outside the firewall, as shown in the following illustration:



Figure 5-2    Single Firewall Between the Web Server and the Internet -Example 2

This configuration exposes the web server machine to the Internet, which is not recommended. As in the previous example, there is a single line of defense. The external web server will typically have some level of trust within the protected network, and so would be a prime target for harmful intent.

This firewall configuration needs to allow the Web Connector Plug-in TCP/IP data connection and UDP ping connection, as described in the following table:

Protocol

Direction

Port

Reason

TCP/IP

Incoming

10818

Web to KXS

TCP/IP

Incoming

See note below

CGI to KXS

TCP/IP

Reply (out)

> 1024

KXS to Web

UDP

Incoming

9610

Web to KXS

UDP

Reply (out)

Ephemeral

KXS to web


Note If a Web Connector Plug-in is not available for the web server in use, CGI applications will be used to communicate with the KXS. The CGI port allocated by default at installation time is: 10819 + (number of KCS/KJS instances)



Double Firewall - the DMZ Configuration

This configuration is becoming more popular as many enterprises open up limited access to their private networks to partners and customers via DMZs:



Figure 5-3    Double Firewall - the DMZ Configuration

The security provided by this configuration is much better than the single firewall examples above. The double layer of protection combined with active monitoring of activity at each firewall and within the DMZ will detect most attempts to penetrate the internal network.

In this case the outer firewall will need to be configured as in the above example to allow HTTP and HTTPS transactions. The inner firewall will need to be configured to allow the web server plug in to communicate with the iPlanet Application Server server(s) behind the firewall.

The default port used by the web plug in to communicate with the KXS instances is 10818. Similarly, the UDP port used for the failover keepalive pings is 9610 by default, changing this requires appropriate modification the firewall configuration. The following table lists the default port numbers for both KXS ports and the UDP ports:

Protocol

Direction

Port

Reason

TCP/IP

Incoming

10818

Web to KXS

TCP/IP

Reply (out)

> 1024

KXS to Web

UDP

Incoming

9610

Failover ping

UDP

Outgoing

Ephemeral

Failover ping reply


Triple Firewall - DMZ With Database Protection

In some corporate settings, databases reside on their own networks, protected by firewalls as shown in this diagram.



This configuration provides maximum security for what may be the most important corporate asset; the data contained within the corporate database. The firewall between the LAN and the database systems provides protection against internal as well as external threats.

The connections to the databases use standard access mechanisms such as ODBC (Open DataBase Connectivity), JDBC (Java DataBase Connectivity) and database vendor supplied connector libraries. The connections to the database are not different from any other application, and so the firewall configuration for the database protection layer will conform to the standard settings required for access to the specific database in use.


Note FTP Access to web server

When an application is deployed, it will typically have a few HTML pages that must be installed in the web server document hierarchy. The installation of these pages is done manually, usually transmitting the pages through FTP (File Transfer Protocol) to the web server(s). When configuring any firewall between iPlanet Application Server and its web server(s) care must be taken to allow FTP (or some other means of copying files) from iPlanet Application Server to the web server. This needs to be permitted only during deployment of an application and can be disabled at other times.

Remote Administration

In order to run iPlanet Application Server Administration Tool remotely, the network connection needs to allow TCP/IP on port 10817 for the connection between iASAT and KAS.



Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated June 25, 2001