Chapter 3 System-Level Features

This chapter provides conceptual and technical background for understanding the following two system-level features provided by Java Enterprise System:

These two features are key to integrating Java Enterprise System components into a single software system.

The Java Enterprise System Integrated Installer

All Java Enterprise System components are installed using a single installer. This installer provides consistent installation and uninstallation procedures and behavior across all components.

The Java Enterprise System installer is an integrated framework that transfers Java Enterprise System software to a host system. It lets you select the Java Enterprise System components you need for any given computing node in your environment and installs those components on that computer. To set up your distributed environment, you use the Java Enterprise System installer to install the appropriate components on each node, one node at a time, in your environment.

The installer runs interactively in both a graphical and text-based mode, and also provides a parameter-driven silent installation mode. It supports, in addition to English, seven languages: French, German, Spanish, Korean, Simplified Chinese, Traditional Chinese, and Japanese.

This section discusses the following aspects of the integrated Java Enterprise System installer (for more detailed information see the Java Enterprise System Installation Guide):

Pre-Existing Software Checking

The installer performs checks at several levels to make sure that all previously installed components are at the appropriate release level to interoperate successfully.

The installer examines the computer on which you are installing and identifies the Java Enterprise System component products that are already installed. It informs you about those that are incompatible and must be upgraded or removed.

Similarly, the installer checks for Java Enterprise System shared components (see Shared Components), such as J2SE or NSS, that are already installed. If the installer finds shared components whose versions are incompatible, it lists them. If you proceed with installation, the installer automatically upgrades the shared components to newer versions.

Dependency Checking

The installer does extensive cross checking of components to verify that the installation components you select will function properly.

Many components have dependencies on other components. The installer provides logic to ensure that those dependencies are met. For this reason, when you select a component to install, the installer automatically includes the components and subcomponents upon which the selected component has dependencies.

You cannot deselect a component if another selected component depends upon that component locally. However, if the dependency is not local, you will receive a warning but be able to proceed (under the assumption that the dependency will be satisfied by a component on a different host computer).

Initial Configuration

Many Java Enterprise System component require some degree of initial configuration before they can be started up. Depending on the component product, the Java Enterprise System installer can perform this initial configuration.

You can choose to have the installer perform this initial configuration (Configure Now) or to skip the initial configuration (Configure Later), in which case you will have to perform initial configuration manually after installation is complete.

If you choose Configure Now, configuration information will be required during installation. In particular, you can specify a set of parameter values that are common across all component products, such as an administrator ID and password.

Uninstallation

Java Enterprise System also provides an uninstallation program. You can use this program to remove component products that were installed on the local computer by the Java Enterprise System installer. The uninstaller checks dependencies, and issues warnings when it discovers a dependency. The uninstaller, like the installer, can be run in graphical, text-based, or silent mode.

Integrated Identity and Security Services

An important feature of the Java Enterprise System is its integrated management of user identities and its integrated authentication and authorization framework.

The following sections provide technical background for understanding the integrated identity and security services provided by Java Enterprise System:

Single User Identity

Within a Java Enterprise System environment, an end user has a single identity. Based on that identity, a user can be allowed access to various resources, such as a portal, web pages, and services such as messaging, calendar, and instant messaging.

This integrated identity and security capability is based on close collaboration between Directory Server, Identity Server, and other Java Enterprise System components.

User access to a Java Enterprise System service or resource is achieved by storing user-specific information in a single user entry in a user repository or directory. That information normally includes information such as a unique name and password, as well as an e-mail address, a role in an organization, web page preferences, and so forth. The information in the user entry can be used to authenticate the user, authorize access to specific resources, or provide various services to that user.

In the case of Java Enterprise System, user entries are stored in a directory provided by Directory Server. When a user wants to request a service provided by a Java Enterprise System component, that service uses Identity Server to authenticate the user and authorize access to specific resources. The requested service can then look up information in the user’s directory entry needed to perform the work requested by the user, as shown in the following figure.

One of the features derived from this system is the ability of a web-based user to sign-on to any Java Enterprise System service, and thereby be automatically authenticated to other system services. This capability, known as single sign-on, is a powerful feature provided by Java Enterprise System.

Directory Basics

A directory is a special kind of database optimized for reading data rather than writing data. Most directories are based on LDAP (Lightweight Directory Access Protocol), an industry-standard protocol. User accounts are entries in a directory.

LDAP directories store data in a hierarchical directory structure. The data is stored in entries that consist of a set of attributes and their respective values. A user entry, for example might have attributes such as sn (surname), telephoneNumber, and userPassword. Directory entries can describe people, organizations, hardware devices, software configurations, or other kinds of objects.

The set of attributes that describe an object, or some aspect of an object, is called an LDAP object class. For example, the attributes mentioned above that might be found in a user entry are defined by a person object class. The set of object classes and corresponding attributes that can be stored in a directory are collectively referred to as the directory schema.

In general, the designer of a business service decides what types of directory entries are needed by that service and what attributes values are needed for that entry. The designer also decides what kind of hierarchy characterizes the directory. The service must be aware of this hierarchical structure to look up entries in the directory.

In the case of a directory that stores end-user attributes, the directory schema might include object classes and attributes for enterprise, organization, and organizational unit. There might also be object classes to define groups within the organization to which individual users might belong.

A directory schema therefore includes all the object classes and attributes needed to represent and characterize directory data. The schema also specifies the data type and format of attribute values.

Fortunately, business service designers rarely need to create a directory schema from scratch because standard LDAP schemas already exist for many business needs. However, an application or service might need user attributes not covered by such standards, and in this case, a designer defines service-specific object classes that extend the standard schema. Nearly all the Java Enterprise System services, for example, extend the standard schema.

Directory Server Schema

Java Enterprise System directory services are provided by Directory Server, which implements an LDAP directory. By default, Directory Server provides a schema based on LDAP standards (LDAPv3), with additional Directory Server-specific extensions. The LDAPv3 schema defines a set of core object classes and attributes that reflect a human-oriented perspective: person, organization, group, and other such objects.

The default Directory Server schema also includes object classes and attributes for defining the schema itself and for Directory Server configuration.

All Java Enterprise System services can use the object classes and hierarchical structure rules specified by the default schema. However, for various services to store user-specific information in the same entry for a given user, the default schema must be extended to include all attributes needed by those services.

Directory Information Tree

To use the identity, security, and other services provided by Java Enterprise System, you need to plan how to structure user information in your directory. You do this by designing a directory information tree (DIT). A DIT is a hierarchical structure that reflects the organization of your enterprise. The DIT affects how services find information in a directory and also has an impact on how you deploy and administer the directory.

The directory tree organizes user data, for example, by group, by people, by geographical location, and so forth. An example directory information tree is shown in the following figure.

The root of the (inverted) directory tree, known as the root suffix, is shown at the top of Figure 3-2. A suffix is a branch or subtree whose entire contents are treated as a unit for the purpose of directory administration tasks. For example, an entire suffix can be initialized in a single operation. Indexing and directory replication (for load balancing or failover) is performed at the level of a suffix.

In most cases, the root suffix represents your main organizational or network domain, in this case example.com. Below the domain level in Figure 3-2 are two organization branches, each of which has an organizational unit (people), which contains user entries. Each branch point represents a directory entry and each is named according to one or more of its attributes. For example, o=org1, means that the o (organization) attribute has the value org1 for that entry. The attribute names dc (domain component), ou (organizational unit), uid (user ID), and cn (common name) are standard attribute names defined in the directory schema.

An entry can have more than one value for a given attribute: cn=Mattew Doe and cn=Matt Doe, or dc=example and dc=com, for example. In addition to the branch points shown in Figure 3-2, it is common to have a branch ou=groupx that lists members in a group x, which might be the basis for access to particular resources. For example, you might group users by management level.

To specify any entry, you provide the full path to the entry through the directory tree. For example, the full path for user3 is uid=user3, ou=people, o=org2, dc=example, dc=com. This full path is called the entry’s distinguished name (DN).

When designing a directory tree, you want to use a structure that closely represents the structure of your organization. This enables you to administer or replicate branches that are meaningful in your enterprise. You also want to choose names that are not likely to change over time.

Authentication and Authorization

Java Enterprise System authentication and authorization services are provided by Identity Server. Identity Server uses information in Directory Server to broker the interaction of users with Java Enterprise System web services or other web-based services in an enterprise.

Identity Server functions require extensions to the default schema provided by Directory Server. These extensions provide object classes needed to define policies, roles, and other aspects of Identity Server’s authentication and authorization services.

Identity Server also makes use of an external component known as a policy agent. The policy agent plugs into the web server hosting a service or resource being secured by Identity Server. The policy agent intercedes on behalf of the Identity Server in requests made by users to the secured resources. For some Java Enterprise System components, for example, Messaging Server and Calendar Server, the functionality of the policy agent is built into the component.

Authentication

Identity Server includes an Authentication Service for verifying the identities of users who request access (by way of HTTP or HTTPS) to web services within an enterprise. For example, a company employee who needs to look up a colleague’s phone number uses a browser to go to the company’s online phone book. To log in to the phone book service, the user has to provide a user ID and password.

The authentication sequence is shown in Figure 3-3. A policy agent intercedes in the phone book log-on request, sending the request to the Authentication Service. The Authentication Service checks the user ID and password against information stored in Directory Server. If the log-in request is valid the user is authenticated and the company phone book is displayed to the employee. If the log-in request is not valid, an error is generated and authentication fails. (The Authentication Service also supports credentials-based authentication over HTTPS)

Single Sign-On

The authentication scenario discussed above omits an important step. When a user’s authentication request is verified, the Identity Server’s Session Service is brought into play. The Session Service generates a session token, which holds the user’s identity information and a token ID. The session token is sent back to the policy agent which forwards it (as a cookie) to the browser from which the authentication request was made.

When the authenticated user attempts to access another secured service, the browser passes the session token to the corresponding policy agent. The policy agent verifies with the Session Service that the user’s previous authentication is still valid, and the user is granted access the second service without being asked to re-enter a user ID and password. In the case of Java Enterprise System components that have policy agent functionality built-in, the single sign-on process is essentially the same.

Thus, a user only needs to sign on once to be authenticated to multiple web-based services provided by Java Enterprise System. The single sign-on remains in effect until the user explicitly signs off or the session expires.

Authorization

Identity Server also includes a Policy Service that provides access control to web-based resources in a Java Enterprise System. The authorization sequence is shown in the following figure.

When an authenticated user makes a request for any Identity Server-secured resource, the policy agent notifies the Policy Service, which uses information in Directory Server to evaluate the access policy covering the resource to see if the user has permission to access the resource. A policy is a rule that describes who is authorized to access a specific resource under specific conditions.

Identity Server provides the means for defining, modifying, granting, revoking, and deleting policies within an enterprise. The policies are stored in Directory Server and configured through policy-related attributes in organization entries. Roles can also be defined for users and incorporated in policy definitions.

Identity Server policy agents are the policy enforcers. When the Policy Service rejects an access request, the policy agent prevents the requesting user access to the secured resources.

Setup Issues

Setting up a Java Enterprise System environment to store user data needed to authenticate users, authorize access to specific resources, and provide various services to users involves two important procedures: extending directory schema and provisioning users.

Extending Directory Schema

To support Java Enterprise System services and custom services in your environment, object classes and attributes are required that are not present in Directory Server’s default schema.

For example, Identity Server requires specialized object classes and attributes for performing policy services, and Messaging Server and Calendar Server both require schema extensions beyond those required for Identity Server.

The Java Enterprise System installer generally accommodates these extensions. For example, when you install Identity Server, the installer can run initial configuration scripts that import the required schema into the default Directory Server schema. When you install Portal Server and Instant Messaging, the installer automatically extends the Identity Server schema. When you install Messaging Server or Calendar Server, however, you have to manually run a script (comm_dssetup) to import the required additional schema into the Identity Server schema.



Note	The versions of Messaging Server and Calendar Server that predate Java Enterprise System use a different schema and directory tree structure (called Sun ONE LDAP Schema 1) than the schema supported by Java Enterprise System (Schema 2). Therefore, if you want to preserve the data in your earlier directory, but want to use the authentication, authorization, and portal services provided by Java Enterprise System, you have to migrate the directory data to Schema 2. Java Enterprise System provides a utility for performing this migration. For more information, see the Sun Java Systems Communications Services Schema Migration Guide.

If you have custom-developed services that need to be supported by the Java Enterprise System infrastructure, and these services require additional schema extensions, you can extend the directory schema accordingly using Directory Server tools. For example, you can use the Directory Server Console, a graphical user interface, to add new schema, or you can define the new schema elements in an LDAP Interchange Format (LDIF) file, which can be imported into the directory schema using the Directory Server ldapmodify command.

User Provisioning

The procedure for enabling end users to access and use system services is called user provisioning. It involves creating an entry for each user in the directory. The user entry must contain all the user-specific attribute values required by the services that the user will want to access.

Historically, each component of Java Enterprise System was an independent product that used a directory more or less independently of other products. Therefore each product had its own provisioning tool for creating user entries in its own directory and for populating that entry with data needed by that product.

However, Java Enterprise System supports a single user entry in a single directory (a single user identity) for all Java Enterprise System services (as well as custom-developed services in the environment). This capability requires a provisioning tool that can be extended to support all object classes and attributes needed by the system.

Identity Server’s provisioning tools, the graphical Identity Server Administration Console and the command line amadmin utility, are designed to support this requirement. The Identity Server includes a capability by which additional object classes and their attributes can be registered as a new “service.” Identity Server uses the registration information when creating or modifying a directory entry.

This registration capability has been used to extend Identity Server’s provisioning tools to support user provisioning for Portal Server and Instant Messaging services. However, Identity Server provisioning tools have not been extended to support user provisioning for Messaging Server and Calendar Server.

Instead, Java Enterprise System provides a separate, command line User Management Utility. This provisioning tool registers all attributes required for Messaging Server and Calendar Server, and thereby lets you provision users for all Java Enterprise System components, including Messaging Server and Calendar Server.

When adding new users on an occasional basis graphical provisioning tools are appropriate. However, in situations where large numbers of new users must be provisioned, such tools are cumbersome. To batch provision large numbers of users, you can provide the User Management Utility with an input file that contains all the required user entry data.


Note	Because of special semantic relationships required between Identity Server attributes, if Identity Server is included in a Java Enterprise System deployment, you should not provision users by creating batch LDIF files and importing them directly into Directory Server using the ldapmodify command. Use the User Management Utility instead.

Table 3-1 Java Enterprise System User Provisioning Tools
Tool	Description	Used For:
Identity Server Console	Graphical administration interface provided with Identity Server	Provisioning for Portal Server, Instant Messaging, and Identity Server, but not for Messaging Server or Calendar Server. Refer to: Sun Java System Identity Server Administration Guide (http://docs.sun.com/doc/817-5709) Also supports provisioning for custom services. Refer to: Sun Java System Identity Server Administration Guide (http://docs/sun.com/doc/817-5709) and Identity Server Developer’s Guide (http://docs.sun.com/doc/817-5710), Chapter 6 “Service Management,” Service Definition
Identity Server amadmin utility	Command line administration interface provided with Identity Server
User Management Utility (commadmin)	Command line provisioning tool installed with Identity Server	Provisioning specifically for or Messaging Server and Calendar Server. Also supports provisioning for all other Java Enterprise System components, but you have to know the attributes and data types. Refer to: Sun Java System Communications Services User Management Utility Administration Guide (http://docs.sun.com/doc/817-5703)
Directory Server Console	Graphical administration interface provided with Directory Server	Generic Directory Server provisioning tool. Don’t use for provisioning users for Java Enterprise System components. Refer to: Sun Java System Directory Server Technical Overview, Chapter 3 “A Quick Look at Directory Server Console,” Managing Entries (http://docs.sun.com/doc/817-5217)
Directory Server ldapmodify command	Command line directory management tool provided with Directory Server	Generic Directory Server directory management tool. Don’t use for provisioning users for Java Enterprise System components. Refer to: Sun Java System Directory Server Technical Overview, Chapter 4 “A Quick Look at Directory Server Command-Line Utilities,” Adding, Changing, and Deleting Entries (http://docs.sun.com/doc/817-5217)
Delegated Administrator	Graphical provisioning tool provided with Messaging Server	Schema 1 provisioning for Messaging Server. Not compatible with Schema 2. Don’t use for provisioning users for Java Enterprise System components. Refer to: iPlanet Delegated Administrator for Messaging and Collaboration 1.2 Installation and Administration Guide (http://docs.sun.com/doc/816-6011-10)

Previous Contents Index Next
Sun Java Enterprise System 2004Q2 Technical Overview