Chapter 1 Key Features, System Architecture, and Process Flow

This document provides detailed instructions for enabling Security Assertion Markup Language (SAML) version 2 in a federated environment. You can adapt these instructions to suit your company's needs.

Sun Java^TM System Access Manager and Federation Manager implement two important sets of standards: Identity Federation Framework (ID-FF) , adopted by the Liberty Alliance Project, and SAML specifications adopted by the OASIS committee. These implementations enable business partners to form a Circle of Trust. The Circle of Trust enables individuals and organizations to easily conduct network transactions while protecting the individual's identity. For detailed information about the Liberty Alliance Project and about Access Manager implementations of federated identity and SAML protocols, see Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.

1.1 Key Features

The setup instructions contained in this document use a specific environment to illustrate how to set up federation and SAMLv2 protocols. This environment is designed to highlight the following key features:

• Access Manager servers are deployed in high-availability mode.

• Federation Managers are deployed in high-availability mode and configured to with work with Sun Java System Directory Server instead of the default flat files.

• XML Signing is enabled for all SAMLv2 protocols.

• SAML2 URL end points are exposed through load balancers with SSL termination.

• Web Policy Agents and J2EE Policy Agents are deployed in front of the Federation Manager instances, and the policy agents work only in single sign-on (SSO) mode .

1.2 System Architecture

In this system architecture, a Service Provider and a Identity Provider form a circle of trust in order to exchange user authentication information using SAMLv2. For these instructions, the circle of trust contains one identity provider, a service that maintains and manages identity information. Once the circle of trust is established, single sign-on is enabled between both providers.

The Service Provider domain is siroe.com. In this deployment, two Federation Managers are load-balanced for high availability, and each is configured for the SAMLv2 protocol. Each Federation Manager server uses a Directory Server user instance for user data.

The Identity Provider domain is example.com. Two Access Manager servers are configured for the SAMLv2 protocol and load-balanced for high availability.

Table 1–1 Software Products Used in Examples

Component	Versions
Sun Java Access Manager	7.0 JES 2005Q4
Sun Java Access Manager Patch	7.0_Patch_5
Sun Java Directory Server	5.2 JES 2005Q4
Sun Java Directory Server Patch	5.2_Patch_4
Sun Java System Federation Manager	7.0
Sun Java Web Server	6.1SP5 JES 2005Q4
Web Policy Agent (for Sun Java WebServer v6.1)	2.2
Web Policy Agent Patch	HotPatch_5
Sun Java Application Server	8.1 JES 2005Q4
Sun Java Application Server Patch	Enterprise Ed 8.1 2005Q1
J2EE Policy Agent (for Sun Java Application server 8.1 2005Q1)	2.2
SAML plug-in	2
SAML v2 plug-in Patch	2
Sun Solaris	10, Update 5

Figure 1–1 on the next page illustrates the Service Provider Site described in this document, Deployment Example 2: Federation Using SAMLv2.

Figure 1–1 Physical Architecture for Federation Using SAMLv2

The Identity Provider Site shown here is a subset of a larger deployment example described in a companion document, Deployment Example: Access Manager Load Balancing, Distributed Authentication, and Session Failover. Use the two companion documents together to build both the Service Provider Site and the Identity Provider Site. See 2.12 Obtaining Instructions for Deploying the Identity Provider Site.

Figure 1–2 From Access Manager Load Balancing, Distributed Authentication UI, and Session Failover

To set up the Identity Provider Site, see Deployment Example: Access Manager Load Balancing, Distributed Authentication, and Session Failover. Follow the detailed instructions for setting up the Directory Servers, the Access Manager Servers, their respective load balancers, and session failover. For the Federation Using SAMLv2 deployment example, it is not necessary to implement the Distributed Authentication UI or the Protected Resources and policy agents pictured here.

1.3 Illustrated Protocol Flows

The following figure describes one possible SAMLv2 transaction.

Figure 1–3 SSO Protocol Flow

The following figure describes the component interactions in an HTTP redirect-based single logout transaction.

Figure 1–4 Single Logout Protocol Flow

1.4 Firewall Rules

Set up firewalls to allow traffic to flow as described in the following table.

Table 1–2 Firewall Rules

From	To	Protocol	Traffic Type
Internet User	LoadBalancer-9:3443	HTTPS	Internet metadata URLs access and user authentication at the Service Provider site
Internet User	LoadBalancer-10:4443	HTTPS	Service Provider application access
Internet User	LoadBalancer-11:6443	HTTPS	Service Proivder application access
Internet User	LoadBalancer-3:9443	HTTPS	Internet metadata URLs access and user authentication at the Identity Provider site
LoadBalancer-10:4080	ProtectedResource-3:1080	HTTP	Service Provider application access by user
LoadBalancer-10:4080	ProtectedResource-4:1080	HTTP	Service Provider application access by user
LoadBalancer-11:5080	ProtectedResource-3:2080	HTTP	Service Provider application access by user
LoadBalancer-11:5080	ProtectedResource-4:2080	HTTP	Service Provider application access by user
Load Balancer-3:7070	AccessManager-1:8080	HTTP	Load balancer redirection to Access Manager
Load Balancer-3:7070	AccessManager-2:1080	HTTP	Load balancer redirection to Access Manager
LoadBalancer-9:1080	FederationManager-1:8080	HTTP	Load balancer redirection to Federation Manager
LoadBalancer-9:1080	FederationManager-2:8080	HTTP	Load balancer redirection to Federation Manager