|
| |
| Sun Java System Access Manager 6 2005Q1 Deployment Planning Guide | |
Chapter 4
Pre-Deployment ConsiderationsSun Java™ Access Manager 6 2005Q1 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 Access Manager 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 continuos 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 Access Manager.
Clustering
Clustering is the use of multiple computers to form a single, highly available system. Clustering isn’t used for Sun Java System Access Manager however, it is crucial within the underlying Sun Java System 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 availability of the service. Vertical scaling, on the other hand, is increasing the capacity of existing 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 Access Manager will be installed must meet certain requirements. At a minimum, Access Manager needs to be installed in tandem with Sun Java System Directory Server to be used as a data store and a web container in which it will be deployed. Another recommendation is that Directory Server and Access Manager should be installed on different machines.
The detailed requirements are high-level, based on a default configuration of the components: one instance of Access Manager (deployed by Web Server), and one instance of Directory Server. Please review the Directory Server Installation and Migration Guide and the Directory Server Deployment Planning Guide, as well as the documentation from the web container of choice before installing Access Manager.
Note
The recommended procedure is to consult Sun Java System Professional Services or a Sun Java System-certified system integrator before designing and deploying a Sun Java System Access Manager.
For optimum performance, run Access Manager run on a 100 MB or greater Ethernet network. The minimum configuration for an Access Manager deployment is a machine with both Access Manager and Sun Java System Web Server installed on it. It should be a machine with one or more CPUs, with greatly diminishing 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 Access Manager 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 Access Manager will be installed must also meet minimum software and operating system requirements.
Operating System Requirements
Access Manager 6 2005Q1 is supported on these platforms:
For more information about the specific versions that are supported, refer to the Sun Java Enterprise System 2005Q1 Release Notes and the Access Manager Release Notes.
Patch Clusters for Solaris
Patch clusters are identified by two numbers, for example: 108827-15. The first number identifies the patch itself, and the second number identifies the version of the patch. Overall patch information and recommended patches can be downloaded from the SunSolve Patch Portal:
To list the patches currently installed on a Solaris machine, use the showrev -p command.
For a list of required patches, refer to the Access Manager 2005Q1 Release Notes and the Java Enterprise System 2005Q1 Release Notes.
JDK Software Requirements
Access Manager 6 2005Q1 supports the following JDK software:
Web Container Requirements
Access Manager 6 2005Q1 supports the following web containers for a full installation or an SDK-only installation:
For the specific versions that are supported, refer to the Access Manager 6 2005Q1 Release Notes.
When a policy agent is installed on a web container, it uses approximately 10MB of disk space. This spaces must be considered when configuring the web container. For detailed information, see the Sun Java System Access Manager Web Policy Agents Guide or the Sun Java System Access Manager J2EE Policy Agents Guide.
Directory Server Requirements
Access Manager 6 2005Q1 requires Sun Java System Directory Server 5 2005Q1. For the most recent list of requirements, refer to the Access Manager 6 2005Q1 Release Notes.
Web Browser Requirements
Administrators and end users use web browsers to perform administrative and user management tasks. For information about the supported web browsers for this release, refer to the Access Manager 6 2005Q1 Release Notes.
Understanding the Access Manager 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.
Access Manager uses Directory Server as the data repository for all its identity profiles, entitlement definitions, and deployment configuration information. Towards this end, Access Manager has its own schema which extends the Directory Server schema. When Access Manager is installed, the Access Manager 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 Access Manager; these object classes and attributes are generally holdovers from previous versions of Access Manager. sunone_schema2.ldif loads the Access Manager-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 Access Manager console and stored in Directory Server are appended with marker object classes. Marker object classes define the designated entries as those which Access Manager 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 Access Manager 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 Access Manager Developer’s Guide. Information on how to migrate existing Directory Server data for use with Access Manager can be found in the Access Manager Migration Guide.
Administrative Roles
Delegated administration of the LDAP entries (mapped to each identity-related object in Access Manager) are implemented through the use of pre-defined roles and access control instructions (ACIs). Default administrative roles and their defined ACIs are created during Access Manager installation, and can be viewed and managed using the Access Manager console. When an Access Manager 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 Access Manager 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-1 summarizes the Access Manager administrator roles and the scope of write permissions that correspond to each one.
Table 4-1 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 simpler 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 Java System Access Manager Administration Guide.
Administrator Passwords
During the installation of Access Manager, you must provide passwords for the Administrator user ID (amadmin) and the LDAP user ID (amldapuser).
The serverconfig.xml file contains the parameters used by the Identity SDK to establish the LDAP connection pool to Directory Server, including the following users:
- Proxy User (User name=“User 1”, cn=puser) can take on any user’s privileges (for example, the organization administrator or an end user).
- Admin User (User name=“User 2”, cn=dsameuser) is used for binding purposes when the Access Manager SDK performs operations on Directory Server that are not linked to a particular user (for example, retrieving service configuration information).
Each of these users has an associated password that is stored in encrypted format in the serverconfig.xml file. Of course, you should always protect these passwords, especially the puser password; however, it is also recommended that you:
For information about changing the password for puser and dsameuser, refer to the amPassword command-line tool in the Access Manager Administration Guide.
Schema Limitations
Access Manager abstractly represents the entries it manages. This means, for example, that an organization in Access Manager is not necessarily the same as an organization in Directory Server. Whether a specific Directory Information Tree (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 Access Manager type.
The following sections describe these limitations of the Access Manager schema:
At the end of this section, several Examples of Unsupported DITs are included.
Only One Type of Entry Can be Marked as an Organization
By adding the Access Manager iplanet-am-managed-org auxiliary class to any entry, Access Manager 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 Access Manager. 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 using Access Manager:
There is one exception to this rule. The entry at the Access Manager root suffix does not count as one entry. So in the following example, the DIT structure can be managed by Access Manager:
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 Access Manager 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 Access Manager 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 can be this type in Access Manager as long as it has the iplanet-am-managed-people-container object class and it has a Access Manager manageable parent of type organization or container.
Only One Organization Description is Allowed in the Access Manager XML
The Access Manager 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 Access Manager configuration. This Access Manager 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=EdisonWatson), 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 Access Manager:
In the following example, you would need three types of Access Manager markers (dc,o,ou) plus the people container type (ou=people). Under these assumptions, the DIT would not work with Access Manager:
