Deployment Scenarios

This chapter details simple deployment scenarios for Identity Server. It contains the following sections:

Multiple Servers Scenario

The recommended deployment scenario contains two physical servers with both Identity Server and Directory Server installed on each. The instances of Directory Server will be set up in a multiple master configuration. The proper procedure for this deployment would begin with the installation of the first instance of Directory Server on the first machine. The second instance of Directory Server would then be installed on the second machine and the multiple master relationship configured. Identity Server can then be installed on the first machine pointing to either instance of Directory Server. The installation method would be to choose an existing directory with or without an existing DIT, depending on the current setup. The second instance of Identity Server would then be installed on the second machine pointing to an existing Directory Server with an existing DIT. Identity Server does not write any information to Directory Server that it recognizes as already existing therefore, there is no danger of overwriting existing data. It will add two attributes which allow the second instance to function.

More than one instance of Identity Server can be installed against Directory Server for enhanced performance, for directory replication support, or for agent failover purposes. In order to have these multiple instances of Identity Server on different hardware against the same Directory Server, the instructions detailed in "To Install Multiple Identity Servers With ammultiserverinstall" can be followed. A second method would be to install the second Identity Server, and point it against the already configured Directory Server. Figure 5-1 illustrates two Identity Server instances installed against a single Directory Server.

To Install Multiple Identity Servers With ammultiserverinstall

To install multiple installations of Identity Server against one master Directory Server, the ammultiserverinstall script must be run. The administrator must have root permissions to create and install multiple Identity Server instances.

Go to the following directory:

At the command line, type the following command:

A new amserver script file at /IdentityServer_base/SUNWam/bin/amserver.instance_name

A new AMConfig.properties file at /IdentityServer_base/SUNWam/lib/AMConfig-instance_name.properties

A new web server instance directory at /IdentityServer_base/SUNWam/servers/https-instance_name

Web Deployment

The most common use of an Identity Server deployment is when a web browser accesses an application or resource deployed on a web server. The application/resource is protected by Identity Server and communicates with it using a policy agent installed on the web server. Additionally, the web server might have the Identity Server SDK deployed. This architecture does not impose restrictions with regards to the number of web servers within a machine, or the instances of Identity Server across multiple machines. For example, a machine might have multiple web servers, each deploying Identity Server. Similarly, there might be multiple web servers running on different machines, each deploying Identity Server. Figure 5-2 illustrates this simple deployment scenario.

Java Application Deployment

Another common scenario for Identity Server is one in which Java™ applications access an Identity Server SDK installed directly on the machine where they are deployed. In this scenario, there must be an additional machine with an instance of Sun ONE Web Server or Sun ONE Application Server running, at least, one instance of Identity Server; this machine maintains the state information to provide single sign-on. Figure 5-3 illustrates this Java application deployment scenario.

Multiple JVM Environment

Identity Server services are supported in multiple Java Virtual Machine (JVM) environments. In other words, an instance of Sun ONE Application Server can be configured to have multiple JVMs with Identity Server services running in all of them. The Identity Server architecture imposes no restrictions on the deployment with regards to the number of Application Server instances within a machine, the number of Identity Server services across multiple machines, or the number of JVMs that a single Application Server can have. See the Sun ONE Application Server documentation for more information on the multiple JVM environment.

Replication Considerations

Load balancing across replicated Directory Servers and locating replicated servers closer to users are two ways to improve Identity Server performance and response time. Directory Servers can be set up in single-supplier or multi-supplier configurations. Load-balancing applications such as Sun ONE Directory Proxy Server can also be used. Directory Proxy Server dynamically performs proportional load balancing of LDAP operations across a set of configured Directory Servers. If one or more Directory Server(s) become unavailable, the load is proportionally redistributed among the remaining servers. When the server comes back on line, the load is proportionally and dynamically reallocated.



Note	Directory replication agreements must be configured before installing Identity Server. This ensures that the supplier and consumer databases are synchronized correctly, allowing time to verify that referrals and updates are synchronized properly.

When Identity Server is installed for replication purposes, each instance of Directory Server and each instance of Identity Server, must be configured with the same values for the following:

Directory Manager

Directory Manager Password

Directory Server Administrator ID

Server Administrator Password

Base suffix

Default organization

Configuring For Replication

Identity Server can be configured to work with single-supplier or multi-supplier replication. Figure 5-4 illustrates a single-supplier configuration where the consumer is a read-only database. Requests for write operations are referred to the supplier database. This configuration provides some measure of enhanced server performance by distributing the workload to more than one directory.

Figure 5-5 illustrates a multi-supplier configuration using multiple instances of Identity Server. This configuration provides failover protection as well as high availability, resulting in further enhanced server performance.

Figure 5-5 Multi Supplier Configuration (also known as Multi-Master Replication)

The following steps can be used to configure replication at the root or top level of the Identity Server directory tree when Identity Server has not yet been installed. They can also be used to configure replication at the default organization level.

Install supplier and consumer Directory Servers.

See the Sun ONE Directory Server Installation Guide for detailed instructions.

Set up replication agreements between the supplier and consumer, and verify that the directory referrals and updates are working properly.

See the Sun ONE Directory Server Administrator’s Guide for detailed instructions.



Note	It might be necessary to migrate existing Directory Server data to work with this version of Identity Server. For instructions on how to do this see the Sun ONE Identity Server Migration Guide.

If deploying Identity Server and Directory Server for the first time, or there is no plan to use existing user data, run the Sun Java Enterprise System 2003Q4 installation program to install Identity Server.

In the server where Identity Server Management and Policy services are installed, modify the following file:

/IdentityServer_base/SUNWam/lib/AMConfig.properties

Modify the following properties to reflect the host and port number of a consumer Directory Server installed in Step 1.

com.iplanet.am.directory.host

com.iplanet.am.directory.port

Modify the following properties to reflect the number of times Identity Server should continue to make the same request when the requested entry is not found.

com.iplanet.am.replica.retries

Modify the following properties to reflect the number of milliseconds Identity Server should allow to elapse between retries.

com.iplanet.am.replica.delay.between.retries

In each Identity Server Authentication module enabled, specify the consumer directory installed in Step 1. In the following substeps, the LDAP Authentication module is used as an example:

In the Identity Server console, choose Service Management.

Locate the authentication module to be reconfigured, clicking the Properties arrow.

In the right pane:

In the first field named LDAP Server and Port, type the host name and port number for the primary (consumer) Directory Server. For example, consumer1.example.com:389.

In the second field named LDAP Server and Port, type the host name and port number for the secondary (or supplier) Directory Server. For example, supplier1.example.com:389.

Click Submit.

In the following file: /Identity_Server_root/SUNWam/config/ums/serverconfig.xml, specify the host name and port number of the consumer directory installed in Step 1 as in Code Example 5-1.

Code Example 5-1 serverconfig.xml Replication Modification


<iPlanetDataAccessLayer>
<ServerGroup name="default" minConnPool="1"
maxConnPool="10">
<Server name="Server1"
host="consumer1.madisonparc.com" port="389"
type="SIMPLE" />

Restart Identity Server with the following command:

Configuring With a Load Balancer

Figure 5-6 illustrates a multi-supplier configuration that includes Directory Proxy Server. This configuration takes full advantage of Identity Server support for failover, high availability, and managed load-balancing.

Using LDAP load balancers adds a layer of high availability and directory failover protection beyond the basic level that comes with Identity Server. For example, Directory Proxy Server can specify what percentage of the load gets redistributed to each of server. And, when all back-end LDAP servers become unavailable, it continues to manage request traffic and begins rejecting client queries. If you choose to install a load-balancer, Identity Server must be configured to recognize the application.

Before configuring:

Set up the Directory Servers for replication. For comprehensive information about directory replication and for detailed setup instructions, see “Managing Replication” in the Sun ONE Directory Server Administrator’s Guide.

Install and configure the LDAP load balancer. Follow the instructions in the documentation that comes with the product.

In the file /IdentityServer_base/SUNWam/lib/AMconfig.properties, modify the following properties to reflect the host and port number of a consumer Directory Server installed in Step a.

For each Identity Server Authentication module enabled, specify the consumer Directory Server installed in Step a. In the following substeps, the LDAP Authentication module is used as an example:

In the Identity Server console, choose Service Management.

Locate the authentication module to be reconfigured, clicking the Properties arrow.

In the right pane:

In the first field named LDAP Server and Port, type the host name and port number for the primary (consumer) Directory Server using the form proxyhostname:port.

In the second field named LDAP Server and Port, enter nothing.

Click Submit.

In the /IdentityServer_base/SUNWam/config/ums/serverconfig.xml file, specify the host name and port number of the consumer directory installed in Step a as in Code Example 5-2.

Code Example 5-2 serverconfig.xml Load Balancer Modification


<iPlanetDataAccessLayer>
<ServerGroup name="default" minConnPool="1"
maxConnPool="10">
<Server name="Server1"
host="idar.example.com" port="389"
type="SIMPLE" />

Restart Identity Server with the following command:

/IdentityServer_base/SUNWam/bin/amserver start



Note	See Appendix D, "Load Balancer Configuration" for more specifics about configuring Identity Server with a load balancer.

Replication Caveats

There may be situations in which directory replication cannot be implemented in an Identity Server deployment. For example, authentication server host names or IP addresses must be the same. This precludes using geographically separated, replicated Identity Server servers. The remote servers would not be able to perform authentication against servers that are only local to their respective LANs. For comprehensive information on planning and implementing Directory Server replication, see the Sun ONE Directory Server Deployment Guide.

Implementing Federation Management

This section details how to configure a deployment using the Federation Management functionality of Identity Server. This scenario assumes that Domain A, Domain B and Domain C each contain two instances of Identity Server and one instance of Directory Server. Domain A and Domain B have Service Provider A and Service Provider B, respectively. Domain C has Identity Provider C.

In order to manage this federation scenario correctly there are two concepts to understand.


Note	Identity Server has the capability to host multiple providers in the same server instance.

A Hosted Provider defines a specific instance of Identity Server as one acting as a service provider.

A Remote Provider contains data related to any type of provider hosted on machine different from the one on which the instance of Identity Server is currently being configured. This may or may not be an instance of Identity Server; it could be any compliant service provider or identity provider.

So, in the above defined scenario, Service Provider A will configure itself as a hosted provider and Service Provider B and Service Provider C as remote providers. Service Provider B will configure itself as a hosted provider and Service Provider A and Service Provider C as remote providers. Service Provider C will configure itself as a hosted provider and Service Provider A and Service Provider B as remote providers. Once these are configured, an Authentication Domain can be created in each of the domains.

Chapter 5 Deployment Scenarios