test

Sun OpenSSO Enterprise 8.0 Technical Overview

Part I An Overview of Sun OpenSSO Enterprise 8.0

This part of the Sun OpenSSO Enterprise 8.0 Technical Overview contains introductory material concerning Sun OpenSSO Enterprise 8.0 (OpenSSO Enterprise). It includes the following chapters:

Chapter 1 Introducing OpenSSO Enterprise

Sun OpenSSO Enterprise 8.0 (OpenSSO Enterprise) integrates authentication and authorization services, single sign-on (SSO), and open, standards-based federation protocols (including the Liberty Alliance Project specifications, WS-Federation and Security Assertion Markup Language [SAML]) to provide a comprehensive solution for protecting network resources by preventing unauthorized access to web services, applications and web content, and securing identity data. This introductory chapter contains a high-level description of OpenSSO Enterprise and what it does. It contains the following sections:

What is OpenSSO Enterprise?

OpenSSO Enterprise is a single product that combines the features of Sun Java™ System Access Manager, Sun Java System Federation Manager, and the Sun Java System SAML v2 Plug-in for Federation Services. Additionally, it is enhanced with new functionality developed specifically for this release. OpenSSO Enterprise provides access management by allowing the implementation of authentication, policy-based authorization, federation, SSO, and web services security from a single, unified framework. The core application is delivered as a simple web archive (WAR) that can be easily deployed in a supported web container.

Note –

OpenSSO Enterprise is Sun Microsystems' commercial distribution of the open source code available at OpenSSO.

To assist the core application, policy agents, the Client SDK, and (possibly) other disparate pieces must be installed remotely and be able to communicate with the OpenSSO Enterprise server. See What Does OpenSSO Enterprise Do? for a high-level picture of the deployment architecture and Chapter 2, Examining OpenSSO Enterprise for more specific information.

What Does OpenSSO Enterprise Do?

The following types of interactions occur daily in a corporate environment.

For each of these transactions, the company must determine who is allowed to view the information or use the application. Some information such as product descriptions and advertising can be made available to everyone in a public online catalog. Other information such as accounting and human resources data must be restricted to employees only. And other sensitive information such as pricing models and employee insurance plans is appropriate to share only with partners, suppliers, and employees. This need for access determination is met by Sun OpenSSO Enterprise, an access management product with authentication, authorization, and single sign-on (SSO) services provided out of the box.

When a user or an external application requests access to content stored on a company’s server, a policy agent (available in a separate download and installed on the same machine as the resource you want to protect) intercepts the request and directs it to OpenSSO Enterprise which, in turn, requests credentials (such as a username and password in the case of a user) for authentication. If the credentials returned match those stored in the appropriate identity data store, OpenSSO Enterprise determines that the user is authentic. Following authentication, access to the requested content is determined by the policy agent which evaluates the policies associated with the authenticated identity. Policies are created using OpenSSO Enterprise and identify which identities are allowed to access a particular resource, specifying the conditions under which this authorization is valid. Based upon the results of the policy evaluation, the policy agent either grants or denies the user access. Figure 1–1 illustrates a high-level deployment architecture of OpenSSO Enterprise.

Figure 1–1 High-level Deployment Architecture of OpenSSO Enterprise

This high-level deployment architecture illustrates how OpenSSO Enterprise controls access among customers, employees, and administrators.

What Are the Functions of OpenSSO Enterprise?

The following sections contain an overview of the functions of OpenSSO Enterprise.

Access Control

OpenSSO Enterprise manages authorized access to network services and resources. By implementing authentication and authorization, OpenSSO Enterprise (along with an installed policy agent) ensures that access to protected resources is restricted to authorized users. In a nutshell, a policy agent intercepts a request for access to a resource and communicates with OpenSSO Enterprise to authenticate the requestor. If the user is successfully authenticated, the policy agent then evaluates the policies associated with the requested resource and the user to determine if the authenticated user is authorized to access the resource. If the user is authorized, the policy agent allows access to the resource, also providing identity data to the resource to personalize the interaction. For more information on access control, see Core Services and Part II, Access Control Using OpenSSO Enterprise.

Federation Management

With the introduction of federation protocols into the process of access management, identity information and entitlements can be communicated across security domains, spanning multiple trusted partners. By configuring a circle of trust and defining applications and services as providers in the circle (either identity providers or service providers), users can opt to associate, connect or bind the various identities they have configured locally for these providers. The linked local identities are federated and allow the user to log in to one identity provider site and click through to an affiliated service provider site without having to reauthenticate; in effect, single sign-on (SSO). OpenSSO Enterprise supports several open federation technologies including the Security Access Markup Language (SAML) versions 1 and 2, WS-Federation, and the Liberty Alliance Project Identity Federation Framework (Liberty ID-FF), therefore encouraging an interoperable infrastructure among providers. For more information on federation management, see Core Services and Part III, Federation Management Using OpenSSO Enterprise.

Web Services Security

A web service is a component service or application that exposes some type of business or infrastructure functionality through a language-neutral and platform-independent, network interface; enterprises might use this web service to build larger service-oriented architectures. In particular, the service defines its interface (for example, the format of the message being exchanged) using the Web Services Description Language (WSDL), and communicates using SOAP and eXtensible Markup Language (XML) messages. The web service client (WSC) communicates with the web service provider (WSP) through an intermediary — usually a firewall or load balancer.

Although web services enable open, flexible, and adaptive interfaces, their openness creates security risks. Without proper security protections, a web service can expose vulnerabilities that might have dire consequences. Hence, ensuring the integrity, confidentiality and security of web services through the application of a comprehensive security model is critical for both enterprises and consumers. A successful security model associates identity data with the web services and creates secure service-to-service interactions. The security model adopted by OpenSSO Enterprise identifies the user and preserves that identity through multiple interactions, maintains privacy and data integrity, uses existing technologies, and logs the interactions. In OpenSSO Enterprise, the following web service security standards are implemented:

The web services security framework uses the Security Token Service and separately installed security agents. For more information on OpenSSO Enterprise web services and web services security, see Core Services and Part IV, The Web Services Stack, Identity Services, and Web Services Security.

Identity Web Services

For some time, OpenSSO Enterprise has provided client interfaces for access to core features and functionality. These interfaces are used by policy agents and custom applications developed by customers. With this release, OpenSSO Enterprise now exposes certain functions as simple identity web services allowing developers to easily invoke them when developing their applications using one of the supported integrated development environment (IDE) products. (The IDE generates the stub code that wraps a call to the web service.) Identity Web Services are available using:

They do not require the deployment of an agent or a proxy and include the following capabilities:

For more information on identity services, see Identity Web Services and Part IV, The Web Services Stack, Identity Services, and Web Services Security.

What Else Does OpenSSO Enterprise Offer?

OpenSSO Enterprise allows for:

Chapter 2 Examining OpenSSO Enterprise

OpenSSO Enterprise provides a pluggable architecture to deliver access management, secure web services, and federation capabilities. This chapter contains information on the internal architecture and features of OpenSSO Enterprise.

The Client/Server Architecture

OpenSSO Enterprise is written in Java, and leverages many industry standards, including the HyperText Transfer Protocol (HTTP), the eXtensible Markup Language (XML), the Security Assertion Markup Language (SAML), and SOAP, to deliver access management, secure web services, and federation capabilities in a single deployment. It consists of client application programming interfaces (a Client Software Development Kit [SDK]), a framework of services that implement the business logic, and service provider interfaces (SPI) that are implemented by concrete classes and can be used to extend the functionality of OpenSSO Enterprise as well as retrieve information from data stores. Figure 2–1 illustrates the client/server architecture of OpenSSO Enterprise.

Figure 2–1 Client/Server Architecture of OpenSSO Enterprise

Multiple layers form the OpenSSO Enterprise architecture.

Each component of OpenSSO Enterprise uses its own framework to retrieve customer data from the plug-in layer and to provide data to other components. The OpenSSO Enterprise framework integrates all of the application logic into one layer that is accessible to all components and plug-ins. The Client SDK and Identity Web Services are installed on a machine remote to the OpenSSO Enterprise server that holds a resource to be protected; they provide remote access to the OpenSSO Enterprise for client applications. (The policy agent, also installed on the remote machine, is basically a client written using the Client SDK and Identity Web Services.) Applications on the remote machine access OpenSSO Enterprise using the Client SDK. Custom plug-in modules are installed on the machine local to OpenSSO Enterprise and interact with the OpenSSO Enterprise SPI to retrieve required information from the appropriate data store and deliver it to the plug-ins and, in turn, the OpenSSO Enterprise framework for processing.

How OpenSSO Enterprise Works

To gain access to a protected resource, the requestor needs to be authenticated and have the authorization to access the resource. When someone (using a browser) sends an HTTP request for access to a protected resource, a policy agent (separately downloaded and installed on the same machine as the resource you want to protect) intercepts the request and examines it. If no valid OpenSSO Enterprise session token (to provide proof of authentication) is found, the policy agent contacts the server which then invokes the authentication and authorization processes. Figure 2–2 illustrates one way in which the policy agents can be situated to protect an enterprise's servers by directing HTTP requests to a centralized OpenSSO Enterprise for processing.

Figure 2–2 Basic OpenSSO Enterprise Deployment

Illustrates how policy agents work with OpenSSO Enterprise to protect an enterprise's web containers.

OpenSSO Enterprise integrates core features such as access control through authentication and authorization processes, and federation. These functions can be configured using the administration console or the ssoadm command line utility. Figure 2–3 is a high-level illustration of the interactions that occur between parties (including the policy agent, browser, and protected application) during authentication and authorization in a OpenSSO Enterprise deployment.

Figure 2–3 OpenSSO Enterprise Authentication and Authorization Interactions

Interactions during OpenSSO Enterprise authentication and authorization.

For more information, see Part II, Access Control Using OpenSSO Enterprise.

Core Services

Services developed for OpenSSO Enterprise generally contain both a server component and a client component. The server component is a simple Java servlet developed to receive XML requests and return XML responses. (The deployment descriptor web.xml defines the servlet name and description, the servlet class, initialization parameters, mappings, and other startup information.) The client component is provided as Java application programming interfaces (API), and in some cases C API, that allow remote applications and other OpenSSO Enterprise services to communicate with and consume the particular functionality.

Each core service uses its own framework to retrieve customer and service data and to provide it to other OpenSSO Enterprise services. The OpenSSO Enterprise framework integrates all of these service frameworks to form a layer that is accessible to all product components and plug-ins. The following sections contain information on the OpenSSO Enterprise core services.

Note –

Many services also provide a public SPI that allows the service to be extended. See the Sun OpenSSO Enterprise 8.0 Developer’s Guide, the Sun OpenSSO Enterprise 8.0 C API Reference for Application and Web Policy Agent Developers, and the Sun OpenSSO Enterprise 8.0 Java API Reference for information.

Authentication Service

The Authentication Service provides the functionality to request user credentials and validate them against a specified authentication data store. Upon successful authentication, it creates a session data structure for the user that can be validated across all web applications participating in an SSO environment. Several authentication modules are supplied with OpenSSO Enterprise, and new modules can be plugged-in using the Java Authentication and Authorization Service (JAAS) SPI.

Note –

The Authentication Service is based on the JAAS specification, a set of API that enables services to authenticate and enforce access controls upon users. See the Java Authentication and Authorization Service Reference Guide for more information.

Components of the Authentication Service include:

The Authentication Service interacts with both the database that stores user credentials (authentication data store) to validate the user, and with the Identity Repository Service plug-ins to retrieve user profile attributes. When the Authentication Service determines that a user’s credentials are genuine, a valid user session token is issued, and the user is said to be authenticated. Figure 2–4 illustrates how the local and remote authentication components interact within a OpenSSO Enterprise deployment.

Figure 2–4 Authentication Service Components Within a OpenSSO Enterprise Deployment

Authentication components within the Authentication Service framework

More information on the architecture of the Authentication Service can be found in the Authentication Service Architecture document on the OpenSSO web site.

Policy Service

Authorization is the process with which OpenSSO Enterprise evaluates the policies associated with an authenticated user’s identity, and determines whether the user has permission to access a protected resource. (A policy defines the rules that specify a user's access privileges to a protected resource.) The Policy Service provides the authorization functionality using a rules-based engine. It interacts with the OpenSSO Enterprise configuration data store, a delegation plug-in (which helps to determine the administrator’s scope of privileges), and Identity Repository Service plug-ins to verify that the user has access privileges from a recognized authority. Policy can be configured using the administration console, and comprises the following:

Figure 2–5 illustrates how the local and remote components of the Policy Service interact within a OpenSSO Enterprise deployment. Note that the PolicyServiceRequestHandler maps to the PolicyRequest XML element.

Figure 2–5 Policy Service Components within a OpenSSO Enterprise Deployment

Policy components within the Policy Service framework

Policy agents are an integral part of authorization. They are programs, available for installation separate from OpenSSO Enterprise, that police the web container which hosts the protected resources. When a user requests access to the protected resource (such as a server or an application), the policy agent intercepts the request and redirects it to the OpenSSO Enterprise Authentication Service. Following authentication, the policy agent will enforce the authenticated user’s assigned policies. OpenSSO Enterprise supports two types of policy agents:

Note –

When policy agents are implemented, all HTTP requests are implicitly denied unless explicitly allowed by the presence of two things:

  1. A valid session

  2. A policy allowing access

    Note –

    If the resource is in the Not Enforced list defined for the policy agent, access is allowed even if there is no valid session.

More information on the architecture of the Policy Service can be found in the Policy Service Architecture document on the OpenSSO web site. For an overview of the available policy agents and links to specific information on installation, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents.

Session Service

The mission of the OpenSSO Enterprise Session Service is to maintain information about an authenticated user's session across all web applications participating in a user session. Additionally, OpenSSO Enterprise provides continuous proof of the user’s identity, enabling the user to access multiple enterprise resources without having to provide credentials each time. This enables the following types of user sessions.

A user session is the interval between the time a user attempts authentication through OpenSSO Enterprise and is issued a session token, and the moment the session expires, is terminated by an administrator, or the user logs out. In what might be considered a typical user session, an employee accesses the corporate benefits administration service. The service, monitored by OpenSSO Enterprise, prompts the user for a username and password. With the credentials OpenSSO Enterprise can authenticate, or verify that the user is who he says he is. Following authentication, OpenSSO Enterprise allows the user access to the service providing authorization is affirmed. Successful authentication through OpenSSO Enterprise results in the creation of a session data structure for the user or entity by the Session Service. Generally speaking, the Session Service performs some or all of the following:

Figure 2–6 illustrates the interactions between the local and remote components of the Session Service within a OpenSSO Enterprise deployment.

Figure 2–6 Session Service Components within a OpenSSO Enterprise Deployment

Interactions between client and OpenSSO Enterprise Session Service components.

Additionally, Figure 2–7 illustrates how the messaging capabilities of Message Queue can be used to push session information to a persistent store based on the Berkeley DataBase (DB). Using OpenSSO Enterprise in this manner enables the following key feature:

Figure 2–7 Session Persistence Deployment Architecture

Session persistence architecture

More information on the architecture of the Session Service can be found in the Session Service Architecture document on the OpenSSO web site. For more information on session failover, see Chapter 8, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Logging Service

When a user logs in to a resource protected by OpenSSO Enterprise, the Logging Service records information about the user's activity. The common Logging Service can be invoked by components residing on the same server as OpenSSO Enterprise as well as those on the client machine, allowing the actual mechanism of logging (such as destination and formatting) to be separated from the contents which are specific to each component. You can write custom log operations and customize log plug-ins to generate log reports for specific auditing purposes.

Administrators can control log levels, authorize the entities that are allowed to create log entries and configure secure logging (the latter for flat files only). Logged information includes the name of the host, an IP address, the identity of the creator of the log entry, the activity itself, and the like. Currently, the fields logged as a log record are controlled by the Configurable Log Fields selected in the Logging Configuration page located under the System tab of the OpenSSO Enterprise console. The Logging Service is dependent on the client application (using the Logging APIs) creating a programmatic LogRecord to provide the values for the log record fields. The logging interface sends the logging record to the Logging Service which determines the location for the log record from the configuration. A list of active logs can also be retrieved using the Logging API. Figure 2–8 illustrates the interactions between the local and remote components of the Logging Service in a OpenSSO Enterprise deployment.

Figure 2–8 Logging Service Components within a OpenSSO Enterprise Deployment

Components within the Logging Service interactions

Caution – Caution –

Generally speaking, writing log records can be done remotely, using the Client SDK, but anything involving the reading API can only be done on the machine on which OpenSSO Enterprise is installed. Using the reading API uses a great deal of system resources, especially when database logging is involved.

Logs can be written to flat files or to one of the supported databases (Oracle and MySQL). See Chapter 15, Recording Events with the Logging Service for more information.

Identity Repository Service

The Identity Repository Service allows OpenSSO Enterprise to integrate an existing user data store (such as a corporate LDAP server) into the environment. The Identity Repository Service is able to access user profiles (as well as group and role assignments if supported) and is capable of spanning multiple repositories — even of different types. The Identity Repository Service is configured per realm under the Data Stores tab and its main functions are:

Access to the Identity Repository Service is provided by the com.sun.identity.idm Java package. The AMIdentityRepository class represents a realm that has one or more identity repositories configured and provides interfaces for searching, creating and deleting identities. The AMIdentity class represents an individual identity such as a user, group or role and provides interfaces to set, modify and delete identity attributes and assign and unassign services. IdRepo is an abstract class that contains the methods that need to be implemented by plug-ins when building new adapters for repositories not currently supported. The current implementation supports Sun Java System Directory Server, IBM Tivoli Directory and Microsoft Active Directory. The following diagram illustrates the design of the Identity Repository Service.

Figure 2–9 Identity Repository Service Design

Design of Identity Repository Service

Note –

Administrator roles are also defined by the Identity Repository Service. (This is currently available only when the Sun Directory Server With FAM Core Services schema is loaded.) For example, the Realm Administrator can access all data in all configured realms while the Subrealm Administrator can access data only within the specified realm. For more information, see Sun OpenSSO Enterprise 8.0 Deployment Planning Guide. For information on realm privileges, see Chapter 2, Organizing Data within Realms, in Sun OpenSSO Enterprise 8.0 Administration Guide.

Federation Services

OpenSSO Enterprise provides an open and extensible framework for identity federation and associated web services that resolve the problems of identity-enabling web services, web service discovery and invocation, security, and privacy. Federation Services are built on the following standards:

Federation Services allows organizations to share identity information (for example, which organizations and users are trusted, and what types of credentials are accepted) securely. Once this is enabled securely, federating identities is possible — allowing a user to consolidate the many local identities configured among multiple service providers. With one federated identity, the user can log in at one identity provider’s site and move to an affiliated site without having to re-establish identity. Figure 2–10 illustrates the interactions between local and remote components of the Federation Services in a OpenSSO Enterprise deployment.

Figure 2–10 Federation Services Components within a OpenSSO Enterprise Deployment

How Federation Services interact with the OpenSSO Enterprise deployment

More information on the Federation Services can be found in the Open Federation Architecture and the Federation Use Case documentation on the OpenSSO web site. Also, see Part III, Federation Management Using OpenSSO Enterprise in this book.

Web Services Stack

The OpenSSO Enterprise Web Services Stack follows a standardized way of integrating web-based applications using XML, SOAP, and other open standards over an Internet Protocol (IP) backbone. They enable applications from various sources to communicate with each other because they are not tied to any one operating system or programming language. Businesses use web services to communicate with each other and their respective clients without having to know detailed aspects of each other's IT systems. OpenSSO Enterprise provides web services that primarily use XML and SOAP over HTTP. These web services are designed to be centrally provided in an enterprise's network for convenient access by client applications. OpenSSO Enterprise implements the follow web service specifications.

The following table lists the OpenSSO Enterprise web services.

Table 2–1 OpenSSO Enterprise Web Services Stack

Web Service Name 

Description 

Authentication Web Service

Provides authentication to a web service client (WSC), allowing the WSC to obtain security tokens for further interactions with other services at the same provider. Upon successful authentication, the final Simple Authentication and Security Layer (SASL) response contains the resource offering for the Discovery Service. 

Discovery Service

A web service that allows a requesting entity, such as a service provider, to dynamically determine a principal's registered attribute provider. Typically, a service provider queries the Discovery Service, which responds by providing a resource offering that describes the requested attribute provider. The implementation of the Discovery Service includes Java and web-based interfaces. 

Liberty Personal Profile Service

A data service that supports storing and modifying a principal's identity attributes. Identity attributes might include information such as first name, last name, home address, and emergency contact information. The Liberty Personal Profile Service is queried or updated by a WSC acting on behalf of the principal. 

Security Token Service

The centralized Security Token Service that issues, renews, cancels, and validates security tokens is also used in tandem with the Web Services Security framework. 

SOAP Binding Service

A set of Java APIs implemented by the developer of a Liberty-enabled identity service. The APIs are used to send and receive identity-based messages using SOAP, an XML-based messaging protocol. 

OpenSSO Enterprise uses both XML files and Java interfaces to manage web services and web services configuration data. A OpenSSO Enterprise XML file is based on the structure defined in the OpenSSO Enterprise Document Type Definition (DTD) files located in path-to-context-root/opensso/WEB-INF. The main sms.dtd file defines the structure for all OpenSSO Enterprise service files (located in path-to-context-root/opensso/WEB-INF/classes).

Caution – Caution –

Do not modify any of the DTD files. The OpenSSO Enterprise API and their internal parsing functions are based on the default definitions and alterations to them may hinder the operation of the application.

For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.

Web Services Security and the Security Token Service

In message security, security information is applied at the message layer and travels along with the web services message. Message layer security differs from transport layer security in that it can be used to decouple message protection from message transport so that messages remain protected after transmission, regardless of how many hops they travel on. This message security is available as Web Services Security in OpenSSO Enterprise and through the installation of an authentication agent. Web Services Security is the implementation of the WS-Security specifications and the Liberty Alliance Project Identity Web Services Framework (Liberty ID-WSF). Web Services Security allows communication with the Security Token Service to insert security tokens in outgoing messages and evaluate incoming messages for the same. Towards this end, authentication agents based on the Java Specification Request (JSR) 196 must be downloaded and installed on the web services client (WSC) machine and the web services provider (WSP) machine.

Note –

JSR 196 agents can be used only on Sun Java System Application Server or Glassfish web containers.

To secure web services communications, the requesting party must first be authenticated with a security token which is added to the SOAP header of the request. Additionally, the WSC needs to be configured to supply message level security in their SOAP requests and the WSP needs to be configured to enable message level security in their SOAP responses. Figure 2–11 illustrates the components used during a secure web services interaction.

Figure 2–11 Web Services Security Components within a OpenSSO Enterprise Deployment

Web Services Security components within a OpenSSO Enterprise deployment

Note –

The stand alone applications can directly invoke the interfaces (secure request by WSC, and validate response by WSP) from the WS-Security Library and establish message-level end-to-end web service security. Standalone Java applications do not need the WS-Security Provider Plugin.

For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.

Identity Web Services

OpenSSO Enterprise contains client interfaces for authentication, authorization, session management, and logging in Java, C, and C++ (using a proprietary XML and SOAP over HTTP or HTTPs communication). These interfaces are used by policy agents and custom applications. Development using these interfaces, though, is labor-intensive. Additionally, the interfaces cause dependencies on OpenSSO Enterprise. Therefore, OpenSSO Enterprise has now implemented simple interfaces that can be used for:

Note –

Identity Web Services also interact with the Logging Service to audit and record Identity Web Services interactions.

These Identity Services are offered using either SOAP and the Web Services Description Language (WSDL) or Representational State Transfer (REST). With SOAP Identity Web Services, you point an integrated development environment (IDE) application project to the appropriate URL and generate the stub code that wraps the function calls to the services. (You can also use wscompile.) With REST Identity Web Services, no coding is necessary. It works right out of box.

Note –

OpenSSO Enterprise supports Eclipse, NetBeans, and Visual Studio®.

When Identity Web Services have been implemented, a user interacts with the application which calls the identity repository to retrieve user profile data for authentication and personalization, the configuration data store to retrieve policy data for authorization, and the audit repository for log requests. The application authenticates, authorizes, audits, and finally creates personalized services for the user by calling either the SOAP/WSDL or REST Identity Web Service as provided by OpenSSO Enterprise.

Figure 2–12 Basic Identity Web Services Process

Illustration of Identity Web Services process

For more information, see Part IV, The Web Services Stack, Identity Services, and Web Services Security.

Global Services

Global services take configuration values and perform functions for OpenSSO Enterprise on a global basis. The following table lists the global services with brief descriptions.

Table 2–2 Global OpenSSO Enterprise Services

Service 

What it Does 

Common Federation Configuration

Contains configuration attributes for Federation Services. 

Liberty ID-FF Service Configuration

Contains configuration attributes for the Liberty Alliance Project Identity Federation Framework. 

Liberty ID-WSF Security Service

Contains configuration attributes for the Liberty Alliance Project Identity Web Services Framework. 

Liberty Interaction Service

Contains configuration attributes for the Liberty Alliance Project Interaction Service — used to get consent from an owner to expose data, or to get additional data. 

Multi-Federation Protocol

Contains configuration attributes for multi-federation protocol circles of trust. 

Password Reset

Contains configuration attributes for the Password Reset Service. 

Policy Configuration

Contains configuration attributes for the Policy Service. 

SAML v2 Service Configuration

Contains configuration attributes for the SAML v2 interactions. 

SAML v2 SOAP Binding

Contains configuration attributes for SAML v2 SOAP Binding Service. 

Security Token Service

Contains configuration attributes for the Security Token Service. 

Session

Contains configuration attributes for the Session Service. 

User

Contains configuration attributes for user profiles. 

Realms

A realm is the unit that OpenSSO Enterprise uses to organize configuration information. Authentication properties, authorization policies, data stores, subjects (including a user, a group of users, or a collection of protected resources) and other data can be defined within the realm. The data stored in a realm can include, but is not limited to:

You create a top-level realm when you deploy OpenSSO Enterprise. The top-level realm (by default opensso) is the root of the OpenSSO Enterprise instance and contains OpenSSO Enterprise configuration data; it cannot be changed after it is created. In general, you should use the default root realm to configure identity data stores, and manage policies and authentication chains. During deployment, OpenSSO Enterprise creates a Realm Administrator who can perform all operations in the configured root realm, and a Policy Administrator who can only create and manage policies.

All other realms are configured under the opensso realm. These sub-realms may contain other sub-realms and so on. Sub-realms identify sets of users and groups that have different authentication or authorization requirements. The use of sub-realms should be restricted to the following two scenarios.

  1. Application Policy Delegation The use case for this is when you need to have different Policy Administrators to create policies for a sub-set of resources. For example, let's assume a sub-realm is created and named Paycheck. This sub-realm is configured with a policy referral from the root realm for configuring protection of resources starting with https://paycheck.sun.com/paycheck. Within the Paycheck sub-realm, a Paycheck Administrator role or group is created and assigned Policy Administration privileges. These administrators are now able to login to the sub-realm and create policies for their applications. By default, the sub-realm inherits the same configuration data store and authentication chains configured for its parent; if these configurations change in the parent, a corresponding change would be needed in the sub-realm. Additionally, all users will still log in to the root realm for access to all the applications. The sub-realm is primarily for the Policy Administrator to manage policies for the application. An educated guess on the number of sub-realms that can be supported would be about 100.

  2. ISP/ASP/Silo The use case for this scenario is when each sub-realm is to have its own set of identity data stores, authentication chains, and policies. Ideally the only common thread between the root and the sub-realm would be the referral policy created in the root realm to delegate a set of resources to the sub-realm. Users would not be able to log in to the root realm (unless they are a member) but would have to authenticate to their sub-realm. Also, agents would have to be configured to redirect user authentication to the particular sub-realm. With regards to performance, the most resource consuming component would be when persistent searches created by the data stores connect to the same directory. An educated guess on the number of sub-realms that can be supported would be about 50.

The OpenSSO Enterprise framework aggregates realm properties as part of the configuration data. Figure 2–13 illustrates how configuration data can use a hierarchy of realms to distribute administration responsibilities. Region 1, Region 2, and Region 3 are realms; Development, Operations, and Sales are realms sub to Region 3.

Figure 2–13 Realm Hierarchy for Configuration Data

This graphic illustrates how access information can be grouped by region and by company functions.

Note –

OpenSSO Enterprise 8.0 supports the Sun Java System Access Manager Legacy mode (which contains no realms) with a provided interface.

Additional Components

The following sections provide information on additional components used in a OpenSSO Enterprise deployment.

Data and Data Stores

OpenSSO Enterprise services need to interact with a number of different data stores. The following distinct repositories can be configured.

A common LDAP connection pooling facility allows efficient use of network resources. In the simplest demonstration environment, a single LDAP repository is sufficient for all data however, the typical production environment tends to separate configuration data from other data. The following sections contain more specific information.

Configuration Data

The default configuration of OpenSSO Enterprise creates a branch in a fresh installation of a configuration data store for storing service configuration data and other information pertinent to the server's operation. OpenSSO Enterprise components and plug-ins access the configuration data and use it for various purposes including:

OpenSSO Enterprise supports Sun Java System Directory Server and the open source OpenDS as configuration data stores. Flat files (supported in previous versions of the product) are no longer supported but configuration data store failover is — using replication. Figure 2–14 illustrates how configuration data in the configuration data store is accessed.

Figure 2–14 Accessing Configuration Data

How OpenSSO Enterprise access centralized configuration data

Previous releases of Access Manager and Federation Manager stored product configuration data in a property file named AMConfig.properties that was installed local to the product instance directory. This file is deprecated for OpenSSO Enterprise on the server side although still supported for agents on the client side. See the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide for more information.

Configuration data comprises the attributes and values in the OpenSSO Enterprise configuration services, as well as default OpenSSO Enterprise users like amadmin and anonymous. Following is a partial listing of the XML service files that contribute to the data. They can be found in the path-to-context-root/opensso/WEB-INF/classes directory.

Note –

The data in this node branch is private and is mentioned here for information purposes only.

Caution – Caution –

By default, the OpenSSO Enterprise configuration data is created and maintained in the configuration data store apart from any identity data. Although users can be created in the configuration data store this is only recommended for demonstrations and development environments.

For more information, see Configuration Data Store.

Identity Data

An identity repository is a data store where information about users and groups in an organization is stored. User profiles can contain data such as a first name, a last name, a phone number, group membership, and an e-mail address; an identity profile template is provided out-of-the-box but it can be modified to suit specific deployments.

Identity data stores are defined per realm. Because more than one identity data store can be configured per realm OpenSSO Enterprise can access the many profiles of one identity across multiple data repositories. Sun Java System Directory Server with OpenSSO Enterprise Schema, Microsoft Active Directory, IBM Tivoli Directory and the AMSDK data store are the currently supported identity repositories. Plug-ins can be developed to integrate other types of repositories (for example, a relational database). Figure 2–15 illustrates a OpenSSO Enterprise deployment where the identity data and the configuration data are kept in separate data stores.

Figure 2–15 OpenSSO Enterprise Deployment with Two Data Stores

Deployment where identity repository and configuration data repository are kept in separate data stores

Note –

The information in an identity repository is maintained by provisioning products separate from OpenSSO Enterprise. The supported provisioning product is Sun Java System Identity Manager.

OpenSSO Enterprise provides out-of-the-box plug-in support for some identity repositories. Each default plug-in configuration includes details about what operations are supported on the underlying data store. Once a realm is configured to use a plug-in, the framework can instantiate it and execute the operations on the appropriate identity repository. Each new plug-in developed must have a corresponding service management schema defining its configuration attributes. This schema would be integrated as a sub schema into idRepoService.xml, the service management file for the Identity Repository Service that controls the identity data stores available under a realm's Data Stores tab. The following sections contain information on the out-of-the-box plug-ins.

Generic Lightweight Directory Access Protocol (LDAP) version 3

The Generic LDAPv3 identity repository plug-in can reside on an instance of any directory that complies with the LDAPv3 specifications. The underlying directory cannot make use of features that are not part of the LDAP version 3 specification, and no specific DIT structure can be assumed as LDAPv3 identity repositories are simply DIT branches that contain user and group entries. Each data store has a name that is unique among a realm's data store names, but not necessarily unique across all realms. The com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo class provides the default LDAPv3 identity repository implementation. There are also implementations for Active Directory and IBM Tivoli Directory

LDAPv3 Plug-in for Active Directory

The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of Microsoft® Active Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.

LDAPv3 Plug-in for Tivoli Directory

The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of IBM Tivoli Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.

Sun Directory Server With FAM Core Services

This repository resides in an instance of Sun Java System Directory Server and holds the identity data. This option is available during the initial configuration of OpenSSO Enterprise.

Sun Directory Server With Full Schema (including Legacy)

This repository resides in an instance of Sun Java System Directory Server and holds the configuration data when installing OpenSSO Enterprise in Legacy and Realm mode. This option must be manually configured.

Access Manager Repository Plug-in

The Access Manager Repository can reside only in Sun Java System Directory Server and is used with the Sun Directory Server With Access Manager Schema. During installation, the repository is created in the same instance of Sun Java System Directory Server that holds the configuration data. The Access Manager Repository Plug-in is designed to work with Sun Java System Directory Server as it makes use of features specific to the server including roles and class of service. It uses a DIT structure similar to that of previous versions of Access Manager.

Note –

This is no longer provided out of the box and many pieces are marked for deprecation. The Access Manager Repository is compatible with previous versions of Access Manager.

When you configure an instance of Access Manager in realm mode for the first time, the following occurs:

Note –

The Java Enterprise System installer does not set up an Access Manager Repository when you configure an Access Manager instance in legacy mode. Legacy mode requires an identity repository that is mixed with the Access Manager information tree under a single directory suffix.

Authentication Data

Authentication data contains authentication credentials for OpenSSO Enterprise users. An authentication data store is aligned with a particular authentication module, and might include:

Identity data may include authentication credentials although authentication data is generally stored in a separate authentication repository. For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide.

The bootstrap File

OpenSSO Enterprise uses a file to bootstrap itself. Previously, AMConfig.properties held configuration information to bootstrap the server but now a file named bootstrap points to the configuration data store allowing the setup servlet to retrieve the bootstrapping data. After deploying the OpenSSO Enterprise WAR and running the configuration wizard, configuration data is written to the configuration data store by the service management API contained in the Java package, com.sun.identity.sm. The setup servlet creates bootstrap in the top-level configuration directory. The content in bootstrap can be either of the following:

If more than one URL is present in the file and OpenSSO Enterprise is unable to connect or authenticate to the data store at the first URL, the bootstrapping servlet will try the second (and so on). Additionally, the number sign [#] can be used to exclude a URL as in:


# ldap://ds.samples.com:389/http://owen2.red.sun.com:8080/
opensso?pwd=AQIC5wM2LY4Sfcxi1dVZEdtfwar2vhWNkmS8&embeddedds=
/opensso/opends&basedn=dc=opensso,dc=java,dc=net&dsmgr=
cn=Directory+Manager&dspwd=AQIC5wM2LY4Sfcxi1dVZEdtf
war2vhWNkmS8

Policy Agents

Policy agents are an integral part of SSO and CDSSO sessions. They are programs that police the web container on which resources are hosted. All policy agents interact with the Authentication Service in two ways:

When a user requests access to a protected resource such as a server or an application, the policy agent intercepts the request and redirects it to the OpenSSO Enterprise Authentication Service for authentication. Following this, the policy agent requests the authenticated user's assigned policy and evaluates it to allow or deny access. (A policy defines the rules that specify a user's access privileges to a protected resource.) OpenSSO Enterprise supports two types of policy agents:

Both types of agents are available for you to install as programs separate from OpenSSO Enterprise. Policy agents are basically clients written using the Client SDK and Identity Services.

Note –

All HTTP requests are implicitly denied unless explicitly allowed by the presence of a valid session and a policy allowing access. If the resource is defined in the Not Enforced list for the policy agent, access is allowed even if there is no valid session.

For more information, see J2EE Agent Architecture and Web Agent and C-API Architecture on the OpenSSO web site. For an overview of the available policy agents and links to specific information on installation, see the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents.

Security Agents

Authentication agents plug into web containers to provide message level security for web services, and supports both Liberty Alliance Project token profiles as well as Web Services-Interoperability Basic Security Profiles (WS-I BSP). (A profile defines the HTTP exchanges required to transfer XML requests and responses between web service clients and providers.) Authentication agents use an instance of OpenSSO Enterprise for all authentication decisions. Web services requests and responses are passed to the appropriate authentication modules using standard Java representations based on the transmission protocol. An HTTP Authentication Agent or a SOAP Authentication Agent can be used. For more information, see Web Services Security and the Security Token Service.

OpenSSO Enterprise Tools

Contained within the OpenSSO Enterprise ZIP are ssoAdminTools.zip and ssoSessionTools.zip. The following sections have some information about these tools.

ssoadm Command Line Interface

ssoadm, the command line interface (CLI), provides a second option to administer OpenSSO Enterprise using the command line. For example, ssoadm can be used to create a policy or import and export Liberty ID-FF metadata. ssoadm is the recommended way for batch processing. It is in ssoAdminTools.zip. For more information, see Chapter 6, Installing the OpenSSO Enterprise Utilities and Scripts, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide and Part I, Command Line Interface Reference, in Sun OpenSSO Enterprise 8.0 Administration Reference.

Session Failover Tools

ssoSessionTools.zip contains scripts and binaries for setting up session failover and databases. For more information, see Chapter 8, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Client SDK

Enterprise resources cannot be protected by OpenSSO Enterprise until the OpenSSO Enterprise Client SDK is installed on the machine that contains the resource that you want to protect. (The Client SDK is automatically installed with a policy agent.) The Client SDK allows you to customize an application by enabling communication with OpenSSO Enterprise for retrieving user, session, and policy data. For more information, see Chapter 14, Using the Client SDK, in Sun OpenSSO Enterprise 8.0 Developer’s Guide and the Sun OpenSSO Enterprise 8.0 Java API Reference.

Service Provider Interfaces for Plug-ins

The OpenSSO Enterprise service provider interfaces (SPI) can be implemented as plug-ins to provide customer data to the OpenSSO Enterprise framework for back-end processing. Some customer data comes from external data base applications such as identity repositories while other customer data comes from the OpenSSO Enterprise plug-ins themselves. You can develop additional custom plug-ins to work with the SPI. For a complete list of the SPI, see the Sun OpenSSO Enterprise 8.0 Java API Reference. Additional information can be found in the Sun OpenSSO Enterprise 8.0 Developer’s Guide. The following sections contain brief descriptions.

Authentication Service SPI

The com.sun.identity.authentication.spi package provides interfaces and classes for writing a supplemental authentication module to plug into OpenSSO Enterprise. The com.sun.identity.authentication package provides interfaces and classes for writing a remote client application that can access user data in a specified identity repository to determine if a user’s credentials are valid.

Federation Service SPI

The com.sun.identity.federation.services package provides plug-ins for customizing the Liberty ID-FF profiles implemented by OpenSSO Enterprise. The com.sun.identity.federation.plugins package provides an interface that can be implemented to perform user specific processing on the service provider side during the federation process. The com.sun.identity.saml2.plugins package provides the SAML v2 service provider interfaces (SPI). The com.sun.identity.wsfederation.plugins package provides the WS-Federation based SPI.

Identity Repository Service SPI

The com.sun.identity.idm package contains the IdRepo interface that defines the abstract methods which need to be implemented or modified by Identity Repository Service plug-ins. The com.sun.identity.plugin.datastore package contains interfaces that search for and return identity information such as user attributes and membership status for purposes of authentication.

Policy Service SPI

The com.sun.identity.policy.interfaces package provides interfaces for writing custom policy plug-ins for Conditions, Subjects, Referrals, Response Providers and Resources.

Service Configuration Plug-in

The com.sun.identity.plugin.configuration package provides interfaces to store and manage configuration data required by the core OpenSSO Enterprise components and other plug-ins.

Note –

In previous releases, the functionality provided by the Service Configuration plug-in was known as the Service Management Service (SMS).

Chapter 3 Simplifying OpenSSO Enterprise

This chapter contains information on the usability and manageability features of OpenSSO Enterprise. It includes the following sections:

Installation and Configuration

Previous versions of Sun Microsystems' access management server product were built for multiple hardware platforms, and different web containers. The complexity of this development process led to the release of separate platform and container patches. To alleviate this extraneous development, OpenSSO Enterprise is now available as a single ZIP file which can be downloaded, unzipped, and quickly deployed; there will be no separate installations for each hardware platform. The ZIP file will contain the full OpenSSO Enterprise web archive (WAR), layouts for the generation of other specific WARs, libraries, the Java API reference documentation, and samples. (Tools for use with OpenSSO Enterprise, including the command line interfaces and policy and authentication agents, can be downloaded separately.) Figure 3–1 illustrates the process for deployment, installation and configuration of a new OpenSSO Enterprise WAR and a patched WAR.

Figure 3–1 Customizing, Patching and Deploying the OpenSSO Enterprise WAR

Diagram illustrating the customization, patching, and deployment of the OpenSSO Enterprise WAR

Note –

When patched, a full patched version of the OpenSSO Enterprise WAR will be included in the download, assuring that there is always a single download to get the latest bits.

The intent of this new process is to allow the administrator to download OpenSSO Enterprise and deploy it on the container or platform of choice, using the web container's administration console or command line interfaces. After the initial launch of the deployed WAR, the user is directed to a JavaServer Page (JSP) called the Configurator that prompts for configuration parameters (including, but not limited to, the host name, port number, URI, and repositories), provides data validation for the parameter values to prevent errors, and eliminates post-installation configuration tasks. Once successfully configured, any further changes to the configuration data store must be made using the OpenSSO Enterprise console or command line interfaces.

Note –

When deploying OpenSSO Enterprise against an existing legacy installation, the Directory Management tab will be enabled in the new console.

For more information including a directory layout of the ZIP, see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Configuration Data Store

OpenSSO Enterprise has implemented an embedded configuration data store to replace the AMConfig.properties and serverconfig.xml files which had been the storage files for server configuration data. Previously, each instance of the server installed had separate configuration files but now when deploying more than one instance of OpenSSO Enterprise, all server configuration data is stored centrally, in one configuration data store per instance. After the OpenSSO Enterprise WAR is configured, a sub configuration is added under the Platform Service to store the data and a bootstrap file that contains the location of the configuration data store is created in the installation directory. Figure 3–2 illustrates how OpenSSO Enterprise is bootstrapped.

Figure 3–2 Bootstrapping OpenSSO Enterprise

Diagram illustrating the use of file to bootstrap OpenSSO Enterprise

Post installation, the configuration data can be reviewed and edited using the administration console or the ssoadm command line interface. For more information see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide and the Sun OpenSSO Enterprise 8.0 Administration Guide.

Note –

OpenSSO Enterprise also supports an LDAPv3–based solution that uses an existing directory server for configuration data storage. This is configured during installation. Supported directories include Sun Java System Directory Server, Microsoft Active Directory, and IBM Tivoli Directory.

Centralized Agent Configuration

Policy agents function based on a set of configuration properties. Previously, these properties were stored in the AMAgent.properties file, residing on the same machine as the agent. With Centralized Agent Configuration, OpenSSO Enterprise moves most of the agent configuration properties to the configuration data store. Now agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Following is an explanation of the local and central agent configuration repositories.

Thus, Centralized Agent Configuration separates the agent configuration properties into two places: a bootstrapping file stored local to the agent and either a local (to the agent) or central (local to OpenSSO Enterprise) agent configuration data store. AgentBootstrap.properties is the bootstrapping file used by agent profiles configured locally or centrally. It is stored on the agent machine and indicates the local or central location from where the agent's configuration properties are retrieved. If the repository is local to the agent, it reads the configuration data from a local file; if the repository is remote, it fetches its configuration from OpenSSO Enterprise. Choosing Centralized Agent Configuration provides an agent administrator with the means to manage multiple agent configurations from a central place using either the OpenSSO Enterprise console or command line interface. Figure 3–3 illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.

Figure 3–3 Retrieving Agent Configuration Data

Illustration depicting the retrieval of agent configuration data

An agent fetches its configuration properties periodically to determine if there have been any configuration changes. Any agent configuration changes made centrally are conveyed to the affected agents which will react accordingly based on the nature of the updated properties. If the properties affected are hot swappable, the agent can start using the new values without a restart of the underlying agent web container. Notification of the agent when configuration data changes and polling by the agent for configuration changes can be enabled. Agents can also receive notifications of session and policy changes.

Note –

A agent configuration data change notification does not contain the actual data; it is just a ping that, when received, tells the agent to make a call to OpenSSO Enterprise and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.

For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.

Common Tasks Wizard

OpenSSO Enterprise has implemented a Common Tasks tab that allows an administrators to create federation-based objects using console wizards. The wizards offer simplified provider configuration with metadata input using the URL http://host-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp or a metadata file. The following things can be done using a Common Task wizard:

Figure 3–4 is a screen capture of the Common Tasks wizard.

Figure 3–4 The Common Tasks Wizard

Screen capture of the Common Tasks Wizard

For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.

Third Party Integration

OpenSSO Enterprise makes it easy to integrate with third-party software. Plug-ins and other tools have been developed to ease the integration of OpenSSO Enterprise and the following products.

For more information, see Sun OpenSSO Enterprise 8.0 Integration Guide.

Sun Java System Identity Manager

Sun Java System Identity Manager enables an enterprise to manage and audit access to accounts and resources as well as distribute the access management overhead. A OpenSSO Enterprise policy agent is deployed on the Identity Manager machine to regulate access to the Identity Manager server. By mapping Identity Manager objects to OpenSSO Enterprise users and resources, you may significantly increase operational efficiency. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 1, Integrating Sun Identity Manager , in Sun OpenSSO Enterprise 8.0 Integration Guide.

Computer Associates SiteMinder

Computer Associates SiteMinder (originally developed by Netegrity) is one of the industry's first SSO products — used in a majority of legacy web SSO deployments to protect their intranet and external applications. OpenSSO Enterprise provides the tools for SSO integration with SiteMinder in both intranet and federated environments. They include a SiteMinder Agent and a OpenSSO Enterprise Authentication Module for SiteMinder. They can be found in the integrations/siteminder directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 2, Integrating CA SiteMinder, in Sun OpenSSO Enterprise 8.0 Integration Guide.

Oracle Access Manager

Oracle Access Manager (originally developed by Oblix) is an SSO product with many of the same features as Sun OpenSSO Enterprise and Computer Associates SiteMinder. Oracle Access Manager can be deployed to protect both internal and external applications. OpenSSO Enterprise provides an Oracle Agent and a custom OpenSSO Enterprise Authentication Module for Oracle Access Manager. They can be found in the integrations/oracle directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 3, Integrating Oracle Access Manager, in Sun OpenSSO Enterprise 8.0 Integration Guide.

Chapter 4 Deploying OpenSSO Enterprise

Sun OpenSSO Enterprise can be deployed in a number of ways. This chapter contains two sample deployment architectures.

For more information, see Sun OpenSSO Enterprise 8.0 Deployment Planning Guide.

Deployment Architecture 1

Figure 4–1 illustrates one deployment architecture for Sun OpenSSO Enterprise.

Figure 4–1 Sample Deployment Architecture 1

Graphic illustrating a sample deployment architecture.

Deployment Architecture 2

Figure 4–2 illustrates another deployment architecture for Sun OpenSSO Enterprise.

Figure 4–2 Sample Deployment Architecture 2

Graphic illustrating a second sample deployment architecture.