Chapter 9 Enabling Web Services Federation Between Active Directory Federation Service and OpenSSO Enterprise

Sun OpenSSO identity federation is based on the Liberty Alliance specification which includes uses the Identity Federation Framework (ID-FF) and SAMLv2 protocols. Microsoft Active Directory Federation Service (ADFS) is based on the Web Services Architecture specification which uses the Microsoft Web Browser Federated Sign-On (MS-MWBF) and Web Services Federation (WS-Federation) protocols.

OpenSSO Enterprise provides support for MS-MWBF so that single sign-on can work among OpenSSO and ADFS-based environments. This interoperability is achieved by creating trust relationships between different security realms, and exchanging security tokens using the Web Services Federation protocol.

This chapter provides information about enabling web services federation between ADFS-based and OpenSSO Enterprise. The following topics are contained in this chapter:

• Analyzing the Deployment Architecture

• Considering Assumptions, Dependencies, and Constraints

• Understanding Typical Business Use Cases

• Setting up and Configuring Single Sign-On Among OpenSSO Enterprise and ADFS Environments

• Evaluating Benefits and Tradeoffs

• Finding More Information

Analyzing the Deployment Architecture

This deployment consists of two different environments:

• An ADFS-based environment

• A load-balanced, multi-server OpenSSO Enterprise environment

This deployment illustrates the interoperability between both environments, and also illustrates the added constraints of a multi-server OpenSSO Enterprise solution.

The ADFS environment is derived entirely from Step-by-Step Guide for Active Directory Federation Services. In this deployment, a web browser (client) interacts with a web resource to request a security token from a requestor Identity Provider or Security Token Service. The request is communicated through a resource partner such as an Identity Provider or Security Token Service.

OpenSSO Enterprise can play the role of either resource (Service Provider) or requestor (Identity Provider). The following figure illustrates OpenSSO Enterprise acting as a Service Provider, known in the MS-MWBF specification as a Resource Identity Provider/Security Token Service (Resource IP/STS). The business use case for this architecture is described in OpenSSO Enterprise Acts as Service Provider.

Figure 9–1 Deployment Architecture for ADFS Integration with OpenSSO Enterprise Acting as Service Provider

The following figure illustrates OpenSSO Enterprise acting as an Identity Provider, known in the MS-MWBF specification as a Requestor Identity Provider/Security Token Service (Requestor IP/STS). The business use case for this architecture is described in OpenSSO Enterprise Acts as Identity Provider.

Figure 9–2 Deployment Architecture for ADFS Integration with OpenSSO Enterprise Acting as Identity Provider

Considering Assumptions, Dependencies, and Constraints

The following are issues you must resolve before you can enable Web Service Federation among ADFS and OpenSSO Enterprise.

Assumptions and Dependencies

• The ADFS-based environment is already set up and running.

  This chapter is based on the assumption that you are proficient in setting up and ADFS-based environment as described in

• OpenSSO Enterprise is already deployed.

  This is a prerequisite for configuring OpenSSO Enterprise to act as an Identity Provider or Service Provider in a circle of trust.

Constraints

• The configuration requirements documented in this chapter include tools and procedures that are not appropriate for a production deployment.

  Examples are: the use of self-signed certificates, the modification of host files, local time synchronization, and so forth. These are described for illustration purposes only. For production deployments, you must use different solutions suitable for your environment.

• OpenSSO Enterprise supports WS-Federation as it relates to its support within the ADFS boundaries. Parts of the WS-Federation specification not required by ADFS may not be supported in this release.

Understanding Typical Business Use Cases

This chapter describes two typical business use cases:

• OpenSSO Enterprise Acts as Service Provider

• OpenSSO Enterprise Acts as Identity Provider

OpenSSO Enterprise Acts as Service Provider

In this use case, Company A is acquired by Company B. The intranets for both companies have been merged, but much of the network infrastructure remains as though they were still two separate entities. Company A maintains an Active Directory domain, and Company B maintains an OpenSSO Enterprise single sign-on infrastructure in its own domain.

In order for Company A employees to access some internal applications available to Company B employees, a trust relationship is created between the Company A domain and the Company B domain. The trust relationship is created using the Web Services Federation protocol. Company A employees, signed on to their Microsoft Windows computers, can now navigate to the Company B paycheck application by using a Web Services Federation secure token.

OpenSSO Enterprise Acts as Identity Provider

In this use case, Company B wants to offer its employees a new online collaborative environment based on Microsoft SharePoint Services. The collaboration solutions is an outsourced model where Company C provides dedicated SharePoint Services to its customers. In order to provide single sign-on to the Company B employees, Company C leverages the federation services provided by ADFS. A trust relationship is created between created between the Company B OpenSSO Enterprise Identity Provider and the Company C Resource Identity Provider /Security Token Service.

Setting up and Configuring Single Sign-On Among OpenSSO Enterprise and ADFS Environments

This chapter provides high-level deployment information for setting up and configuring single sign-on among OpenSSO Enterprise and ADFS environments. For detailed information, see the Microsoft Administering Active Directory Federation Services Guidehttp://technet.microsoft.com/en-us/library/cc736337.aspx for instructions on configuring Resource and Account Partners. See the Sun OpenSSO Enterprise 8.0 Administration Guide for information about using the ssoadmin command or administration console to generate metadata, create a circle of trust and import entities.

Enabling WS-Federation between an ADFS environment and an OpenSSO Enterprise environment involves exchanging metadata to enable a trust relationship. Prior to this, the following requirements must be met:

• All communications between WS-Federation components must be made over SSL.

  ADFS does not perform an HTTP POST of a WS-Federation RSTR to a non-HTTPS URL.

• Name resolution is based on host files. Therefore, host files must be appropriately updated with host names and IP addresses.

• The ADFS environment can rely on DNS.

• All servers must be time-synchronized.

  This is essential to proper token validation.

• Token signing certificates must be created and imported for both ADFS and OpenSSO Enterprise endpoints.

  This process is automated in ADFS, but requires the use of the keytool command for OpenSSO Enterprise.

The creation of a trust relationship relies on the exchange of metadata between the parties involved. Importing this information is straightforward and can be done through the GUI on the ADFS side. On the OpenSSO Enterprise side, to import the information you can use the ssoadmin command-line utility or the ssoadmin.jsp.

Configuring OpenSSO Enterprise to Act as a Service Provider

This use case requires that the ADFS server in the Company B domain be configured to recognize the Company A OpenSSO Enterprise endpoint as a Resource Partner. The Company B ADFS server must be recognized as a valid Identity Provider in a circle of trust that includes the Company A OpenSSO Enterprise server as a Service Provider.

In the OpenSSO Enterprise environment:

Use the ADFS snap-in to create a new Resource Partner. The new Resource Partner must be defined using the proper name and endpoint URL.

In the ADFS-based environment:

• Create metatdata and extended metadata files to define the Company B ADFS server as the Identity Provider, and the Company A OpenSSO Enterprise server as the Service Provider in a WS-Federation protocol paradigm.

• Create a new circle of trust and import each Identity Provider and Service Provider to belong to this circle of trust.

This configuration currently works only if a user account with the same UPN is created in both the ADFS domain and the OpenSSO Enterprise server. This is a major constraint.

Configuring OpenSSO Enterprise to Act as an Identity Provider

This use case requires that the ADFS server in the Company C domain to be configured to recognize the Company A server as an Account Partner. The Company A server must be configured to recognize the Company C ADFS server as a Service Provider in a circle of trust.

In the OpenSSO Enterprise environment:

• Configure a new keystore for the token signing certificate, or leverage the one provided by the container.

• Create metadata and extended metadata files to define the Company A OpenSSO Enterprise server as the Identity Provider.

• Create metadata and extended metadata files to define the Company B ADFS server as the Identity Provider, and the Company C ADFS server as the Resource Provider in a WS-Federation protocol paradigm.

• Create a new circle of trust, and import each Identity Provider and Service Provider to belong to this new circle of trust.

In the ADFS environment:

• Create a new Account Partner using the ADFS snap-in.

  The proper name and endpoint URL must be defined.

• Import the OpenSSO Enterprise token signing certificate (DER format). For detailed information, see the .Sun OpenSSO Enterprise 8.0 Administration Guide

Evaluating Benefits and Tradeoffs

The following information helps you decide whether enabling Web Services Federation between ADFS and OpenSSO Enterprise is suitable for your needs.

Benefits

Using OpenSSO Enterprise as Service Provider

You are likely to leverage WS-Federation in a mixed environment involving Windows domains and heterogeneous web service environments. In such cases, using WS-Federation eliminates the need to complete the complicated setups involved with Desktop SSO (IWA, Kerberos, etc.). This simplifies the integration of web services in the ADFS-based environments.

Using OpenSSO Enterprise as Identity Provider

The immediate benefit is the single sign-on to SharePoint Services from non-ADFs environments. This can be extended to pure claims-based applications residing inside the Resource Partner's domain.

Tradeoffs

The main drawback to using WS-Federation is that currently only limited support or configuration help is offered for ADFS claims within OpenSSO Enterprise. For example, the Microsoft Administering Active Directory Federation Services Guidehttp://technet.microsoft.com/en-us/library/cc736337.aspx depicts the use of group claims and their mapping between realms. The use of group claims eliminates the need to map user principals information from one realm to the next in a federated environment. These claims, based on group memberships, have not been tested in this deployment example configuration.

Finding More Information

Specifications

• Microsoft Web Browser Federated Sign-on Protocol Specification

  http://msdn.microsoft.com/en-us/library/cc236471.aspx

• Web Services Federation Language

  http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf

Guides and Overviews

• Understanding WS-Federation

  http://msdn.microsoft.com/en-us/library/bb498017.aspx

• Overview of ADFS

  http://technet.microsoft.com/en-us/library/cc755828.aspx

• Microsoft Administering Active Directory Federation Services Guide

  http://technet.microsoft.com/en-us/library/cc736337.aspx

Case Study

OpenSSO, WS-Federation & IBM DataPower by Joachim Andre

https://opensso.dev.java.net/files/documents/3676/79106/OpenSSO-WS-Fed-DataPower-FederationPoC.pdf