Deployment Considerations

This chapter provides information you should keep in mind as you plan your Identity Server deployment.

Directory Issues

The way you install and configure Identity Server will depend upon your company's current directory environment and your long-term directory needs. Before installing Identity Server, you should plan your new directory—or optimize your existing directory—for the highest performance and extensibility. The following sections discuss how you can best leverage the Directory Information Tree (DIT) that comes with Identity Server.

For detailed information regarding general Directory Server planning and implementation, see the Directory Server Deployment Guide available at the following URL:

Installing Against an Existing Directory

You can install Identity Server against an existing Sun ONE Directory Server that is already provisioned with user data. But immediately after you run the Identity Server installation program, you must make modifications in both your existing directory and in the Identity Server configuration so the two will work together. Modifications will vary depending upon your DIT structure, but may include:

Identity Server Schema


Note	If you’re installing Identity Server against an existing Directory Server, the required directory modifications are complex. They call for a high level of expertise in LDAP planning and implementation, as well as proficiency in XML. The procedures are complicated and can be time-consuming. Be sure to plan accordingly for this phase of deployment.

You can install Identity Server schema by choosing the option Configure An Existing Directory Server during the installation program. The Identity Server schema is installed on the server where the Directory Server is installed. The schema file ds_remote_schema.ldif is loaded to your Directory Server schema directory.

Whether or not your directory is already provisioned with users, the following Identity Server objects are created and stored in the directory:

The Identity Server base suffix that is created during installation is designed for storing and managing user data. Special object classes identify the user and group entries in the directory that will be managed by Identity Server. These object classes make it possible for Identity Server to manage only selected data—user data—and not interfere with other aspects of your tree such as servers or hardware.

Unsupported DITs

It is important to understand that DSAME abstractly represents the entries it manages. This means that, for example, an organization in DSAME is not necessarily the same as an organization in iDS. Whether a specific DIT can be managed or not depends on how the you choose to represent or manage your directory entries, and whether your DIT fits into the limitations of each DSAME type.

Limitations to Consider

Only One Type of Entry Can be Marked as an Organization

By adding the DSAME iplanet-am-managed-org auxiliary class to any entry, DSAME will manage this entry as if it is an organization. But there is a limitation: only one type of entry may be marked as an organization in DSAME. For example, if you have an entry o=sun, and another entry dc=ibm in your DIT, you cannot mark them both as organizations. In the following example, if you want both dc and o entries to be organizations, the DIT structure will not be manageable via DSAME.

There is one exception to this rule. The entry at the DSAME root suffix does not count as one entry. So in the following example, the DIT structure can indeed be managed by DSAME:

If you were to add dc=company1 below o=continent1, then this DIT would be manageable only if dc is marked as a container. Container is another abstract type in DSAME that typically maps to an OrganizationalUnit. In most DITs, you would add the iplanet-am-managed-container entry to all OrganizationlUnits.

However, you could add this marker object class to any entry type. The DIT structure in the following example is allowed:

In this example, since you cannot mark both o= and ou= entries as organizations you could mark the o= entries as organization and the ou= entries as containers. When exposed in the UI, both organizations and containers have the same options. You can create subordination or subcontinents, people containers, groups, roles, and users under both of them..

People Containers Must be Parent Entries for Users

Another abstract entry type is the people container. The DSAME type assumes that this entry is a parent entry for users. When you mark an entry as a people container with iplanet-am-managed-people-container, the UI will assume it can only contain sub-people containers or users. The attribute OrganizationUnit is typically used as a people container, but any entry may be this type in DSAME as long as it has the iplanet-am-managed-people-container object class and it has a DSAME manageable parent of type organization or container.

Only One Organization Description is Allowed in the DSAME XML

The DSAME organization is defined in amEntrySpecific.xml. Only one organization description is allowed in this file. As a result, when you customize directory entry properties, or create administration pages or search pages in the UI, your custom attributes apply globally to the entire DSAME configuration. This DSAME requirement may not meet the needs of some companies, especially hosting companies, that require different display attributes for each organization in the deployment.

In the following example, Edison-Watson is a hosting company that provides internet services to a number of companies. CompanyA wants to display fields for capturing a user’s name First Name, Surname, and Badge Number. CompanyB wants to display fields for capturing a user’s First Name, Last Name, and Employee Number.

The organization description is defined at the root level (o=Edison-Watson), and not at the organization level. By default, the UI for both CompanyA and CompanyB must be identical. Also, all services globally define attributes to be of the subschema type user. So if CompanyA has attributes for its users in the auxiliary class CompanyA-user, and CompanyB has attributes in CompanyB-user then CompanyB’s attributes will be overridden, and will not be displayed.

As a workaround, you can modify the ACIs to work for user display. However, this workaround will not address the attributes in Search and Create windows.

Examples of Unsupported DITs

In the following example, you would need three types of organization makers: o, ou, and l. Assuming that l=california and l=alabama are not a people containers, this DIT would not work with DSAME:

In the following example, you would need three types of DSAME markers (dc,o,ou) plus the people container type (ou=people). Under these assumptions, the DIT would not work with DSAME:

Directory Replication

If you plan to use replicated directories with Identity Server, you should define your database replication agreements before running the Identity Server installation program. See "Support for Directory Replication and High Availability" of this manual for more information.

Policy Management Issues

Delegated administration and web access management in Identity Server are implemented through the use of specialized roles and policies. These are created for you at installation, and can be viewed and managed in the Identity Server graphical user interface. As you plan your directory structure, consider how you can leverage these pre-defined Identity Server objects to meet your enterprise needs.

Roles

Identity Server roles are an extension of the roles functionality that comes with Directory Server. In Directory Server, a role is an entry grouping mechanism. This grouping mechanism is designed to be more flexible than a static group, and easy to maintain like a dynamic group.

In Identity Server, the concept of roles is the same as in Directory Server, but with an added level of abstraction. When you install Identity Server, several administrator roles are automatically created for you. Each administrator role specifies a different scope of access control, providing a means for delegating user account administration. You can configure a role to contain any combination of access control instructions (ACIs), policy rules or service attributes. You can configure roles in the Roles page of the Administration Console. You can also create roles with specific permissions to provide a customer delegation model.

The following table summarizes the Identity Server administrator roles and the scope of write permissions that correspond to each role.

Table 2-1 Administrator Roles and Permissions
Administrator Role	Has permissions to modify directory entries at this level of the tree:
	Base Suffix	Role Definitions	Organization	Group	User	Own Entry
Top-Level Administrator	X	X	X	X	X	X
Top-Level Help Desk*			X*
Organization			X	X	X	X
Organization Help Desk*			X*
Container				X	X	X
Container Help Desk*			X*
Group				X	X	X
People Container					X	X
User (self-administrator)						X
* Help Desk Administrators can only modify passwords of users within their own branch of the tree.

When you create a directory entry, the appropriate administrator roles and ACIs are created and assigned to the directory entry. You can then assign a role to an individual user.

For example, when you use Identity Server to create a new organization, two new roles are automatically created and stored in the directory:

If you assign the organization administrator role to a user, mikeb, within the organization, then mikeb inherits all the permissions accorded an organization administrator. If you assign the help desk administrator role to a user, ginac, then ginac inherits the more restricted permissions of a help desk administrator. Ultimately, you’ll find that using roles instead of group-based ACIs is more efficient and requires less maintenance.

Policies and Policy Agents

You can control access to web resources in your enterprise by applying policy to roles and organizations. A policy is made up of rules, subjects, and conditions. A rule grants or denies a user access to a specified resource such as a service or a page of content stored in a server. Subjects specify who the rule will apply to. Conditions specify any constraints on the policy. Policy agents, which you install on the Web Servers in your enterprise, evaluate and enforce the policies you define.

When a user tries to access a protected resource such as a web page stored on a server in your enterprise, the Identity Server Policy Service evaluates the rules attached to the user's organization, role, or userid. Based upon the net result of the rules and conditions assigned to the user, the individual is either granted or denied access to the web page. You can configure rules and policies in the Identity Server Administration Console. For more information about setting up policies, see the Sun ONE Identity Server Administration Guide. For comprehensive information about Identity Server Policy Agents and how to install and configure them, see the Sun ONE Policy Agents Guide at http://docs.sun.com/db/prod/s1.ipdirsame.

Service Attributes

You can use service attributes to define how services will work with Identity Server. Some service attributes are set at the global level and impact the entire Identity Server installation, some impact only individual users, and some can be set at multiple levels. To specify a value for an attribute, it’s important to understand the scope of its effect. To make this easier, service attributes are organized into the following categories: global, dynamic, policy, and user.

Global. Global attributes apply to the entire DIT. You can set these values in Service Management view.

Dynamic. Dynamic attributes can be set in Service Management at the global level or in User Management view for an organization or role. These values can also be inherited from a parent object.

Policy. Policy attributes can be set in Policy Management view. Once policy is defined, it can be applied to one or more roles and organizations. These values can also be inherited from a parent object.

User. User attributes apply to individual user entries. You can set these values in Organization Management view.

You can use the Administration Console to configure and set policy for services. For more information, see the Sun ONE Identity Server Administration Guide at http://docs.sun.com/db/prod/s1.ipdirsame.

Installing Other Products for Use With Identity Services

You can deploy Identity Server with remote Web Servers, with LDAP load-balancer such as Sun ONE Directory Access Router, and in multi-master replications. Before you run the Identity Server installation program, consider how these products might fit into your deployment. In many cases, you must install and configure these products before you install Identity Server.

Remote Web Servers

In this manual, Web Servers are “remote” relative to the Web Server that runs Identity Server Policy and Management services. You may already have remote Web Servers deployed to serve content pages for your enterprise. You may want to install additional ones. A remote server becomes integrated with Identity Server only when you install a Policy agent on it. For detailed Web Server installation and administration information, see the documentation that comes with the server, or access the documentation on the Internet at http://docs.sun.com/db/prod/s1websrv.

Policy Agent

The Identity Server Policy agent can be installed on various web servers installed in your enterprise. The agent enforces access rules and policies that are set on specific pages stored on the server. The agent intercepts each request received by a configured Web Server and communicates with the Policy service. The Policy service authenticates the user’s credentials, and then examines the user’s roles and policies. If the user has the proper credentials and policy assignment, the agents allow the user to access the URL over HTTP.

The Identity Server Policy Agent is a separate product and is available for download at the following URL:

Multiple Directory Servers for Failover and High Availability

You can use the Identity Server installation program to install Directory server for the purposes of upgrading, setting up failover directories, or for setting up multi-master replication.You should install, configure and deploy Directory Server properly for Identity Server to be successful. For more information, see "Support for Directory Replication and High Availability".

For detailed Directory Server deployment and installation information, see the documentation that comes with the server, or access the documentation on the Internet at http://docs.sun.com/prod/s1dirsrv.

LDAP Load-Balancers

You can configure Identity Server to work with load-balancers such as Sun ONE Directory Access Router. This might be useful if you want to precisely manage directory high availability. For more information, see "Support for Directory Replication and High Availability".

For detailed Sun ONE Directory Access Router installation and administration information, access the documentation on the Internet at http://docs.sun.com/db/prod/s1.ipdirar

For information on any other load-balancer, see the documentation that comes with the product.

Hardware Requirements

You must make sure that the systems on which you plan to install Identity Server meet the minimum hardware requirements. While all the Identity Server components can theoretically be installed on a single server machine, you will most likely not want to do this. Please review the installation and deployment information in each component’s documentation before designing your Identity Server deployment. The recommended procedure is to consult Sun ONE Professional Services or another Sun ONE-certified system integrator before designing and deploying an Identity Server installation.

Optimal Hardware Requirements

Typically, directory resource requirements are high. The actual requirements differs from the above. They are based on customer specific, data, and usage characteristics.

Recommended Hardware Configurations

One computer system for Directory Server with 512MB to 1GB memory and approximately 300MB disk space for minimal data in Directory Server.

One computer system for Identity Server (and Sun ONE Web Server) and potentially Sun ONE Application Server and Policy agents, with 512MB to 1GB memory and 25MB-100MB disk space. Log and debug files may require additional GB disk space over time.

For large installations, you should plan at least 2GB disk space to support the product binaries, databases, and log files (log files require 1 GB by default); 4GB and greater may be required for very large directories.

If you have existing web servers that need to be protected, the Policy agent needs to be installed on each web server. The agent requires 10 MB of disk space.

Table 2-2 contains some guidelines for disk space and memory requirements depending on the number of entries managed by your Directory Server.

Table 2-2 Directory Server Disk Space Guidelines
Number of Entries	Disk Space and Memory Required
10,000 - 250,000 entries	Free disk space: 2 GB, Free memory: 256MB
250,000 - 1,000,000 entries	Free disk space: 4 GB, Free memory: 512 MB
Over 1,000,000 entries	Free disk space: 8 GB, Free memory: 1 GB

Software Requirements

Ensure that your systems meet the following software, and operating system requirements.

Operating System Requirements

Patch Clusters for Solaris

When running Sun ONE Directory Server on a Solaris 8 operating system, you must ensure that the recommended patch cluster is installed. Solaris patches are identified by two numbers, for example 108827-15. The first number (108827) identifies the patch itself. The second number identifies the version of the patch (15). We recommend installing the latest version of the patch in order to benefit from the latest fixes.

Use the command showrev -p to list the patches currently installed on your machine. All patches can be downloaded from http://sunsolve.sun.com. At that site, go to Patches>Recommended & Security Patches to see the list of Recommended & Security Patch Clusters for Solaris.

For any patches not found in the above cluster, please go to Patches>Patchfinder on http://sunsolve.sun.com

Sun ONE Directory Server Patches

The idsktune utility, installed with Sun ONE Directory Server, may recommend further patches you should install. For instructions on running idsktune, refer to the following section of the Sun ONE Directory Server Installation Guide:

Sun ONE Certificate Server 4.7 Patch Installation

In order to configure the Identity Server Security Service, you must install a patch for the Sun ONE Certificate Server version 4.7. Before you install the patch, Certificate Server must be installed on your system.

For Certificate Server installation instructions, see the Sun ONE Certificate Server Installation and Setup Guide at the following location:

Installing the Certificate Server 4.7 Patch

Once the patch is installed, configure the Identity Server Security Service in the Identity Server Console.

Java Requirement

Remote Web Server Requirements

UNIX	CMS_Root/bin/cert
Windows	CMS_Root\bin\cert

UNIX	tar -xvof CMS47sp1.tar
Windows	unzip CMS47sp1.zip

Identity Server Web Agents use approximately 10MB of disk space. For detailed information on Web Server requirements for Identity Server Web Agents, see the Sun ONE Policy Agents Installation Guide at the following URL:

Web Browser Requirements

Administrators and end users use web browsers to perform user management tasks. Identity Server supports the following web browsers:

Chapter 2 Deployment Considerations