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 JavaTM 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.
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 .
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.
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.
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.
The following figure describes one possible SAMLv2 transaction.
The following figure describes the component interactions in an HTTP redirect-based single logout transaction.
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 |