Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Chapter 2 Building the Deployment Architecture

A deployment architecture identifies the software components needed to meet your company's enterprise requirements, showing the interrelationships among the components. This chapter provides an overview of a typical OpenSSO Enterprise environment, and the technical requirements you need to consider as you plan your OpenSSO Enterprise deployment architecture.

The following topics are contained in this chapter:

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.

Examining a Single Sign-On Deployment Example

The most basic OpenSSO Enterprise deployment is designed to achieve single sign-on in a secure, highly-available, and scalable environment that includes dedicated configuration and user data stores. Keep these goals in mind as you build your deployment architecture.

Use the following deployment example to get a sense of how you can map your enterprise requirements to a deployment architecture.

Identifying the Major Components

The following figure illustrates the most basic deployment architecture for OpenSSO Enterprise in single sign-on environment. A list of the components that comprise the architecture follows.

Figure 2–1 Single Sign-On Deployment Architecture Example

Illustrates where the components will be situated
when the deployment is complete and optional firewalls.

Sun OpenSSO Enterprise

Two instances of OpenSSO Enterprise provide the core functionality. Each instance is configured with its own embedded configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more. User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server.

Distributed Authentication User Interface

The Distributed Authentication User Interface is a component of OpenSSO Enterprise that provides a thin presentation layer for user authentication. During user authentication, the Distributed Authentication User Interface interacts with OpenSSO Enterprise to retrieve credentials from the user data store, thus protecting the OpenSSO Enterprise servers from direct user access. The Distributed Authentication User Interface does not directly interact with the user data store.

Sun Java System Directory Server

Two instances of Directory Server provide storage for the OpenSSO Enterprise user data. Both instances of Directory Server are masters that engage in multi-master replication. Multi-master replication allows data to be synchronized in real time between two directories, providing high availability to the OpenSSO Enterprise layer.

Sun OpenSSO Enterprise Policy Agents 3.0

Policy agents are used to restrict access to hosted content or applications. The policy agents intercept HTTP requests from external users and redirect the request to OpenSSO Enterprise for authentication. Web policy agents protect any resources under the doc root of the web container. J2EE policy agents protect a variety of hosted J2EE applications; in this deployment, agentsample is used. The agents communicate with the OpenSSO Enterprise instances through one of two configured load balancers.

Protected Resource Host Machines

The protected resources host machines contain the content for which access is restricted. Towards this end, web servers, application servers and policy agents will be installed. Two load balancers are configured in front of the host machines to balance traffic passing through the policy agents.

Sun Java System Message Queue

OpenSSO Enterprise uses two instances of Message Queue to form a cluster for distributing client connections and delivering messages. The Berkeley Database by Sleepycat Software, Inc. is the session store database. When an instance of OpenSSO Enterprise goes down and session failover is enabled, the user's session token can be retrieved from one of the Message Queues by the available instance of OpenSSO Enterprise. This ensures that the user remains continuously authenticated, allowing access to the protected resources without having to reauthenticate.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are configured for simple persistence and deployed as follows:

Distributed Authentication User Interface Load Balancer. This external-facing load balancer exposes the remote, web-based Distributed Authentication User Interface for user authentication and self-registration.

OpenSSO Enterprise Load Balancer. This internal-facing load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.

J2EE Policy Agents Load Balancer. The load balancer in front of the J2EE policy agents installed on the Protected Resource machines provides round-robin load balancing and a single virtual server by balancing traffic passing through the agents.

Web Policy Agents Load Balancer. The load balancer in front of the web policy agents installed on the Protected Resource machines provides round-robin load balancing and a single virtual server by balancing traffic passing through the agents.

Directory Server Load Balancer. The load balancer in front of the Directory Server instances provide round-robin load balancing and a single virtual Directory Server host name for the instances of OpenSSO Enterprise. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.

For detailed instructions on how to deploy these components, see Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0.

Designing the Single Sign-On Deployment Architecture

Once you've identified the major components you need in your environment, you can build your deployment architecture to map to your enterprise needs. In this deployment example, the deployment architecture is designed to meet the goals of the most basic OpenSSO Enterprise single sign-on environment:

All components (including installations of OpenSSO Enterprise and Directory Server, the Distributed Authentication User Interface, and policy agents) are redundant to achieve high availability.
All components use load-balancing for session failover and high performance.
Each instance of OpenSSO Enterprise is installed with an embedded configuration data store.
Each instance of Directory Server contains am-users to serve as the user data store.
The environment is configured for system failover capability, ensuring that when one instance of OpenSSO Enterprise goes down, requests are redirected to the second instance.
The environment is configured for session failover capability. Session failover ensures that when the instance of OpenSSO Enterprise where the user's session was created goes down, the user's session token can still be retrieved from a backend session database. Thus, the user is continuously authenticated, and does not have to log into the system again unless the session is invalidated as a result of logout or session expiration.
Communications to the OpenSSO Enterprise load balancer, to the Distributed Authentication User Interface load balancer, and to the Directory Server load balancer are in Secure Sockets Layer (SSL).
Policy agents are configured with a unique agent profile to authenticate to OpenSSO Enterprise.
The Distributed Authentication User Interface uses a custom user profile to authenticate to OpenSSO Enterprise instead of the default amadmin or UrlAccessAgent.

Examining a SAMLv2 Identity Federation Deployment Example

In a deployment configured for communication using SAMLv2, a Service Provider and an Identity Provider must be created within a circle of trust. The circle of trust enables business providers to easily conduct cross-network transactions for an individual while protecting the individual's identity.

Use the following deployment example to get a sense of how you can map your enterprise requirements to a SAMLv2 Identity Federation deployment architecture.

Identifying the Major Components

Identity Provider Deployment

An identity provider specializes in providing authentication services. As the administrating service for authentication, an identity provider maintains and manages identity information. It establishes trust with a service provider in order to exchange user credentials, enabling single sign-on between the providers. Authentication by an identity provider is honored by all service providers with whom the identity provider is partnered. The following image illustrates the identity provider architecture in this deployment.

Figure 2–2 Identity Provider Deployment Architecture

Illustrates where the identity provider components
will be situated

The identity provider domain in this deployment is idp-example.com. The identity provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be transferred to another application in a different domain. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAMLv2 without having to deal with federation protocol and processing.

The following list of components will be installed and configured in the Identity Provider environment.

Sun OpenSSO Enterprise

Two instances of OpenSSO Enterprise provide the core functionality. Each instance is created with a configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more. Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.

User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server.

Sun Java System Directory Server

Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are configured for simple persistence and deployed as follows:

OpenSSO Enterprise Load Balancer.

This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.
Directory Server Load Balancer.

The load balancer in front of the Directory Server instances provide round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.

Service Provider Deployment

A service provider offers web-based services to an identity. This broad category can include portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, governmental agencies, and other organizations that consume identity information for purposes of access. The following figure illustrates the Service Provider architecture in this deployment.

Figure 2–3 Service Provider Deployment Architecture

Illustrates where the service provider components
will be situated

The service provider domain in this deployment is sp-example.com. The service provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be received from the identity provider. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAMLv2 without having to deal with federation protocol and processing.

The following list of components will be installed and configured using the procedures documented in Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0.

Sun OpenSSO Enterprise

Sun Java System Directory Server

Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.

Sun Java System Application Server

Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are deployed as follows:

OpenSSO Enterprise Load Balancer

This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.
Directory Server Load Balancer

The load balancer in front of the Directory Server instances provides round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.

Sun OpenSSO Enterprise Policy Agents

Protected Resource Host Machine

The protected resource host machine contains the content for which access is restricted. BEA WebLogic Server and a J2EE policy agent is installed. Sun Java System Web Server a web policy agent is also installed. Additionally, a sample JSP is installed to act as the legacy application for purposes of demonstrating the Secure Attribute Exchange feature.

For step‐by‐step instructions for deploying these components as illustrated in this chapter, see Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0.

Designing the SAMLv2 Identity Federation Architecture

Once you've identified the major components you need in the Service Provider and Identity Provider environments, you can build your deployment architecture to map to your enterprise needs. In this deployment example, the deployment architecture is designed to achieve the most basic OpenSSO Enterprise circle of trust. The architecture is designed to meet the following enterprise requirements:

All instances of OpenSSO Enterprise are deployed behind a load balancer for high-availability.
Instances of OpenSSO Enterprise acting as an identity provider are configured to work with instances of Sun Directory Server configured as the user data store.
XML Signing is enabled for all SAMLv2 protocols.
The SAMLv2 URL end points are exposed through load balancers with SSL termination and regeneration configuration.
A web policy agent and a J2EE policy agent are deployed in front of the service provider instances of OpenSSO Enterprise; the policy agents work in single sign-on mode only.

Designing the Deployment Architecture

Once you've designed your basic deployment architecture, then you can determine which additional OpenSSO Enterprise features you want to deploy. The chapters in Part II of this manual are designed to help you determine which OpenSSO Enterprise features are suitable for your enterprise. Each chapter in Part II contains the following:

Brief overview of an OpenSSO Enterprise feature
Diagram depicting the feature's role in a deployment example
Diagram illustrating how the feature works
High-level configuration requirements
Dependencies, constraints, benefits and tradeoffs you should consider
Typical business use cases

Once you've developed a deployment architecture that includes the OpenSSO Enterprise features you need, you can proceed to develop your detailed implementation plan.