2.1 Topology

Each major subsystem can have many instances and many ways of connecting. Not every possible layout is supported. This section includes three subsections that describe the possibilities and why some configurations are preferred over others.

2.1.1 Minimal Design

The simplest logical configuration of the User Application is a one-of-everything installation, consisting of one Identity Vault tree, one instance of the Identity Manager engine and drivers, and one instance of an application server running a single instance of the User Application. In terms of physical implementation, you could, in theory, run all of this on one machine. But you would not do that in the real world, for a variety of reasons including security, maintainability, and performance. In deciding on the number of machines needed for a practical real-world installation, you would want (at a minimum) to take the following into account:

Novell Audit Server: This application is responsible for capturing event information (and possibly a good deal of other information) from the User Application environment at runtime. It might also be doing double duty as a persistence store for other applications in your company. For a variety of reasons, you probably do not want to put other major pieces of the Identity Manager system (for example, the application server or the Identity Vault) on the same machine as the Audit server.

Identity Vault: This is a heavily trafficked component with a need for good performance and good scalability. Consider putting the Identity Vault on a dedicated machine. You probably do not want another high-traffic system, such as an application server with a deployment of the User Application, running on the same machine as the Identity Vault.

Database: If this instance of a supported database is also your Novell® Audit database, it is probably on a dedicated machine. The User Application uses this component in the following ways:

  • As a persistence store for portal configuration data

  • As the persistence store for state information on in-process workflows

  • Optionally, as the logging store for Novell Audit.

Application Server: For performance and capacity reasons, you should probably run this piece on a dedicated machine.

These considerations suggest at minimum a three-machine configuration.

2.1.2 High Availability Design

Clustering for high availability and capacity is discussed in Section 2.7, Clustering. For now, you should know that:

  • Identity Manager supports high availability of the Identity Vault, engine, and drivers through the multinode installation and shared-storage mechanisms described in the section “High Availability” in the Identity Manager Administration Guide. A comprehensive procedure for setting up such a system using SUSE® Linux is at:


  • High availability of the User Application is available through JBoss clustering. You can set up a JBoss cluster so that each node runs one User Application instance. The instances are all coequals (peers).

  • Automatic failover is supported. An interrupted workflow can resume after the loss of a cluster node.

See Section 2.7, Clustering for more information.

2.1.3 Design Constraints

The two most important architectural constraints are:

  • No User Application instance can service (search, query, add users to, and so forth) more than one user container. Also, a user container association with an application is meant to be permanent.

  • No User Application driver can be associated with more than one User Application, except when the User Applications are installed on sister nodes of the same JBoss cluster. In other words, a one-to-many mapping of drivers to User Applications is not supported.

The first constraint enforces a high degree of encapsulation in User Application design.

Suppose you have the following organizational structure:

Figure 2-1 Sample Organizational Structure


During installation of the User Application, you are asked to specify the top-level user container that your installation looks for in the Identity Vault. In this case, you could specify ou=Marketing,o=ACME or (alternatively) ou=Finance,o=ACME. You cannot specify both. All User Application searches and queries (and administrator log-ins) are scoped to whichever container you specify.

NOTE:In theory, you could specify a scope of o=ACME in order to encompass Marketing and FInance. But in a large organization, with potentially many ou containers (rather than just two relating to Marketing and Finance), this is not likely to be practical.

It is possible, of course, to create two independent installations of the User Application (sharing no resources in common), one for Marketing and another for Finance. Each installation would have its own database, its own appropriately configured User Application driver, and each User Application would be administered separately, possibly having unique themes.

If you truly need to place Marketing and Finance within the same scope for one User Application installation, there are two possible tactics to consider. One is to insert a new container object (for example, ou=MarketingAndFinance) in the hierarchy, above the two sibling nodes; then point to the new container as the scope root. Another tactic is to create a filtered replica (a special type of eDirectory tree) that combines the needed parts of the original ACME tree, and point the User Application at the replica’s root container. (Consult the Novell eDirectory Administration Guide for more information on filtered replicas.)

If you have questions about a particular system layout, contact your Novell representative for assistance or advice.