During the technical requirements phase of the solution life cycle you perform a usage analysis, identify use cases, and determine quality of service requirements for the proposed deployment solution. This chapter provides a high-level technical overview of the requirements related to this process for Sun JavaTM System Access Manager 7.1, including:
There 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 your deployment expected to support, and what is your projected growth rate?
It is critical that user growth and system usage are monitored and that this data is compared with the projected data to ensure that the current capacity is capable of handling the projected growth.
Do you have plans to add additional services that might impact the current design?
The architecture being developed now is optimized for the current service. Your future plans should also be examined.
In addition, the architecture should provide a foundation for the objectives detailed in the following sections.
Consider the following options when you are planning for a secure internal and external networking environment:
Server-based firewalls provide an additional layer of security by locking down port-level access to the servers. As with standard firewalls, server-based firewalls lock down incoming and outgoing 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 has two zones that 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 use load balancers to improved performance.
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 specified length of time. It is generally accomplished with multiple host servers that appear to the user as a single highly available system. In a deployment that meets the minimal requirements (all applications on a single server), the SPOFs might include:
Access manager web container
Directory Server
Java Virtual Machine (JVM)
Directory Server hard disk
Access Manager hard disk
Policy agents
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.
Clustering is the use of multiple computers to form a single, highly available system. Clustering is often crucial for the Sun Java System Directory Server data store. For example, a clustered multi-master replication (MMR) server pair can increase the availability of each master instance by ensuring availability.
Horizontal scaling is achieved by connecting multiple host servers so they work as one unit. A load balanced service is considered horizontally scaled because 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 a single host server. The types of resources that can be scaled include CPUs, memory, and storage. Horizontal scaling and vertical scaling are not mutually exclusive; they can work together for a deployment solution. Typically, servers in an environment are not installed at full capacity, so vertical scaling is used to improve performance. When a server approaches full capacity, horizontal scaling can be used to distribute the load among other servers.
The minimum configuration for an Access Manager deployment is a single host server running Access Manager and a web container such as Sun Java System Web Server. Directory Server can be running on the same server or on a different server. In a multiple server deployment, Access Manager instances and their respective web containers are installed on a different host servers, with a load balancer distributing client requests to the various Access Manager instances. Usually, Directory Server and Access Manager are installed on different servers.
For optimum performance, run Access Manager on a 100 Mbytes or greater Ethernet network. A minimum configuration Access Manager deployment (a single server running Access Manager and a web container) should have one or more CPUs, with greatly diminishing returns on processor performance after four CPUs. Two to four CPUs per host server are recommended. A minimum of 512 Mbytes of RAM is necessary for basic testing of the software.
For an actual deployment, 1 Gbytes of RAM is recommended for threads, the Access Manager SDK, the HTTP server, and other internals; 2 Gbytes for basic operation and object allocation space, and 100 Mbytes 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 used (assuming the 4 Gbytes memory limitation of 32–bit applications).
Access Manager has specific minimum software requirements, including:
For the latest information about the software requirements, including supported releases, any required patches, and known limitations, see the Sun Java System Access Manager 7.1 Release Notes.
Access Manager 7.1 is supported on these platforms:
SolarisTM 10 OS on SPARC®, x86, and x64 based systems
Solaris 9 OS on SPARC and x86 systems
Red HatTM Linux OS
Microsoft Windows OS
HP-UX OS
For the specific versions of each operating system that are supported, see the Sun Java System Access Manager 7.1 Release Notes.
For information about downloading OS patches and patch clusters, see SunSolve Online at http://sunsolve.sun.com/.
To list the patches currently installed on a Solaris system, use the showrev -p command.
Access Manager 7.1 supports the following web containers for either a full installation or an SDK-only installation:
Sun Java System Web Server
Sun Java System Application Server
BEA WebLogic
IBM WebSphere Application Server
BEA WebLogic and IBM WebSphere Application Server are not supported on HP-UX systems.
For the supported versions of these web containers, see the Sun Java System Access Manager 7.1 Release Notes.
When a policy agent is installed on an Access Manager web container, it uses approximately 10 Mbytes of disk space. This additional space must be considered when configuring the web container. For more information, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.
Access Manager 7.1 has the following requirements for an LDAP directory server:
The Access Manager information tree, which contains the following information, is stored in Sun Java System Directory Server:
How users authenticate
Which resources users can access
What information is available to applications after users are given access to resources
The Access Manager identity repository is used to store user data such as users and groups. Access Manager 7.1 can use Sun Java System Directory Server or an LDAP version 3 (LDAP v3) compliant directory server as the identity repository.
For more information about the Access Manager information tree and identity repository, see the Sun Java System Access Manager 7.1 Technical Overview.
For the specific version of the JDK software required by Access Manager 7.1 , see the Sun Java System Access Manager 7.1 Release Notes.
If you are planning to implement Access Manager session failover, these components are required:
Web container to run Access Manager: Sun Java System Web Server, Sun Java System Application Server, IBM WebSphere Application Server, or BEA WebLogic.
Sun Java System Directory Server. All Access Manager instances must access the same Directory Server.
Sun Java System Message Queue. The Message Queue broker cluster manages the session messages between Access Manager instances and the session store database.
Berkeley DB (http://www.oracle.com/database/berkeley-db.html) is the default session store database. Use the version that is distributed with the Sun Java Enterprise System 5 release.
Access Manager session failover is supported on the following platforms:
Solaris 10 OS on SPARC, x86, and x64 based systems
Solaris 9 OS on SPARC and x86 systems
Red Hat Linux OS
Microsoft Windows OS
HP-UX OS
For the latest information about the supported versions of these platforms and components, see the Sun Java System Access Manager 7.1 Release Notes.
For more information, see Chapter 6, Implementing Session Failover, in Sun Java System Access Manager 7.1 Postinstallation Guide.
Access Manager administrators and end users use web browsers to perform administrative and user management tasks. For information about the supported web browsers for this release, see the Sun Java System Access Manager 7.1 Release Notes.
To access the Access Manager Console, JavaScript must be enabled for the browser.
To implement secure Internet communications, the following deployment scenarios or activities require Access Manager 7.1 to use Java Secure Socket Extension (JSSE) encryption instead of JSS encryption:
Client SDK deployment on an SSL-enabled web container instance
Distributed Authentication deployment on an SSL-enabled web container instance
Single Access Manager 7.1 WAR file deployment on an SSL-enabled web container instance
Use of the com.sun.identity.idm API with an SSL-enabled Access Manager server
Access Manager deployment on an SSL-enabled third-party web container instance (BEA WebLogic or IBM WebSphere Application Server)
For JSSE information and downloads, see the following Sun Developer Network (SDN) web site: http://java.sun.com/products/jsse/
When assessing the technical requirements for your Access Manager deployment, consider the following administrative users and accounts:
In Access Manager Realm mode, the Delegation plug-in works with the Identity Repository plug-in to determine a network administrator's scope of privileges. Default administrator roles are defined in the Identity Repository plug-in. The Delegation plug-in forms rules that describe the scope of privileges for each network administrator, and also specifies the roles to which the rules apply. The following table lists the roles defined in the Identity Repository and the default rule the Delegation plug-in applies to each role.
Table 3–1 Access Manager Roles and Scope of Privileges in Realm Mode
Identity Repository Role |
Delegation Rule |
---|---|
Realm Administator |
Can access all data in all realms of the Access Manager information tree. |
Subrealm Administrator |
Can access all data within a specific realm of the Access Manager information tree. |
Policy Administrator |
Can access all policies in all realms of the Access Manager information tree. |
Policy Realm Administrator |
Can access policies only within the specific realm of the Access Manager information tree. |
The Authentication service and Policy service use the aggregated data to perform the authentication and authorization processes. The code for the Delegation plug-in and Identity Repository plug-in are not public in Access Manager.
In Access Manager Legacy mode, 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. In Access Manager 7.1 in Realm mode, roles depend on policies rather then ACIs.
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.
The following table summarizes the Access Manager administrator roles and the permissions that apply to each one.
Table 3–2 Default and Dynamic Roles and Their Permissions in Legacy Mode
Role |
Administrative Suffix |
Permissions |
---|---|---|
Top-level Organization Admin (amadmin) |
Root level |
Read and write access to all entries (such as roles, policy, and groups) 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 at all levels. Used by sub-organizations to delegate referral policy creation. |
Organization Admin |
Organization only |
Read and write access to all entries (such as roles, policy, and groups) 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 (such as roles, policy, and groups) 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 (such as roles, policy, and groups) under the created group only. |
People Container Admin |
People Container only |
Read and write access to all entries (such as roles, policy, and groups) under the created people container only. |
User (self-administrator) |
User only |
Read and write access to attributes in the user entry only (except for user attributes such as nsroledn and inetuserstatus). |
Using roles instead of group-based ACIs is more efficient and requires less maintenance. Filtered roles are simpler for LDAP clients, because 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.
For more information about default ACIs, see the Access Manager Console Online Help.
During the installation of Access Manager, the following administrative accounts are created:
Administrator user ID (amadmin) is the Access Manager top-level administrator that has unlimited access to all entries managed by Access Manager. You cannot change the default name, amadmin.
During installation, you must provide a password for amadmin. To change the amadmin password after installation, use the Access Manager Administration Console.
Bind DN user for LDAP, Membership, and Policy services (amldapuser) is the administrative user that has read and search access to all Directory Server entries. You cannot change the default name, amldapuser.
During installation, you must provide a password for amldapuser. Do not use the same password that you used for amadmin. To change the amldapuser password after installation, use the Directory Server Console or the ldapmodify utility.
If you change the amldapuser password, you must also modify the LDAP authentication service and policy configuration services to reflect the change (amldapuser is the default user used in these services). You must make changes in each organization where these services are registered.
Proxy user (puser) can take on any user's privileges (for example, an organization administrator or end user).
Admin user (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).
Both puser and dsameuser have an associated password that is stored in encrypted format in the serverconfig.xml file, in the following directories:
Solaris systems: /etc/opt/SUNWam/config
Linux and HP-UX systems: /etc/opt/sun/identity/config
Windows systems: javaes-install-dir\identity\config
The javaes-install-dir variable represents the Java ES 5 installation directory. The default value is C:\Program Files\Sun\JavaES5.
After installation, it is recommended that you change the password for puser and dsameuser, but do not use the same password that you used for amadmin or amldapuser. To change the puser or dsameuser password, use the ampassword utility:
The ampassword --admin (or -a) option changes the password for dsameuser. (This option does not change the amadmin password.)
The ampassword --proxy (or -p) option changes the password for puser.
Changing the puser or dsameuser password depends on your deployment.
If Access Manager is deployed on a single host server:
Use the ampassword utility to change the respective password in Directory Server and in the local serverconfig.xml file.
Restart the Access Manager web container.
If Access Manager is deployed on multiple host servers:
On the first server, use the ampassword utility to change the respective password in Directory Server and in the local serverconfig.xml file.
Encrypt the new password using the ampassword --encrypt (or -e) option.
On each additional server where Access Manager is deployed, change the password manually in the serverconfig.xml file, using the new encrypted password from Step 2.
On each server where you changed the password, including the first server, restart the Access Manager web container.
For information about the ampassword utility, see the Sun Java System Access Manager 7.1 Administration Reference.
A Policy Agent in the Access Manager Policy Agent 2.2 software set authenticates to Access Manager using a user name and password stored in its AMAgent.properties file. The process is similar but slightly different for Web Agents and J2EE Agents.
A Web Agent uses the following properties in the AMAgent.properties file to store its user name and password used to authenticate to Access Manager:
com.sun.am.policy.am.username contains the name of the user that the Web Agent uses to login to Access Manager. The default name is UrlAccessAgent.
com.sun.am.policy.am.password contains the encrypted password of the user that the Web Agent uses to login to Access Manager. The password must be encrypted using the crypt_util utility.
When an Access Manager instance is initially configured, the Java ES installer or the amconfig script creates the amService-UrlAccessAgent user in the top-level realm with the same password as the amldapuser user.
By default, all Web Agents use the same user name and password to authenticate to an Access Manager instance. To improve security and to allow each Web Agent to use a unique name and password, you can create an agent profile in the Access Manager Administration Console for a Web Agent to use for authentication. For more information, see Using an Agent Profile for Authentication.
A J2EE Agent communicates with Access Manager with a user name (agent ID) and password through an agent profile created in the Access Manager Administration Console. After the agent profile is created, the J2EE Agent then uses the following properties in its AMAgent.properties file to store the user name (agent ID) and password:
com.sun.identity.agents.app.username contains the user name (agent ID) that the J2EE Agent uses to login to Access Manager.
com.iplanet.am.service.secret contains the encrypted password of the user name (agent ID) that the J2EE Agent uses to login to Access Manager. The password must be encrypted using the agentadmin utility with the --encrypt option.
See the next section for information about agent profiles.
To authenticate to Access Manager, a J2EE Agent requires that you create an agent profile in the Access Manager Administration Console. A Web Agent can also use an agent profile, which allows each Web Agent to have a unique user name (agent ID) and password. For the steps to create an agent profile, see the Access Manager Console online Help.
An agent profile also allows you to change the password and user name (agent ID) for a Policy Agent, as required by your deployment. To change a password and user name (if required), follow these general steps:
Log in to the Access Manager Console as the Access Manager administrator (amadmin).
In the agent profile for the Policy Agent, change the password and user name (agent ID), if required. Save the profile.
Encrypt the new agent password from Step 2 using the crypt_util utility for Web Agents or the agentadmin utility with the --encrypt option for J2EE Agents.
Set the following properties in the Policy Agent's AMAgent.properties file:
For Web Agents: Set the com.sun.am.policy.am.password property to the new encrypted password from Step 3. If you also changed the user name (agent ID), set the com.sun.am.policy.am.username property to the new user name (agent ID) from Step 2.
For J2EE Agents: Set the com.iplanet.am.service.secret property to the new encrypted password from Step 3. If you also changed the user name (agent ID), set the com.sun.identity.agents.app.username property to the new user name (agent ID) from Step 2.
Restart the Web Agent web container for the new password (and user name if you changed it) to take effect.
For more detailed information about creating and configuring agent profiles and encrypting passwords, see the Access Manager Policy Agent 2.2 documentation collection:
http://docs.sun.com/coll/1322.1
If the Anonymous module is enabled, anonymous users can log into Access Manager without providing a password. The default anonymous user is anonymous, but you can change this name or define a list of anonymous users by setting the following realm attributes in the Access Manager Administration Console:
Valid Anonymous Users specifies a list of user IDs that you want to have anonymous access.
Default Anonymous User Name allows you to specify a name other than the default value of anonymous. This name is used if the Valid Anonymous User list is empty.
Case Sensitive User IDs specifies that anonymous user IDs must case-sensitive. By default, user IDs are not case-sensitive.
Authentication Level limits anonymous users to specific types of access, such as read and search only. The default value is 0.
These attributes apply to a realm, so you can set different anonymous access attributes to specific realms.
For information about enabling the Anonymous module and creating anonymous users, see the Access Manager Console online Help.
In general, a schema is a set of rules imposed on data that defines how it is stored. Sun Java System Directory Server uses the Lightweight Directory Access Protocol (LDAP) schema to define 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 Sun Java System Directory Server as its data repository, which includes the Access Manager schema that extends the Directory Server schema. When Access Manager is installed, the Access Manager schema, from the ds_remote_schema.ldif and sunone_schema2.ldif files, is integrated with the Directory Server schema. The ds_remote_schema.ldif file defines the LDAP object classes and attributes that are specifically used by Access Manager. The sunone_schema2.ldif file loads the Access Manager LDAP schema object classes and attributes.
You can view the ds_remote_schema.ldif, sunone_schema2.ldif, and other Access Manager LDIF files in the following directories:
Solaris systems: /etc/opt/SUNWam/config/ldif
Linux and HP-UX systems: /etc/opt/sun/identity/config/ldif
Windows systems: javaes-install-dir\identity\config\ldif
The javaes-install-dir variable represents the Java ES 5 installation directory. The default value is C:\Program Files\Sun\JavaES5.
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 about the marker object classes can be found in the Access Manager Developer’s Guide. For information about migrating existing Directory Server data for use with Access Manager, see the Sun Java Access Manager 6 2005Q1 Migration Guide.
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.
By adding the Access Manager sunISManagedOrganization auxiliary class to any entry, Access Manager can manage this entry as if it is an organization. However, 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 the dc and o entries to be organizations, the DIT structure will not be manageable using Access Manager:
The entry at the Access Manager root suffix, however, does not count as one entry. Therefore, in the following example, the DIT structure can be managed by Access Manager:
If you were able 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, because 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 console, both organizations and containers have the same options. You can create subordination or subcontinents, people containers, groups, roles, and users under both of them.
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.
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.
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: