Example Access Manager Logical Architectures

This section provides the following scenarios as examples of logical architectures for Access Manager solutions, including:

• Access Manager Web Deployment

• Access Manager Multiple Server Deployment

• Java Application Deployment

• Access Manager Session Failover Deployment

• Access Manager and Portal Server Deployment

• Federation Management, SAML, and Web Services

Access Manager Web Deployment

A common Access Manager deployment has a web browser accessing an application or resource deployed on a web server. The application or resource is protected by Access Manager and communicates with it using a policy agent also installed on the web server. The web server might also have the Access Manager SDK deployed. This scenario does not restrict the number of web servers on a machine or the instances of Access Manager deployed on multiple machines. For example, a machine might have multiple web servers, each deploying an instance of Access Manager. Similarly, multiple web servers might also be running on different machines, each deploying an instance of Access Manager.

The following figure shows an Access Manager web deployment scenario.

Figure 4–1 Access Manager Web Deployment

Access Manager Multiple Server Deployment

An Access Manager multiple server deployment has two or more host servers, with one or more instances of Access manager installed on each host server. Each Access Manager instance accesses the same Directory Server. You can configure the Directory Server instances in a multiple master replication (MMR) configuration, if required for your deployment.

The Access Manager instance installed on the first host server points to an instance of Directory Server. During installation using the Java ES installer, you can choose an existing Directory Server with or without an existing directory information tree (DIT), depending on your deployment.

You install subsequent instances of Access Manager on other host servers by running the Java ES installer, with the Access Manager instance pointing to a Directory Server with an existing DIT. Access Manager then does not write any information to Directory Server because it recognizes the Directory Server as already existing.

The following figure shows multiple Access Manager instances on different host servers with one Directory Server.

Figure 4–2 Multiple Access Manager Instances With One Directory Server

For more information, see Chapter 3, Deploying Multiple Access Manager Instances, in Sun Java System Access Manager 7.1 Postinstallation Guide.

Java Application Deployment

Another common scenario for Access Manager allows Java applications to access an Access Manager SDK installed directly on the server where they are deployed. This scenario requires an additional server with an instance of a web container (such as Sun Java System Web Server or Sun Java System Application Server) running at least one instance of Access Manager. This server also maintains the information to provide single sign-on (SSO). The following figure shows a Java application deployment scenario.

Figure 4–3 Java Application Deployment

Access Manager Session Failover Deployment

Access Manager provides a web container independent session failover implementation using Sun Java System Message Queue (Message Queue) as the communications broker and the Berkeley DB as the default session store database. Access Manager session failover retains a user’s authenticated session state in the event of a single hardware or software failure, which allows the user’s session to fail over to a secondary Access Manager instance without losing any session information or requiring the user to login again.

Overview of Access Manager Session Failover

Access Manager 7.1 session failover includes these components:

• Two or more instances of Access Manager 7.1, with each instance running on a supported web container on two or more host servers.

• Message Queue broker cluster, which manages the session messages between the Access Manager instances and the session store database.

• Berkeley DB (http://www.oracle.com/database/berkeley-db.html), as the session store database. The Berkeley DB client daemon is amsessiondb.

Access Manager session failover follows the Message Queue publish/subscribe (topic destinations) delivery model:

1. When a user initiates, updates, or ends a session, Access Manager publishes a session creation, update, or deletion message to the Message Queue broker cluster.

2. The Berkeley DB client (amsessiondb) subscribes to the Message Queue broker cluster, reads the session messages, and stores the session operations in the database.

If an Access Manager instance fails due to a single hardware or software problem, a user’s session associated with that instance fails over to a secondary Access Manager instance, as follows:

1. The secondary Access Manager instance publishes a query request to the Message Queue broker cluster for the user’s session information.

2. The Berkeley DB clients (amsessiondb) subscribing to the same session request topic on the Message Queue broker cluster receive the query request retrieve the corresponding entry from the session database, and then publish the user’s session information to the Message Queue broker cluster with the session response topic.

3. The secondary Access Manager instance subscribing to the session response topic receives the response with the user’s session and continues without losing any session information or the user having to login again.

If a Message Queue broker fails, Access Manager continues to operate in non-session failover mode. When the Message Queue broker is later restarted, Access Manager returns to session failover mode.

For more information about the Message Queue components and the publish/subscribe delivery model, see the Sun Java System Message Queue 3.7 UR1 Technical Overview.

Session Failover Deployment Scenario

The following figure shows a basic scenario with two host servers, each running an Access Manager instance on a web container, the Message Queue broker cluster, and the Berkeley DB client (amsessiondb). The load balancer distributes client requests to the Access Manager instances. Both Access Manager instances access the same Directory Server (not shown in the figure).

Figure 4–4 Access Manager Session Failover Basic Deployment Scenario

You can add additional sites similar to the one shown in the figure, with each site accessing the same Directory Server. Session failover, however, occurs only for the Access Manager instances within a site; cross-site session failover is not supported in the current release.

For more information, see Chapter 6, Implementing Session Failover, in Sun Java System Access Manager 7.1 Postinstallation Guide.

Access Manager and Portal Server Deployment

For the Java Enterprise System 5 release, you can deploy Access Manager with Portal Server either on the same physical server or on multiple servers.

Installation on a Single Server

In this scenario, Access Manager and Portal Server are installed on the same physical server. You must also install or have access to an installed version of Directory Server, which can be either on the same server or a remote server.

To install these components, run the Java Enterprise System installer in a single session and make these selections:

• On the Component Selection panel, select these products and subcomponents:

  • Under Communication & Collaboration Services, select Portal Server.

  • Under Directory & Identity Services, select Access Manager 7.1 and its subcomponents:

    • Identity Management and Policy Services Core

    • Access Manager Administration Console

    • Common Domain Services for Federation Management

    • Access Manager SDK

      By default, when you select Portal Server, the installer installs only the Access Manager SDK, so you must specifically check the other subcomponents.

    Install and configure one of the following web containers:

  • Sun Java System Application Server

  • Sun Java System Web Server

Installation on Multiple Servers

In this scenario, Portal Server will access Access Manager on a local server from a remote server. You must also install or have access to an installed version of Directory Server, which can be either on a local or remote server:

• On the local server, install Access Manager and a web container. You must install and configure the components on this server before you install and configure the components on the remote server.

• On the remote server, install Portal Server and the Access Manager SDK. You do not need to select the other Access Manager subcomponents on the remote server.

For more information about deploying Access Manager and Portal Server, see the Sun Java System Portal Server 7.1 Deployment Planning Guide.

Federation Management, SAML, and Web Services

In 2001, Sun Microsystems joined with other companies to form the Liberty Alliance Project. This project defines standards for developing identity-based infrastructures, software, and web services.

Initially, Access Manager implemented the Liberty Identity Federation Framework (Liberty ID-FF) specification, which comprises a framework for account federation and single sign-on (SSO). Subsequent releases of Access Manager added new features, as defined in version 1.2 of the Liberty ID-FF specifications and the version 1.0 specifications of the Liberty Identity Web Services Framework (Liberty ID-WSF).

The Liberty ID-WSF framework defines a web services stack that you can use to support the Liberty Alliance Project business model. Example services include a personal profile service, discovery service, authentication service, and SOAP binding service. These web services leverage the Liberty ID-FF for principal authentication, federation, and privacy protections.

Access Manager also implements a Security Assertion Markup Language (SAML) service to exchange security information. Both the SAML 1.0 and 1.1 specifications are supported.

For more information, see the Sun Java System Access Manager 7.1 Federation and SAML Administration Guide. This guide includes an introduction to the specifications and information about how Access Manager has implemented them. It also includes configuration information, use cases, and summaries of the application programming interface (API).

Sun Java System Federation Manager

Sun Java System Federation Manager 7.0 2005Q4 is a lightweight server application that helps companies to quickly build interoperable identity and authentication services based on the Liberty Alliance Project specifications. These services work with and complement existing or newly deployed federation technologies, such as web access management solutions and authentication authorities.

You can use Federation Manager to build a reusable, standards-based framework to exchange security assertions, user attributes, and policies across a distributed network of partners. Federation Manager is a standalone product that can work with any Liberty or SAML-compliant product. You do not have to install Access Manager in order to use Federation Manager. For more information, see the following documentation collection:

http://docs.sun.com/coll/1321.1

Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services

The Sun Java System Access Manager Policy Agent 2.2 for Sun Java System Application Server 9.0 / Web Services plugs into Sun Java System Application Server Platform Edition 9.0 to provide message-level security and support for both Liberty Alliance Project token profiles and Web Services-Interoperability Basic Security Profiles (WS-I BSP). This agent provides both an HTTP authentication agent and a SOAP authentication agent and uses Access Manager 7.1 for all authentication decisions.

For more information, including the installation procedure for the agent, see the link to the Sun Java System Access Manager Policy Agent 2.2 Guide for Sun Java System Application Server 9.0/Web Services.

Sun Java System Application Server Platform Edition 9.0 is not a Java Enterprise System 5 component. For more information, see the following documentation collection:

http://docs.sun.com/coll/1343.3