| Sun ONE Identity Server Deployment Guide |
Chapter 4
Pre-Deployment ConsiderationsSun™ ONE Identity Server 6.1 enables large organizations with a heterogeneous hardware, software and application infrastructure to successfully deploy an identity management solution for their employees, contractors, customers and suppliers. This chapter provides a high-level technical overview of the issues related to this process. It contains the following sections:
Deployment OptionsThere are several key factors that an organization should consider when planning for an Identity Server deployment. These considerations generally deal with risk assessment and a growth strategy. For example,
- How many users is the environment expected to currently support, and what is the projected growth rate?
It is critical that user growth and system usage are monitored and this real data is compared with the projected data to ensure that the current capacity is capable of handling the projected growth.
- Are there future plans to add additional services to the environment which might impact the current design?
The architecture being developed now is optimized for the current service. Future plans should also be examined.
In addition, the architecture should provide a foundation for the objectives detailed in the following sections.
Security
There are a number of options to consider when providing for a secure internal and external networking environment. They include:
- Server-based firewalls that provide an additional layer of security by locking down port-level access to the servers. As with standard firewalls, server-based firewalls lock down in-coming and out-going TCP/IP traffic.
- Minimization refers to removing all unnecessary software and services from the server in order to minimize the opportunity for exploitation of the vulnerabilities of a system.
- A Split-DNS infrastructure is one in which two zones are created in one domain. One zone is used by an organization’s internal network clients and the other is used by external network clients. This approach is recommended to ensure a higher level of security. The DNS servers can also be load-balanced for performance.
High Availability
IT deployments strive for no single point of failure (SPOF) as well as continous availability to its users. Different products achieve availability in different ways; for example, clustering or multi-master replication. The desired high availability refers to a system or component that is continuously operational for a desirably long length of time. It is generally accomplished with multiple server machines that appear to the user as a single highly available system. In a deployment that meets the minimal requirements (all applications on one machine), the SPOFs might include:
As most of these issues can be waylaid, much planning for high availability centers around backup and failover processing as well as data storage and access. For storage, a redundant array of independent disks (RAID) is one approach. For any system to be highly available, the parts of the system should be well-designed and thoroughly tested before they are used. For example, a new application program that has not been thoroughly tested is likely to become a frequent point-of-breakdown in a production system.
Note
In a high availability scenario, the encryption key needs be filled out identically for all installs of Identity Server.
Clustering
Clustering is the use of multiple computers to form a single, highly available system. Clustering isn’t used for Sun ONE Identity Server however, it is crucial within the underlying Sun ONE Directory Server data store. For example, a clustered MMR server pair can increase the availability of each master instance by ensuring availability.
Scalability
Horizontal scaling is achieved by connecting multiple server machines so they work as one unit. A load balanced service is considered horizontally scaled as it increases the speed and availabilty of the service. Vertical scaling, on the other hand, is increasing the capacity of exisitng hardware by adding resources within one server machine. The types of resources that may be scaled include CPUs, memory, and storage. Horizontal scaling and vertical scaling are not mutually exclusive; they can work hand-in-hand. Typically, servers in an environment are not installed at full capacity, so vertical scaling is used to improve performance. When a machine approaches full capacity, horizontal scaling can be used to distribute the load among a larger number of servers.
Hardware RequirementsThe hardware on which Identity Server will be installed must meet certain requirements. At a minimum, Identity Server needs to be installed in tandem with Sun ONE Directory Server 5.2 (to be used as a data store) and a web container in which it will be deployed. It is recommended that Directory Server and Identity Server be installed on different machines.
The detailed requirements are high-level, based on a default configuration of the components: one instance of Identity Server (deployed by Sun ONE Web Server), and one instance of Directory Server. Please review the Directory Server Installation And Tuning Guide and the Deployment Guide, as well as the documentation from the web container of choice before installing Identity Server.
Note
The recommended procedure is to consult Sun ONE Professional Services or a Sun ONE-certified system integrator before designing and deploying a Sun ONE Identity Server.
It is recommended that Identity Server be run on a 100 MB or greater Ethernet network. The minimum configuration for an Identity Server deployment is a machine with both Identity Server and Sun ONE Web Server installed on it. It should be a machine with one or more CPUs, with greatly diminshing returns on processor investment after four. Two to four CPUs per server is highly recommended. A minimum of 256 MB of RAM is necessary for basic testing of the software. For an actual deployment scenario, 1 GB of RAM is recommended for threads, the SDK, the HTTP server, and other internals; 2 GBs for basic operation, and object allocation space, and 100 MBs per 10,000 concurrent sessions. Each Identity Server is recommended to cap out at 100,000 concurrent sessions, after which horizontal load balancing should be applied (assuming the 4GB memory limitation of 32bit applications).
Note
Typically, directory resource requirements are high although they may differ based on customer specific data and usage.
Software RequirementsThe systems on which Identity Server will be installed must also meet minimum software and operating system requirements.
Operating System Requirements
Identity Server is supported on the following platforms:
Patch Clusters for Solaris
When running Directory Server on a Solaris 8 operating system, the recommended patch cluster must be installed. Patch clusters 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). The latest patches should be installed in order to benefit from the latest fixes. Overall patch information and recommended patches can be downloaded from the SunSolve Patch Support Portal. (Patch clusters are required for Sun ONE Directory Server, Sun ONE Web Server and Sun ONE Application Server.)
Note
The command showrev -p can be used to list the patches currently installed on a Solaris machine. .
Following are a list of patches that should be installed before installation of Identity Server. See the Sun Java Enterprise System 2003Q4 Installation Guide for more complete information on the required patches.
Java™ Requirement
Identity Server requires Java version 1.3.1. It is recommended though that Java version 1.4.1 is used.
Resource Web Server Requirements
Supported web containers for Identity Server are Sun ONE Web Server 6.1 and Sun ONE Application Server 7.0. When policy agents are installed on these web containers, they use approximately 10MB of disk space. This must be taken into account when configuring the web container that serves content. For detailed information, see the Sun ONE Identity Server Web Policy Agents Guide or the Sun ONE Identity Server J2EE Policy Agents Guide.
Web Browser Requirements
Administrators and end users use web browsers to perform user management tasks. Identity Server supports the following web browsers:
Understanding the Identity Server SchemaIn general, a schema is a set of rules imposed on data that serves to define how it is stored. Directory Server contains a Lightweight Directory Access Protocol (LDAP) schema that defines how its data is stored. Object classes define attributes in a LDAP schema. In Directory Server, each data entry must have one or more object class(es) to specify the type of object the entry describes and define the set of attributes it contains. Each entry then is basically a set of attributes and their corresponding values and the list of object classes to which these attributes correspond.
Identity Server uses Directory Server as the data repository for all its identity profiles, entitlement definitions, and deployment configuration information. Towards this end, Identity Server has its own schema which extends the Directory Server schema. When Identity Server is installed, the Identity Server schema, detailed in ds_remote_schema.ldif and sunone_schema2.ldif, is integrated with the Directory Server schema. ds_remote_schema.ldif details LDAP object classes and attributes that are specifically used by Identity Server; these object classes and attributes are generally holdovers from previous versions of Identity Server. sunone_schema2.ldif loads the Identity Server-specific LDAP schema object classes and attributes defined by Sun Microsystems’ new internal schema document. For reference, ds_remote_schema.ldif and sunone_schema2.ldif are reproduced in Code Example 4-1 and Code Example 4-2, respectively.
Code Example 4-2 sunone_schema2.ldif
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.185 NAME 'sunManagedOrganization' DESC 'Auxiliary class which must be present in an organization entry' SUP top AUXILIARY MAY ( inetDomainStatus $ sunPreferredDomain $ associatedDomain $ sunPreferredOrganization $ sunAdditionalTemplates $ sunOverrideTemplates $ sunRegisteredServiceName $ organizationName ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.75 NAME 'sunManagedSubOrganization' DESC 'Auxiliary class which must be present in an sub organization entry' SUP top AUXILIARY MAY ( inetDomainStatus $ parentOrganization ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.29 NAME 'sunNameSpace' DESC 'Auxiliary class which must be present at the root of a subtree representing a namespace' AUXILIARY MAY sunNameSpaceUniqueAttrs X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.27 NAME 'sunservicecomponent' DESC 'Sub-components of the service' SUP top MUST ou MAY ( sunserviceid $ sunsmspriority $ sunkeyvalue $ sunxmlkeyvalue $ description ) X-ORIGIN 'Sun Java System Identity Management' )
Marker Object Classes
Identity entries created using the Identity Server console and stored in Directory Server are appended with marker object classes. Marker object classes define the designated entries as those which Identity Server will manage. The object classes will not interfere with other aspects of the directory tree, such as servers or hardware. As well, existing identity entries can not be managed using Identity Server until they are modified to include these object classes. More detailed information on the marker object classes can be found in Chapter 5, “Identity Management” in the Sun ONE Identity Server Customization And API Guide. Information on how to migrate existing Directory Server data for use with Identity Server can be found in the Sun ONE Identity Server Migration Guide .
Administrative Roles
Delegated administration of the LDAP entries (mapped to each identity-related object in Identity Server) are implemented through the use of pre-defined roles and access control instructions (ACIs). Default administrative roles and their defined ACIs are created during Identity Server installation, and can be viewed and managed using the Identity Server console. When an Identity Server identity-related object is created, the appropriate administrative roles (and, thus, corresponding ACIs) are also created and assigned to the LDAP entry for that object. The role can then be assigned to an individual user who maintains control of that object’s node. For example, when Identity Server creates a new organization, several roles are automatically created for it and stored in Directory Server:
- Organization Administrator has read and write access to all entries in the configured organization.
- Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute in those entries.
- Organization Policy Administrator has read and write access to all policies in the organization.
The assignation of any of these roles to a user gives that user all the permissions accorded that role. Table 4-2 summarizes the Identity Server administrator roles and the scope of write permissions that correspond to eachone.
Table 4-2 Default And Dynamic Roles And Their Permissions
Role
Administrative Suffix
Permissions
Top-level Organization Admin (amadmin)
Root level
Read and write access to all entries (roles, policy, groups, etc.) under top-level organization.
Top-level Organization Help Desk Admin
Root level
Read and write access to all passwords under top-level organization.
Top-level Organization Policy Admin
Root level
Read and write access to policies created under top-level organization only. Used by sub-organizations to delegate referral policy creation.
Organization Admin
Organization only
Read and write access to all entries (roles, policy, groups, etc.) under the created sub-organization only.
Organization Help Desk Admin
Organization only
Read and write access to all passwords under the created sub-organization only.
Organization Policy Admin
Organization only
Read and write access to all policies under the created sub-organization only.
Container Admin
Container only
Read and write access to all entries (roles, policy, groups, etc.) under the created container only.
Container Help Desk Admin
Container only
Read and write access to all passwords under the created container only.
Group Admin
Group only
Read and write access to all entries (roles, policy, groups, etc.) under the created group only.
People Container Admin
People Container only
Read and write access to all entries (roles, policy, groups, etc.) under the created people container only.
User (self-administrator)
User only
Read and write access to all attributes in the user entry only.
Using roles instead of group-based ACIs is more efficient and requires less maintenance. Filtered roles are simplier for LDAP clients, since they can just ask for the nsRole attribute of a user. Roles do suffer though from scope limitations, where a role must be a peer of a parent of a member of that role. More detailed information on the default ACIs can be found in Chapter 14, “Administration Attributes” in the Sun ONE Identity Server Administration Guide.
Schema Limitations
The following sections detail some limitations of the Identity Server schema.
People Containers
In Identity Server, the people container is a parent entry for users only. An organizational unit is typically used as a people container, but any entry may be this type as long as it has the iplanet-am-managed-people-container object class and an Identity Server manageable parent type object, organization or container. When an LDAP entry is marked with iplanet-am-managed-people-container, Identity Server assumes it will only contain sub-people containers or users. Therefore , the people container can only contain sub-people containers or users.
Only One Identity Server Organization Allowed
Only one LDAP object type can be marked as an Identity Server organization. In other words, the iplanet-am-managed-org marker object class can only be added to one LDAP type entry. (This object class is added so Identity Server will manage this entry as if it were an organization.)
Caution
Be aware that the root suffix organization created during installation does not count towards this one organization restriction.
Thus, in Figure 4-1, both the dc and o entries can not be managed as organizations using the Identity Server console.
Figure 4-1 Unmanageable Directory Tree
In Figure 4-2, this tree can be managed by Identity Server.
Figure 4-2 One Organization Rule Exception
If you were to add dc=company1 below o=continent1, this tree would be manageable only if dc is marked as a container, not an organization. The iplanet-am-managed-container object class is usually added to all organizational units, however, it can be added to any entry.
Figure 4-3 Two Organizational Units Allowed
In this example, since you cannot mark both o= and ou= entries as organizations you could mark the o= entry as an organization and the ou= entries as containers. Management of both organizations and containers using Identity Server have the same options. People containers, sub-organizations, groups, roles, and users can be created under both of them.
Unsupported Directory Trees
Most existing directory trees can be reconfigured to work with Identity Server although, in some cases, reconfiguration is not recommended. In general, if an existing tree uses more than one type of LDAP entry (examples: dc, o, and ou) to define organizations, the user data will be recognized by Identity Server only under certain conditions. 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 people containers, this DIT would not work with Identity Server.
Figure 4-4 Scenario 1: Three LDAP Organization Attributes not Allowed
In the next example, you would need three types of Identity Server markers (dc, o, ou) plus the people container (ou=people). Under these assumptions, the DIT would not work with Identity Server:
Figure 4-5 Scenario 2: Three LDAP Organization Attributes not Allowed
