Setting Deployment Goals

You should consider several key factors when planning OpenSSO Enterprise 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 you have in place now may be optimized for your company's current needs. Examine your future needs as well.

The following sections describe some basic functionality you should also consider when planning your OpenSSO Enterprise deployment.

Security

Consider the following options when you are planning for a secure internal and external OpenSSO Enterprise 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.

High Availability

High availability refers to a system or component in the OpenSSO Enterprise environment 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. Successful deployments strive for no single point of failure as well as for continuos availability to its users. Different products achieve availability in different ways. For example, clustering is the use of multiple computers to form a single, highly available system. Clustering is often crucial for the Sun Directory Server data store. A clustered multi-master replication (MMR) server pair can increase the availability of each master instance by ensuring availability.

In an OpenSSO Enterprise deployment that meets the minimal requirements, the single points of failure might include:

• OpenSSO Enterprise web container

• Directory Server

• Java^TM Virtual Machine (JVM)

• Directory Server hard disk

• OpenSSO Enterprise hard disk

• Policy agents

Planning for high availability centers around backup and failover processing as well as data storage and access. OpenSSO Enterprise provides session failover and SAML assertion failover functionality. 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. A new application program that has not been thoroughly tested is likely to become a frequent point-of-breakdown in a production system.

Scalability

Horizontal scaling is achieved in the OpenSSO Enterprise environment 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.

Dedicated Data Stores

OpenSSO Enterprise requires two data stores. During installation, you must specify the location of each data store. For detailed information, see Chapter 4, Configuring OpenSSO Enterprise Using the GUI Configurator, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Configuration Data Store

The configuration data store contains information about how users are authenticated, which resources users can access, and what information is available to applications after users are given access to resources. You can use the OpenSSO Enterprise configuration store that is automatically embedded in each OpenSSO Enterprise. Or you can use the Sun Directory Server configuration data store.

User Data Store

During OpenSSO Enterprise installation, you must specify which user data store you want to use.

OpenSSO Enterprise User Data Store

Use this option when you want to store user data in the OpenSSO Enterprise user data store.

Other User Data Store

Use this option when you want to store user data in a data store such as Sun Java System Directory Server.

OpenSSO Enterprise uses an identity repository to store user data such as users and groups. You can use Sun Directory Server or a supported LDAPv3 compliant directory server as the identity repository. Use the tables in this section to help you determine which user data store meets your needs.

In the following table, a Policy Subject refers to the “who” part of the policy definition. The Policy Subject specifies the members or entities to which the policy applies. Policy Condition refers to the additional restrictions with which the policy applies. Examples are a specified window of time in a day, a specified IP address, or a specified authentication method.

Table 2–1 Supported Features for Various Directory Servers

OpenSSO Enterprise Feature	Sun Directory Server LDAPv3	Microsoft Active Directory LDAPv3	IBM Tivoli Directory	Generic LDAPv3
User Data Storage	Yes	Yes	Yes	No
Configuration Data Storage	Yes	No	No	No
AMSDK (legacy)	Yes	No	No	No
LDAP Authentication	Yes	Yes	Yes	Yes
Membership Authentication	Yes	No	No	No
AD Authentication	Not Applicable	Yes, with limitations	Not Applicable	Not Applicable
Policy Subjects and Policy LDAP Filter Condition	Yes	Yes	Yes	Yes
Password Reset	Yes (with OpenSSO Enterprise SDK only)	No	No	No
Account Lockout	Yes	No	No	No
Cert Authentication	Yes	Yes	Yes	Yes
MSISDN Authentication	Yes	Yes	Yes	Yes
Data Store Authentication (through LDAPv3 user store configuration)	Yes	Yes	Yes	Yes
User creation with Password and Password Management	Yes	No	Yes	Yes

The following table summarizes the user management operations supported through the IDRepo interface for various user data stores. An interface has been implemented specifically for Sun Directory Server and Microsoft Active Directory. The default implementation of this interface can be used and supported for any LDAPv3 user repository.

Table 2–2 Data Stores and Supported Operations

Feature	Sun Directory Server LDAPv3	Microsoft Active Directory LDAPv3	IBM Tivoli Directory	Generic LDAPv3	AMSDK (Legacy)
Create User	Yes	Yes*	Yes	No	Yes
Modify User	Yes	Yes*	Yes	No	Yes
Delete User	Yes	Yes*	Yes	No	Yes
Create Role	Yes	No	No	No	Yes
Modify Role	Yes	No	No	No	Yes
Delete Role	Yes	No	No	No	Yes
Assign Role	Yes	No	No	No	Yes
Evaluate Role for Membership	Yes	No	No	No	Yes
Create Group	Yes	Yes*	Yes**	No	Yes
Modify Group	Yes	Yes*	Yes**	No	Yes
Delete Group	Yes	Yes*	Yes**	No	Yes
Evaluate Group for Membership	Yes	Yes*	Yes**	No	Yes
Create Agent	Yes	No	No	No	No
Delete Agent	Yes	No	No	No	No
Modify Agent	Yes	No	No	No	No
Federation Attributes	Yes	Yes	Yes	No	Yes

*Some limitations exist, or additional configuration is required.

** See limitations in the next section “Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store.”

Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store

IBM Tivoli Directory Server's groups can be Static, Dynamic, and Nested. However, the OpenSSO Enterprise IDRepo framework (IDRepo DataStore) supports only the Static group. A Static group defines each member individually using either of the following:

• Structural ObjectClass: groupofNames, groupOfUniqueNames, accessGroup, or accessRole

• Auxiliary ObjectClass: ibm-staticgroup or ibm-globalAdminGroup

A Static group using the Structural ObjectClass groupOfNames and groupOfUniqueNames requires at least one member for ObjectClass groupOfNames or one uniquemember for groupOfUniqueNames. The Static group using the ObjectClass ibm-staticgroup does not have this requirement. The ObjectClass ibm-staticgroup is the only ObjectClass for which members are optional; all other object classes require at least one member.

OpenSSO Enterprise supports only one ObjectClass for groups. If you choose a type of group with an ObjectClass that requires at leas one member, then a user value must be present. This user will automatically be added to the group when a group is created. You can remove this user from the group afterward if you don't want this user to be a member of the group.

The value for the filter for searching of groups must the value specified by the chosen LDAP Group ObjectClass.

Most IBM Tivoli groups require at least one member when the group is created. When a group is created using the OpenSSO Enterprise console, no users are assigned to the group by default. Since IBM Tivoli has this restriction, when a group is created, the default user or member cn=auser1,dc=opensso,dc=java,dc=net is always automatically created and added to the group.

Additional Information for Determining Which User Data Store to Use

• Account Lockout locks a user account based on the policies defined in the Directory Server.

  For example, the user account can be locked when a specified number of login failures occurs.

• The key difference between using a policy LDAP subject and the IDRepo interface subject is that policy LDAP subjects don't provide caching and notification updates. The AMIdentity Subject does provide caching an notification updates.

  The policy LDAP subjects provide LDAP Organization, Role (if Sun Directory Server), Group, and User subjects to evaluate membership of a user and determine if the user belongs to one of these subjects. The same result can be obtained using the Identity Repository (IDRepo) interface subject named AMIdentity Subject. This interface subject was introduced when the product was named Access Manager 7.0. You can develop a policy subject for a JDBC user store. Authentication also supports the JDBC repository through the JDBC authentication module.

• The IDRepo interface provides basic user management features for user, group, role, and OpenSSO Enterprise policy agent entities.

  This interface enables OpenSSO Enterprise to support any user repository through the development of new plug-ins. Although limited to Sun Directory Server, Microsoft Active Directory, and IBM Tivoli Directory today, the IDRepo interface could potentially be expanded to include any LDAPv3 directory server such as OpenLDAP or Novel Directory for JDBC, flat files, and so forth.

• Prior to Access Manager 7.0, user management was supported using Access Manager object classes and attributes in addition to using specific features from Sun Directory Server. This support still exists through the legacy AMSDK interface. But this support is deprecated and will be removed future releases.

Notification Support for the User Data Store

The data change in the directory server must be propagated to OpenSSO Enterprise in a timely manner to ensure that OpenSSO Enterprise represents the correct data. The data in OpenSSO Enterprise is updated two ways. One way is by receiving notifications from the directory servers, and the other way is by polling the directory servers. For notification, directory servers typically provide persistent search notifications which OpenSSO Enterprise subscribes to. For polling, OpenSSO Enterprise provides configurable parameters to specify the intervals. OpenSSO Enterprise supports persistent search notifications with Sun Directory Server, Microsoft Active Directory, and IBM Tivoli Directory.